WriteAlign Accessibility Conformance Report
Based on VPAT® Version 2.5Rev
Report Date: August 2026 (re-assessed after a review of the application’s custom interface components)
Product Information
- Name of Product / Version
- WriteAlign (Web Application)
- Product Description
- WriteAlign is a web-based AI-powered writing evaluation platform that analyzes student writing and provides automated feedback aligned to rubrics and standards.
- Contact
- Region 7 Education Service Center — Digital Learning Department. Accessibility inquiries may be directed to support@writealign.net.
This VPAT represents a preliminary self-assessment of WriteAlign's accessibility based on internal review. As an evolving AI-driven platform, accessibility improvements are ongoing.
Evaluation Methods Used
WriteAlign was evaluated through a combination of automated testing and source review. Automated evaluation used axe-core (run against public and authenticated pages via Playwright) and eslint-plugin-jsx-a11y (strict ruleset). Both reported zero violations across the application; the axe-core crawl was last run in June 2026 and the static ruleset was re-run in August 2026 across all 662 interface source files.
The August 2026 assessment added a source-level review of the criteria that automated tools cannot evaluate. This covered the application’s custom interactive components (tab sets, dialogs, comboboxes, sliders, sortable tables and charts) for keyboard operability and for agreement between the roles and states they declare and the behaviour they implement; the text of every heading, form label and control name defined in the source; the wording of client-side validation messages; and the presence of live regions on asynchronous status. Defects found in that review were corrected and are covered by unit tests, because neither automated tool can detect them.
Two limits on that evidence should be read alongside the tables below. The interface changes made in August 2026 postdate the June 2026 axe-core crawl and have not been re-crawled in a browser. No evaluation with a screen reader has been performed, so criteria that depend on what is actually announced — including status messages, focus order in dynamic flows, and the structure of AI-generated feedback — are reported as “Partially Supports”. Formal third-party accessibility auditing has not been completed.
Applicable Standards / Guidelines
This report covers the following standards. “Included” indicates the conformance level is addressed in the tables below.
| Standard | Level A | Level AA | Level AAA |
|---|---|---|---|
| WCAG 2.0 | Included | Included | Not included |
| WCAG 2.1 | Included | Included | Not included |
| WCAG 2.2 | Included | Included | Not included |
Table 1 — WCAG Level A
| Success Criterion | Conformance Level | Remarks & Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Supports | Meaningful icons and controls expose accessible names (aria-label or a visible text label); decorative graphics are marked aria-hidden. Verified by automated linting (eslint-plugin-jsx-a11y, strict) and axe-core, both reporting zero violations across the application. Charts are exposed as images with a descriptive name, and the values they plot are additionally provided as a data table available to assistive technology, so the information in a chart is not available only in graphical form. |
| 1.3.1 Info and Relationships | Partially Supports | Page structure (headings, lists, landmarks) passes automated structural checks. On the student AI-feedback view, the view switcher is exposed as a tab set, score tables carry row and column header associations, and label/value pairs are marked up as description lists. Form hint and error text is programmatically associated with its input through the shared form component. Charts that previously exposed only an image label now also provide the plotted values as text. The body of AI-generated feedback is rendered from model-produced Markdown; the semantic structure of that generated content is not controlled by the application and has not been audited with assistive technology. Surfaces outside those listed have not been individually reviewed for relationships conveyed by visual presentation alone. |
| 1.3.2 Meaningful Sequence | Supports | Content is presented in a logical reading order and maintains meaning when accessed sequentially. |
| 2.1.1 Keyboard | Partially Supports | Interactive controls are native, keyboard-operable elements and pass automated keyboard checks. A code-level review of the custom widgets identified and corrected several controls that were operable only by pointer: dashboard tab sets whose unselected tabs could not be reached, column sorting that responded only to a click on the header cell, a drill-down table row with no keyboard equivalent, image and video resize handles, the resizable split divider's reset, and horizontally scrolling regions that contained no focusable element. Two gaps remain. Creating an inline annotation requires selecting text in a passage region that cannot receive keyboard focus, so annotation authoring is effectively pointer-only; reading and opening existing annotations is keyboard-operable. Separately, end-to-end keyboard operation has not been verified by a manual pass on a live build. |
| 2.1.2 No Keyboard Trap | Supports | Users can navigate away from all components using standard keyboard controls. |
| 2.4.3 Focus Order | Partially Supports | Focus order follows the visual reading order on audited pages. Thirteen confirmation and edit dialogs were found to be rendered as non-modal dialogs while presenting as modal, which left keyboard focus on the page behind them; these now take focus on open, confirm the modal focus behaviour provided by the browser, and return focus to the control that opened them when dismissed. The same focus handling was added to the mobile bottom sheet, and the scoring wizard now moves focus to each new step rather than leaving it on a button that has been removed. Other non-dialog overlays, popovers and multi-step flows have not all been individually verified, and focus order in dynamically updated regions has not been confirmed by a manual pass on a live build. |
| 3.1.1 Language of Page | Supports | The default language of each page is programmatically defined. |
| 3.3.1 Error Identification | Supports | User input errors are identified and described in text where applicable. |
| 3.3.2 Labels or Instructions | Supports | All form controls are programmatically associated with a visible label or an accessible name, and where a field carries helper text or an error message that text is now also associated with the control rather than only placed beside it. Verified by automated linting (eslint-plugin-jsx-a11y, strict) and axe-core, both reporting zero violations. |
| 4.1.2 Name, Role, Value | Partially Supports | UI components expose an accessible name and role, and no nested or mislabeled interactive elements remain; automated checking reports no violations. A code-level review of the custom controls then found declared roles and states that the implementation did not provide, and these have been corrected: dialogs that declared themselves modal without being modal, image and video resize controls that declared an adjustable value with no way to adjust it, a split-panel divider that exposed no position value, a filter control that declared a list-box popup it did not contain, a combobox that did not report which option was highlighted, and tab sets that did not identify the panel they controlled. This row is reported as partially supporting because that review was static; the corrected states have not been confirmed against assistive technology on a live build, and custom controls outside the shared component library have not each been individually reviewed. |
Table 2 — WCAG Level AA
| Success Criterion | Conformance Level | Remarks & Explanations |
|---|---|---|
| 1.4.3 Contrast (Minimum) | Supports | Text and meaningful UI elements meet the WCAG AA contrast ratios (4.5:1 normal, 3:1 large). Verified across public and authenticated pages by axe-core (zero contrast violations, June 2026). |
| 2.4.6 Headings and Labels | Partially Supports | Heading order and labels pass automated structural checks. The text of every heading, form label and control name defined in the application source has since been reviewed. Headings and form labels were found to be descriptive; no duplicate same-level headings describing different content were found. The defect identified was in list tables, where icon-only row controls were named only by their verb — "Edit", "Archive", "View" — repeated once per row with nothing identifying the record. Those controls now include the name of the record they act on, and several ambiguous form labels were made specific. Two limitations: headings and labels that are supplied at runtime from data entered by administrators (for example rubric, resource and assignment names) cannot be assessed here and depend on what those users enter; and a small number of section headings that are brief but disambiguated by their surrounding content have been left as written. |
| 2.4.7 Focus Visible | Supports | All interactive elements display a visible keyboard focus indicator, applied consistently through the shared design-system focus tokens. Verified across the component library and application (June 2026). |
| 3.3.3 Error Suggestion | Partially Supports | Input errors are identified and announced (role=alert), and the message is now programmatically associated with its input through the shared form component. Messages for the fields with a knowable correction have been made specific: email, date and month fields state the expected format with an example, numeric fields state the permitted range, and support-ticket fields state the required length instead of showing the validation library's default wording. The specificity of suggested corrections still varies elsewhere. Fields that rely on the browser's built-in constraint messages, some server-side messages reachable only when client-side checking is bypassed, and per-row messages in the roster import file validator have not been revised and may identify an error without suggesting the correction. |
| 4.1.3 Status Messages | Partially Supports | Status messages use ARIA live regions: toast notifications (role=status / role=alert) and scoring progress, completion, and errors across the assignment and score-wizard views (aria-live / role=status / role=alert). The student submission status indicator, which polls while work is being scored and previously changed to Scored or Failed silently, now announces the outcome and the score; the scoring wizard announces each step change; and the shared button reports its in-progress state, which covers the application's "Saving" and "Processing" controls. Announcement has not been verified with a screen reader. Several status surfaces are still not announced, the most significant being the result counts on list and search pages, which update in place when a filter changes, and progress reporting for roster imports and file uploads outside the scoring wizard. |