Accessibility Statement

What is already true

• Colour contrast. Body text meets 4.5:1 and interactive elements meet 3:1 against their background, in both light and dark themes. The palette was chosen against those thresholds rather than checked afterwards.
• Keyboard. Every tool can be completed without a mouse. Tab order follows the visual order, and there is a “skip to content” link before the navigation.
• Focus. A visible focus ring appears for keyboard users on every interactive element, and is suppressed for pointer users so it never looks like a bug.
• Colour is never the only signal. The diff viewer marks additions and removals with symbols as well as colour, because roughly one in twelve men has a red-green colour vision deficiency.
• Labels. Every input has a real associated label. Icon-only buttons carry an accessible name. Nothing depends on a placeholder as its label.
• Motion. prefers-reduced-motion disables transitions and smooth scrolling site-wide.
• Announcements. Errors and confirmations use live regions, so a screen reader user hears “Copied” without focus being moved.
• Zoom. The layout works at 200% zoom and at 320 CSS pixels wide without horizontal scrolling.
• Structure. One h1 per page and a heading order with no skipped levels, so heading navigation works.

What is not yet true

Stating this is more useful than claiming full conformance:

• The diff viewer is a data table with many rows. It is navigable, but not yet as pleasant to traverse with a screen reader as it should be.
• Drag-and-drop file zones have a keyboard-accessible browse button, but reordering a file list uses buttons rather than a proper drag-and-drop accessible pattern.
• Testing so far is automated plus manual keyboard passes. Full screen-reader testing across NVDA, JAWS and VoiceOver has not been completed.

Reporting a barrier

If something here blocked you, please tell us at support@adeptbay.com. Include the page, what you were trying to do, and your browser and assistive technology if you know them.

Accessibility bugs are treated as correctness bugs, not enhancements: they go to the front of the queue with the ones where a tool returns a wrong answer.