Accessibility
Proving you're human
shouldn't have a timer.
Nearly every way to prove you're a person runs on a countdown. A code appears, you have thirty seconds to read it and type it, and if you need longer than that the internet decides you're not real.
That's a strange way to treat people, from an industry whose whole job is telling humans apart from machines.
22 of 33
Only twenty-two of thirty-three tested combinations of screen reader and authentication method reached acceptable usability. The rest were somewhere between difficult and impossible.
“Broken Access”, ACM Web Conference, 2025The fields don't announce themselves
One-time-code inputs routinely ship without accessible names or live regions. A screen-reader user may not be told a code was sent, where to type it, how long they have, or whether it worked.
Thirty seconds is a policy decision
Nothing about security requires a code to expire while you're still reading it. That window excludes people using switch control, magnification, or simply moving at their own pace.
Nobody in this category competes on it
We looked at every major authenticator app, including the ones the privacy community recommends. Not one of them markets accessibility as a strength. It's an open lane, and it shouldn't be.
Why ours doesn't have that problem
Not because we solved a hard problem. Because a signed credential is a different shape from a code you retype — and that shape happens to be the accessible one.
| A code you type | A 5arz badge | |
|---|---|---|
| Time limit | 30–60 seconds | None |
| You must read something | Yes, accurately | No |
| You must retype something | Yes, without error | No |
| Fails if you're slow | Yes | No |
| Works one-handed or by switch | Often not | Yes |
| Works with no sight at all | Depends on the site | Yes |
Your device holds the credential and presents it when asked. There's nothing to read, nothing to transcribe, and no clock. We didn't design that for accessibility — but it is the accessible answer, and it would be strange not to say so.
What we commit to
Written as commitments rather than features, because these are things we should be held to.
- No step in any 5arz flow will ever have a time limit. Not verification, not recovery, not consent. If a future feature seems to need one, it gets redesigned.
- Every state change is announced. Live regions on every result, error and transition — so nothing important is communicated only by something appearing on screen.
- Every flow completes by keyboard alone, and by switch control. No drag gestures, no timed double-taps, no interaction that assumes a steady hand.
- Nothing is signalled by colour alone. The green dot that shows verification is running always carries a text label beside it.
- WCAG 2.2 Level AA across the site and the app. The standard referenced by Section 508 in the US and EN 301 549 in Europe. Audited, with the report published here.
- Motion is optional. We honour prefers-reduced-motion everywhere, including on this page.
- Plain language, checked. Our consent screens read at around a grade-8 level. Consent nobody can read isn't consent.
- Accessibility bugs are treated as functional bugs. Same queue, same priority. Not a backlog labelled “a11y” that never gets scheduled.
Where we're not there yet
A page like this is worth nothing if it only lists wins.
The audit isn't done
We build to WCAG 2.2 AA, but we have not yet completed an independent audit. When it's done, the report goes on this page — including whatever it finds.
First-time enrollment uses a vendor
Your first document check runs in an identity vendor's own flow, and its accessibility isn't ours to control. We're testing vendors on this and will say which we use and how they perform. Every check after the first is ours, and has no timer.
Found a barrier? Tell us.
This goes to a person, not a form queue. Tell us what you were trying to do, what assistive technology you use, and where it broke. We'll reply.
If you'd rather not email, anything you send to info@5arz.com marked “accessibility” reaches the same people.