Accessibility statement

Nazeel's dashboard, CLI output and public website are built to be usable without a mouse and without sight. This statement says what is checked, how, and what is not yet done — the last part being the one that makes the rest worth reading.

The target is WCAG 2.2 level AA. Nazeel has not been audited by a third party against it, so this is a statement of what the product does and how it is verified, not a conformance claim someone else has signed.

What is checked automatically

Every change runs these; a failure blocks the build.

• axe-core over the pages people actually work in — sign in, environments, new environment, environment detail, the admin licence page and the policy page — in English and in Arabic. Arabic is not a formality here: RTL is where these defects hide, and a page passing in English says nothing about it mirrored.
• axe-core over the public website (make a11y): the landing page, the privacy and terms pages, the 404 page and the generated documentation, again in both languages.
• Keyboard operation of environment creation, the flow a developer performs most often: every stop in the tab order is a real control with a name, and the wizard advances with the keyboard alone.
• Focus management in dialogs: focus moves into a dialog when it opens, cannot leave it with Tab while it is open, and returns to whatever opened it on Escape.
• The tabs pattern: arrow keys move between tabs, Home and End jump to the ends, and only the selected tab is in the tab order so Tab moves past the strip rather than through it.

What the product does

• Every form control has a programmatic label, not only a visible one nearby. Hints and error messages are linked with aria-describedby, so the text explaining a field's format is read out rather than seen only by people who can see it.
• Status is never colour alone. Every state carries a shape and a word beside its colour, which is also why the design uses one accent rather than a palette of meanings.
• Both languages, both directions. The interface mirrors through CSS logical properties; numbers, identifiers, image references and durations stay left-to-right inside Arabic text, because a container tag reversed is a container tag that does not work.
• Visible focus. The focus ring is part of the design tokens and is never removed.
• Headings describe the document. Levels do not skip, so the outline a screen reader navigates by matches the page a sighted user sees.
• Motion is minimal, and what exists respects prefers-reduced-motion.

What is not covered

• Colour contrast is verified against the design tokens, not in the automated run. The test environment computes no real colours, so the rule cannot produce a meaningful result there and is turned off in that run specifically — not because contrast does not matter.
• The web terminal is an xterm.js canvas. A screen reader cannot read it usefully. This is inherent to a terminal emulator rather than something Nazeel has neglected; kubectl exec in your own accessible terminal does the same job, and the CLI is a full alternative to the dashboard for the common flows.
• No third-party audit has been performed.
• No formal screen-reader testing matrix. The automated checks cover semantics; they do not replace a person using NVDA, JAWS or VoiceOver end to end.

Reporting a problem

If something here is wrong, or you hit a barrier this statement does not mention, report it the way you would any other defect. An accessibility statement that is never corrected is worth less than none.