Accessibility

We aim to meet WCAG 2.2 Level AA. Accessibility is treated as a core requirement, not an afterthought.

What we do

• Every control has an associated label, and choosing a file works from the keyboard as well as by drag-and-drop — the drop zone contains a real button, so dragging is never the only route.
• Processing status, progress and completion are announced to screen readers through aria-live regions, and the search result count is announced as you type.
• Status is conveyed with text and icons, not color alone.
• Sliders expose their current value, and a control that cannot affect the output — the quality slider on PNG or lossless WebP — is disabled with the reason stated next to it rather than left live and ignored.
• Focus styles are clearly visible, focus stays where you are working when a panel closes, and touch targets meet the WCAG 2.2 minimum size.
• Tables that scroll sideways can take focus, so they can be scrolled without a pointer.
• Links inside body text are underlined, not distinguished by color alone.
• We respect the prefers-reduced-motion setting.
• Pages carry no horizontal scroll down to a 320 px viewport, and remain usable at 200% zoom.

How this is checked

Every release runs an automated axe-core audit against WCAG 2.0, 2.1 and 2.2 A/AA rules on the home page, the tool index, a category page, four tool pages and the guides — on desktop and on a mobile viewport — and fails the build on any critical or serious violation. Alongside it, end-to-end tests complete a whole job (choose a file, change a setting, process, download) using only the keyboard.

Automated testing does not prove a page is accessible; it catches the machine-checkable subset. We have not commissioned an independent audit or user testing with assistive-technology users, and we would rather say so than imply a level of assurance we do not have.

Feedback

If you encounter an accessibility barrier, please tell us at [email protected] so we can fix it.