A widget that collects testimonials sits on other people’s websites, so its accessibility becomes theirs. We treat that as our problem, and we publish what we actually tested rather than a badge.
WCAG 2.2 Level AA is the target for the ReviewMix app, this website, and the embeddable widget in both of its delivery modes.
We do not claim to be conformant, and the distinction is deliberate rather than modest. A conformance claim means every success criterion has been evaluated on every surface, and part of that evaluation — listening to the product with a screen reader — has been done by software here, not by a person. Until that changes, saying “conformant” would tell you something we have not earned.
Automated accessibility scans cover every public route of the app, this website, the dashboard and its empty and error states, all five onboarding steps, and both widget delivery paths, at desktop and mobile widths. They live in the repository as a test suite and are run against the product as those surfaces change. They are not yet wired to run automatically on every deploy, so their currency depends on us running them rather than on a gate.
On top of that, a person has driven the keyboard through the product, and the depth varies by surface in a way worth being precise about. On the app’s public routes, all five onboarding steps, the email-preferences page and the widget in a real embed, the walk followed the real Tab order and confirmed that focus stays visible and nothing traps you. On this website and the dashboard, each control was checked individually without re-verifying the full traversal. The collection page where your customers leave a testimonial was redesigned after its last manual pass, so its current form is covered by automated scans but has not been walked by hand again yet.
Defects those passes found were fixed rather than recorded — the widget’s controls, page titles across several routes, a focus ring on the preference page, and the tab strip on this site’s own homepage among them.
No human has audited ReviewMix with a screen reader. We check the things software can check — that live regions announce real content rather than sitting empty, that controls carry accessible names, that roles and structure are what they claim to be — and those checks run on every deploy. They cannot judge whether an announcement is useful, whether the reading order makes sense in practice, or whether a flow is merely operable rather than actually pleasant. That judgement needs a person, and we have not had one do it.
Automated tooling of this kind reaches roughly a third of the AA success criteria. We say this plainly because a green test suite is easy to present as more than it is.
Two further limits worth naming: the widget renders inside websites we do not control, so the surrounding page’s colours and stylesheet can affect contrast in ways we cannot measure from here; and third-party components we embed, such as the anti-spam challenge on the collection form, are only as accessible as their vendors make them.
Send us a message and tell us what you were trying to do, what got in the way, and what you are using — a browser and screen reader name is plenty. It reaches the person who built the thing, and an accessibility barrier is treated as a defect, not a feature request.
If you rely on assistive technology and are willing to tell us what does not work, we want to hear from you specifically. That is the pass we have not been able to run.
Last reviewed 19 August 2026. This statement describes what has been tested at that date; it is updated when the testing changes, not on a schedule.