Accessibility

Keyboard. Everything interactive is reachable and operable from a keyboard, with a visible focus outline that is not removed. Every page starts with a skip link to the main content.

Screen readers. Pages use real headings in order, real landmarks, and real form labels tied to their inputs. Errors are announced when they appear rather than only shown in red. Icons that carry meaning have text; icons that repeat adjacent text are hidden from assistive technology instead of read twice.

Contrast. Text meets the WCAG AA contrast ratio against its background in both the light and dark palettes, including secondary text, which is the usual place a design fails.

Motion. The interface has animation, and all of it stops if your system is set to reduce motion.

Zoom and text size. The layout is built in relative units, so enlarging text enlarges the interface rather than cutting it off.

Colour. Nothing is communicated by colour alone. A state shown in colour is also shown in words.

No testing with real users of assistive technology. Automated checks and careful construction are not a substitute for that, and it is the most significant gap on this page.

No testing with voice control software or a switch device.

No formal audit against WCAG 2.2, and therefore no conformance claim.

No setting inside the product to reduce motion independently of the system one. If your operating system is not set to reduce motion, there is currently no way to ask for it here.

The photo pipeline has no way to add alternative text to a profile photo yet. A screen reader user currently gets no description of a photo, which on a product built around photos is a real limitation rather than a detail.

Tell us what you were trying to do, what happened, and what you were using, the browser, and the assistive technology if any. That is usually enough to reproduce it.

Contact has the routes. Accessibility problems are treated as defects, not as requests.