Accessibility
Last updated: 6 August 2026
Qortex Tools aims to meet WCAG 2.1 Level AA. This page describes what we do to get there, what is verified, and what is not.
How this is verified
Accessibility is a build gate, not a review step. A pull request that introduces an accessibility violation does not merge.
Every change runs automated accessibility checks with axe-core, in Chromium, Firefox and WebKit, across the main user-interface states of every tool. Zero violations is required, not aspired to.
We also verify a keyboard-only path through each tool, and colour contrast is enforced by a lint rule that rejects any colour not in the approved palette.
Automated testing is not sufficient on its own. It reliably catches contrast failures, missing labels, and structural problems. It does not catch whether a screen reader announcement is genuinely useful, or whether a control makes sense to someone who cannot see it.
What we do deliberately
Results are announced as a summary, not read aloud in full. When a tool finishes, a screen reader hears something like "three problems found in 1,204 lines", not the entire output. Reading ten thousand generated rows aloud would be hostile.
The output then sits in a labelled region that receives focus, so you arrive at it deliberately rather than having it read at you.
Every interactive control is reachable and operable by keyboard, with a visible focus indicator that survives on every background.
Colour never carries meaning alone. A failed validation is marked by position, an icon and a message, not only by being red.
Motion respects prefers-reduced-motion.
Layout does not shift as content loads. Regions reserve their space in advance, which matters for anyone using magnification.
Known limitations
Stated plainly rather than omitted.
The code editor. The API Response Validator uses a code editor component for syntax highlighting and line anchoring. It is keyboard accessible, but a complex editor is never as straightforward with a screen reader as a plain text area. If it causes you difficulty, tell us: a simpler input mode is feasible and we would rather know it is needed.
Large result sets. A validation producing thousands of errors renders a capped list. Navigating that many results is laborious regardless of assistive technology.
Screen reader testing is automated, not manual. We verify structure and announcements programmatically. We have not conducted testing sessions with screen reader users, and until we do, we cannot claim the experience is good rather than merely compliant.
Browsers we support: current versions of Chrome, Safari, Firefox and Edge. Older browsers may not render correctly, and the tools require JavaScript. Guide content and page structure remain readable without it.
If something does not work
Please tell us. A specific report is more useful than a general one: which tool, what you were doing, what assistive technology, and what happened.
The contact form, or email support@qortexlab.com.
We will respond, and we treat accessibility defects as defects rather than enhancement requests.
Where we are heading
WCAG 2.2 Level AA is the newer standard. We will state it here once our build checks and a manual review have been aligned with it, rather than claiming it in advance.