NDIS Website Accessibility Checklist: 24 WCAG 2.1 AA Checks for Australian Providers

What standard does an NDIS website actually have to meet?

WCAG 2.1 Level AA. That is the answer, but the reason is worth understanding because it changes how seriously you take it.

The Disability Discrimination Act 1992 does not name WCAG or specify any coding requirement. What it does is make it unlawful to discriminate in the provision of services, including services delivered online. When a complaint reaches the Australian Human Rights Commission or a court, WCAG is the benchmark used to judge whether a website created an unlawful barrier.

For NDIS providers the expectation sits higher than for an average business, for an obvious reason: your users are more likely than the general population to rely on screen readers, keyboard navigation, captions and high-contrast display. The NDIS itself states its own website targets WCAG 2.1 A and AA conformance.

So: not a statute you can be fined under by name, but a real legal exposure and a genuine barrier to the people you exist to serve.

The 24-point checklist

Grouped by the four WCAG principles. Each item states the check, then what it means in practice.

1. Perceivable — can people take the information in?

• Alt text on every meaningful image. Describe what the image conveys, not what it looks like. Decorative images get empty alt (alt="") so screen readers skip them.
• Colour contrast of at least 4.5:1 for body text, 3:1 for large text. This is the single most commonly failed check on Australian provider sites.
• Never use colour alone to convey meaning. "Fields marked in red are required" fails; add an asterisk or the word Required.
• Captions on all video. Auto-generated YouTube captions are not sufficient — they need review for names, service terms and acronyms.
• Transcripts for audio. Podcasts, recorded webinars, audio explainers.
• Text resizes to 200% without breaking. Zoom your site to 200% in a browser and check nothing overlaps or gets cut off.
• Content reflows at 320px wide without horizontal scrolling.

2. Operable — can people navigate and use it?

• Everything works with a keyboard alone. Unplug your mouse and try to complete your referral form. This one test finds more failures than any other.
• Visible focus indicator. When tabbing, you must always be able to see where you are. Many themes remove this for aesthetics.
• No keyboard traps. You can tab into and back out of every component, including modals and embedded maps.
• Skip-to-content link as the first focusable element, so screen reader users bypass the nav on every page.
• No auto-playing media, or an obvious pause control within reach.
• No content that flashes more than three times per second.
• Descriptive link text. "Read our support coordination services" not "click here". Screen reader users often navigate by pulling up a list of links alone.
• Touch targets at least 44x44 pixels with spacing between them.

3. Understandable — is it clear and predictable?

• Page language declared in the HTML (lang="en-AU").
• Plain English. Aim for a Year 7 to 9 reading level on participant-facing pages. Write "we help you find services" rather than "we facilitate service navigation pathways".
• Consistent navigation in the same position on every page.
• Form labels visibly attached to their fields. Placeholder text alone is not a label — it disappears when typing starts.
• Errors identified in text and describe the fix. "Enter a phone number including area code" beats a red border.
• Acronyms explained on first use. Write out NDIS, SIL, SDA, plan management the first time each appears on a page.

4. Robust — does it work with assistive technology?

• Valid, semantic HTML. Real heading tags in order, real buttons, real lists — not divs styled to look like them.
• One h1 per page, headings in logical order with no skipped levels.
• ARIA labels where genuinely needed — and nowhere else. Incorrect ARIA is worse than none at all.

How to test this yourself, for free

You do not need to hire anyone to find most of your problems. Three tests take about forty minutes and will surface the majority of failures.

Important caveat: automated tools catch roughly 30 to 40 percent of WCAG issues. They cannot judge whether your alt text is meaningful or whether your language is clear. A clean Lighthouse score is a starting point, not a pass.

What this usually costs to fix

It depends entirely on what you are starting from.

• Retrofitting an existing site is the expensive path. If accessibility was not considered during the build, contrast, semantics and keyboard behaviour are woven through every template. Budget several thousand dollars, and accept that some issues cannot be fully fixed without a rebuild.
• Building it in from the start costs close to nothing extra. Semantic HTML, proper contrast and keyboard support are how a site should be built anyway. At BuildFirstSite, WCAG 2.1 AA is included in every build rather than sold as an add-on — sites start at $800 and go to $4,500 for larger builds. Full figures are on our pricing page.
• Accessibility overlay widgets — the floating accessibility button you see on some sites — do not make a site compliant. They are widely criticised by disability advocates and have been named in US litigation. Avoid them.

Where most NDIS provider sites fail

From reviewing provider websites, the same five issues recur. None are hard to fix.

The PDF one deserves particular attention. A scanned service guide is an image — a screen reader gets nothing from it. If you publish documents, publish them as real web pages, or as tagged accessible PDFs. Learn more about how we build fully accessible sites on our web development services page.

Common questions