NDIS Provider Website: Plain-English and Easy-Read Pages Using AI

Give the AI your own service facts, ask for short plain-English drafts at a set reading level, then have a person rewrite them into easy-read: one idea per sentence, one picture per idea, and a participant to test it. AI speeds up the first draft; it cannot judge whether the page is understood.

The pages in question are the public website you control, not any NDIS portal login. The pattern is the same for a four-person support team or a larger provider: write facts down once, draft pages from those facts, and review them with the people they are for. The NDIS itself publishes Easy Read downloads beside many of its participant pages, so many participants and families already know the format and will notice when a provider's version falls short.

Follow me on Instagram@sagnikteaches

Why a provider's website needs two versions of each page

A participant, a family member and a support coordinator often read the same page for different reasons. The coordinator wants to know whether you cover a region, offer a service and have capacity. The participant wants to know who will turn up, what it will cost them and what happens if they are unhappy. A page written for a funding body usually serves neither.

Connect on LinkedInSagnik Bhattacharya

Plain English and easy-read are not the same thing, and mixing them up is the most common mistake. Plain English is ordinary writing with the padding removed: short sentences, common words, active voice, headings that say what follows. Easy-read goes further. It uses very short sentences, one idea each, large type, plenty of white space, and a picture beside every point so the image carries the meaning. It follows a recognised style, and organisations that produce it often test drafts with people who use it.

Subscribe on YouTube@sagnikteaches

The practical rule: write the plain-English page first, because everything else is derived from it. If a sentence cannot be made clear in plain English, it will not survive being cut into easy-read.

Step 1: write a facts sheet before you open any AI tool

The biggest risk with AI on a service page is not clumsy wording but invented detail. Ask for "a page about our supports" and you will get confident filler: "tailored, person-centred supports delivered by passionate staff." None of it comes from you. The fix is to supply the facts and forbid anything else.

Build a one-page facts sheet. Keep it in a document you control, not inside a chat. Include these headings and fill each in with your own information:

• Who we are: legal name, trading name, years operating, size of team, how the service started (one sentence).
• What we do: each support you actually deliver, in the words your team uses, and what you do not do.
• Where and when: areas covered, days and hours, whether you offer evenings, weekends or short-notice cover.
• How to start: the steps from first call to first visit, who the first contact is, how long each step normally takes.
• Cost and agreements: how you charge in general terms, what a service agreement covers, how cancellations work, and where the current NDIS pricing schedule can be checked.
• Safety and complaints: how workers are screened, how to raise a concern with you, and how to take a complaint outside your organisation.
• Registration: exactly what you are registered for, with your registration details, and what you are not registered for.

The registration line deserves special care. Wording such as "fully accredited" or "approved by the NDIS" invites trouble if it overstates what you hold. State the plain facts: which registration groups (the NDIS Commission now calls them "registration groups or classes of support") you are registered to deliver, and the date your registration is valid until, copied from your certificate of registration. The Commission says registered providers are generally registered for three years and are listed on its public NDIS Provider Register, so a family can check your page against the register in a minute. Make sure the two agree.

If you are not registered, say so plainly and say who you can support. The Commission's registration page (checked November 2026) says unregistered providers can deliver most supports, but only to participants who self-manage or plan-manage their funding; NDIA-managed participants, specialist disability accommodation, supported independent living, specialist behaviour support and plan management all need a registered provider. A line such as "We are not a registered NDIS provider. We can support you if your plan is self-managed or plan-managed" saves a wasted call on both sides. This is a good place for your manager or compliance lead to sign off before anything is published.

One "What we do" page, from facts sheet to finished draft

Say a small provider that supports adults living in their own homes wants a "What we do" page. The owner has a facts sheet. The sections below show the real sequence, with illustrative content.

The starting facts, abbreviated: "We help adults with daily tasks at home: cooking, shopping, getting to appointments, and community outings. We do not provide nursing care. Support workers visit for 2 to 6 hours. Most new clients start within about two weeks of signing an agreement, depending on worker availability. Evenings are possible; overnight support is not."

The prompt sent to the AI tool:

You are writing a web page for a small disability support provider.
Use ONLY the facts below. Do not add services, claims, numbers,
awards or promises that are not in the facts. If something is
missing, write [MISSING: what is needed] instead of guessing.

Reading level: a reader aged about 12. Sentences under 18 words.
Use "we" and "you". Active voice. No jargon without a short
explanation. Headings that say what follows.

Page: "What we do"
Structure: short opening paragraph, then a list of supports,
then "What we do not do", then "How to get started".

FACTS:
[paste the facts sheet sections here]

A typical first draft comes back looking roughly like this (illustrative):

We help adults do everyday things at home. This can include cooking, shopping and getting to appointments. We can also go out with you in your community. A support worker visits for 2 to 6 hours. We can visit in the evening. [MISSING: weekend availability]

That is good for a first pass because the gaps are flagged. Now the human edit. The owner notices "We can also go out with you in your community" is slightly vague, and "everyday things" hides the specifics. They rewrite it to "We can go with you to the shops, the park or a social group." They add the "we do not" section by hand: "We do not provide nursing care. We do not offer overnight support." Those two sentences protect participants from wasted calls and protect you from disputes about what you promised.

Time for the whole page: about 40 minutes, most of it the owner's own edit. Without the facts sheet it would take longer, because the draft would contain claims to hunt down and delete.

Step 2: draft plain-English pages with guardrails

For each page, reuse the same prompt wrapper and swap in the page name and the relevant facts. A few rules keep the output honest.

Ask for gaps, not guesses

The "[MISSING: ...]" instruction in the prompt above is the single most useful line. It turns invention into a to-do list. Before publishing, search the draft for "MISSING" and for any number, date or percentage that is not in your facts sheet.

Ban the filler phrases up front

Add a line such as: "Do not use: person-centred, tailored, best-in-class, journey, passionate." If your team really uses a term such as "person-centred" in its model of care, keep it only where you then explain what it means in practice: "You choose what we do and when."

Check the reading level with a tool

Paste the draft into a free readability checker, or ask the AI to count words per sentence and list any over 18. Treat the result as a rough guide. A readability score cannot tell you whether a sentence is clear, but it will catch the 40-word sentence you missed.

Keep names, photos and stories out

Do not put participant names, case details or support notes into a general chat tool to "make the story warmer". Testimonials come from the person, in their words, with their written consent. If you want help structuring a consent request, that is a job for a template, not for pasting real cases. The privacy side is covered in AI for NDIS providers: what is safe under the privacy principles.

Step 3: turn each plain-English page into easy-read

AI is useful here as a sentence-splitter and a first-pass simplifier, not as the author of the final version. Give it the approved plain-English page, never the raw facts, so that the meaning has already been checked once.

Convert the page below into an Easy Read draft.
Rules:
- One idea per sentence. Maximum 10 words per sentence where possible.
- Use everyday words. Replace any hard word with a simpler one.
  If a hard word is needed (for example "complaint"), keep it and
  add a short meaning the first time.
- Use "we" and "you".
- Put each sentence on its own line.
- After each sentence, in square brackets, suggest ONE simple picture
  (for example [a person cooking in a kitchen]).
- Do not add any fact that is not in the page.
- Keep headings short, as questions where natural.

PAGE:
[paste the approved plain-English page]

Sample output (illustrative) for the opening of the same page:

What do we do?
We help you at home. [a support worker and a person in a kitchen]
We can help you cook. [a person stirring a pot]
We can help you shop. [a shopping bag]
We can go with you to appointments. [a person getting into a car]

What you would fix: the AI's suggested pictures are generic, and "We help you at home" gives no sense of how long. A person would add "A worker visits for 2 to 6 hours." with a clock picture, and would consider whether "appointments" needs a one-line meaning ("a visit to the doctor or another service"). They would also check that no sentence relies on the one before it to make sense, because in easy-read each line must stand alone.

Where the pictures come from

This is a decision to make deliberately. Options include a licensed easy-read picture library, a set of photos you take yourself with written consent, or drawings produced by a designer. Generated images are the riskiest option because the same character can look different in each picture and details drift. Whichever you use, check every picture against its sentence by asking a participant what they think the picture says.

Step 4: a short accessibility check before publishing

Easy-read content is no use if the page itself cannot be reached. Run this check on each new page. It takes about 15 minutes.

1. Headings in order. One main heading, then subheadings that follow without skipping levels. Screen-reader users navigate by headings.
2. Text size and contrast. Body text of at least 16 pixels, dark text on a plain light background, no text over photographs. The accessibility guidelines' minimum contrast for normal text is 4.5 to 1; a free contrast checker gives you the ratio for your colours.
3. Alt text on every picture. A short description of what the picture shows. For easy-read pictures, the alt text is usually the sentence itself.
4. Link text that makes sense alone. "Call us on this number" beats a bare "here" or "more". Phone numbers should be tappable on mobile.
5. Keyboard test. Press Tab repeatedly. Can you reach every link and button, and can you see where you are?
6. Zoom test. Zoom the browser to 200 per cent: nothing should be cut off or overlap. Then narrow the window to phone width (the guidelines use 320 CSS pixels, roughly 400 per cent zoom on a laptop): the page should fit in one column without sideways scrolling.
7. Download the easy-read as a PDF as well. Some families print it. Make sure the PDF has real text, not just a picture of text.

The free accessibility checking tools built into modern browsers will flag missing alt text and contrast problems quickly, though they find only part of the issues. The keyboard and zoom tests catch what they miss. If you want something more formal, the Web Content Accessibility Guidelines (WCAG), currently version 2.2, are the standard to point a web developer to; level AA is the usual target, and the contrast, zoom and link-text checks above come from it.

Step 5: test with a real reader before it goes live

This is the step AI cannot do, and the one that makes the page actually easy-read. Ask two or three people who use easy-read, or an advocate who works with them, to read the page while you watch. Do not explain anything. Ask them what the page is for, what they would do next, and what they would ask the provider. Note every place they hesitate.

Pay the reviewers for their time, as a person would be paid for any consultation, or follow your organisation's policy on participant involvement. Never present someone's unpaid feedback as a formality. A realistic outcome: the reader understands every sentence, but is not sure what "start" means in "How to start". You change it to "How to join us" and add a phone-shaped picture next to "Call us".

Keep a one-line review log: page, date, who checked accuracy, who tested understanding, changes made. It is also useful when a participant asks why a page says something, and fits into the evidence folder described in the NDIS audit checklist tutorial.

Five more page examples, with what to watch in each

The "How to get started" page

This is the page a worried first-time participant reads. Write it as numbered steps, each with who does what and how long it normally takes. Example: "1. You call or send a message. 2. We call you back, usually within one working day. 3. We meet to talk about what you want. 4. We send you a service agreement to read. 5. You sign when you are ready." Avoid promising a start date; say "we will tell you when a worker is free". If your enquiry handling is slow, the page makes the gap visible, so fix the process, not the wording. A fast reply routine is covered in how to get clients as an NDIS provider.

The "Costs and agreements" page

Do not copy figures from memory. Say how you charge in general terms and point to the official pricing page. Since 24 September 2026 the NDIS maximum prices sit in a pricing schedule set by the Minister's pricing determination (the older "pricing arrangements and price limits" document covered 2025-26), and the maximum prices apply to NDIA-managed and plan-managed participants. The NDIS also says providers must tell participants the price of a support before delivering it, so a page that promises "we explain every cost before you start" is describing a duty, not a favour. Explain what a service agreement is in one sentence and link to the readable agreement. A page that says "we explain every cost before you sign, and you can cancel with notice as set out in your agreement" is true and useful, as long as the agreement actually says so. The agreement itself is covered in the NDIS service agreement tutorial.

The "Making a complaint" page

This one earns the most scrutiny. Put it where it can be found, not buried in the footer. Say who to tell, how (phone, email, in person, through an advocate), what happens next, and that raising a concern will not lead to worse treatment. Then say how to take a concern outside your organisation, using the official contact details copied from the regulator's own page and checked quarterly. An AI draft will often produce a gentle but vague paragraph, so insert the specific steps by hand.

The "Our team" page

Ask the AI to turn a short factual profile into two plain sentences. Example input: "Worker since 2022. First aid and manual handling certificates. Likes gardening and cooking." Output: "I have worked with us since 2022. I have first aid training. I like gardening and cooking." Never ask the AI to embellish. Staff consent to their photo and details, and details like qualifications must come from your records. Do not name qualifications you have not checked.

The "Frequently asked questions" page

Use the AI to turn your enquiry inbox into a question list. Export questions only, strip names and anything identifying, and paste a sample of 30 to 50 questions. Ask it to group them and list the ten most common. Then write the answers yourself from the facts sheet. A realistic result: seven of the ten questions are about start dates, cost and whether you cover a particular suburb or region, which tells you the main pages are not answering them.

When "sound welcoming" produced nurses the provider never had

Take a provider that asks the AI to "make the page sound welcoming" and publishes the result without a facts check. The page says "our qualified nurses are available around the clock." The provider has no nurses and does not offer overnight cover. A family calls expecting nursing support and the first conversation is an apology. The cost is a lost enquiry and possibly a complaint, and it is entirely avoidable: the draft contained a claim that was in no source document.

The safeguard is mechanical. Before publishing, highlight every noun that describes a service, person, qualification or number, and tick it against the facts sheet. Anything unticked is deleted or confirmed. It takes ten minutes per page.

Keeping the pages current without rewriting them

Pages go stale quietly: the maximum prices change each financial year, a worker leaves, you stop covering an area. Put a calendar reminder on the first Monday of each quarter with three jobs. First, re-read the facts sheet and update it. Second, ask the AI to compare the updated facts sheet with the current page and list every difference (paste both, no personal data). Third, edit the pages and republish easy-read versions together with the plain-English ones, so they never disagree.

When wording about registration or pricing changes, have a person check the regulator's current guidance, not an AI summary. Models can be out of date on rules that change often, and they can state old figures confidently. The 2026 pricing change is a good example: a model trained earlier will still talk about the "price limits" document as if nothing had moved. The NDIS website also carries a notice (November 2026) that its pages are being updated for new legislation, which is another reason to read the live page each quarter.

What to promise, and what to leave out

Easy-read pages carry extra weight because people trust simple words. That makes overpromising more harmful. Avoid anything that implies outcomes: "we will help you reach your goals", "we will improve your independence." You can describe what you do ("we practise cooking with you") without guaranteeing a result. Avoid comparative claims about other providers, and avoid describing funding rules unless you have checked them this month.

A good test is to read each sentence and ask: "Could the participant hold us to this?" If yes, make sure it is true and written into the agreement. If you are not sure, leave it out.

How to tell whether the new pages are working

Measure three simple things for 60 days after the update. First, the questions arriving by phone and email: are the basic ones (where, when, how much) falling off? Second, the share of enquiries that turn into a first conversation, which should hold or rise. Third, direct feedback from the testers and from the first participants who say they used the easy-read page. If the website tool you use shows page visits, look at whether people reach the contact page from the easy-read version.

If numbers do not move, the issue is usually the page's position, not its wording: the easy-read link is hidden, or the contact details are low on the page. Move them before rewriting anything.

If you would rather map this with someone, my AI implementation consultation covers it. Otherwise, the routine above is enough to run on your own: facts sheet, constrained draft, human edit, easy-read pass, accessibility check, reader test.

Questions providers ask before publishing easy-read pages

Can AI make the pictures for an easy-read page?

It can produce images, but easy-read pictures must match the words exactly and show the same people and objects each time. Generated images drift, so many providers use a licensed easy-read picture library or their own photos with consent. If you do use generated images, check each one against its sentence with a participant.

Do I need a separate easy-read page for every service?

Not at first. Start with the pages people reach most: what we do, how to get started, what it costs and who to call with a complaint. Add the rest as participants ask for them. One clear easy-read page beats ten rushed ones.

Should the easy-read version replace the normal page?

No. Keep the plain-English page as the main page and link to the easy-read version beside it. Some people prefer the standard layout, and families, support coordinators and referrers usually read the standard version.

Who should approve the final wording?

A person who knows the service and a person who uses easy-read should both approve it. The first checks accuracy, the second checks whether it can be understood. Record the date and names on a simple review log.

Further reads

• NDIS Provider Policies and Procedures: Tailoring Templates With AI — Align website claims with the policies you actually run.
• NDIS Providers Automation Assessment Checklist: Which Jobs for AI First? — Decide which admin jobs to automate after the website.
• How to Write NDIS Progress Notes: An AI-Assisted Audit Checklist — Keep records that back up what the site says.
• NDIS Software for Small Providers: Per-User Costs and What You Get — Compare software before adding forms to the site.
• NDIS Invoicing: Checking Claims Against Shift Notes With AI — Tighten the claims side once enquiries grow.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: NDIS Quality and Safeguards Commission pages on registration and registration groups; NDIS pages on pricing arrangements, provider responsibilities and service agreements (with their Easy Read downloads); W3C Web Content Accessibility Guidelines 2.2. All checked November 2026.