Blossom Care Disability Services is a registered NDIS provider based in Kings Park, in Sydney’s west. You do not have to take that from us. The NDIS Quality and Safeguards Commission publishes a provider register. Blossom Care Disability Services Pty Ltd sits on it, with seven approved registration groups and a registration current to 4 November 2027.
Those groups cover a wide span: support coordination, community participation, household tasks, daily tasks and shared living, assistance with life stage transition, specialised disability accommodation, and group and centre activities. That range is the central fact about the website. A provider holding one support can explain itself on a single page. A provider holding seven cannot.
The people reading the site are not one audience either. A participant wants to know whether the supports on offer match what they need. A family member is deciding whether the organisation is real and safe. A support coordinator, working through a caseload, wants to see the supports and the availability without making a phone call to find out.
Three problems sit in front of any provider website, and they pull in different directions.
The first is range. Seven supports listed on one page make that page compete with itself for seven different searches. Someone looking for supported independent living is not asking the same question as someone looking for a support coordinator. One page answers neither of them well.
The second is trust, and it is unusually load-bearing in this sector. Choosing a provider is not a low-stakes purchase, and almost nothing a provider says about itself can be checked by the person reading it. Registration is the exception. That is why it belongs on the page in plain text rather than implied by a logo.
The third is access, and it is the one most provider websites treat as an afterthought. Some of the people reading a disability services website cannot use a site built the ordinary way. Keyboard-only navigation, screen readers, readable contrast, forms that explain their own errors. On a provider site those decide whether a participant can enquire at all.
Nobody can verify that from the outside without doing the work. So we did the work and published it.
Support coordination, community participation, community nursing care, supported independent living, individualised living options, specialist disability accommodation and transport each sit on their own URL with their own heading and their own explanation.
A visitor arrives on a page about the exact support they were searching for, rather than a list they have to scan. And a search engine gets seven distinct documents to match against seven distinct intents, instead of one page trying to answer all of them.
An about page, a blog, and a contact page with a single enquiry form. Plus a page explaining the NDIS itself, which links out to the Commission’s own guidance on the Code of Conduct and on provider obligations.
On 7 August 2026 we ran the full test across all twelve pages using axe-core 4.10.2 on Chromium, followed by keyboard, focus, target size and form passes by hand.
We published the result as a document rather than a claim. It lists the tools and their versions, the pages and the enquiry process covered, every criterion checked, what passed, what did not, and what has not been fixed. It also lists what we did not test, which is the section most accessibility statements leave out.
Some of what the test confirmed is worth stating plainly, because it was measured rather than asserted:
main, one nav, one header and one footer per page. Landmark regions are how assistive technology skips past navigation.Five criteria did not pass, and colour contrast is the widest of them. Those are published with the same detail, along with the reason they remain in place. A test report that only contains passes is not a test report.
The site is a React application, and that decision predates the accessibility work described above. It carries a trade-off a WordPress build does not. The page assembles in the browser rather than arriving complete, which affects how some tools and some assistive technology reach the content.
For providers who want to update their own site without booking a developer, we now build on WordPress instead, and the NDIS websites we build today are accessible from the first template rather than tested at the end.
| Element | How it is handled |
| Supports | Seven dedicated pages, one per support, reachable from the main navigation |
| Registration | Provider status and approved groups verifiable on the NDIS Commission register |
| NDIS guidance | A dedicated page linking to the Commission’s Code of Conduct, provider obligations, and feedback and complaints |
| Enquiry path | One contact form with labelled fields, plus a phone number and email address in the footer of every page |
| Accessibility | All twelve pages tested against WCAG 2.2 Level AA, with the report published in full |
| Consistent help | Phone number and contact link in the same position in the header and footer on every page |
Blossom Care holds seven registration groups and a registration a family can check in a minute. The website now presents those supports one at a time, in language a participant and a coordinator can both use, on pages that can be found on their own terms.
What it also has, and almost no provider website in Australia does, is a published record of how accessible it actually is. Not a badge, not an overlay widget, not a sentence about being committed to inclusion. A dated document with tool versions in it, listing what passed and what did not.
A provider website that claims accessibility without evidence is asking families to accept exactly the kind of unverified assurance the sector exists to move away from. The report is the alternative to asking.
Most providers do not, and there is no way to find out by looking at it. If you hold more than one registration group and you have never seen your site tested, that is the place to start. Talk to us about your website, or see the live Blossom Care site and try it with the Tab key.