Accessibility Statement
Version 1.0 · Last updated: 28 August 2026
Zanza wants anyone to be able to train, log their work and review their progress — whether or not they use a screen reader, a keyboard instead of a mouse, or system text at twice the size.
This statement says where we are today, without dressing it up. We would rather publish an honest list of what fails than a conformance claim nobody has verified.
1. Target and current status
Target: WCAG 2.2 level AA.
Status: partially conformant. We meet some of the criteria and we know we fail others. They are listed in §3.
The status is not the same across our three surfaces:
| Where | Status |
|---|---|
| zanzahq.com (this site) | Closest to the target. Plain HTML, native controls, images with alternative text |
| app.zanzahq.com (professional dashboard) | Partially conformant, with specific and localised gaps |
| Zanza mobile app (iOS and Android) | The furthest behind. Its main screens are not usable with a screen reader |
2. What does work today
Colour contrast. Text colours were measured against criterion 1.4.3 (minimum 4.5:1 for normal text):
- Mobile app: every main text pair passes AA. The worst case measured is 6.25:1.
- Dashboard: primary text reaches 17.2:1 in light theme and 16.0:1 in dark; secondary text, 4.7:1 and 6.9:1. Both pass.
Images. Every image in the dashboard and on this site carries alternative text.
Keyboard in the dashboard. The plan builder and catalogue tables can be traversed entirely by keyboard, including jumping to the end of a filled block with Ctrl/⌘ + arrow, and extending the selection with Shift.
Screen reader labels in the dashboard. Two out of three components carry explicit labels or roles.
3. What does NOT work yet
This is the part that matters. Each item is a known failure, not a suspicion.
3.1 Mobile app
- Charts have no text alternative. The quality radar, the progress curves and the body discomfort map are custom-drawn (40 components). To a screen reader they simply do not exist today: they announce neither what they are nor what they show.
- Many tap targets are not announced. 56 interactive areas are built on a plain gesture detector, which does not tell the system that it is a button or what it does.
- There are almost no accessibility labels of our own: one in the whole project. Standard components bring theirs, but everything custom-drawn — which is a lot — stays mute.
- We have not checked what happens with system text at large sizes. Dense screens (the logging sheet, the set tables) will most likely break their layout.
3.2 Professional dashboard
- Tertiary text has insufficient contrast. Indices and small hints sit at 3.2:1 in light theme and 4.2:1 in dark, below the required 4.5:1.
- Seven interactive elements cannot be reached with the Tab key, because they are built on non-interactive elements instead of buttons.
- The "reduce motion" preference is honoured in only one component. Every other animation plays regardless.
3.3 All surfaces
- Information conveyed by colour alone is not always duplicated in text. Training qualities (strength, hypertrophy, power…) are distinguished by colour in tables and charts. Most places also carry a written label — but not all of them.
4. How we assessed it, and what we did NOT test
A technical self-assessment of the source code, carried out on 28 August 2026: a review of accessibility labels and interactive elements, and colour contrast measured with WCAG's own formula, not by eye.
What we have not done, and why we do not claim conformance:
- We have not tested with real screen readers (VoiceOver, TalkBack, NVDA).
- We have not completed a keyboard-only walkthrough.
- We have not tested at 200% zoom.
- There has been no third-party audit and no testing with disabled people, which is the only thing that turns a list like this into a real evaluation.
When that happens, we will update this page and say so here.
5. If something does not work for you, write to us
Tell us what you were trying to do, on which screen, and with what assistive technology (screen reader, keyboard, magnification…). You do not need technical vocabulary and you do not need to justify anything.
We reply within 20 working days — deliberately the same deadline the Privacy Policy gives for ARCO rights: if an accessibility barrier stops you from exercising one of those rights, the deadline for asking for help should not be longer than the deadline for the right itself. And if what you describe is a barrier that is not on the list above, we add it.
In the meantime, we give you the alternative route. If a barrier stops you from doing something on the platform — checking your plan, exercising a right, reading a document — tell us what you need and through which channel, and we handle it that way. The Privacy Policy says the same for legal documents, which we provide in an accessible format to anyone who asks, free and without explanations.
A right you can only exercise through a channel you cannot use is not a right.
6. What we will fix first
No promised dates, but a definite order, and a criterion behind it: what locks someone out entirely comes before what merely inconveniences them.
- Making the app's tap targets announce themselves. This is what makes the app unusable with a screen reader today.
- A text alternative for charts: making the radar and the curves readable as figures.
- Raising the dashboard's tertiary text contrast above 4.5:1.
- Turning the seven elements the Tab key cannot reach into real buttons.
- Honouring "reduce motion" across every animation.
- Testing with a screen reader and keyboard-only, and correcting this page with what comes out.