Accessibility
Accessibility
The constraint we designed this site around first is keyboard operation. If a component cannot be reached, understood and dismissed without a pointer, it does not ship. Our target is WCAG 2.2 Level AA. This page states what has actually been built, what has not yet been independently verified, and how to tell us when we have got something wrong.
- Target
- WCAG 2.2 Level AA
- Conformance claim
- None. Self-assessed only, and not audited by a third party
- Verified by us
- Keyboard-only traversal, 400% zoom, reduced-motion, 320 px width
- Not yet done
- Screen-reader testing with people who use one daily
- Feedback response
- Target of five business days — to be confirmed as a commitment
Draft structure only. This is not legal advice. The engineering detail further down this page is accurate as at the date below. This document as a whole is still a structural template. No lawyer has reviewed it, and it makes no legal claim about compliance with any Act or standard.
The wording must be replaced with counsel-reviewed text before this site is published, particularly anything that could read as a conformance claim or a binding service commitment. Read the technical lists as a description of what the code does, not as a warranty.
Status of this statement
Self-assessment 14 September 2026 · Version 0.1 (draft) · Scope: this website only
We are not claiming conformance. A conformance claim requires a documented evaluation against every applicable success criterion, on a defined set of pages, by someone competent to make it. That has not been done. What follows is an honest account from the people who wrote the code.
Accessibility on this site is a property of the design system rather than of individual pages. Landmarks, focus styling, the navigation behaviour and the interactive patterns live in shared CSS and two small JavaScript modules. Fixing something once fixes it everywhere, which is the main reason the approach is worth describing publicly.
The Target
WCAG 2.2 Level AA, and why that version.
WCAG 2.2 adds criteria that matter for the kind of interface this site uses — focus visibility when an element is partly obscured, dragging alternatives, and target size. Building to 2.1 and calling it current would have skipped exactly the things a mega-menu and a carousel get wrong.
What the four principles mean in practice here
- Perceivable
- Text alternatives, contrast that holds in both palettes, and no information carried by colour or motion alone
- Operable
- Everything reachable and dismissible from the keyboard, with a visible focus indicator and no timed interaction
- Understandable
- Consistent navigation, headings that descend without skipping, and error messages that say what to do
- Robust
- Native elements first, ARIA only where a native element cannot express the pattern, and correct state on every control
Regulatory framing to be confirmed. WCAG is the benchmark commonly referenced by Australian government digital policy, and accessibility obligations also arise under discrimination law. The precise wording of that relationship is a question for counsel, so this page describes engineering practice and leaves the legal characterisation open.
Implemented
What is actually in the code.
Each item below is verifiable by opening the page and using it. Nothing here is aspirational. If you test one of these and find it does not behave as described, that is a defect and we want to hear about it.
Semantic landmarks on every page
One header, one main, one footer, and navigation regions with accessible names. Content sections are real section elements labelled by their own heading, so a screen-reader rotor lists the page structure rather than a wall of generic regions.
Skip link to the main content
The first focusable element on every page moves focus to #main. It is visually hidden until focused, then appears in the top-left corner with the accent background. The header is sticky, so pages also carry scroll padding that keeps a focused target from sliding underneath it.
A visible focus indicator that is never removed
A two-pixel accent outline with a three-pixel offset, applied through :focus-visible so pointer users are not shown a ring they did not ask for. No rule in the stylesheet sets outline: none without replacing it. The accent colour was chosen to remain visible against both the ink and paper surfaces.
Keyboard-operable mega-menu with correct ARIA state
Each top-level trigger is a real button carrying aria-expanded and aria-controls. Down and Up arrows open the panel and place focus on its first or last item. Left and Right arrows move between triggers. Escape closes the panel and returns focus to the trigger that opened it. Tabbing past the end of a panel closes it rather than trapping you, because the panel is not modal.
The mobile drawer is modal, and behaves like it
When the drawer opens, focus moves into it, the rest of the document is marked inert, and background scrolling is locked. Tab cycles within the drawer. Escape closes it and returns focus to the button that opened it. The distinction matters: the drawer covers the viewport, so trapping focus is correct there and wrong in the mega-menu.
Tabs follow the ARIA tab pattern properly
A tablist of buttons with aria-selected and aria-controls, panels with role="tabpanel" labelled by their tab, and a roving tabindex so one Tab press enters the group and arrow keys move within it. Left, Right, Home and End are all handled. Selecting by click does not steal focus.
Filter chips announce their result count
Filters are buttons with aria-pressed, not styled links. Changing a filter updates one role="status" aria-live="polite" element with the new count, so the change is announced instead of happening silently. Counts are also rendered visibly on each chip.
Reduced motion is respected, not approximated
The scroll-reveal animations, the counters and the carousel's smooth scrolling all check prefers-reduced-motion and switch to an immediate state rather than a faster animation. Content is never hidden behind an animation that has not run — with JavaScript disabled entirely, everything is visible.
Contrast that holds in both themes
The palette carries two accent values: one for large elements on dark surfaces, and a darker variant used wherever accent-coloured text sits on a light surface. A section's surface class re-themes every component inside it, so a card cannot end up with light text on a light background by being moved. The theme toggle is a button with aria-pressed, and the site follows the operating-system preference until you choose otherwise.
Usable at 320 px and at 400% zoom
Layouts are fluid rather than fixed at breakpoints, type scales with the viewport, and no page scrolls horizontally at 320 px. Wide content — spec tables and diagrams — is placed in its own horizontally scrollable container so the page body does not have to move. Nothing on the site conveys meaning through colour or motion alone; every state has a text or shape equivalent.
Not Verified
What we have not proven yet.
Building to a standard and being tested against it are different things. This list is the honest gap, and it is here because a vendor that publishes only the first list is not telling you much.
- No third-party audit
- No independent accessibility audit has been commissioned or completed. The assessment behind this page was done by the team that wrote the code, which is the weakest form of review
- No assistive-technology user testing
- The patterns have not been tested by people who use a screen reader, switch access, voice control or magnification every day. Developer testing finds broken markup; it does not find a workflow that is technically conformant and still unusable
- No screen-reader matrix
- We cannot yet state behaviour on specific combinations such as NVDA with Firefox, JAWS with Chrome, or VoiceOver with Safari on iOS
- Placeholder images lack final alt text
- Image slots across the site are still labelled placeholder blocks. Real alt text can only be written once the real photograph or diagram exists, and a diagram will need a long description as well
- No conformance report
- There is no accessibility conformance report or WCAG-EM evaluation on file, so a procurement officer asking for one will be told it does not exist yet
- Documents and media not assessed
- Any future PDF, video or embedded third-party widget is out of scope of this statement until it is separately assessed. Video will need captions and a transcript before it is published
- Two patterns need JavaScript
- Accordion and tab panels start closed and cannot be opened without JavaScript. Everything else on the site degrades cleanly, so this is a real gap rather than a theoretical one
- Cognitive load untested
- The copy is deliberately technical because of who reads it. Plain-language summaries have not been written, and readability has not been measured
Keyboard Reference
Every interaction, without a pointer.
This table documents what the code does today. It is also our test script — if a change breaks one of these rows, the change is wrong.
| Context | Key | Behaviour |
|---|---|---|
| Any page | Tab from the top | Reveals the skip link; activating it moves focus to the main content |
| Header navigation | Down arrow / Up arrow | Opens the menu panel and focuses its first or last item |
| Header navigation | Left arrow / Right arrow | Moves between the top-level menu triggers |
| Open menu panel | Escape | Closes the panel and returns focus to its trigger |
| Open menu panel | Tab past the last item | Closes the panel and continues through the page in order |
| Mobile drawer | Tab / Shift + Tab | Cycles within the drawer, which is modal while open |
| Mobile drawer | Escape | Closes the drawer and restores focus to the menu button |
| Tab groups | Left / Right arrow | Moves to the previous or next tab and selects it |
| Tab groups | Home / End | Jumps to the first or last tab in the group |
| Accordions | Enter / Space | Toggles the panel and updates aria-expanded |
| Carousels | Left / Right arrow | Scrolls by one page while the track has focus |
| Filter chips | Enter / Space | Applies the filter and announces the new result count |
| Forms | Enter on submit | Validates, then moves focus to the first field with an error |
Assessment Plan
How the gap gets closed.
Five steps, in order, because each depends on the one before it. No dates are published yet — committing to a date we have not resourced would be the same kind of unverified claim this page exists to avoid.
Self-assessment — done
Manual keyboard traversal of every page, zoom to 400%, a 320 px viewport check, reduced-motion verification, a heading-order and landmark pass, and a static audit that fails the build on a duplicate id, a broken ARIA reference, an unlabelled region or a missing alt attribute.
Automated scanning in the build — next
Add an automated accessibility scan to the deployment pipeline so regressions are caught before they reach the site. Automated tools find a minority of real issues, so this raises the floor rather than proving conformance.
Independent audit against WCAG 2.2 AA
Engage an external specialist to evaluate a representative page sample, using a documented methodology. Publish the findings, including the ones we have not fixed yet, with a remediation date against each.
Testing with assistive-technology users
Paid sessions with people who use screen readers, magnification, switch access and voice control daily. This is the step that finds the problems an audit scores as a pass, and it is the step most often cut.
Publish a conformance report and keep it current
Once the audit and user testing are complete, publish an accessibility conformance report with its scope and evaluation date, and repeat the assessment whenever the design system changes materially.
Questions
What buyers and auditors ask us.
Government tenders ask most of these. The answers are short because the honest answer to several of them is currently no.
Not yet. No report exists for this website, and we will not produce one from a self-assessment. If a tender requires one, ask us early so the audit can be scheduled rather than back-dated.
Where the requirement is about a platform we would build for you, that is a separate question with a better answer: accessibility criteria can be written into the statement of work with acceptance testing attached.
The site is built with standard HTML, CSS and a small amount of JavaScript, and it is designed to work in current versions of the major browsers. We have not completed a formal support matrix, and we will not publish one until it has been tested rather than assumed.
With JavaScript disabled the site is still readable and navigable: the reveal animations do not run, and all body content is shown rather than left transparent. Two things do degrade, and we would rather name them than let you discover them. Accordion panels and tab panels start closed and need JavaScript to open, so the content inside them is not reachable. Progressive enhancement of those two patterns is on the fix list.
None are published yet. When they are, the rule we intend to hold is that an architecture diagram ships with a text description of the same information, video ships with captions and a transcript, and anything offered as a PDF is also available as an HTML page.
A tagged PDF is harder to get right than a web page, so the web page should be the primary format rather than the afterthought.
We acknowledge the report, reproduce it, and tell you whether it is a defect in the design system or in one page. Design-system defects are fixed once and corrected everywhere, which is usually faster than it sounds.
If we cannot fix something quickly, we will say so, describe a way to get at the same information, and give you a date. Response targets on this page are still drafting assumptions and need to be confirmed as commitments before launch.
Feedback
Tell us what broke.
A specific report is worth more than a general one. The page address, the thing you were trying to do, and the browser and assistive technology you were using is usually enough for us to reproduce it.
If the format of a reply is a barrier in itself, say how you would prefer to be contacted and we will use that instead. A phone conversation is a perfectly good way to file a bug.
- Accessibility feedback
- hello@cloudnatives.example
- By phone
- +61 0 0000 0000
- Response target
- Five business days — to be confirmed as a commitment
- External escalation
- To be confirmed with counsel before publication
Other ways to reach us are on the contact page.