Website accessibility for NDIS providers: what WCAG 2.2 AA means in practice

An accessible NDIS provider website is more than a passing automated score. This guide separates the NDIS communication requirements from the WCAG 2.2 AA benchmark, then explains practical barriers, testing and ongoing maintenance.

A person finds an NDIS provider through Google and needs to establish whether the service is relevant, available locally and suitable, what happens after an enquiry, and how to ask a preliminary question.

The information may exist while the website remains unusable: the menu requires a mouse, enlarged text disappears, service details sit only in a poorly structured PDF, or an inaccessible form or CAPTCHA blocks submission.

Key point: A website is not accessible merely because the information exists. People must be able to find, understand and act on it using different devices, input methods and assistive technologies.

That requires design and development, understandable content, usable forms and documents, appropriate testing, and publishing practices that maintain accessibility as the website changes.

What the NDIS Practice Standards actually say about accessible communication

A common claim is that every NDIS provider website is directly required by the NDIS Practice Standards to meet WCAG 2.2 Level AA. That merges related but distinct ideas.

The NDIS Practice Standards apply to registered providers, but the modules relevant to registration and audit depend on the supports delivered. Within the core module for higher-risk supports and services, communication about supports must respond to participant needs and use the language, mode of communication and terms the participant is most likely to understand. The core module also requires timely information that supports informed choice.

Other core-module standards on the provision of supports add that available supports, access or entry criteria and associated costs must be clearly defined and suitably communicated. Support plans must be readily accessible, and participants must be supported to understand service agreements and conditions.

These are practical communication outcomes. The cited provisions do not prescribe a public website structure or nominate a WCAG version and conformance level for every provider website. The website is nevertheless a major channel through which participants may understand, compare and contact providers.

NDIS requirement, Australian legal context and WCAG benchmark are related—but they are not the same thing.

This article provides general website-planning information, not legal advice. Providers should obtain appropriate advice about the laws, registration requirements and contractual obligations that apply to their organisation.

The wider Australian digital-accessibility context

The website question does not end with the NDIS Practice Standards.

The Disability Discrimination Act 1992 makes disability discrimination unlawful in specified areas of public life, including the provision of goods, services and facilities. Its application to a particular organisation is a legal question.

In April 2025, the Australian Human Rights Commission released updated Guidelines on equal access to digital goods and services. The guidelines are not legally binding and should be read alongside the Disability Discrimination Act and relevant state and territory laws.

Within that guidance, the Commission recommends that organisations conform to WCAG 2.2 at a minimum Level AA, while considering relevant Level AAA criteria where appropriate.

A useful working hierarchy is:

1. Legal obligations: determined by applicable Australian discrimination law and the organisation’s circumstances.
2. NDIS provider obligations: the standards and other requirements that apply to the provider’s registration and services.
3. Technical benchmark: WCAG 2.2 Level AA as the current minimum target recommended by the Australian Human Rights Commission.
4. Real-world outcome: people with disability can complete essential tasks without avoidable barriers.

What WCAG 2.2 AA means in plain English

The Web Content Accessibility Guidelines, or WCAG, are an international technical standard organised around four principles.

Perceivable: Information is available in forms people can perceive, including text alternatives, captions, adequate contrast and content that remains usable when enlarged.

Operable: Navigation and controls work through different input methods. A mouse is not required to open a menu, move through a form or activate a button.

Understandable: Content and interactions are clear and predictable. Labels, instructions and error messages help people know what to do.

Robust: Browsers and assistive technologies can reliably identify structure, controls, names, roles and changing states.

A, AA and AAA are conformance levels—not quality scores

WCAG success criteria are classified at three levels:

• Level A addresses foundational barriers.
• Level AA includes all Level A and Level AA criteria and is the usual organisational target.
• Level AAA includes further criteria, but W3C does not recommend requiring blanket Level AAA conformance across entire sites because some content cannot satisfy every AAA criterion.

A claim of Level AA conformance is not the same as a scanner reporting 90 or 100 per cent. Conformance applies to complete pages, including their responsive variations. Where a conformance claim covers a multi-page process, every page in that process must conform at the claimed level. A passing service page therefore does not establish that the enquiry process as a whole conforms.

What WCAG 2.2 added

WCAG 2.2 introduced nine success criteria beyond WCAG 2.1. Not all will apply to every provider website, but several connect directly to common participant interactions.

WCAG 2.2 generally requires a single-pointer alternative for author-created interactions that depend on dragging, unless dragging is essential or another defined exception applies. This may matter where a third-party booking tool, document-signing system or portal uses drag-and-drop interaction.

Applicability matters. A simple public website without accounts or login functionality may have no authentication process to assess. A criterion should be evaluated against the content and functions that actually exist—not treated as a disconnected list of boxes.

Accessibility is easier to understand through participant tasks

A technical standard becomes more useful when it is applied to what people are trying to accomplish.

Consider the full journey:

Finding the right service

Information architecture determines whether people can locate the right content before page-level accessibility is even considered. Our guide to structuring an NDIS provider website examines that wider architecture in detail.

Navigation labels should describe what people will find. Supported independent living is more useful than an internal program name. Service pages should use clear headings, state geographic coverage and distinguish similar supports.

Links also need meaningful wording. Repeated Learn more links provide little information when listed out of context by assistive technology. View supported independent living locations gives the destination.

Breadcrumbs, search and service filters must remain usable by keyboard, expose clear labels and states, and preserve a logical focus order.

Understanding whether the service is suitable

A participant or supporter should be able to establish what a support involves, who it may suit, important boundaries, where it is delivered and what happens next. Use direct language, descriptive headings and explanations of unfamiliar terms; do not hide reliable entry, exclusion or cost information behind contact us to learn more.

Do not rely on colour, icons or images alone. A green tick and red cross need text equivalents, while a service-area map needs a location list. This aligns with the core module’s emphasis on timely, understandable information supporting informed choice.

Reading and viewing the page

Contrast is only one part of accessible presentation. People should be able to enlarge text and zoom without losing content, needing excessive two-directional scrolling or causing controls to overlap. Informative images need useful text alternatives; decorative images generally should not be announced.

Prerecorded audio-only content needs an equivalent alternative, usually a transcript. Video needs appropriate captions, including relevant non-speech information. Where important visual information in prerecorded video is not already conveyed in the soundtrack, audio description is also required for Level AA conformance. Essential wording should not be embedded in images or depend on mouse hover.

Navigating without a mouse

Every interactive element should be reachable and operable by keyboard. Focus should move logically, remain visible and never become trapped. Menus should open and close predictably, dialogs should manage focus correctly, and controls should expose information assistive technology can identify.

A sticky cookie notice, chat widget or promotional panel must not completely hide the item with keyboard focus.

Making an enquiry or referral

Forms often determine whether an accessible information journey leads to an accessible service pathway.

Each field needs a visible, persistent label; placeholder text alone disappears when typing begins. Identify required fields in text, provide instructions before errors occur, and name the field and problem when validation fails. There was an error is not enough; Email address: enter an address in the format [email protected] is useful.

A good form should preserve entered information, provide clear error and success messages, avoid repeated entry and inaccessible CAPTCHA barriers, allow enough time, request only necessary information and state what happens next.

Provide more than one practical contact method where possible, based on communication channels the organisation can actually support. Offering a phone number or email address can give users another option, but it does not by itself make an inaccessible online process conformant.

Finding complaints, safeguards and help

Complaints, feedback, privacy and safeguarding information should be easy to locate. Keep help and contact options consistent, explain what happens after feedback is submitted and do not demand extensive personal or clinical information merely to ask a preliminary question.

Plain language is part of accessibility—but it is not a substitute for technical accessibility

Clear writing does not fix an unlabelled form, keyboard trap, missing caption or low-contrast interface. The reverse is also true: a technically well-formed page can remain difficult when it is full of unexplained acronyms, organisational language and vague service descriptions.

Useful NDIS website content should:

• state the important answer early under descriptive headings;
• explain acronyms and unfamiliar terms;
• separate essential information from secondary detail;
• describe the next step precisely;
• use literal rather than promotional language;
• avoid making people infer service coverage, entry criteria or boundaries;
• provide alternative formats where the intended audience requires them.

Distinguish plain-language website content for a broad audience from tailored communication for an individual participant and deliberately produced alternative formats such as audio, large print, Braille, Auslan or Easy Read.

Do not casually label shortened or simplified marketing copy as Easy Read. Easy Read should be treated as a distinct communication format with an appropriate development and review process.

The main website may be accessible while the participant journey is not

A provider may invest in accessible page templates and still introduce barriers through the systems connected to them.

Common failure points include:

• PDFs and video players;
• referral, intake, booking and payment systems;
• embedded maps, chat and CAPTCHA services;
• cookie-consent interfaces;
• document-signing systems;
• third-party forms and account portals.

The complete process matters. A service page may pass a page-level assessment while the enquiry process as a whole fails because its form cannot be completed by keyboard or its fields are not properly labelled.

For essential public information, usable HTML is usually the strongest primary format. Required documents need real headings and lists, meaningful reading order, titles, language information, useful link text and accessible controls. Searchable text alone is not proof of accessibility.

Third-party procurement therefore needs an accessibility requirement. Ask what standard and functions were tested, which assistive technologies and browsers were used, what limitations remain and how defects are handled after updates.

Why an automated accessibility score is not proof

Automated tools can detect some contrast, attribute, structure and markup problems. They cannot reliably judge whether alternative text is useful, focus follows the task, an error message helps, content is understandable, a document’s reading order is meaningful or a participant can complete the journey. No tool alone can establish conformance.

A sensible testing model uses several layers:

1. automated checks across representative pages and templates;
2. manual keyboard testing of navigation, dialogs, forms and complete journeys;
3. visual testing at increased zoom, enlarged text and narrow viewport widths;
4. appropriate assistive-technology testing, including screen-reader checks;
5. evaluation with people with disability, especially for high-value participant journeys.

W3C recommends combining standards evaluation with user evaluation; neither replaces the other, and one person cannot represent every disability experience.

What should be included in an accessibility review?

A provider commissioning a review should be able to tell what is being assessed and what the resulting claim means.

The WCAG Evaluation Methodology (WCAG-EM) 2.0, published as a W3C Group Note on 23 July 2026, provides a current framework for defining scope, setting the conformance target and accessibility-support baseline, identifying essential functionality, selecting representative samples, including complete processes, evaluating the sample and reporting findings. Not every provider review needs to follow it formally, but it is a useful reference when assessing whether an audit scope is credible.

A credible scope identifies the WCAG version and level; pages, components and complete processes included; browsers, devices and assistive technologies used; automated and manual methods; treatment of documents and third-party systems; user evaluation; issue priorities; remediation retesting; exclusions; and the date or website version assessed.

The report should distinguish definite failures, items requiring further review, usability findings and recommendations beyond minimum conformance.

Be cautious when the proposed solution consists only of:

• one automated report;
• a plugin installation presented as a complete solution;
• an unexplained numerical score;
• a compliance badge without a documented scope;
• an assurance that the site is “100% accessible”;
• an audit that silently excludes forms, documents or third-party tools.

Accessibility does not end when the website launches

Websites regress as content, components and integrations change. Accessibility therefore needs an operating model, not only a launch test.

Useful controls include:

• accessibility requirements in design, development and procurement briefs;
• reusable components that have been tested before editors use them;
• CMS fields and instructions that support correct headings, link text and image alternatives;
• training for content authors and approvers;
• accessible document templates;
• release checks for new components and integrations;
• scheduled reviews of critical participant journeys;
• a process for recording, prioritising and resolving reported barriers;
• named ownership across website, content, quality and operational teams.

Evaluate accessibility throughout design and development, then review changes as they are introduced rather than relying solely on a large periodic audit.

Publish an honest accessibility statement

An accessibility statement should help users understand the website—not provide unsupported reassurance.

It should explain:

• the standard and level being targeted;
• the digital service and current conformance status covered;
• when and how it was last assessed;
• known limitations and available alternatives;
• how to report a barrier and how the organisation will respond;
• when the statement was last reviewed.

Do not claim full conformance unless an appropriate evaluation supports it. Identify the applied standard, assessment method and known limitations, provide a practical alternative where needed, and include an accessible feedback channel.

An accessibility statement that directs users to an inaccessible form reproduces the problem it is meant to address.

A practical first review for an NDIS provider website

The following check is triage, not a WCAG audit. It can still reveal barriers that need prompt attention.

Test whether you can:

1. Reach and operate every menu, link, button and form using only a keyboard.
2. See which element currently has keyboard focus.
3. Enlarge text and zoom the page without losing content or controls.
4. Understand the page structure from its headings alone.
5. Distinguish links and understand their destination out of context.
6. Identify services, locations, entry criteria and important boundaries without interpreting internal jargon.
7. Understand informative images without seeing them.
8. Access captions, transcripts or audio descriptions for relevant audiovisual content.
9. Complete the enquiry process and recover from errors.
10. Access essential information without depending on an inaccessible document.
11. Locate help, complaints, privacy and alternative contact methods consistently.
12. Complete the same critical journey on a narrow mobile screen.

Do not stop at the homepage. Test a realistic sequence:

Search result → service page → suitability information → contact choice → enquiry form → confirmation

Any failure that prevents someone from identifying, assessing or contacting the provider is a meaningful barrier, even before a formal audit assigns it a WCAG criterion and conformance level.

Accessibility is an organisational capability

The NDIS Practice Standards include strong accessible-communication expectations in the core module, while the modules applicable to a registered provider depend on the supports delivered and its audit pathway. The Australian Human Rights Commission separately recommends WCAG 2.2 Level AA as the current minimum technical target. An accessible participant journey extends beyond the visible website into forms, documents, portals and third-party systems.

Design and development matter. So do content, procurement, testing, publishing and governance.

Choose the standard you are working towards. Identify the website journeys participants most depend on. Test those journeys properly. Remove the most consequential barriers first. Then put controls in place to stop them returning.

Frequently asked questions

Does every NDIS provider website legally have to meet WCAG 2.2 AA?

The cited core-module standards establish requirements for responsive, understandable communication where that module applies, but they do not expressly prescribe WCAG 2.2 AA for every public website. The Australian Human Rights Commission separately recommends WCAG 2.2 at minimum Level AA in its digital-accessibility guidance. Broader legal obligations depend on the Disability Discrimination Act, other applicable laws and the organisation’s circumstances. Obtain legal advice where a definitive compliance position is required.

Is a WCAG-conformant website automatically easy for everyone to use?

No. WCAG conformance addresses defined accessibility criteria, but it cannot guarantee that every person will find the content clear or the journey intuitive. Evaluation with people with disability can identify usability and comprehension barriers that a standards review alone may not reveal.

Can an accessibility plugin make a website compliant?

A plugin may assist with a limited function, but it cannot correct every underlying design, code, content, document and third-party-system problem. Its contribution should be evaluated as part of the whole website rather than treated as proof of conformance.

Are PDFs and embedded forms included in website accessibility?

They should be included when they contain information or processes people need. An accessible page does not solve the problem when the essential document, booking tool, referral form or next step remains inaccessible.

How often should an NDIS provider website be tested?

There is no single interval that suits every website. Test during design and development, before major releases, after significant template or integration changes, when users report barriers and periodically across critical participant journeys. High-change services generally need more frequent review than stable brochure content.

Relevant guidance checked

This article provides website-planning information, not legal, registration or compliance advice. Official guidance was checked on 14 August 2026.

• NDIS Practice Standards — NDIS Quality and Safeguards Commission
• Disability Discrimination Act 1992 — Federal Register of Legislation
• Core module: Rights and responsibilities — NDIS Quality and Safeguards Commission
• Core module: Provision of supports — NDIS Quality and Safeguards Commission
• Guidelines on equal access to digital goods and services — Australian Human Rights Commission
• Standards and guidelines for digital accessibility — Australian Human Rights Commission
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
• WCAG Evaluation Methodology (WCAG-EM) 2.0 — W3C Group Note
• What’s New in WCAG 2.2 — W3C Web Accessibility Initiative
• Evaluating Web Accessibility — W3C Web Accessibility Initiative
• Involving Users in Evaluating Web Accessibility — W3C Web Accessibility Initiative
• Developing an Accessibility Statement — W3C Web Accessibility Initiative