Skip to content
Euphona

Legal

Accessibility statement

The short version

We build to WCAG 2.2 AA and check it automatically on every deploy — every page, four screen widths, and a deploy that fails the check does not ship. What we have not done is test with a real screen reader or commission an independent audit, and this page says which claims rest on which.

A summary is not the agreement. Where the two differ the clauses apply — but if the summary is misleading, that is our mistake to fix rather than yours to discover.

What we aim at

WCAG 2.2 Level AA, across the marketing site, the free tools and the Studio alike. Our users are mostly in the United States, where the ADA sets no formal technical standard for a private business — but WCAG is what courts have consistently used to decide these cases, and web accessibility suits ran to over three thousand in US federal court last year. The European Accessibility Act, enforced since June 2026, asks for 2.1 AA outright. Building to 2.2 AA satisfies both with room rather than exactly, so that is what we build to.

The same target applies at every screen size we support, which is a continuous range from 320 px to 3840 px. There is no separate mobile site and no reduced feature set on a small screen — the reason being that a single responsive codebase is the only version we can actually keep accessible, since a second one is a second place for it to rot.

How we are doing against it

Every page on this site currently passes. That is a statement about automated rules rather than about every human experience of the site — see below — but it is measured on every build rather than asserted once.

“This site” means this one. The target above covers the Studio too, and the Studio is still being built, so nothing here is a measurement of it. When it opens it goes through the same check on the same deploy gate, and this paragraph will say so with its own number. We are separating the two because a statement that quietly lets a tested marketing site vouch for an untested application is the specific way these documents go wrong.

Three things go beyond the minimum, because they are where accessibility is usually lost in practice rather than in principle:

  • Touch targets are at least 44 px under a coarse pointer, not the 24 px that WCAG 2.2 would accept. A thumb is not a mouse and the standard’s floor is a floor.
  • Nothing is hover-only. Every action reachable by hovering is reachable by tapping and by keyboard, because a hover-only control simply does not exist on a touch screen.
  • Keyboard shortcuts are never the only route. The command palette and the transport keys are accelerators; every task they perform can also be done by pointing at something.

How this is checked

On every deployment, automatically, and a failure stops the deployment rather than filing a ticket. The check loads every page in a real browser at four widths — 320, 768, 1280 and 1920 px — and for each one asserts that axe-core reports no violation at WCAG 2.0, 2.1 and 2.2 Level A and AA; that nothing overflows horizontally; that every interactive target meets the size floor; and that the skip link is real once focused rather than merely present in the markup.

The most recent run covered 212 page renders and reported no violation, no overflow and no undersized target. We publish that number rather than an adjective because a number is a thing you can ask us to reproduce.

What we have not tested

This is the part of an accessibility statement worth reading, and most of them do not have one.

  • No screen-reader testing has been done by a person. Automated rules find missing labels and bad contrast; they do not find a heading order that makes no sense when read aloud, or a live region that announces the wrong thing at the wrong time. Until someone has actually driven this site with VoiceOver and TalkBack, we cannot tell you it works well with one — only that it does not break the rules we can check.
  • No independent audit. Everything above is our own testing of our own work. An external review is worth commissioning and has not been.
  • No testing with disabled users. Which is the only test that finally counts, and the one we most want to hear about from you in the meantime.
  • The audio tools have a floor we cannot design away. A loudness meter and a before/after comparison are, at bottom, about hearing something. We can and do make every number readable, every control operable and every result stated in text rather than only in sound — but we will not pretend a hearing-impaired user gets the same thing from an A/B player that a hearing one does.

Telling us it is wrong

Write to support@euphonaai.com and say what you were trying to do, what happened, and what you were using — the assistive technology and browser matter more than anything else you could tell us. You do not need to identify the guideline; that is our job.

We aim to reply within five working days, and to tell you either when it is fixed or why it is hard. If something on this site is blocking you right now, say so and we will look for a way to get you what you needed while the fix is built.

If we do not fix it

You are entitled to escalate, and it is not a courtesy we are extending. In the United States you can file a complaint with the Department of Justice under the Americans with Disabilities Act, and in several states — California among them — inaccessibility carries a private right of action and statutory damages, so you may also have a claim of your own. In the European Union each Member State designates an authority that takes complaints about inaccessible consumer services under the Accessibility Act, and you can go to the one where you live without going through us first. In the United Kingdom the route is the Equality Advisory and Support Service.

We would rather you told us first and got it fixed. But a page that describes a right and then hides the route to exercising it is doing the opposite of what this document is for.