EliReview is a peer-review platform for higher-education courses. This report covers
the student-side web application at /student/*, including the
login page, student dashboard, course home page, and the five task flows: Writing,
Review, Reflection, Revision Plan, and Revision.
This evaluation used the following methods, combinations, and tools:
| Standard / Guideline | Included In Report |
|---|---|
| WCAG 2.2 Level A & AA | Yes |
| Revised Section 508 (2017) | Yes |
| EN 301 549 V3.2.1 (2021-03) | Yes |
| Criteria | Conformance Level | Remarks & Explanations |
|---|---|---|
| 1.1.1 Non-text Content (Level A) |
Supports | Eli Review provides text alternatives for non-text content. The product uses few images: logos carry the text alternative “Eli Review”, illustrative empty-state graphics carry descriptive alternatives, and decorative images are marked so that assistive technology skips them. Icon-only buttons carry text labels, and the review-results pie chart is presented alongside a text legend that lists each choice and its percentage. |
| 1.2.1 Audio-only and Video-only (Prerecorded) (Level A) |
Not Applicable | Eli Review’s student-side application contains no prerecorded audio-only or video-only content. This success criterion is not applicable. |
| 1.2.2 Captions (Prerecorded) (Level A) |
Not Applicable | Eli Review’s student-side application contains no prerecorded video with audio. This success criterion is not applicable. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) |
Not Applicable | Eli Review’s student-side application contains no prerecorded synchronized media. This success criterion is not applicable. |
| 1.2.4 Captions (Live) (Level AA) |
Not Applicable | Eli Review’s student-side application contains no live synchronized media. This success criterion is not applicable. |
| 1.2.5 Audio Description (Prerecorded) (Level AA) |
Not Applicable | Eli Review’s student-side application contains no prerecorded synchronized media. This success criterion is not applicable. |
| 1.3.1 Info and Relationships (Level A) |
Supports | Eli Review conveys information, structure, and relationships through semantic markup that assistive technology can read. Each page provides a single top-level heading and a main navigation landmark, and form controls, dialogs, icon buttons, and the text editor toolbar carry programmatic labels. |
| 1.3.2 Meaningful Sequence (Level A) |
Supports | Static analysis confirmed no CSS `order:` property used to visually reorder content out of DOM order across app/ (grep returned 0 matches). DOM order matches visual reading order. |
| 1.3.3 Sensory Characteristics (Level A) |
Supports | There is no copy text that references sensory characteristics. |
| 1.3.4 Orientation (Level AA) |
Supports | Eli Review does not restrict content to a single display orientation. The interface is a responsive web application that works in both portrait and landscape, and it does not lock orientation. |
| 1.3.5 Identify Input Purpose (Level AA) |
Supports | Eli Review identifies the purpose of input fields that collect information about the user. The login, sign-up, account settings, and password-reset forms set the autocomplete value WCAG defines for each field, including username, email, current password, new password, and given and family name, so browsers and assistive technology can offer accessible autofill. |
| 1.4.1 Use of Color (Level A) |
Supports | Eli Review renders all in-text links with a persistent underline so they are distinguishable from surrounding text without relying on color alone. Navigation links identified by their position, such as those in the app header, do not carry underlines. Status indicators pair color with an icon and a text label throughout the interface. |
| 1.4.2 Audio Control (Level A) |
Not Applicable | Eli Review’s student-side application contains no audio that plays automatically and no audio playback controls. This success criterion is therefore not applicable. |
| 1.4.3 Contrast (Minimum) (Level AA) |
Supports | We use Material 3 Design color tokens and have a set typography standard. |
| 1.4.4 Resize Text (Level AA) |
Supports | Text in Eli Review can be resized up to 200 percent using standard browser zoom without loss of content or functionality, in Chrome, Safari, and Firefox. |
| 1.4.5 Images of Text (Level AA) |
Supports | Eli Review does not use images of text to present content. The only images in the student interface are illustrations, each of which is either described with alternative text or marked as decorative. |
| 1.4.10 Reflow (Level AA) |
Supports | Eli Review reflows to a width of 320 CSS pixels, the equivalent of 400 percent zoom, without loss of content or functionality and without requiring horizontal scrolling, except for content such as data tables that require a two-dimensional layout. |
| 1.4.11 Non-text Contrast (Level AA) |
Supports | Eli Review uses Material Design 3 color tokens for its borders and status indicators. Interactive component borders — including text input outlines and segmented controls — use the outline token, which meets the 3 to 1 minimum in both light and dark themes. Lower-contrast borders on cards and dividers are supplementary to the content inside each component, which visually defines the boundary, making these borders decorative. Status fill colors that fall below 3 to 1 in isolation are always accompanied by a visible text label or icon and are not used as the sole indicator of state. |
| 1.4.12 Text Spacing (Level AA) |
Supports | Requires runtime text-spacing bookmarklet test. Theme uses unitless line-height (overridable) and px letter-spacing. |
| 1.4.13 Content on Hover or Focus (Level AA) |
Supports | All hover entities use a shared MUI component which has been customized to support (a) (b) and (c). Enforced by linting rules. |
| 2.1.1 Keyboard (Level A) |
Supports | All of Eli Review can be operated with a keyboard. Interactive controls, including the course cards on the dashboard and the expandable sections within task views, can be reached and activated using the keyboard alone. |
| 2.1.2 No Keyboard Trap (Level A) |
Supports | Keyboard focus is never trapped in Eli Review. Dialogs hold focus only while open, can be closed with the Escape key or a visible Close button, and return focus to the control that opened them when dismissed. |
| 2.1.4 Character Key Shortcuts (Level A) |
Supports | Keyboard shortcuts in WYSIWYG only apply to WYG when in focus. All other shortcuts are for focus control. |
| 2.2.1 Timing Adjustable (Level A) |
Supports | Eli Review does not impose time limits on completing tasks. There is no session-timeout countdown or other user-facing time limit in the student interface. |
| 2.2.2 Pause, Stop, Hide (Level A) |
Supports | The only moving content in Eli Review consists of activity and progress indicators, such as loading spinners and save indicators, which WCAG exempts from this requirement. Eli Review presents no decorative content that moves automatically for more than five seconds. |
| 2.3.1 Three Flashes or Below Threshold (Level A) |
Not Applicable | No blink, <marquee>, or strobing > 3Hz content in the codebase. Animations are all 1-2s cycles (loading rotation, breathing highlights). No flashing-light content. |
| 2.4.1 Bypass Blocks (Level A) |
Supports | Eli Review provides a skip-to-content link and a focusable main landmark on every page, allowing keyboard and screen-reader users to bypass the header and navigation and move directly to the page content. |
| 2.4.2 Page Titled (Level A) |
Supports | Every page in the student interface has a unique, descriptive title that identifies its purpose. |
| 2.4.3 Focus Order (Level A) |
Supports | No positive tabIndex values anywhere in app/ (only 0 and -1). DOM order matches visual order in audited components. autoFocus appears in only 4 sites, all justified (menu autoFocusItem, FindEvidenceDrawer search field on open, EliWYSIWYG entry, PDFSelectionPopup textarea). |
| 2.4.4 Link Purpose (In Context) (Level A) |
Partially Supports | Most links in Eli Review describe their purpose through their text or surrounding context. Two ‘Learn more’ links, in the writing editor and the revision upload area, do not convey their destination programmatically. Adding a descriptive accessible name to each would resolve this. |
| 2.4.5 Multiple Ways (Level AA) |
Supports | Eli Review provides more than one way to reach any task. Students can navigate from the dashboard through the course home and task list, from the global header, through the back control on each task page, or directly by URL. |
| 2.4.6 Headings and Labels (Level AA) |
Supports | Every page in the student interface has a unique title and a single top-level heading, and headings follow a logical, descriptive order that helps users locate content. |
| 2.4.7 Focus Visible (Level AA) |
Partially Supports | Most interactive components in Eli Review show a clear focus indicator when navigated by keyboard. The data table on the course home page removes the focus indicator from its column headers and cells, so keyboard users moving through the table cannot see which cell has focus. Restoring a visible focus style to the table would resolve this. |
| 2.5.1 Pointer Gestures (Level A) |
Supports | The only path-based gesture in Eli Review is the drag-and-drop used to gather evidence in the Reflection task, and it offers a full keyboard alternative: focus an item, lift it with Space or Enter, move it with the arrow keys, drop it with Space or Enter, and cancel with Escape, with spoken announcements at each step. |
| 2.5.2 Pointer Cancellation (Level A) |
Supports | Actions in Eli Review complete when the pointer is released rather than when it first makes contact, so a user can move away from a control before releasing to cancel the action. No function is triggered by a long press. |
| 2.5.3 Label in Name (Level A) |
Supports | Where a control has both visible text and a programmatic label, the accessible name contains the visible text, so speech-input users can activate controls by their visible names. A review of labeled controls across the student interface found no mismatches. |
| 2.5.4 Motion Actuation (Level A) |
Not Applicable | Eli Review’s student-side web application does not respond to device motion or user motion (no shake-to-undo, no tilt gestures, no orientation-as-input). This success criterion is not applicable. |
| 3.1.1 Language of Page (Level A) |
Supports | The language of every page in Eli Review is set to English in the page markup, so assistive technology can present content with the correct pronunciation. |
| 3.1.2 Language of Parts (Level AA) |
Supports | Eli Review presents content in a single language, English, and contains no passages in another language that would require a different language setting. |
| 3.2.1 On Focus (Level A) |
Supports | Moving focus to a control in Eli Review never causes an unexpected change of context. The one control that responds to focus expands content within the same component and does not navigate, open a dialog, or submit a form. |
| 3.2.2 On Input (Level A) |
Supports | Audited 76 onChange handlers across student/shared task components. None cause context changes (no navigation, no modal opens, no submits triggered by input change without explicit user action). Standard state-update + autosave-mutation pattern throughout. |
| 3.2.3 Consistent Navigation (Level AA) |
Supports | Navigation in Eli Review is rendered from a single shared header, so the logo, user menu, and notifications appear in the same place and order on every page. |
| 3.2.4 Consistent Identification (Level AA) |
Supports | Components that repeat across Eli Review, such as the Save, Submit, and Close buttons and icons, are built from shared components, so they look and are labeled the same way wherever they appear. |
| 3.3.1 Error Identification (Level A) |
Partially Supports | Most forms in Eli Review identify input errors in text next to the affected field. On a few forms, including login, password reset, and account settings, the error appears as general text that is not programmatically tied to the field, and an unanswered required peer-review question is reported only in a summary rather than on the field itself. Associating these messages with their fields would resolve this. |
| 3.3.2 Labels or Instructions (Level A) |
Partially Supports | Most fields in Eli Review have visible labels and instructions. A default programmatic label of ‘Text Input’ is currently applied to text fields and overrides their visible labels, so screen readers announce ‘Text Input’ instead of the intended label, and some peer-review free-text questions are not programmatically associated with their visible question text. Correcting the default label would resolve this across the product. |
| 3.3.3 Error Suggestion (Level AA) |
Partially Supports | Most error messages in Eli Review suggest how to correct the problem, such as the password rules and required-field prompts. A general account-settings error does not suggest a correction, and an unanswered required peer-review question offers a suggestion only in the summary rather than at the field. The login message is kept general by design for security. Adding field-level suggestions would resolve the remaining gaps. |
| 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) |
Supports | Each task submission in Eli Review is protected by a confirmation step. The Writing, Peer Review, Revision, and Reflection submissions each present a review-and-confirm dialog before work is submitted, and the Peer Review confirmation states that responses cannot be edited afterward. |
| 4.1.1 Parsing (Obsolete in WCAG 2.2) (Level A) |
Not Applicable | This success criterion was removed in WCAG 2.2 and is no longer applicable. It is retained here only for traceability against earlier WCAG and Section 508 references. Eli Review’s pages are well formed. |
| 4.1.2 Name, Role, Value (Level A) |
Partially Supports | Interactive user interface components provide a name, role, and state that assistive technology can determine: icon buttons, tabs, and loading indicators were reviewed and announce correctly. However, the student dashboard applies an aria-label to nine non-interactive paragraph elements (for example “Reflection Task Scenarios” and “Revision Task Scenarios”). aria-label is not supported on a paragraph with no role, so assistive technology drops these labels and the intended accessible names are not conveyed. Removing the aria-label and presenting the text visibly, or moving the label onto an element with an appropriate role, would resolve this. |
| 4.1.3 Status Messages (Level AA) |
Partially Supports | Success message for student tasks do get announced w/o focus change. Error messages were not tested across all interfaces. Further testing with NVDA would take from partially support to supports. |
| 2.4.11 Focus Not Obscured (Minimum) (Level AA) |
Supports | When a control receives keyboard focus in Eli Review, it remains at least partially visible and is not entirely hidden by other content. The interface uses a sticky header, and focused controls scroll into view beneath it rather than being covered. |
| 2.5.7 Dragging Movements (Level AA) |
Supports | The single drag interaction in Eli Review, used to order evidence in the Reflection task, offers a complete single-pointer and keyboard alternative: lift with Space or Enter, move with the arrow keys, drop with Space or Enter, and cancel with Escape, with spoken announcements. |
| 2.5.8 Target Size (Minimum) (Level AA) |
Partially Supports | Mostly supported across the site via Figma constraints. In some low screen real estate situations target size may be less than 24×24. |
| 3.2.6 Consistent Help (Level A) |
Supports | There is an ever present Contact Eli control in the Nav Menu. |
| 3.3.7 Redundant Entry (Level A) |
Supports | Eli Review does not ask users to re-enter information they have already provided in the same process. Sign-up reuses the email from the first step, and task flows automatically save and restore entered values as the user moves between steps. |
| 3.3.8 Accessible Authentication (Minimum) (Level AA) |
Supports | Signing in to Eli Review does not require solving a puzzle or any other cognitive function test. Login uses a username and password, password fields accept pasting and password-manager autofill, and there is no CAPTCHA or transcription challenge. |
| Criteria | Conformance Level | Remarks & Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Supports | Eli Review provides text alternatives for non-text content. The product uses few images: logos carry the text alternative “Eli Review”, illustrative empty-state graphics carry descriptive alternatives, and decorative images are marked so that assistive technology skips them. Icon-only buttons carry text labels, and the review-results pie chart is presented alongside a text legend that lists each choice and its percentage. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Not Applicable | Eli Review’s student-side application contains no prerecorded audio-only or video-only content. This success criterion is not applicable. |
| 1.2.2 Captions (Prerecorded) | Not Applicable | Eli Review’s student-side application contains no prerecorded video with audio. This success criterion is not applicable. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Not Applicable | Eli Review’s student-side application contains no prerecorded synchronized media. This success criterion is not applicable. |
| 1.2.4 Captions (Live) | Not Applicable | Eli Review’s student-side application contains no live synchronized media. This success criterion is not applicable. |
| 1.2.5 Audio Description (Prerecorded) | Not Applicable | Eli Review’s student-side application contains no prerecorded synchronized media. This success criterion is not applicable. |
| 1.3.1 Info and Relationships | Supports | Eli Review conveys information, structure, and relationships through semantic markup that assistive technology can read. Each page provides a single top-level heading and a main navigation landmark, and form controls, dialogs, icon buttons, and the text editor toolbar carry programmatic labels. |
| 1.3.2 Meaningful Sequence | Supports | Static analysis confirmed no CSS `order:` property used to visually reorder content out of DOM order across app/ (grep returned 0 matches). DOM order matches visual reading order. |
| 1.3.3 Sensory Characteristics | Supports | There is no copy text that references sensory characteristics. |
| 1.3.4 Orientation | Supports | Eli Review does not restrict content to a single display orientation. The interface is a responsive web application that works in both portrait and landscape, and it does not lock orientation. |
| 1.3.5 Identify Input Purpose | Supports | Eli Review identifies the purpose of input fields that collect information about the user. The login, sign-up, account settings, and password-reset forms set the autocomplete value WCAG defines for each field, including username, email, current password, new password, and given and family name, so browsers and assistive technology can offer accessible autofill. |
| 1.4.1 Use of Color | Supports | Eli Review renders all in-text links with a persistent underline so they are distinguishable from surrounding text without relying on color alone. Navigation links identified by their position, such as those in the app header, do not carry underlines. Status indicators pair color with an icon and a text label throughout the interface. |
| 1.4.2 Audio Control | Not Applicable | Eli Review’s student-side application contains no audio that plays automatically and no audio playback controls. This success criterion is therefore not applicable. |
| 1.4.3 Contrast (Minimum) | Supports | We use Material 3 Design color tokens and have a set typography standard. |
| 1.4.4 Resize Text | Supports | Text in Eli Review can be resized up to 200 percent using standard browser zoom without loss of content or functionality, in Chrome, Safari, and Firefox. |
| 1.4.5 Images of Text | Supports | Eli Review does not use images of text to present content. The only images in the student interface are illustrations, each of which is either described with alternative text or marked as decorative. |
| 1.4.10 Reflow | Supports | Eli Review reflows to a width of 320 CSS pixels, the equivalent of 400 percent zoom, without loss of content or functionality and without requiring horizontal scrolling, except for content such as data tables that require a two-dimensional layout. |
| 1.4.11 Non-text Contrast | Supports | Eli Review uses Material Design 3 color tokens for its borders and status indicators. Interactive component borders — including text input outlines and segmented controls — use the outline token, which meets the 3 to 1 minimum in both light and dark themes. Lower-contrast borders on cards and dividers are supplementary to the content inside each component, which visually defines the boundary, making these borders decorative. Status fill colors that fall below 3 to 1 in isolation are always accompanied by a visible text label or icon and are not used as the sole indicator of state. |
| 1.4.12 Text Spacing | Supports | Requires runtime text-spacing bookmarklet test. Theme uses unitless line-height (overridable) and px letter-spacing. |
| 1.4.13 Content on Hover or Focus | Supports | All hover entities use a shared MUI component which has been customized to support (a) (b) and (c). Enforced by linting rules. |
| 2.1.1 Keyboard | Supports | All of Eli Review can be operated with a keyboard. Interactive controls, including the course cards on the dashboard and the expandable sections within task views, can be reached and activated using the keyboard alone. |
| 2.1.2 No Keyboard Trap | Supports | Keyboard focus is never trapped in Eli Review. Dialogs hold focus only while open, can be closed with the Escape key or a visible Close button, and return focus to the control that opened them when dismissed. |
| 2.1.4 Character Key Shortcuts | Supports | Keyboard shortcuts in WYSIWYG only apply to WYG when in focus. All other shortcuts are for focus control. |
| 2.2.1 Timing Adjustable | Supports | Eli Review does not impose time limits on completing tasks. There is no session-timeout countdown or other user-facing time limit in the student interface. |
| 2.2.2 Pause, Stop, Hide | Supports | The only moving content in Eli Review consists of activity and progress indicators, such as loading spinners and save indicators, which WCAG exempts from this requirement. Eli Review presents no decorative content that moves automatically for more than five seconds. |
| 2.3.1 Three Flashes or Below Threshold | Not Applicable | No blink, <marquee>, or strobing > 3Hz content in the codebase. Animations are all 1-2s cycles (loading rotation, breathing highlights). No flashing-light content. |
| 2.4.1 Bypass Blocks | Supports | Eli Review provides a skip-to-content link and a focusable main landmark on every page, allowing keyboard and screen-reader users to bypass the header and navigation and move directly to the page content. |
| 2.4.2 Page Titled | Supports | Every page in the student interface has a unique, descriptive title that identifies its purpose. |
| 2.4.3 Focus Order | Supports | No positive tabIndex values anywhere in app/ (only 0 and -1). DOM order matches visual order in audited components. autoFocus appears in only 4 sites, all justified (menu autoFocusItem, FindEvidenceDrawer search field on open, EliWYSIWYG entry, PDFSelectionPopup textarea). |
| 2.4.4 Link Purpose (In Context) | Partially Supports | Most links in Eli Review describe their purpose through their text or surrounding context. Two ‘Learn more’ links, in the writing editor and the revision upload area, do not convey their destination programmatically. Adding a descriptive accessible name to each would resolve this. |
| 2.4.5 Multiple Ways | Supports | Eli Review provides more than one way to reach any task. Students can navigate from the dashboard through the course home and task list, from the global header, through the back control on each task page, or directly by URL. |
| 2.4.6 Headings and Labels | Supports | Every page in the student interface has a unique title and a single top-level heading, and headings follow a logical, descriptive order that helps users locate content. |
| 2.4.7 Focus Visible | Partially Supports | Most interactive components in Eli Review show a clear focus indicator when navigated by keyboard. The data table on the course home page removes the focus indicator from its column headers and cells, so keyboard users moving through the table cannot see which cell has focus. Restoring a visible focus style to the table would resolve this. |
| 2.5.1 Pointer Gestures | Supports | The only path-based gesture in Eli Review is the drag-and-drop used to gather evidence in the Reflection task, and it offers a full keyboard alternative: focus an item, lift it with Space or Enter, move it with the arrow keys, drop it with Space or Enter, and cancel with Escape, with spoken announcements at each step. |
| 2.5.2 Pointer Cancellation | Supports | Actions in Eli Review complete when the pointer is released rather than when it first makes contact, so a user can move away from a control before releasing to cancel the action. No function is triggered by a long press. |
| 2.5.3 Label in Name | Supports | Where a control has both visible text and a programmatic label, the accessible name contains the visible text, so speech-input users can activate controls by their visible names. A review of labeled controls across the student interface found no mismatches. |
| 2.5.4 Motion Actuation | Not Applicable | Eli Review’s student-side web application does not respond to device motion or user motion (no shake-to-undo, no tilt gestures, no orientation-as-input). This success criterion is not applicable. |
| 3.1.1 Language of Page | Supports | The language of every page in Eli Review is set to English in the page markup, so assistive technology can present content with the correct pronunciation. |
| 3.1.2 Language of Parts | Supports | Eli Review presents content in a single language, English, and contains no passages in another language that would require a different language setting. |
| 3.2.1 On Focus | Supports | Moving focus to a control in Eli Review never causes an unexpected change of context. The one control that responds to focus expands content within the same component and does not navigate, open a dialog, or submit a form. |
| 3.2.2 On Input | Supports | Audited 76 onChange handlers across student/shared task components. None cause context changes (no navigation, no modal opens, no submits triggered by input change without explicit user action). Standard state-update + autosave-mutation pattern throughout. |
| 3.2.3 Consistent Navigation | Supports | Navigation in Eli Review is rendered from a single shared header, so the logo, user menu, and notifications appear in the same place and order on every page. |
| 3.2.4 Consistent Identification | Supports | Components that repeat across Eli Review, such as the Save, Submit, and Close buttons and icons, are built from shared components, so they look and are labeled the same way wherever they appear. |
| 3.3.1 Error Identification | Partially Supports | Most forms in Eli Review identify input errors in text next to the affected field. On a few forms, including login, password reset, and account settings, the error appears as general text that is not programmatically tied to the field, and an unanswered required peer-review question is reported only in a summary rather than on the field itself. Associating these messages with their fields would resolve this. |
| 3.3.2 Labels or Instructions | Partially Supports | Most fields in Eli Review have visible labels and instructions. A default programmatic label of ‘Text Input’ is currently applied to text fields and overrides their visible labels, so screen readers announce ‘Text Input’ instead of the intended label, and some peer-review free-text questions are not programmatically associated with their visible question text. Correcting the default label would resolve this across the product. |
| 3.3.3 Error Suggestion | Partially Supports | Most error messages in Eli Review suggest how to correct the problem, such as the password rules and required-field prompts. A general account-settings error does not suggest a correction, and an unanswered required peer-review question offers a suggestion only in the summary rather than at the field. The login message is kept general by design for security. Adding field-level suggestions would resolve the remaining gaps. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Supports | Each task submission in Eli Review is protected by a confirmation step. The Writing, Peer Review, Revision, and Reflection submissions each present a review-and-confirm dialog before work is submitted, and the Peer Review confirmation states that responses cannot be edited afterward. |
| 4.1.1 Parsing (Obsolete in WCAG 2.2) | Not Applicable | This success criterion was removed in WCAG 2.2 and is no longer applicable. It is retained here only for traceability against earlier WCAG and Section 508 references. Eli Review’s pages are well formed. |
| 4.1.2 Name, Role, Value | Partially Supports | Interactive user interface components provide a name, role, and state that assistive technology can determine: icon buttons, tabs, and loading indicators were reviewed and announce correctly. However, the student dashboard applies an aria-label to nine non-interactive paragraph elements (for example “Reflection Task Scenarios” and “Revision Task Scenarios”). aria-label is not supported on a paragraph with no role, so assistive technology drops these labels and the intended accessible names are not conveyed. Removing the aria-label and presenting the text visibly, or moving the label onto an element with an appropriate role, would resolve this. |
| 4.1.3 Status Messages | Partially Supports | Success message for student tasks do get announced w/o focus change. Error messages were not tested across all interfaces. Further testing with NVDA would take from partially support to supports. |
| 2.4.11 Focus Not Obscured (Minimum) | Supports | When a control receives keyboard focus in Eli Review, it remains at least partially visible and is not entirely hidden by other content. The interface uses a sticky header, and focused controls scroll into view beneath it rather than being covered. |
| 2.5.7 Dragging Movements | Supports | The single drag interaction in Eli Review, used to order evidence in the Reflection task, offers a complete single-pointer and keyboard alternative: lift with Space or Enter, move with the arrow keys, drop with Space or Enter, and cancel with Escape, with spoken announcements. |
| 2.5.8 Target Size (Minimum) | Partially Supports | Mostly supported across the site via Figma constraints. In some low screen real estate situations target size may be less than 24×24. |
| 3.2.6 Consistent Help | Supports | There is an ever present Contact Eli control in the Nav Menu. |
| 3.3.7 Redundant Entry | Supports | Eli Review does not ask users to re-enter information they have already provided in the same process. Sign-up reuses the email from the first step, and task flows automatically save and restore entered values as the user moves between steps. |
| 3.3.8 Accessible Authentication (Minimum) | Supports | Signing in to Eli Review does not require solving a puzzle or any other cognitive function test. Login uses a username and password, password fields accept pasting and password-manager autofill, and there is no CAPTCHA or transcription challenge. |
| 508-302.1 Without Vision | Partially Supports | Submitted writing task tested manually with NVDA software. In order to get this from partially to fully support we would need to do a full manual walkthrough. |
| 508-302.2 With Limited Vision | Partially Supports | Eli Review supports users with limited vision across contrast, zoom, and text spacing. Text and interactive elements meet the WCAG contrast minimums, the interface supports 200 percent zoom and reflows at the equivalent of 400 percent zoom without loss of content, and content remains usable when text spacing is increased. Some border colors do not yet meet the non-text contrast minimum and are pending remediation, which prevents full conformance. |
| 508-302.3 Without Perception of Color | Partially Supports | All informational symbols or indicators have accompanying icons, or plain English language that describe their state. Could be problematic in mobile view of student task list. |
| 508-302.4 Without Hearing | Not Applicable | Eli Review’s student-side application contains no audio content. Users without hearing can use all functionality without modification. This criterion is satisfied trivially / not applicable in the auditory sense. |
| 508-302.5 With Limited Hearing | Not Applicable | Eli Review’s student-side application contains no audio output. This criterion is not applicable. |
| 508-302.6 Without Speech | Not Applicable | Eli Review’s student-side application does not require speech input from the user. Users without speech can use all functionality. This criterion is not applicable. |
| 508-302.7 With Limited Manipulation | Supports | All student side actions are able to be completed without a mouse. Manually tested 2026/05/21 |
| 508-302.8 With Limited Reach and Strength | Supports | All student side actions are able to be completed without a mouse. Manually tested 2026/05/21 |
| 508-302.9 With Limited Language, Cognitive, and Learning Abilities | Supports | All navigation is positioned statically per viewport. Error messages are clear and concise. |
| 508-401.1 Hardware — Scope | Not Applicable | Eli Review is a web application; no physical product hardware is provided. All of Chapter 4 (Hardware) is therefore not applicable. |
| 508-402.1 Closed Functionality | Not Applicable | Eli Review does not include closed-functionality hardware. This criterion is not applicable. |
| 508-403.1 Biometrics | Not Applicable | Eli Review does not use biometrics for identification or control. This criterion is not applicable. |
| 508-404.1 Preservation of Information Provided for Accessibility | Not Applicable | Eli Review provides no hardware connectors. This criterion is not applicable. |
| 508-405.1 Privacy — Hardware | Not Applicable | Eli Review does not include hardware features requiring privacy considerations distinct from those addressed by the web application. This criterion is not applicable. |
| 508-406.1 Standard Hardware Connections | Not Applicable | Eli Review is software; no hardware connections are provided. This criterion is not applicable. |
| 508-501.1 Software — Scope | Supports | Eli Review is web-based software with a user interface. Its conformance with the applicable functional and WCAG requirements is documented in the WCAG 2.2 and Section 508 results in this report. |
| 508-502.2.1 User Control of Accessibility Features | Not Applicable | Eli Review is not a closed-functionality product. Users access accessibility features through their browser and operating system. This sub-criterion is not applicable. |
| 508-502.3 Accessibility Services | Partially Supports | Submitted writing task tested manually with NVDA software. In order to get this from partially to fully support we would need to do a full manual walkthrough. |
| 508-502.4 Platform Accessibility Features | Not Applicable | Eli Review relies on browser and operating-system platform accessibility features (e.g. OS magnifier, browser zoom). The product does not disable or override these features. |
| 508-503.2 User Preferences | Partially Supports | Eli Review honors several platform preferences: it follows the operating system light or dark color-scheme setting, and keyboard focus indicators follow the platform focus-visible behavior. It does not yet fully honor the platform font-size setting, because text sizes are defined in fixed pixels rather than relative units, and it does not provide specific support for platform high-contrast or forced-colors modes. Browser zoom remains available as an alternative for enlarging content. |
| 508-503.3 Alternative User Interfaces | Not Applicable | Eli Review does not provide an alternative user interface; the primary web UI is the only interface and it is itself designed for accessibility. |
| 508-503.4 User Controls for Captions and Audio Description | Not Applicable | Eli Review’s student-side application contains no media playback. This criterion is not applicable. |
| 508-504.2 Content Creation or Editing — Authoring Tools | Not Applicable | Eli Review is not an authoring tool for accessibility-conforming content production in the §504 sense. Students compose text; they do not produce accessibility-claimed deliverables. |
| 508-602.2 Accessibility and Compatibility Features | Supports | VPAT will be hosted along side marketing site |
| 508-602.3 Electronic Support Documentation | Partially Supports | Eli Review support is available exclusively via email at [email protected].
We have help articles for Eli Classic and limited ones for Eli 2026, with the new marketing site in the works. We have a fully accessible support link and contact Eli section where they can write a message. |
| 508-602.4 Alternate Formats for Non-Electronic Support | Not Applicable | Eli Review’s support documentation is provided electronically only; no non-electronic format is offered. This criterion is not applicable. |
| 508-603.2 Information on Accessibility and Compatibility Features | Supports | VPAT will be hosted on WordPress static site.
Contact Eli modal in the app as well as a support link, has email contact info. |
| 508-603.3 Accommodation of Communication Needs | Partially Supports | Eli Review offers support by email at [email protected], which users with communication disabilities can reach without barriers. Telephone support is not offered. Help documentation is complete for the classic product and still in progress for the current product. |
| Criteria | Conformance Level | Remarks & Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Supports | Eli Review provides text alternatives for non-text content. The product uses few images: logos carry the text alternative “Eli Review”, illustrative empty-state graphics carry descriptive alternatives, and decorative images are marked so that assistive technology skips them. Icon-only buttons carry text labels, and the review-results pie chart is presented alongside a text legend that lists each choice and its percentage. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Not Applicable | Eli Review’s student-side application contains no prerecorded audio-only or video-only content. This success criterion is not applicable. |
| 1.2.2 Captions (Prerecorded) | Not Applicable | Eli Review’s student-side application contains no prerecorded video with audio. This success criterion is not applicable. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Not Applicable | Eli Review’s student-side application contains no prerecorded synchronized media. This success criterion is not applicable. |
| 1.2.4 Captions (Live) | Not Applicable | Eli Review’s student-side application contains no live synchronized media. This success criterion is not applicable. |
| 1.2.5 Audio Description (Prerecorded) | Not Applicable | Eli Review’s student-side application contains no prerecorded synchronized media. This success criterion is not applicable. |
| 1.3.1 Info and Relationships | Supports | Eli Review conveys information, structure, and relationships through semantic markup that assistive technology can read. Each page provides a single top-level heading and a main navigation landmark, and form controls, dialogs, icon buttons, and the text editor toolbar carry programmatic labels. |
| 1.3.2 Meaningful Sequence | Supports | Static analysis confirmed no CSS `order:` property used to visually reorder content out of DOM order across app/ (grep returned 0 matches). DOM order matches visual reading order. |
| 1.3.3 Sensory Characteristics | Supports | There is no copy text that references sensory characteristics. |
| 1.3.4 Orientation | Supports | Eli Review does not restrict content to a single display orientation. The interface is a responsive web application that works in both portrait and landscape, and it does not lock orientation. |
| 1.3.5 Identify Input Purpose | Supports | Eli Review identifies the purpose of input fields that collect information about the user. The login, sign-up, account settings, and password-reset forms set the autocomplete value WCAG defines for each field, including username, email, current password, new password, and given and family name, so browsers and assistive technology can offer accessible autofill. |
| 1.4.1 Use of Color | Supports | Eli Review renders all in-text links with a persistent underline so they are distinguishable from surrounding text without relying on color alone. Navigation links identified by their position, such as those in the app header, do not carry underlines. Status indicators pair color with an icon and a text label throughout the interface. |
| 1.4.2 Audio Control | Not Applicable | Eli Review’s student-side application contains no audio that plays automatically and no audio playback controls. This success criterion is therefore not applicable. |
| 1.4.3 Contrast (Minimum) | Supports | We use Material 3 Design color tokens and have a set typography standard. |
| 1.4.4 Resize Text | Supports | Text in Eli Review can be resized up to 200 percent using standard browser zoom without loss of content or functionality, in Chrome, Safari, and Firefox. |
| 1.4.5 Images of Text | Supports | Eli Review does not use images of text to present content. The only images in the student interface are illustrations, each of which is either described with alternative text or marked as decorative. |
| 1.4.10 Reflow | Supports | Eli Review reflows to a width of 320 CSS pixels, the equivalent of 400 percent zoom, without loss of content or functionality and without requiring horizontal scrolling, except for content such as data tables that require a two-dimensional layout. |
| 1.4.11 Non-text Contrast | Supports | Eli Review uses Material Design 3 color tokens for its borders and status indicators. Interactive component borders — including text input outlines and segmented controls — use the outline token, which meets the 3 to 1 minimum in both light and dark themes. Lower-contrast borders on cards and dividers are supplementary to the content inside each component, which visually defines the boundary, making these borders decorative. Status fill colors that fall below 3 to 1 in isolation are always accompanied by a visible text label or icon and are not used as the sole indicator of state. |
| 1.4.12 Text Spacing | Supports | Requires runtime text-spacing bookmarklet test. Theme uses unitless line-height (overridable) and px letter-spacing. |
| 1.4.13 Content on Hover or Focus | Supports | All hover entities use a shared MUI component which has been customized to support (a) (b) and (c). Enforced by linting rules. |
| 2.1.1 Keyboard | Supports | All of Eli Review can be operated with a keyboard. Interactive controls, including the course cards on the dashboard and the expandable sections within task views, can be reached and activated using the keyboard alone. |
| 2.1.2 No Keyboard Trap | Supports | Keyboard focus is never trapped in Eli Review. Dialogs hold focus only while open, can be closed with the Escape key or a visible Close button, and return focus to the control that opened them when dismissed. |
| 2.1.4 Character Key Shortcuts | Supports | Keyboard shortcuts in WYSIWYG only apply to WYG when in focus. All other shortcuts are for focus control. |
| 2.2.1 Timing Adjustable | Supports | Eli Review does not impose time limits on completing tasks. There is no session-timeout countdown or other user-facing time limit in the student interface. |
| 2.2.2 Pause, Stop, Hide | Supports | The only moving content in Eli Review consists of activity and progress indicators, such as loading spinners and save indicators, which WCAG exempts from this requirement. Eli Review presents no decorative content that moves automatically for more than five seconds. |
| 2.3.1 Three Flashes or Below Threshold | Not Applicable | No blink, <marquee>, or strobing > 3Hz content in the codebase. Animations are all 1-2s cycles (loading rotation, breathing highlights). No flashing-light content. |
| 2.4.1 Bypass Blocks | Supports | Eli Review provides a skip-to-content link and a focusable main landmark on every page, allowing keyboard and screen-reader users to bypass the header and navigation and move directly to the page content. |
| 2.4.2 Page Titled | Supports | Every page in the student interface has a unique, descriptive title that identifies its purpose. |
| 2.4.3 Focus Order | Supports | No positive tabIndex values anywhere in app/ (only 0 and -1). DOM order matches visual order in audited components. autoFocus appears in only 4 sites, all justified (menu autoFocusItem, FindEvidenceDrawer search field on open, EliWYSIWYG entry, PDFSelectionPopup textarea). |
| 2.4.4 Link Purpose (In Context) | Partially Supports | Most links in Eli Review describe their purpose through their text or surrounding context. Two ‘Learn more’ links, in the writing editor and the revision upload area, do not convey their destination programmatically. Adding a descriptive accessible name to each would resolve this. |
| 2.4.5 Multiple Ways | Supports | Eli Review provides more than one way to reach any task. Students can navigate from the dashboard through the course home and task list, from the global header, through the back control on each task page, or directly by URL. |
| 2.4.6 Headings and Labels | Supports | Every page in the student interface has a unique title and a single top-level heading, and headings follow a logical, descriptive order that helps users locate content. |
| 2.4.7 Focus Visible | Partially Supports | Most interactive components in Eli Review show a clear focus indicator when navigated by keyboard. The data table on the course home page removes the focus indicator from its column headers and cells, so keyboard users moving through the table cannot see which cell has focus. Restoring a visible focus style to the table would resolve this. |
| 2.5.1 Pointer Gestures | Supports | The only path-based gesture in Eli Review is the drag-and-drop used to gather evidence in the Reflection task, and it offers a full keyboard alternative: focus an item, lift it with Space or Enter, move it with the arrow keys, drop it with Space or Enter, and cancel with Escape, with spoken announcements at each step. |
| 2.5.2 Pointer Cancellation | Supports | Actions in Eli Review complete when the pointer is released rather than when it first makes contact, so a user can move away from a control before releasing to cancel the action. No function is triggered by a long press. |
| 2.5.3 Label in Name | Supports | Where a control has both visible text and a programmatic label, the accessible name contains the visible text, so speech-input users can activate controls by their visible names. A review of labeled controls across the student interface found no mismatches. |
| 2.5.4 Motion Actuation | Not Applicable | Eli Review’s student-side web application does not respond to device motion or user motion (no shake-to-undo, no tilt gestures, no orientation-as-input). This success criterion is not applicable. |
| 3.1.1 Language of Page | Supports | The language of every page in Eli Review is set to English in the page markup, so assistive technology can present content with the correct pronunciation. |
| 3.1.2 Language of Parts | Supports | Eli Review presents content in a single language, English, and contains no passages in another language that would require a different language setting. |
| 3.2.1 On Focus | Supports | Moving focus to a control in Eli Review never causes an unexpected change of context. The one control that responds to focus expands content within the same component and does not navigate, open a dialog, or submit a form. |
| 3.2.2 On Input | Supports | Audited 76 onChange handlers across student/shared task components. None cause context changes (no navigation, no modal opens, no submits triggered by input change without explicit user action). Standard state-update + autosave-mutation pattern throughout. |
| 3.2.3 Consistent Navigation | Supports | Navigation in Eli Review is rendered from a single shared header, so the logo, user menu, and notifications appear in the same place and order on every page. |
| 3.2.4 Consistent Identification | Supports | Components that repeat across Eli Review, such as the Save, Submit, and Close buttons and icons, are built from shared components, so they look and are labeled the same way wherever they appear. |
| 3.3.1 Error Identification | Partially Supports | Most forms in Eli Review identify input errors in text next to the affected field. On a few forms, including login, password reset, and account settings, the error appears as general text that is not programmatically tied to the field, and an unanswered required peer-review question is reported only in a summary rather than on the field itself. Associating these messages with their fields would resolve this. |
| 3.3.2 Labels or Instructions | Partially Supports | Most fields in Eli Review have visible labels and instructions. A default programmatic label of ‘Text Input’ is currently applied to text fields and overrides their visible labels, so screen readers announce ‘Text Input’ instead of the intended label, and some peer-review free-text questions are not programmatically associated with their visible question text. Correcting the default label would resolve this across the product. |
| 3.3.3 Error Suggestion | Partially Supports | Most error messages in Eli Review suggest how to correct the problem, such as the password rules and required-field prompts. A general account-settings error does not suggest a correction, and an unanswered required peer-review question offers a suggestion only in the summary rather than at the field. The login message is kept general by design for security. Adding field-level suggestions would resolve the remaining gaps. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Supports | Each task submission in Eli Review is protected by a confirmation step. The Writing, Peer Review, Revision, and Reflection submissions each present a review-and-confirm dialog before work is submitted, and the Peer Review confirmation states that responses cannot be edited afterward. |
| 4.1.1 Parsing (Obsolete in WCAG 2.2) | Not Applicable | This success criterion was removed in WCAG 2.2 and is no longer applicable. It is retained here only for traceability against earlier WCAG and Section 508 references. Eli Review’s pages are well formed. |
| 4.1.2 Name, Role, Value | Partially Supports | Interactive user interface components provide a name, role, and state that assistive technology can determine: icon buttons, tabs, and loading indicators were reviewed and announce correctly. However, the student dashboard applies an aria-label to nine non-interactive paragraph elements (for example “Reflection Task Scenarios” and “Revision Task Scenarios”). aria-label is not supported on a paragraph with no role, so assistive technology drops these labels and the intended accessible names are not conveyed. Removing the aria-label and presenting the text visibly, or moving the label onto an element with an appropriate role, would resolve this. |
| 4.1.3 Status Messages | Partially Supports | Success message for student tasks do get announced w/o focus change. Error messages were not tested across all interfaces. Further testing with NVDA would take from partially support to supports. |
| 2.4.11 Focus Not Obscured (Minimum) | Supports | When a control receives keyboard focus in Eli Review, it remains at least partially visible and is not entirely hidden by other content. The interface uses a sticky header, and focused controls scroll into view beneath it rather than being covered. |
| 2.5.7 Dragging Movements | Supports | The single drag interaction in Eli Review, used to order evidence in the Reflection task, offers a complete single-pointer and keyboard alternative: lift with Space or Enter, move with the arrow keys, drop with Space or Enter, and cancel with Escape, with spoken announcements. |
| 2.5.8 Target Size (Minimum) | Partially Supports | Mostly supported across the site via Figma constraints. In some low screen real estate situations target size may be less than 24×24. |
| 3.2.6 Consistent Help | Supports | There is an ever present Contact Eli control in the Nav Menu. |
| 3.3.7 Redundant Entry | Supports | Eli Review does not ask users to re-enter information they have already provided in the same process. Sign-up reuses the email from the first step, and task flows automatically save and restore entered values as the user moves between steps. |
| 3.3.8 Accessible Authentication (Minimum) | Supports | Signing in to Eli Review does not require solving a puzzle or any other cognitive function test. Login uses a username and password, password fields accept pasting and password-manager autofill, and there is no CAPTCHA or transcription challenge. |
| en-4.2.1 Usage without vision | Partially Supports | Submitted writing task tested manually with NVDA software. In order to get this from partially to fully support we would need to do a full manual walkthrough. |
| en-4.2.2 Usage with limited vision | Partially Supports | Eli Review supports users with limited vision across contrast, zoom, and text spacing. Text and interactive elements meet the WCAG contrast minimums, the interface supports 200 percent zoom and reflows at the equivalent of 400 percent zoom without loss of content, and content remains usable when text spacing is increased. Some border colors do not yet meet the non-text contrast minimum and are pending remediation, which prevents full conformance. |
| en-4.2.3 Usage without perception of color | Partially Supports | All informational symbols or indicators have accompanying icons, or plain English language that describe their state. Could be problematic in mobile view of student task list. |
| en-4.2.4 Usage without hearing | Not Applicable | Eli Review’s student-side application contains no audio content. Users without hearing can use all functionality without modification. This criterion is satisfied trivially / not applicable in the auditory sense. |
| en-4.2.5 Usage with limited hearing | Not Applicable | Eli Review’s student-side application contains no audio output. This criterion is not applicable. |
| en-4.2.6 Usage with no or limited vocal capability | Not Applicable | Eli Review’s student-side application does not require speech input from the user. Users without speech can use all functionality. This criterion is not applicable. |
| en-4.2.7 Usage with limited manipulation or strength | Supports | All student side actions are able to be completed without a mouse. Manually tested 2026/05/21 |
| en-4.2.8 Minimize photosensitive seizure triggers | Not Applicable | No blink, <marquee>, or strobing > 3Hz content in the codebase. Animations are all 1-2s cycles (loading rotation, breathing highlights). No flashing-light content. |
| en-4.2.9 Usage with limited cognition, language, or learning | Supports | All navigation is positioned statically per viewport. Error messages are clear and concise. |
| en-4.2.10 Privacy | Partially Supports | Eli Review masks password entry and supports browser password managers, so credentials can be entered without being revealed to onlookers. Password and identity fields do not yet declare their purpose through the autocomplete attribute, which limits private, automatic entry for some assistive-technology users. Adding these values would resolve the gap. |
| en-5.1.1 Closed functionality | Not Applicable | Eli Review does not include closed-functionality hardware. This criterion is not applicable. |
| en-6.1 ICT with two-way voice communication | Not Applicable | Eli Review does not provide two-way voice communication. All of section §6 is not applicable. |
| en-7.1 ICT with video capabilities | Not Applicable | Eli Review’s student-side application provides no video. All of section §7 is not applicable. |
| en-8.1 Hardware | Not Applicable | Eli Review is a web application; no product hardware is provided. All of section §8 is not applicable. |
| en-9.1.1.1 Non-text content (Web) | Supports | Eli Review provides text alternatives for non-text content. The product uses few images: logos carry the text alternative “Eli Review”, illustrative empty-state graphics carry descriptive alternatives, and decorative images are marked so that assistive technology skips them. Icon-only buttons carry text labels, and the review-results pie chart is presented alongside a text legend that lists each choice and its percentage. |
| en-9.1.3.1 Info and Relationships (Web) | Supports | Eli Review conveys information, structure, and relationships through semantic markup that assistive technology can read. Each page provides a single top-level heading and a main navigation landmark, and form controls, dialogs, icon buttons, and the text editor toolbar carry programmatic labels. |
| en-9.1.4.3 Contrast (Minimum) (Web) | Supports | We use Material 3 Design color tokens and have a set typography standard. |
| en-9.1.4.10 Reflow (Web) | Supports | Eli Review reflows to a width of 320 CSS pixels, the equivalent of 400 percent zoom, without loss of content or functionality and without requiring horizontal scrolling, except for content such as data tables that require a two-dimensional layout. |
| en-9.2.1.1 Keyboard (Web) | Supports | All of Eli Review can be operated with a keyboard. Interactive controls, including the course cards on the dashboard and the expandable sections within task views, can be reached and activated using the keyboard alone. |
| en-9.4.1.2 Name, Role, Value (Web) | Partially Supports | Interactive user interface components provide a name, role, and state that assistive technology can determine: icon buttons, tabs, and loading indicators were reviewed and announce correctly. However, the student dashboard applies an aria-label to nine non-interactive paragraph elements (for example “Reflection Task Scenarios” and “Revision Task Scenarios”). aria-label is not supported on a paragraph with no role, so assistive technology drops these labels and the intended accessible names are not conveyed. Removing the aria-label and presenting the text visibly, or moving the label onto an element with an appropriate role, would resolve this. |
| en-9.6 WCAG 2.1 AA conformance (Web) | Partially Supports | Pending remediation on partially support or not support line items. No line item does not support. |
| en-10.1 Non-web documents | Not Applicable | Eli Review’s student-side application does not deliver non-web documents (PDF, Word, etc.) within scope of this audit. All of section §10 is not applicable. |
| en-11.1 Software — general | Partially Supports | Eli Review’s interactive components expose a correct name, role, and state to assistive technology. Some status messages, such as save confirmations and error notifications, are not yet reliably announced to screen readers, which prevents full conformance until those announcements are completed. |
| en-11.5.2 Software — Authoring tools | Not Applicable | Eli Review is not an authoring tool for accessibility-conforming content production in the §11.5.2 sense. Students compose text; they do not produce accessibility-claimed deliverables. This criterion is not applicable. |
| en-12.1.1 Accessibility and compatibility features (Documentation) | Supports | VPAT will be hosted along side marketing site |
| en-12.1.2 Documentation — accessible electronic format | Partially Supports | Eli Review support is available exclusively via email at [email protected].
We have help articles for Eli Classic and limited ones for Eli 2026, with the new marketing site in the works. We have a fully accessible support link and contact Eli section where they can write a message. |
| en-12.2.2 Support services — communication needs | Partially Supports | Eli Review offers support by email at [email protected], which users with communication disabilities can reach without barriers. Telephone support is not offered. Help documentation is complete for the classic product and still in progress for the current product. |
| en-13.1 ICT providing relay or emergency service access | Not Applicable | Eli Review does not provide telecommunications relay or emergency service access. All of section §13 is not applicable. |
