Accessibility commitment
Evident aims to make student-support documentation workflows usable by educators, administrators, and families with diverse access needs.
The product is built with semantic HTML, keyboard-aware components, visible focus states, and automated accessibility checks for representative flows.
Current target
Evident targets WCAG 2.1 AA-informed product practices for core public, educator, and family-facing workflows.
This statement describes current readiness work and should not be interpreted as a completed third-party certification, completed VPAT, or completed ACR.
Testing approach
Automated checks use Playwright and axe-core on representative public and authenticated pages.
Manual checks should cover keyboard navigation, focus visibility, form labels and errors, modal behavior, data tables, PDFs, and screen reader spot checks.
VPAT / ACR readiness path
Evident maintains a vendor self-assessment Accessibility Conformance Report (ACR) against WCAG 2.1 A and AA, plus a prioritized remediation backlog, available to schools on request through the support contact path.
The self-assessment is based on automated axe-core testing and source-code review. A full manual screen-reader sweep and an independent third-party audit are the next steps, and the remediation backlog tracks the open gaps as fixes ship.
How we build for access
These are the practices we work toward across core public, educator, and family-facing workflows. They describe our intent and ongoing work, not a completed conformance claim.
- Keyboard navigation. We aim to keep primary actions reachable and operable by keyboard, with a visible focus indicator so you can see where you are on the page.
- Screen reader considerations. We use semantic HTML, labeled form fields, and accessible dialog patterns so that assistive technology can announce structure, controls, and errors. Documented screen reader testing across core flows is still in progress.
- Color and contrast. We work toward readable text contrast and try not to rely on color alone to communicate status. Some legacy routes still need contrast verification.
- Printable and parent-facing outputs. Reports and packets are designed to be readable in print and shareable with families. Generated PDFs still need a focused accessibility audit before we make stronger PDF claims.
Audit scope
Keyboard navigation
- Current evidence: Existing Playwright accessibility coverage includes representative public and authenticated routes.
- Readiness action: Manually verify tab order, skip links, escape behavior, and keyboard activation across procurement, dashboard, student, packet, and family routes.
Focus states
- Current evidence: The design system uses visible ring focus styles on standard controls.
- Readiness action: Check custom cards, links, accordions, dialogs, and dashboard actions for visible focus at 200 percent zoom.
Color contrast
- Current evidence: Automated axe checks exist, with some known color-contrast filtering on legacy routes.
- Readiness action: Re-run contrast checks on public trust routes and dashboard routes, then document or fix any filtered contrast issues.
Form labels and errors
- Current evidence: Forms generally use labels and validation messaging through existing UI patterns.
- Readiness action: Verify school signup, login, student forms, invitation forms, import forms, and packet-prep forms announce errors correctly.
Modal accessibility
- Current evidence: Dialogs are built on Radix primitives in most flows.
- Readiness action: Verify dialog titles, descriptions, focus trap, escape behavior, and return focus on student, chart, import, and packet flows.
Table accessibility
- Current evidence: Admin and report views use structured table patterns in several areas.
- Readiness action: Verify captions, header scope, sorting labels, and empty-state descriptions on admin and reporting tables.
PDF accessibility
- Current evidence: PDF reports are generated through React PDF components.
- Readiness action: Audit generated PDFs for reading order, text availability, headings, and whether color alone communicates status.
Screen reader checks on core flows
- Current evidence: Automated tests catch structural issues but do not replace assistive technology checks.
- Readiness action: Spot-check procurement pages, signup, dashboard, student detail, packet generation, and family portal with NVDA or VoiceOver.
Known gaps to resolve
- A vendor self-assessment ACR exists and is available on request; an independent third-party audit has not been completed.
- PDF accessibility needs a focused audit before stronger PDF accessibility claims are made.
- Some legacy automated checks filter known contrast issues; those filters should be reviewed route by route.
- Screen reader testing needs documented manual results for the core school-buying and product workflows.
Report an accessibility barrier
If you run into a barrier using Evident, or you need content in a different format, tell us what happened and the page or workflow where it occurred. The more specific the report, the faster we can reproduce and fix it. We use these reports to prioritize remediation. We read every message and aim to respond promptly, though we do not publish a fixed response-time guarantee.
Helpful details to include: the page or URL, the device and browser, the assistive technology you were using (if any), and what you expected to happen.
Request a VPAT / ACR
If your district requires a formal VPAT/ACR or accessibility conformance documentation for procurement review, reach out and we will share our current readiness status and remediation timeline. We do not claim a completed third-party certification, VPAT, or ACR today, so we will be candid about what is in progress.