Accessibility statement

Our commitment

We aim to meet WCAG 2.2 Level AA across the site. We are honest that we are partially conformant: most of the site meets that bar, and the areas that do not are listed below rather than quietly omitted.

Accessibility here is treated as a defect class, not a project. A keyboard trap is a bug with the same priority as a wrong hash.

What is in place

Every page also starts with a skip to content link, so keyboard and screen reader users are not walked through the navigation on every visit.

Keyboard shortcuts

Tab / Shift + Tab

Move forward and backward through every interactive element on the page.

Ctrl + K  or  ⌘ + K

Open the command palette and jump to any tool by name. Escape closes it.

Arrow keys

Adjust panel splitters and editor heights once the handle has focus, for people who cannot drag.

Enter

Runs the primary action from any single-line input, so a check never requires reaching for a button.

Escape

Closes overlays, the palette and full-screen panels, returning focus where it started.

Known gaps

These are real and we are working on them. Listing them is more useful to you than a compliance badge.

• Code editors. The formatter panes are custom components. Line-level navigation and screen reader announcement inside a large document are weaker than in a plain textarea. Every formatter therefore keeps a copy button and a plain-text export as an accessible path to the same result.
• Drag-based resizing. Splitters and height handles are keyboard-operable, but the visual affordance still reads as drag-only. The buttons beside them do the same job.
• Dense result tables. Some network and security reports render wide tables that require horizontal scrolling on small screens. A text export is available on those pages as an alternative.
• Third-party output. Where a tool renders data from an external provider, we cannot control the wording or structure of that data.
• Colour-coded severity. Severity always carries a text label, but a few older tool pages still lean harder on colour than we would like.

How this was assessed

This statement is based on internal review, not a third-party audit — and saying so matters, because a great many accessibility statements imply an audit that never happened.

• Keyboard-only walkthroughs of every page, checking focus order, visible focus and escape routes
• Automated checks with browser accessibility tooling on representative pages
• Contrast measured against WCAG thresholds in both light and dark themes
• Zoom and reflow testing to 400% and at narrow viewport widths
• Spot checks with a screen reader on the main flows

An independent audit is the right next step, and this page will be updated with its findings — including the failures — when one is done.

Report a barrier

If something on this site blocked you, please tell us. We treat these reports as priority bugs, and a specific report is worth more than any amount of internal testing.

Email [email protected] with the page URL, what you were trying to do, and what got in the way. If you use assistive technology, naming it and its version helps us reproduce the problem. We aim to respond within 2 business days.