Encephlo, Inc. Accessibility Conformance Report
WCAG Edition (Based on VPATĀ® Version 2.5Rev)
Name of Product/Version: Encephlo, web application (continuously deployed; this report reflects the build of September 18, 2026)
Report Date: September 18, 2026
Product Description: Encephlo is a web-based AI course tutor for higher education. An instructor uploads a syllabus and course materials; a course specific tutor is generated; students reach it through an invite code and ask questions in a chat interface. Instructors receive a summary of what their students are asking. The product runs in the browser. There is no native mobile or desktop application in scope for this report.
Contact Information: Encephlo, Inc., suraj@encephlo.com. The public accessibility statement is published at https://encephlo.com/accessibility.
Notes:
This report covers the business-to-business product: the public marketing pages, account creation and sign-in, the student invite and join flow, the instructor studio, and the student tutor application.
Excluded from scope, and why: consumer-oriented pages and checkout, which are
not offered to institutions; internal development-only routes; and three legacy
or experimental student features (/focus, /opportunities, /scheduler) that
are not reachable from the student navigation. One development-only control, a
read-aloud voice selector rendered exclusively when NODE_ENV is development,
is excluded because it does not exist in the shipped product.
Level AAA was not evaluated and the Level AAA table has been removed, as permitted by the VPAT Report Size guidance. No Level AAA conformance is claimed.
This is the first accessibility audit ever conducted on this product. The audit was performed on August 27, 2026. Several defects it found were fixed before publication rather than reported as open, and those fixes are part of the build this report describes; each one is identified in the remarks with the measured value before and after. Remaining nonconformities carry a remediation note. When they are fixed, this report will be reissued under a new date rather than silently edited.
Evaluation Methods Used:
Testing was performed against the running application by a tester with full knowledge of the product's functionality, combining:
- Automated testing with axe-core 4.13.0, using the rule tags
wcag2a,wcag2aa,wcag21a,wcag21aa, andwcag22aa. Public pages were scanned through a headless Chrome harness; authenticated surfaces were scanned by injecting the same engine into a live signed-in session. - Manual keyboard testing using real key events: tab order, focus indicator visibility, and absence of keyboard traps.
- Accessibility tree inspection, examining the roles, names, and states actually exposed to assistive technology.
- Live-region instrumentation, using a DOM mutation recorder to observe what is and is not announced during a streaming tutor response.
- Viewport and adaptation testing at 1280x900 and 320x900, and under the WCAG 1.4.12 text-spacing overrides.
- Source inspection for attributes and behaviors not observable at runtime.
Because animated entrance transitions are used widely in this interface, all
measurements were taken with prefers-color-scheme and prefers-reduced-motion
emulation and after the interface settled, so that reported colors and focus
indicators reflect the resting state a user sees.
Testing not performed: no session with a live screen reader (NVDA, JAWS, or VoiceOver) has been conducted. Verdicts touching assistive-technology output are based on the accessibility tree and live-region instrumentation, which show what is exposed, rather than on listening to a screen reader render it. This limitation is stated again on the public accessibility page.
Applicable Standards/Guidelines
| Standard/Guideline | Included In Report |
|---|---|
| Web Content Accessibility Guidelines 2.0 | Level A: Yes. Level AA: Yes. Level AAA: No. |
| Web Content Accessibility Guidelines 2.1 | Level A: Yes. Level AA: Yes. Level AAA: No. |
| Web Content Accessibility Guidelines 2.2 | Level A: Yes. Level AA: Yes. Level AAA: No. |
Terms
- 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.
WCAG 2.x Report
Note: When reporting on conformance with the WCAG 2.x Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in the WCAG 2.0 Conformance Requirements.
Table 1: Success Criteria, Level A
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Supports | Automated checks for image alternatives, button names, and input image alternatives pass across all in-scope surfaces. Decorative icons are hidden from assistive technology; functional icon controls carry text alternatives. Video result cards use the video title as the image alternative. Six unlabeled icon buttons in the student navigation were found during this audit and were given accessible names before publication. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Supports | The product contains no prerecorded audio-only or video-only content. Video suggestions surfaced by the tutor are rendered as a thumbnail linking out to YouTube; no media plays inside the product. Per WCAG Understanding Conformance, a criterion with no applicable content is satisfied. |
| 1.2.2 Captions (Prerecorded) | Supports | No prerecorded synchronized media is presented within the product. See 1.2.1. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Supports | No prerecorded synchronized media is presented within the product. See 1.2.1. |
| 1.3.1 Info and Relationships | Supports | Heading hierarchy, list semantics, form label association, table structure, and landmark checks pass on all in-scope surfaces. Each layout provides a main landmark. Tab interfaces in the instructor studio expose correct tab, tablist, and tabpanel roles with accurate aria-selected and aria-controls relationships, confirmed by inspection of the live accessibility tree. |
| 1.3.2 Meaningful Sequence | Supports | DOM order matches visual order on the surfaces walked. Keyboard traversal of the instructor studio and the student tutor followed the visible layout without displacement. |
| 1.3.3 Sensory Characteristics | Supports | Instructions do not rely solely on shape, size, or visual location. Controls are identified by text or accessible name rather than by position. |
| 1.4.1 Use of Color | Supports | Color is not the sole means of conveying information. Links are underlined or otherwise distinguished, and status is carried by text and icon in addition to color. |
| 1.4.2 Audio Control | Supports | Read-aloud audio is off by default and requires the user to enable it. When active, a persistent read-aloud control bar provides stop and voice controls. No audio plays automatically on page load. |
| 2.1.1 Keyboard | Supports | All interactive controls tested were operable from the keyboard, including the instructor studio tab set, the chat composer, and the send action. Verified with real key events rather than scripted focus. |
| 2.1.2 No Keyboard Trap | Supports | Sequential keyboard traversal of the studio and tutor surfaces did not encounter a component that trapped focus. |
| 2.1.4 Character Key Shortcuts | Supports | The product implements no single-character key shortcuts and uses no accesskey attributes, confirmed by source inspection. |
| 2.2.1 Timing Adjustable | Supports | No time limits are imposed on reading or interaction. Tutor responses stream in but impose no deadline on the user, and the session does not expire during use. |
| 2.2.2 Pause, Stop, Hide | Supports | This criterion failed at audit: the tutor's streaming reply is auto-updating content that a user could not pause. A "Pause reply" control now appears beneath the reply while it is being written; it freezes the on-screen text where it stands, stops the typing indicator and cursor animation, and "Resume reply" continues from the same character. Decorative entrance animations honor prefers-reduced-motion and are skipped when it is set. Read-aloud highlighting starts only when the user presses play and has a persistent stop control, so it is user-initiated rather than automatic. Loading indicators are brief activity signals and are treated as essential. |
| 2.3.1 Three Flashes or Below Threshold | Supports | No content flashes more than three times per second. Animations are opacity and position transitions under one second. |
| 2.4.1 Bypass Blocks | Supports | This criterion failed at audit: each layout exposed a main landmark, but there was no skip link, so a sighted keyboard user had to traverse the entire session sidebar, which grows with the number of sessions, before reaching the chat composer. A "Skip to main content" link is now the first focusable element on the marketing site, the student application, and the instructor studio. It is visually hidden until it receives keyboard focus and moves focus into the main region. The student join flow has no navigation to bypass. |
| 2.4.2 Page Titled | Supports | Every in-scope route sets a descriptive and distinct document title. |
| 2.4.3 Focus Order | Supports | Focus order follows a logical reading and operation sequence on the surfaces walked, verified by recording the accessibility properties of each element reached by sequential Tab presses. |
| 2.4.4 Link Purpose (In Context) | Supports | Automated link-name checks pass. Link text, alone or with its surrounding context, describes the destination. |
| 2.5.1 Pointer Gestures | Supports | No functionality requires multipoint or path-based gestures. All operations are single-pointer activations. |
| 2.5.2 Pointer Cancellation | Supports | Actions are triggered on the up-event by standard button and link elements; no functionality completes on the down-event. |
| 2.5.3 Label in Name | Supports | Accessible names for controls with visible text begin with, or contain, that visible text. Icon-only controls carry descriptive names that include the object acted upon, for example "Options for MATH 150". |
| 2.5.4 Motion Actuation | Supports | No functionality is operated by device motion or user motion. |
| 3.1.1 Language of Page | Supports | The document element declares lang="en" on every route. |
| 3.2.1 On Focus | Supports | Receiving focus does not trigger a change of context on any control tested. |
| 3.2.2 On Input | Supports | Changing a setting does not automatically cause a change of context. Form submission requires explicit activation. |
| 3.2.6 Consistent Help | Supports | A help affordance is presented in a consistent position across the application surfaces on which it appears. |
| 3.3.1 Error Identification | Supports | Sign-in and sign-up errors are rendered in text and exposed with role="alert", so the error is both visible and announced. |
| 3.3.2 Labels or Instructions | Supports | Automated form-label checks pass on all in-scope forms. Inputs carry visible labels or accessible names, and the chat composer is labeled "Chat input". |
| 3.3.7 Redundant Entry | Supports | No process requires the user to re-enter information already provided in the same session. |
| 4.1.1 Parsing | Supports | For WCAG 2.0 and 2.1, the September 2023 errata update indicates this criterion is always supported. Obsolete and removed in WCAG 2.2. |
| 4.1.2 Name, Role, Value | Supports | This criterion failed at audit: six icon-only buttons in the student navigation exposed no accessible name and were announced only as "button", on every student route. They were given accessible names before publication and the failure no longer reproduces; automated verification now reports zero violations on those routes. All other components expose correct roles, names, and states, including the studio tab set and the chat composer. |
Table 2: Success Criteria, Level AA
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) | Supports | The product presents no live synchronized media. |
| 1.2.5 Audio Description (Prerecorded) | Supports | The product presents no prerecorded synchronized media. See 1.2.1. |
| 1.3.4 Orientation | Supports | No orientation lock is applied. Content renders in both portrait and landscape; verified at 320px width with no loss of content or functionality. |
| 1.3.5 Identify Input Purpose | Supports | This criterion failed at audit: the sign-in and sign-up forms collected the user's name, email address, and password with no autocomplete attributes, so the purpose of these fields was not programmatically determinable. The fields now carry autocomplete="name", autocomplete="email", autocomplete="current-password" (sign-in), and autocomplete="new-password" (sign-up and confirmation), which also lets password managers fill them reliably. The only other password-type field, a Canvas API token entry in the instructor studio, is a credential for a third-party system rather than personal information and intentionally sets autocomplete="off". |
| 1.4.3 Contrast (Minimum) | Partially Supports | Three failures were measured and fixed before publication, against the 4.5:1 requirement: footer text on all public pages (3.77:1, now 5.83:1), instructor Insights statistic labels (3.85:1, now 6.04:1), and the "Draft" status badge in the instructor studio (4.44:1, now 6.27:1). The underlying cause was an opacity modifier applied to the muted text color; the same pattern appears at other sites in the product that have not yet been measured against every background they render on. Remediation: audit and remove opacity modifiers on body text throughout. Target: Q4 2026. |
| 1.4.4 Resize text | Supports | Text scales without loss of content or functionality. Layout is relative-unit based and reflows rather than clipping; confirmed by the 320px reflow result, which is the more demanding equivalent condition. |
| 1.4.5 Images of Text | Supports | Text is rendered as live text throughout. Images of text are not used for content, only for logotypes. |
| 1.4.10 Reflow | Supports | At a 320px viewport width, content presents without loss of information or functionality and without two-dimensional scrolling. Measured document scroll width equals viewport width, so no horizontal scrolling is introduced. |
| 1.4.11 Non-text Contrast | Partially Supports | Focus indicators and primary control boundaries meet the 3:1 requirement. The undo icon in the instructor composer measured 2.39:1 against its bubble and was raised to 5.64:1 before publication. Some other low-emphasis interface icons use the same opacity-modifier pattern described in 1.4.3 and have not been individually measured against every background. Remediation: measure and correct alongside the 1.4.3 work. Target: Q4 2026. |
| 1.4.12 Text Spacing | Supports | With the WCAG-specified overrides applied for line height, letter spacing, word spacing, and paragraph spacing, no content was clipped or overlapped and no horizontal scrolling was introduced. Measured, not assumed. |
| 1.4.13 Content on Hover or Focus | Supports | Tooltips are dismissible with Escape, do not obscure the triggering content, and remain visible while the pointer is over them. Implemented through a component library with these behaviors built in. |
| 2.4.5 Multiple Ways | Supports | More than one way exists to locate content: persistent navigation, a session list, in-product search of tutors, and direct links. |
| 2.4.6 Headings and Labels | Supports | Headings and labels describe topic or purpose. Automated heading-order and label checks pass on all in-scope surfaces. |
| 2.4.7 Focus Visible | Supports | Every control reached by keyboard displays a visible focus indicator, rendered either as a 2px solid outline in the brand teal or as a two-layer ring with a light offset. Verified with real keyboard input and measured after transitions completed. The per-course and per-session option controls in the student sidebar, which slide into view on pointer hover, were also made to slide into view when they receive keyboard focus, so their indicator is never clipped. |
| 2.4.11 Focus Not Obscured (Minimum) | Partially Supports | On the surfaces walked, focused controls remained visible. This criterion has not been isolation-tested against the sticky application header on long scrolled pages, where a focused element could in principle be covered. Remediation: targeted testing of scrolled states, then correction with scroll-margin if needed. Target: Q4 2026. |
| 2.5.7 Dragging Movements | Supports | No functionality requires a dragging movement. All operations have single-pointer alternatives. |
| 2.5.8 Target Size (Minimum) | Supports | This criterion failed at audit: a course options control measured 20x20 CSS pixels and an inline undo control in the instructor composer measured 14x14, against a 24x24 minimum. Both were enlarged to 24x24 before publication. The hover-revealed option controls in the student sidebar, which were measured mid-transition at 14px wide, no longer shrink below 24x24 while sliding into view. Controls on the surfaces tested otherwise meet the minimum or fall under the inline-text and user-agent exceptions. |
| 3.1.2 Language of Parts | Supports | Content is presented in English throughout. No passages in another language are marked or required. |
| 3.2.3 Consistent Navigation | Supports | Navigation is presented in the same relative order across pages within each of the marketing, instructor, and student areas. |
| 3.2.4 Consistent Identification | Supports | Components with the same function carry consistent names and iconography across the product. |
| 3.3.3 Error Suggestion | Supports | Authentication errors describe the problem in text. Where the cause is known and correctable, the message says how to correct it. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Supports | Institutional users incur no financial transactions; students are never billed. Destructive actions such as deleting a tutor or a session require confirmation through a dialog. |
| 3.3.8 Accessible Authentication (Minimum) | Supports | Authentication does not require a cognitive function test without an alternative: sign-in with Google, Microsoft, or Apple is offered alongside email and password, nothing blocks pasting into the password field, and the autocomplete attributes described under 1.3.5 let password managers fill the fields. |
| 4.1.3 Status Messages | Partially Supports | This criterion failed at audit and was the most serious finding. The tutor transcript contained no live region: instrumentation of a real question showed roughly 1,800 characters of tutor response entering the page over about fourteen seconds with no announcement and no focus movement, making the product's core function silent to a screen reader user. A polite, atomic live region was added before publication; it now announces the start of the response and then the completed reply once, verified by instrumentation. The verdict remains Partially Supports because not every status change elsewhere in the product, such as upload and save states, has been individually verified. Remediation: audit remaining status changes. Target: Q4 2026. |
Legal Disclaimer
This report describes the accessibility of the Encephlo web application as measured on the date shown. It is a self-assessment prepared by the vendor and has not been reviewed by an independent third party. The product is under continuous development; conformance may change between report dates. Encephlo, Inc. makes no warranty that the product will meet any particular institutional accessibility requirement, and invites institutions to test it against their own standards. To report an accessibility problem or request an updated report, contact suraj@encephlo.com.