Accessibility statement

The Nezal dashboard is built to be usable without a mouse and without sight. So are the CLI output and the public website. This statement says what is checked and how. It also says 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. Nezal 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 rather than 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 — from sign in and the environment list through the new-environment wizard and environment detail to the admin licence and policy pages — in English and in Arabic. Arabic is not a formality here: RTL is where these defects hide. A page passing in English says nothing about it mirrored.
• axe-core over the public website: the landing page and the privacy and terms pages as well as the 404 page and the generated documentation. This runs in both languages too.
• Keyboard operation of environment creation because it is 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 and cannot leave it with Tab while it is open. It returns to whatever opened it on Escape.
• The tabs pattern: arrow keys move between tabs and Home and End jump to the ends. 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 and 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. That is also why the design uses one accent rather than a palette of meanings.
• Both languages and both directions. The interface mirrors through CSS logical properties. Numbers and identifiers stay left-to-right inside Arabic text along with image references and durations 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 and not in the automated run. The test environment computes no real colours so the rule cannot produce a meaningful result there. It 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 Nezal has neglected. kubectl exec in your own accessible terminal does the same job. 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 or JAWS or VoiceOver end to end.

Reporting a problem

Report anything wrong here the way you would any other defect. The same goes for a barrier this statement does not mention. An accessibility statement that is never corrected is worth less than none.