Accessibility statement

What works today

• Every control is reachable and operable with a keyboard alone, in a logical order, with a visible focus ring that is never removed.
• A Skip to content link is the first thing a keyboard or screen reader user reaches on every page.
• The downloader announces its state changes (loading, error, result) through a live region, so a result is not silent.
• Buttons that show only an icon carry an accessible name, and decorative images and icons are hidden from assistive technology.
• Headings run in order, one H1 per page, so a screen reader's heading list is a usable table of contents.
• Text and interface colours meet WCAG 2.1 AA contrast in both the light and dark themes.
• The theme follows your system preference until you override it, and the choice is remembered.
• Animations and scroll effects are disabled when your system asks for reduced motion.
• Layouts reflow to a single column and stay usable at 200% zoom and on small screens.
• Form fields have real labels, and errors are described in words rather than by colour alone.

Known gaps

Listed because pretending they do not exist helps nobody.

• The command palette (Cmd or Ctrl + K) has not been tested end to end with a screen reader. Everything it does is reachable through the normal interface, so nothing is exclusive to it.
• Long batch queues announce each row's status individually, which can be verbose. Grouping those announcements is not done yet.
• The QR handoff dialog traps focus but has not been audited against every screen reader and browser combination.
• Guide screenshots have descriptive alt text, but there are no long descriptions for the more complex annotated images.
• No formal third-party audit has been carried out. Everything above is self-assessed, and this page says so rather than implying a certification that does not exist.

Reporting a barrier