• Working worldwide
  • 14 years of development experience
info@deviec.com
DEVIEC
Start your project

Industry

NDIS provider websites that participants can actually use

Three different audiences read your site: participants, their families, and support coordinators comparing providers. Each needs something different, and all of them need it to be genuinely accessible rather than accessible-looking.

  • Accessibility treated as a build requirement, not an add-on
  • Plain language, tested for readability
  • Service pages that answer what a coordinator needs to compare
  • Careful, private handling of sensitive enquiries
Discuss your websiteAll industries
A support worker assisting a client in a welcoming, accessible setting

What makes an NDIS provider website different?

Two things. First, accessibility is not optional — a proportion of your visitors use screen readers, keyboard navigation, magnification or voice control, and a site that fails them fails the people you exist to serve. Second, your site is read by three audiences with different needs: a participant deciding whether they would feel comfortable, a family member checking credibility, and a support coordinator rapidly comparing providers against a participant's plan.

  • Built and tested against WCAG 2.2 AA practices, including with a keyboard
  • Plain language written for readability, not for search engines
  • Structured so a coordinator can compare services in under a minute

Common problems

What we usually find on provider websites

  • Accessibility that fails on the first test

    An accessibility statement on the site, but low-contrast text, no visible focus, unlabelled form fields and images without alt text.

  • Language written for the sector, not the reader

    Pages full of scheme terminology that a participant reading independently cannot follow.

  • Services described but not defined

    A list of support categories with no indication of what is actually delivered, where, or whether places are available.

  • No route for a coordinator

    Coordinators need capacity, coverage area and a referral route quickly. Most provider sites make them hunt for it.

  • Enquiry forms that ask too much too soon

    Long forms requesting sensitive personal and medical detail before any relationship exists.

  • Unusable on a phone

    Which matters when a family member is looking something up in a waiting room on a small screen.

What we build

Features that earn their place on a provider site

Accessibility

Built in from the first template, verified before launch.

  • Full keyboard operation with visible focus
  • Contrast meeting AA on text and interface elements
  • Semantic headings, landmarks and form labels
  • Content that reflows without loss at high zoom
  • Reduced-motion preference respected

Content structure

Written so three audiences each find their answer.

  • Plain-language service descriptions
  • What is delivered, where, and by whom
  • Coverage areas stated explicitly
  • Practitioner and team profiles

Enquiries

Designed to be safe and low-pressure.

  • Short first-contact form asking only what is needed
  • No sensitive medical detail requested at first contact
  • Clear statement of what happens after submitting
  • Alternative contact routes for people who prefer them

Being careful

Where we will not help, and why that matters

We build websites. We are not NDIS consultants, and we will not write copy that implies registration status, compliance certification, audit outcomes or eligibility advice. Those claims belong to you, must be accurate for your registration and jurisdiction, and carry consequences if they are wrong.

What we will do is build a site that presents your actual services accurately, handles enquiries from vulnerable people carefully, and meets the accessibility standard your audience genuinely needs. Where copy touches on scheme terminology or eligibility, you or your compliance adviser approve the wording before it goes live.

  • No claims about registration or compliance status written by us
  • Scheme terminology used only where you confirm it is accurate
  • Sensitive enquiry data minimised by design
  • A privacy and consent approach appropriate to the information you collect
A care professional talking with a client in a calm, private setting

Approach

How an NDIS provider build runs

  1. 01

    Audience mapping

    Participants, families and coordinators: what each needs and in what order.

    You receive: Audience and journey map

  2. 02

    Service structure

    Your actual services, coverage areas and capacity, structured for comparison.

    You receive: Content model and page inventory

  3. 03

    Accessible design

    Templates designed and checked for contrast, focus order, target size and reflow before build.

    You receive: Accessibility-reviewed designs

  4. 04

    Build

    Semantic, keyboard-operable templates with properly labelled forms.

    You receive: Staging site

  5. 05

    Test

    Keyboard, screen reader, zoom, contrast and mobile testing, plus a plain-language review.

    You receive: Accessibility test record

  6. 06

    Launch and review

    Go live, then review real enquiry behaviour and adjust.

    You receive: Live site and improvement list

Questions

NDIS website questions

Can you guarantee our site is fully compliant with accessibility law?
No one honestly can, because compliance depends on content added after launch as much as on the build. What we can do is build and test against WCAG 2.2 Level AA, document what was tested and how, and give your team the guidance needed to keep new content accessible. An automated checker alone is not sufficient, and we test with a keyboard as well.
Will you write our service descriptions?
We will draft plain-language versions from information you provide, and you approve every word. We will not invent service details, capacity figures or coverage areas, and anything touching registration or eligibility must be confirmed by you before publication.
How should enquiry forms handle sensitive information?
By not collecting it at first contact. The initial form should establish who is enquiring, roughly what they need and how to reach them. Detailed personal or health information belongs in a secure intake process after a conversation has started, not in a public web form.
Do we need a separate easy-read version of the site?
Usually not, if the main site is genuinely written in plain language. A separate easy-read version tends to become the neglected one. The better investment is making the primary content clear enough that it does not need a parallel version.
Can support coordinators find what they need quickly?
That is a specific design goal. Coordinators want coverage area, service types, current capacity and a referral route, fast. We structure that into a page they can scan rather than burying it in general marketing copy.

Related

Also relevant

Building or rebuilding a provider website?

Tell us who your site has to serve and what the current one gets wrong. We will tell you what we would change first.

Discuss your websiteAll industries