Accessibility

The standard we work to

WCAG 2.1 Level AA is what we design against, test against, and measure regressions against.

We do not claim to conform to it. Saying that honestly would take a full manual audit against every success criterion that applies, and we have not done one. So it is our target rather than a claim, and the sections below say what has been checked and what has not.

One interface

There is no accessibility mode to switch on, no lite version, no separate interface, and no third-party accessibility overlay. Everyone gets the same product. Overlays tend to paper over problems rather than fix them, so we would rather fix the page.

What that means in practice:

• Buttons are buttons and links are links. Because the controls are real, keyboard support and screen reader behaviour work by default instead of being simulated.
• Form fields have proper labels, not just placeholder text.
• Keyboard focus is always visible.
• When something finishes in the background, we announce it, so you are told rather than left on a page that quietly changed.
• The layout reflows, so zooming in does not break it.
• Animation respects your reduced motion setting.
• Colour is never the only thing carrying meaning. If something is flagged, it does not say so with colour alone.

How we check

Automated checks run on every change. They test our pages against the WCAG 2.1 A and AA rules and check that controls can be reached by keyboard. If a change breaks either, it does not ship.

People check the rest, periodically: keyboard-only walkthroughs of the main teacher workflows, and review of how screens read in context.

Automated tools catch somewhere between 40 and 60 percent of accessibility problems. A clean run means nothing machine-detectable broke. It does not mean the page is accessible. The things that matter most to someone using a screen reader, like whether alternative text is actually meaningful and whether focus moves sensibly through a real task, can only be judged by a person.

Where we are now

Most of the product comes back clean under our automated checks. Three problems are open, and we would rather name them than let you find them.

On the grading workspace, some text does not have enough contrast against its background, and some controls in the margin comment cards are nested inside each other in a way that screen readers handle badly.

In the rubric builder, two controls work with a pointer only and cannot be operated by keyboard. That number is capped and can only go down.

Four things we have not done, and would need to before claiming conformance: a full manual audit against every applicable criterion, an audit by an outside expert, a published VPAT, and testing across the major screen readers.

Telling us about a problem

If something is hard or impossible to use, please tell us. You can use the problem report control on any page inside the product, or email support@writegrader.com.

Accessibility reports go into the same queue as any other defect and are prioritised by how badly they block someone, not by how many people reported it. One person telling us a function cannot be reached by keyboard is treated as a blocking problem. We will tell you when it is fixed.

What comes next

In this order:

1. Fix whatever the automated sweep finds.
2. Finish a manual keyboard-only pass over the main teacher workflows.
3. Do a screen reader pass over the same workflows.
4. Publish a VPAT built from the results of those two.
5. Consider bringing in an outside expert to audit us.

We have deliberately not put dates on these. We would rather give you an order we are actually following than dates we miss. If your institution needs committed dates, raise it while we are working out the contract and we will talk about it properly.