An accessible website for NDIS providers should let people understand your services and contact you without unnecessary barriers. Yet a website that looks clear to your team can still be difficult to use with a keyboard, screen reader, magnification or voice control.

You do not need to start with a full rebuild. A structured first-pass audit can reveal problems your team can fix immediately and technical issues to send to your developer.

This guide focuses on testing the journey from finding a service to submitting an enquiry. It is not a formal accessibility assessment, but it will help you replace guesswork with a practical repair list.

Auditing an accessible website for NDIS providers

Start with tasks, not individual design features. Someone visiting your website may need to check whether you cover their suburb, understand your support options or ask a question without making a phone call.

Choose three journeys to test:

• Find a service and check where it is available.
• Understand how to enquire, including what happens next.
• Send an enquiry using the contact form.

Include your homepage, one important service page, your contact page and any external booking or referral tool. A third-party form is still part of the experience, even if your agency did not build it.

Create an issue log recording the page address, task attempted, barrier found, device or browser used, and person responsible for fixing it. Describe the problem precisely: “Cannot reach the submit button using Tab” is more useful than “Form is inaccessible”.

1. Try the whole enquiry journey without a mouse

Put your mouse aside. Use Tab to move forwards through interactive elements, Shift+Tab to move backwards, Enter to activate links, and Space to activate buttons where appropriate. Use arrow keys within controls that support them.

You should be able to identify where you are on the page at every step. This is usually shown by a visible outline or highlight, called a focus indicator.

What to check

• Can you open the navigation menu and reach every important page?
• Does the focus move in a sensible order?
• Can you close pop-ups and return to the page?
• Can you select form options and submit an enquiry?
• Can you reach content without repeatedly tabbing through a long menu?

A menu that opens only when someone hovers over it is a warning sign. So is a chat widget that traps keyboard focus. Record exactly where you get stuck and ask your developer to test the underlying control, rather than simply changing its appearance.

2. Enlarge the page and test it on a phone

Increase browser zoom to 200%, then inspect the navigation, service information and enquiry form. For a stronger check, try 400% zoom on a desktop browser. Look for overlapping text, missing controls and content that forces you to scroll sideways to read ordinary paragraphs.

These are useful checks, not a complete assessment of WCAG resizing and reflow requirements.

Next, open the same pages on a phone. Check whether sticky banners, cookie notices and chat buttons cover important information. Try selecting links and form controls without accidentally activating nearby items.

Ask your developer to investigate fixed-height text boxes, rigid layouts and restrictions on zoom. Do not treat smaller text as the solution to a layout that breaks when enlarged.

3. Check contrast, images and moving content

Light grey text on white backgrounds can be difficult to read, even when it suits your branding. Use a contrast checker to test actual text and background colour combinations, including buttons, form instructions and error messages.

WCAG Level AA specifies a minimum contrast ratio of 4.5:1 for ordinary text and 3:1 for large text. Large text has a defined meaning in WCAG, so ask your developer to verify the relevant requirements rather than judging by appearance.

Check that colour is not the only way information is communicated. A required field or error needs a clear textual indication, not just a red border.

• Informative images: provide alternative text conveying the information or purpose.
• Decorative images: use empty alternative text so screen readers can skip them.
• Videos: provide accurate captions and a transcript. Consider whether important visual information also needs audio description or a text alternative.
• Moving content: avoid unnecessary autoplay and provide appropriate controls to pause movement.

Keep essential service information in page text rather than embedding it only in a graphic.

4. Read your service page as a first-time visitor

Accessibility includes understanding, not just operating the website. Read one service page without assuming the visitor knows your organisation or NDIS terminology.

Can someone quickly identify what support you provide, where you work, and how to ask whether the service suits their needs?

Expand abbreviations on first use. Replace vague phrases such as “holistic capacity-building solutions” with a concrete description of the support you actually deliver. Break lengthy explanations into short sections with descriptive headings.

Link text should explain its destination. “Read about our community participation support” is clearer than several identical “Learn more” links.

Do not assume plain language and Easy Read are interchangeable. Easy Read is a specific approach combining carefully structured text and supporting images. If your audience needs it, involve experienced practitioners and people who will use the resource.

5. Submit your own enquiry form, including mistakes

Forms deserve special attention because a barrier here can prevent someone from contacting you after they have found the right service.

Use test details, avoid real participant information, and let your intake team know you are testing. First submit the form with required fields blank. Then enter an incorrectly formatted email address.

Look for useful instructions and recoverable errors

• Every field should have a persistent, descriptive label, not just placeholder text that disappears when typing begins.
• Required fields should be clearly identified before submission.
• Error messages should explain what needs correcting and identify the relevant field.
• Information already entered should remain when an error occurs.
• Successful submission should produce a clear confirmation, including a realistic explanation of the next step.

Ask whether every required question is necessary for an initial enquiry. Requiring a plan upload or detailed disability history can add friction and collect sensitive information before it is needed.

If spam protection creates an image puzzle or another barrier, ask your developer about less intrusive options. Offer alternative contact methods without treating them as a substitute for fixing the form.

6. Check documents and third-party tools

Follow every link needed to complete your chosen journeys. You may discover that an otherwise usable service page leads to an inaccessible PDF or booking platform.

For essential information, provide an HTML page wherever practical. If a PDF is necessary, it needs more than selectable text: reading order, headings, document tags, link descriptions and form fields may also need attention.

Ask booking and referral software suppliers for current accessibility documentation and details of known limitations. Test the actual configuration on your website, not just their demonstration page.

Turn your findings into a repair plan

Prioritise issues by how seriously they obstruct essential tasks:

• Fix first: blocked navigation, keyboard traps, unusable forms and controls hidden by overlays.
• Fix next: poor contrast, confusing errors, unclear instructions and inaccessible essential documents.
• Schedule ongoing improvements: older content, secondary resources and publishing practices.

Give each issue an owner and a retest date. After a fix, repeat the original task rather than accepting a screenshot as proof that the problem is resolved.

Automated tools can flag some issues, but they cannot establish that your website is accessible. Arrange a specialist assessment against WCAG 2.2 Level AA as a practical technical target, with the scope and limitations clearly documented. This does not by itself establish legal compliance.

Include paid testing with people with disability where possible. Different people use different technologies and strategies; one person's successful experience does not validate every journey.

Keep accessibility in your publishing routine

Repeat these checks after changes to navigation, forms, templates or booking tools. Give staff a short publishing checklist covering headings, descriptive links, image alternatives, captions and readable documents.

Publish an accessibility contact option and describe known limitations honestly. Do not claim full accessibility because you installed a plugin or passed an automated scan.

When coordinating your NDIS marketing services, include accessibility checks in campaign page briefs and website updates. People should be able to use the destination, not merely click the advertisement.

Need help prioritising website improvements? Book a free strategy call to discuss your provider website and enquiry journey.

Frequently asked questions

How can I check whether my NDIS website is accessible?

Start by completing key tasks using only a keyboard, enlarging the page, testing on a phone and deliberately triggering form errors. Use automated checks to identify additional issues, then arrange specialist testing for a more comprehensive assessment.

Which accessibility standard should an NDIS provider website target?

WCAG 2.2 Level AA is a practical technical target to discuss with your developer or accessibility specialist. Ask them to define the assessment scope and document findings. Meeting a technical target does not by itself establish compliance with every applicable legal obligation.

Will an accessibility plugin make our website accessible?

Not by itself. A plugin may offer useful features, but it cannot reliably repair every issue with navigation, content, forms or third-party tools. Prioritise accessible underlying design and code, supported by manual testing.

Do we need to rebuild our website to improve accessibility?

Not necessarily. Many barriers can be addressed through content edits, template repairs and form improvements. Audit essential journeys first, then ask your developer whether targeted repairs or a rebuild would better address the documented problems.