Accessibility

How this site is built

1. Plain HTML with a real heading structure, landmarks and a skip link on every page.
2. Everything works with the keyboard. The focus indicator is loud on purpose.
3. Navigation, the mobile menu and the contact form are HTML and CSS, with no JavaScript. The one script, on the language chooser, only adds type-to-filter; the full list works without it.
4. Text adapts to narrow screens and zoom without needing a horizontal scrollbar, and nothing is locked to a fixed size.
5. Decorative artwork is marked as decorative, so a screen reader skips it instead of reading out a background.
6. Motion is minimal, and what there is respects the reduced-motion setting in your operating system.
7. Non-English text is tagged with its language. That means screen readers pronounce it correctly and conversation turns stay in the right order in the markup, on both sides of the exchange.

How the application is built

1. It is written to WCAG 2.2 AA, on the same design system as this site, so the colours, the focus indicator and the type scale are the ones documented there.
2. Motion respects the reduced-motion setting in your operating system, as it does here.
3. The status of a conversation is announced rather than only shown, so a screen reader hears that a turn is being translated, revised or waiting on an answer.
4. Controls carry labels rather than relying on an icon, and anything decorative is hidden from assistive technology instead of being read out.
5. Dictation on your own device types into a turn the same way it types into an email, so nobody has to learn a new way of speaking to it.
6. The interface renders in the language of the person reading it, not only the translations, on both sides of the conversation.

Colour and contrast

Every foreground and background colour, on this site and in the application, comes from the InMyWords design system, with the contrast ratios documented. Body text meets WCAG AA at 4.5:1 or better, while rails and markers that carry meaning meet 3:1 or better. These checks run before each deployment.

Colour never carries speaker, status or risk on its own. Every turn names its speaker and its language in text and every marker has a label.

What has been checked

The site has been checked for keyboard operation, heading order, colour contrast of text against its background and behaviour at high zoom (320px, 390px, 768px, 1024px and 1440px).

What has not been checked

Neither the site nor the application has been through a formal audit against WCAG 2.2 AA by an independent tester, and neither has been tested end to end with every combination of screen reader and browser. Both are written to that standard; until an independent tester has said so, we are not claiming a conformance level for either. When that has happened, this page will display the result, including anything that failed.

Known gaps

1. The home page headline sits over photographic artwork. The artwork is darkened behind the text so the ratio holds, but it is a photograph and not a flat panel.
2. The web font shipped with this site covers Latin and Latin Extended. Text in another script would fall back to a system font until the matching Noto subset is added.
3. In the application, the language of a turn is declared on the note beside it but not on every rendered turn, so a screen reader may announce a translated turn in the voice for the wrong language. This is a fix rather than a design decision.

Reporting a barrier

If something here stopped you, please tell us: [email protected]. It helps to know what you were using, so please share browser, assistive technology and what you were trying to do. We treat these as bugs, not feedback, and a report about a barrier gets answered before most other post.

This statement describes both inmywords.chat and the InMyWords application. A barrier in either is reported to the same address.