Skip to content
ToolZool
Buy Zooly a coffee

Legal · last updated 1 September 2026

Accessibility

What we have built for, what we test, what we know is imperfect, and how to tell us when we have got it wrong.

Our target

ToolZool aims to meet WCAG 2.2 Level AA. That is a target we are working towards deliberately, not a certification we have been awarded.

What is built in

Keyboard. Every interactive element is reachable and operable by keyboard. A skip link is the first focusable element on every page. Focus is always visible — we have not removed a focus ring anywhere.

Structure. Pages use real landmarks and one h1, with heading levels that descend without skipping. Breadcrumbs, navigation and lists are marked up as such, so a screen reader announces them correctly.

Contrast. Body text meets or exceeds a 4.5:1 contrast ratio against its background in both light and dark themes. Where the approved design fell just short of that, we adjusted the colour rather than the requirement.

Motion. The site honours prefers-reduced-motion. With it enabled, transitions and animations are effectively removed rather than merely shortened.

Themes. Light and dark are both designed, not inverted. The site follows your system preference by default and remembers an explicit choice.

Text. Layouts use relative units and reflow to 400 per cent zoom without horizontal scrolling. Wide content — tables and code — scrolls inside its own container rather than pushing the page sideways.

Images. Decorative illustrations carry an empty alt, so assistive technology skips them rather than announcing “Zooly” repeatedly. Images that carry meaning are described.

What we test

Every change is checked with an automated accessibility scan across the main page types, and the keyboard path through the header, the mobile navigation, search and forms is walked manually. Automated scanning catches perhaps a third of real problems, so we do not treat a clean scan as a pass.

Known limitations

Stating these is more useful than claiming they do not exist.

  • We have not yet tested with screen readers systematically. We have followed the specifications carefully, but specification-following is not the same as testing with VoiceOver, NVDA and JAWS. That testing is planned.
  • The tool interface is not yet complete. The compression tool’s interface is published in a disabled state while the engine is built. Its accessible behaviour under real use — progress announcements, error messages, focus management after a result — will be built and tested as part of making it work, not retrofitted.
  • We have not had the site audited independently. Everything above is our own assessment.

Telling us we got it wrong

If something on ToolZool is difficult or impossible for you to use, please tell us through the contact page. Describe what you were trying to do, what happened, and what you were using — browser, assistive technology, device.

We treat accessibility reports as bugs, not as feature requests. We will tell you what we are doing about it and when.