| Name of Product/Version | Thesaurus Linguae Graecae® (TLG®) |
|---|---|
| Report Date | October 2026 |
| Product Description | A web-based scholarly research platform (JSP/PHP pages with supporting JavaScript modules) serving an international audience, including full-text browsing, canon/lemma/author search and autocomplete, statistics with charts and geographic distribution maps, an on-screen Greek keyboard, and vocabulary/flashcard tools. |
| Contact Information | Email: tlg@uci.edu |
| Notes | |
| Evaluation Methods Used |
|
Standards/Guidelines
This report covers the degree of conformance for the following accessibility standard/guidelines:
| Standard/Guideline | Included in Report |
|---|---|
| Web Content Accessibility Guidelines (WCAG) 2.1 |
Level A (Yes) Level AA (Yes) Level AAA (No) |
Conformance Terminology
The terms used in the Conformance Level information are defined as follows:
- Supports
- The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
- Partially Supports
- Some functionality of the product does not meet the criterion.
- Does Not Support
- The majority of product functionality does not meet the criterion.
- Not Applicable
- The criterion is not relevant to the product.
- Not Evaluated
- The product has not been evaluated against the criterion. This can only be used in WCAG Level AAA criteria.
WCAG 2.1 Level A and AA Report
Table 1: Success Criteria, Level A
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| Principle 1: Perceivable | ||
| 1.1.1 Non-text Content (Level A) | Supports | Icon-only buttons and links receive an accessible name from a visually-hidden span; decorative icons carry aria-hidden="true". Charts and the geographic map are exposed as a canvas with role="img", named via aria-labelledby and described via aria-describedby, with an accompanying data table or detailed list. Map markers (10×10px) fall under the WCAG 2.5.8 exception because the detailed list provides an equivalent control. |
| 1.2.1 Audio-only and Video-only (Prerecorded) (Level A) | Supports | Two videos provided via YouTube are embedded in the site. |
| 1.2.2 Captions (Prerecorded) (Level A) | Supports | Two videos provided via YouTube have captions added. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) | Does Not Support | The site doesn’t contain any prerecorded synchronized media. Two videos produced in 2009 and made available via YouTube do not include Audio Description. |
| 1.3.1 Info and Relationships (Level A) | Supports | Semantic HTML and native landmarks (header, nav, main, footer, section, aside, form) are used ahead of ARIA roles; every landmark and focus target is anchored to a real heading; data tables are the documented accessible counterpart to every chart. |
| 1.3.2 Meaningful Sequence (Level A) | Supports | The page architecture uses semantic HTML and a logical heading/landmark structure. Interactive components are designed with programmatic structure and managed focus. |
| 1.3.3 Sensory Characteristics (Level A) | Supports | The site’s patterns identify controls and regions by text, headings, labels, and programmatic relationships rather than relying solely on visual position, shape, or color. |
| 1.4.1 Use of Color (Level A) | Supports | The site’s patterns do not rely on color alone to provide accessible names, states, or data access; charts have textual/data equivalents. |
| 1.4.2 Audio Control (Level A) | Not Applicable | The site does not have any automatically playing audio. |
| Principle 2: Operable | ||
| 2.1.1 Keyboard (Level A) | Supports | All features operable by a sighted mouse user are operable by keyboard and screen reader. Autocompletes, dialogs, on-screen keyboard, text links acting as buttons, and other custom controls include keyboard handling. |
| 2.1.2 No Keyboard Trap (Level A) | Supports | Focus traps are used only for unitary components and always provide an exit through Escape and/or a close button. |
| 2.1.4 Character Key Shortcuts (Level A) | Not Applicable | No single-character shortcut mechanism requiring deactivation/remapping is used on the site. Custom keyboard interactions use standard navigation and activation keys. |
| 2.2.1 Timing Adjustable (Level A) | Not Applicable | The site doesn’t contain any user time limits. |
| 2.2.2 Pause, Stop, Hide (Level A) | Not Applicable | The site doesn’t contain any moving, blinking, scrolling, or auto-updating content requiring these controls. |
| 2.3.1 Three Flashes or Below Threshold (Level A) | Supports | The site doesn’t contain any flashing content. |
| 2.4.1 Bypass Blocks (Level A) | Supports | A visually-hidden-focusable skip link targets #main-content (tabindex="-1") to move focus past repeated banner/navigation content into the main landmark and pages use landmarks and headings for efficient navigation. |
| 2.4.2 Page Titled (Level A) | Supports | The site provides unique, descriptive HTML page titles for every page. |
| 2.4.3 Focus Order (Level A) | Supports | Most pages follow a default flow of navigation for a meaningful focus order. Focus behavior is deliberately managed for searches, dialogs, accordions, traps, and pagination to preserve meaning and operability. |
| 2.4.4 Link Purpose (In Context) (Level A) | Supports | Visible link text serves as the accessible name; supplemental context (e.g., “see author in canon”, new-tab and PDF indicators) is appended in a hidden span after the visible text rather than replacing it. |
| 2.5.1 Pointer Gestures (Level A) | Not Applicable | No multipoint or path-based gesture is required in the site’s functionality. Equivalent native controls are used for interaction. |
| 2.5.2 Pointer Cancellation (Level A) | Supports | To ensure the user is able to cancel a pointer click, all clicking actions are handled via the click event, not other events like mousedown which activate the event on the down click and prevent cancellation. |
| 2.5.3 Label in Name (Level A) | Supports | Visible text is preserved within accessible names; when extra screen-reader context is needed, hidden text is appended rather than replacing the visible label. |
| 2.5.4 Motion Actuation (Level A) | Not Applicable | The site contains no functionality operated by device motion or user motion. |
| Principle 3: Understandable | ||
| 3.1.1 Language of Page (Level A) | Supports | The default human language of every page is programmatically defined using the lang="en" attribute on the root HTML element. |
| 3.2.1 On Focus (Level A) | Supports | The site’s focus model does not trigger unexpected context changes merely from receiving focus. |
| 3.2.2 On Input (Level A) | Supports | Search submissions use explicit submit events; in-place updates preserve focus and announce results. The site’s patterns avoid unexpected focus movement for ordinary input changes. |
| 3.3.1 Error Identification (Level A) | Supports | Input fields marked as required utilize the browser’s default alert mechanism; custom validation alerts use assertive live regions adjacent to the input and are programmatically associated through aria-describedby or show as browser alerts. |
| 3.3.2 Labels or Instructions (Level A) | Supports | Every form control has a real <label for>, visually hidden where the design shows only a placeholder; placeholder text is never used as a label substitute; required fields rely on the native required attribute; usage hints and legends are provided for composite controls where needed. |
| Principle 4: Robust | ||
| 4.1.1 Parsing (Level A) | Supports | For WCAG 2.0 and 2.1, the September 2023 errata update indicates this criterion is always supported. See the WCAG 2.0 Editorial Errata and the WCAG 2.1 Editorial Errata. |
| 4.1.2 Name, Role, Value (Level A) | Supports | A documented labeling ladder (visible text → <label for> → aria-labelledby → hidden span) governs accessible names; native elements are used ahead of ARIA roles; composite widgets (autocomplete combobox/listbox, accordion buttons with aria-expanded/aria-controls, modals with role="dialog" and aria-modal) carry complete ARIA wiring applied consistently by shared controllers. |
Table 2: Success Criteria, Level AA
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| Principle 1: Perceivable | ||
| 1.2.4 Captions (Live) (Level AA) | Not Applicable | The site doesn’t contain any live synchronized media. |
| 1.2.5 Audio Description (Prerecorded) (Level AA) | Not Applicable | The site doesn’t contain any prerecorded synchronized media. |
| 1.3.4 Orientation (Level AA) | Supports | The testing workflow includes responsive checks across screen sizes and orientations, and there are no orientation restrictions. |
| 1.3.5 Identify Input Purpose (Level AA) | Supports | Inputs have programmatic labels, type attributes, and autocomplete purpose tokens implemented for the inputs covered by this criterion. |
| 1.4.3 Contrast (Minimum) (Level AA) | Supports | The site’s WAVE workflow includes contrast evaluation and targets zero WAVE errors. Hidden accessibility text is intentionally given sufficient contrast to avoid WAVE errors. |
| 1.4.4 Resize text (Level AA) | Supports | The responsive testing process and semantic layout support resizing; there are no loss-of-function limitations. |
| 1.4.5 Images of Text (Level AA) | Supports | The site interface uses real DOM text for accessible names and interface content; no required images of text are identified. |
| 1.4.10 Reflow (Level AA) | Supports | Responsive checks are part of the per-page testing workflow, including mobile-specific variants at 400% zoom and 320px width. There are no exceptions of required two-dimensional scrolling for ordinary content. |
| 1.4.11 Non-text Contrast (Level AA) | Supports | WAVE contrast evaluation is part of the documented per-page compliance workflow. Controls also expose state programmatically rather than by visual styling alone. |
| 1.4.12 Text Spacing (Level AA) | Supports | The site uses semantic HTML and responsive layouts; all pages have been tested with the Stylus browser extension to meet the styling success criteria defined on w3.org. |
| 1.4.13 Content on Hover or Focus (Level AA) | Supports | Native title tooltips are used only as a redundant sighted-user affordance; the same information is present in the accessible name, so essential information is not available only on hover or focus. |
| Principle 2: Operable | ||
| 2.4.5 Multiple Ways (Level AA) | Supports | The site contains a sitemap located in the footer of every page. The sitemap lists out links to every single page of the site accessible to the user. |
| 2.4.6 Headings and Labels (Level AA) | Supports | Every landmark region and focus-shift target is anchored to a real, descriptive heading; dynamic labels are updated in-place via set_hidden_label() and set_author_input_label() rather than removed; ResultsHeading targets are reset to default text rather than emptied, since empty headings are treated as defects. |
| 2.4.7 Focus Visible (Level AA) | Supports | Keyboard and focus testing has been done ensuring the focused element is highlighted while navigating with the keyboard. The focus outline utilizes a double-color design of blue and gold to satisfy contrast requirements on different background colors. |
| Principle 3: Understandable | ||
| 3.1.2 Language of Parts (Level AA) | Supports | When content deviates from the page’s default English language, the change in human language is programmatically identified. Specifically, Ancient Greek text snippets and passages are wrapped in elements utilizing the lang="grc" attribute. |
| 3.2.3 Consistent Navigation (Level AA) | Supports | Shared header, sidebar navigation, main content, and footer components establish a consistent page navigation architecture; navigation regions receive unique labels, and identical link sets appearing on the same page intentionally share the same label. |
| 3.2.4 Consistent Identification (Level AA) | Supports | Recurring components (modals, icon-only buttons, accordions, autocompletes) follow single shared structures and JS lifecycles (e.g., generate_snippet_modal_html/initialize_snippet_modal, AutocompleteController) so equivalent functionality is identified consistently across the site. |
| 3.3.3 Error Suggestion (Level AA) | Supports | Errors are announced and associated with relevant inputs; users are free to enter any type of text on the majority of inputs for search features without strict rules or suggestions. General errors may be presented as browser alerts. |
| 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) | Supports | The site prevents data and legal errors by validating input formats using native HTML5 attributes (required, type, autocomplete) prior to submission. Users must explicitly confirm site license agreements via checkboxes and verify their accounts through double opt-in emails, and they can review or edit their personal data at any time via the Account Management page. No financial information is collected from users. |
| Principle 4: Robust | ||
| 4.1.3 Status Messages (Level AA) | Supports | The search lifecycle (searching → results → focus) is announced through the shared LiveStatus module without requiring a focus change for in-place updates; a zero-width-space toggle forces re-announcement of identical consecutive messages so repeated status text is not silently dropped by assistive technology. |
References
- W3C Web Content Accessibility Guidelines (WCAG) 2.1
- W3C WCAG 2 Level AA Conformance
- Information Technology Industry Council (ITI) VPAT
VPAT® is a registered service mark of the Information Technology Industry Council (ITI). This report is an Accessibility Conformance Report prepared using the VPAT WCAG Edition framework.
Legal Disclaimer
This report is based on the Thesaurus Linguae Graecae (TLG) project’s internal accessibility documentation, design standards, and documented implementation practices as of the stated report date. It reflects the project’s understanding of the accessibility features and limitations of the TLG website and does not constitute an independent accessibility audit or a guarantee of full compliance with applicable accessibility standards. Conformance levels designated as “Not Evaluated” should not be interpreted as indicating either compliance or noncompliance with the corresponding criteria.
While the TLG strives to maintain and improve the accessibility of its resources, variations in browsers, assistive technologies, and individual user environments may affect accessibility. Any identified accessibility issues will be reviewed and addressed as appropriate, taking into account their impact, technical feasibility, and available resources.