Accessibility

WCAG 2.2, Level AA. The version matters: 2.2 added criteria that most sites quietly fail, including Focus Not Obscured (2.4.11), which is what happens when a sticky header or a fixed bar covers the thing you just tabbed to.

Australian government and enterprise procurement generally expects this standard. We apply it to client work by default rather than as an upgrade.

Automatically, on every single deployment:

• An automated accessibility audit runs against the built page at 320, 360, 390 and 430 pixels wide, plus desktop — not one “mobile” size.
• Every text and background colour pair is checked against the contrast requirement by a test that reads the real stylesheet, so a colour can’t drift below the threshold without the build failing.
• The form’s error state is audited separately, because that is where most forms fail: error summaries, invalid-field marking, and focus handling.
• Layout is checked at 400% zoom and with text-only zoom at 200%, and for sideways scrolling at every width down to 320 pixels.
• Everything runs in both Chromium and WebKit, so Safari behaviour is covered rather than assumed.

• Skip links to the main content and straight to the contact form.
• A visible focus indicator on every interactive element, including on the dark section where a single-colour ring would disappear.
• Form errors stated in words, never by colour alone, with a summary that receives focus and links to each field that needs fixing.
• Real labels on every field — never a placeholder standing in for one.
• Reduced-motion and high-contrast preferences honoured, and the page still works with Windows High Contrast mode active.
• The FAQ uses native browser elements, so it works with the keyboard and with JavaScript switched off entirely.

Automated testing catches roughly a third of accessibility problems. It is a floor, not a guarantee, and we would rather say so than imply otherwise.

• This site has not been independently audited by a third-party accessibility specialist.
• It has not been tested with every combination of screen reader and browser. Screen readers differ, and something that reads well in one can read poorly in another.
• It has not been tested with users who rely on assistive technology day to day, which is the only test that really settles the question.

Tell us and we will fix it — you don’t need to explain the technical detail, just what went wrong and what you were using. We treat accessibility bugs on this site as faults, not feature requests.

If you need anything on this site in another format, ask and we will send it to you.