Accessibility Statement

Our Commitment

EdPilot is committed to ensuring its AI-powered education platform is accessible to all users, including individuals with disabilities. We design and build to conform to Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, as required under the Americans with Disabilities Act (ADA) Title II and the DOJ Title II Final Rule (April 2024), as well as applicable federal regulations (28 C.F.R. Part 35) and Section 508 of the Rehabilitation Act.

For institutions in the European Union and European Economic Area, EdPilot targets compliance with EN 301 549 v3.2.1 (the harmonised European standard for ICT accessibility), which references WCAG 2.1 AA as its web content criteria. A Voluntary Product Accessibility Template (VPAT®) / Accessibility Conformance Report is available upon request for institutional procurement teams — contact accessibility@edpilot.ai.

Conformance Status

EdPilot is substantially conformant with WCAG 2.2 Level AA across all platform surfaces. The following accessibility features have been engineered, audited, and verified:

Navigation & Focus

• Skip-to-main-content link on every page (WCAG 2.4.1)
• Full keyboard navigation throughout the application
• Visible focus indicators on all interactive elements using a 2px solid accent-color ring (WCAG 2.4.7, WCAG 2.4.11 — new in 2.2)
• View toggle buttons use aria-pressed and aria-label so keyboard and screen reader users know the active layout at all times
• Screen reader announcements for all client-side route changes via a live-region route announcer (WCAG 4.1.3)
• Session timeout warning dialog with focus management and role="alertdialog" (WCAG 2.2.1). Authentication sessions extend automatically on user activity and provide at least 20 seconds warning before expiry (WCAG 2.2.6 — new in 2.2)
• Draggable reorder handles provide keyboard-accessible alternatives via arrow-key controls and an explicit "Move up / Move down" action menu (WCAG 2.5.7 — new in 2.2)

Screen Reader & ARIA Support

• All modal dialogs use role="dialog", aria-modal="true", and aria-labelledby wiring (WCAG 4.1.2). This includes the Exit Student View modal, Leave Class confirmation, Join Class modal, Create Course modal, and the general Confirm Dialog component.
• All modal dialogs implement a full keyboard focus trap — Tab and Shift+Tab cycle only within the open dialog, and pressing Escape dismisses it and returns focus to the triggering element (WCAG 2.1.2)
• All form inputs have programmatically associated <label> elements or aria-label attributes. Search inputs that are visually labelled by a placeholder also carry a screen-reader-only <label> element (WCAG 1.3.1)
• The AI chat message container uses aria-live="polite" and aria-relevant="additions" so new messages are announced to screen readers without interrupting ongoing speech
• AI streaming responses are announced with aria-busy="true"during generation and a debounced "Response complete" status message on completion (WCAG 4.1.3)
• Loading skeleton states carry role="status" and aria-live="polite" so screen readers announce when content is loading (WCAG 4.1.3)
• Collapsible sections use aria-expanded, aria-controls, and role="region" with aria-labelledby
• Tab panels use the full WAI-ARIA tabs pattern with roving tabIndex and arrow-key navigation
• All decorative icons are hidden from assistive technology with aria-hidden="true"
• All informational images include meaningful alternative text (WCAG 1.1.1)
• Unsaved-data warnings use role="alert" so they are announced immediately to screen readers (WCAG 4.1.3)
• Help text and error messages are programmatically associated with their form controls via aria-describedby (WCAG 1.3.1, 3.3.1)

Data & Visualizations

• The course leaderboard is rendered as a semantic <table> with <th scope="col">, aria-sort on sortable columns, and a screen-reader-only caption (WCAG 1.3.1)
• XP progress bars use role="progressbar" with aria-valuenow, aria-valuemin, aria-valuemax, and a descriptive aria-label (WCAG 1.3.1)
• The Concept Difficulty analytics chart offers a "View as table" toggle, rendering a fully accessible <table> alternative to the bar chart (WCAG 1.3.1, 1.4.1)
• All status indicators (course signals, integrity alerts, material health) use text labels alongside colour, never colour alone (WCAG 1.4.1)

Color & Contrast

• All body text meets WCAG 1.4.3 AA contrast ratios (minimum 4.5:1 against background surfaces)
• Secondary text set to #9D9DA8 (~5.1:1) and muted-foreground lightness raised to 65% to satisfy AA requirements
• Input placeholder text raised to placeholder-white/50 across all search and chat inputs (WCAG 1.4.3)
• High-contrast mode supported via @media (prefers-contrast: more): all CSS custom properties override to near-black/pure-white, borders become fully opaque, focus rings increase to 3px, and semi-transparent surfaces are replaced with solid equivalents (WCAG 1.4.11)
• Non-text UI components (icons used as controls, input borders, focus rings) meet the 3:1 contrast requirement for UI components (WCAG 1.4.11)

Motion & Animation

• All animations and transitions respect the prefers-reduced-motion: reduce media query — durations are collapsed to 0.01ms and custom keyframe animations are disabled (WCAG 2.3.3)
• Framer Motion reads the reduced-motion preference at runtime and disables physics-based animations accordingly

Mobile & Touch Accessibility

• All interactive targets meet the WCAG 2.5.8 minimum target size of 24×24 CSS pixels (new in WCAG 2.2); primary actions meet the recommended 44×44px touch target size
• Platform tested with iOS VoiceOver (Safari) and Android TalkBack (Chrome) on mobile browsers as part of each release cycle
• Orientation is not locked — the platform is fully functional in both portrait and landscape (WCAG 1.3.4)
• No functionality requires pointer-specific gestures (pinch, swipe) without a single-pointer alternative (WCAG 2.5.1)
• LTI launches from Canvas Mobile and Blackboard Student apps are tested for accessibility parity with the full web experience

Course Material Accessibility (Faculty Tools)

• Server-side accessibility scanner runs automatically on every uploaded file — detecting image-only or scanned PDFs, PPTX slides with missing alt text, DOCX images without descriptions, and high-risk spreadsheet structures (WCAG 1.1.1, 1.3.1)
• Structured remediation warnings are displayed to faculty immediately after upload, with specific guidance for each issue and a link to remediation tools
• Faculty see a pre-upload accessibility advisory checklist before submitting files, establishing expectations before content reaches students
• An accessibility acknowledgment step is integrated into the faculty onboarding flow
• A Materials Accessibility panel in the professor analytics dashboard tracks accessibility health across all uploaded course files, showing scan status, warning counts, and remediation progress

Automated Testing & CI/CD

• Automated axe-core accessibility audit runs on every pull request via GitHub Actions, covering page stubs spanning public routes and authenticated dashboard pages (WCAG 2.2 AA + best-practice rules)
• Pa11y-CI is configured for scheduled scanning against staging deployments, testing all public-facing routes at WCAG 2.2 AA standard
• Type-checking, linting, and the a11y audit gate are all required to pass before code merges to main

Known Limitations

The following limitations remain and are on our active remediation roadmap:

• PDF tag structure and reading order — our server-side scanner detects image-only PDFs but cannot inspect internal PDF tag trees, reading order, or heading structure, which require PDF/UA tooling not available in a pure JavaScript environment. Faculty are advised to use Adobe Acrobat's accessibility checker before uploading.
• Third-party embedded content — externally hosted content (linked resources, embedded media) is outside our control and may not meet WCAG 2.2 AA. We recommend faculty verify accessibility of any external materials before sharing with students.
• Complex analytics chart interactions — while all charts with bar-based visualizations offer a table-view alternative, some advanced analytics charts (trajectory graphs, timing heatmaps) do not yet have an equivalent data table. This is scheduled for the next release.
• Content Security Policy inline-script directives — the current CSP includes 'unsafe-inline' for scripts, which is required by the current build pipeline. Migration to a nonce-based CSP is planned to eliminate this exception.

Technical Specifications

EdPilot relies on the following technologies for conformance:

• HTML5 / WAI-ARIA 1.2
• CSS including prefers-reduced-motion, prefers-contrast: more, and prefers-color-scheme media queries
• JavaScript / React 19 / Next.js App Router
• Radix UI primitives (Dialog, Tabs, Tooltip, DropdownMenu, Select) with built-in WAI-ARIA patterns

The platform is evaluated using the following tools and methods:

• Automated axe-core static analysis (runs in CI on every pull request)
• Pa11y-CI WCAG 2.2 AA scan against staging deployments
• Manual keyboard navigation testing
• Screen reader testing: NVDA + Chrome (Windows), VoiceOver + Safari (macOS/iOS), TalkBack + Chrome (Android)
• WCAG 2.2 AA manual checklist review
• Color contrast verified using APCA and WCAG 2.x contrast algorithms

A VPAT® / Accessibility Conformance Report aligned to WCAG 2.2 AA and Section 508 is available to institutional procurement teams upon request. Email accessibility@edpilot.ai with subject line "VPAT Request."

Formal Complaints

If you are not satisfied with our response, you may contact the U.S. Department of Justice Civil Rights Division or file a complaint with the appropriate federal agency overseeing the program. Additional information is available at ada.gov. EU/EEA users may also contact their national accessibility enforcement body under the European Accessibility Act (EAA) / Web Accessibility Directive.

Compliance Timeline & Roadmap

Under the DOJ Title II final rule (April 2024), covered entities must conform to WCAG 2.1 Level AA. EdPilot has implemented a comprehensive, multi-phase accessibility program — upgraded to WCAG 2.2 AA — spanning structural ARIA compliance, color contrast remediation, semantic markup, high-contrast mode support, automated CI/CD gating, a faculty-facing materials accessibility pipeline, mobile and touch accessibility testing, and full keyboard focus-trap management across all modal dialogs.

Active roadmap items include: data table alternatives for all remaining analytics charts, nonce-based CSP migration, annual third-party WCAG 2.2 audit, and ongoing VPAT maintenance. We treat accessibility as an ongoing engineering priority and review this statement with every major release.