Website Accessibility for NDIS and Aged Care Providers: A Practical WCAG Guide

The ABS Survey of Disability, Ageing and Carers counted 5.5 million Australians with disability in 2022, or 21.4% of the population. Among people aged 65 and over the share was 52.3%, about 2.3 million people. A disability support or home care website is written for exactly these readers, and for the partners, adult children, support coordinators and hospital discharge staff reading on their behalf.

The same survey hints at what that looks like on screen. About three in four people with disability named a physical condition as their main one, with arthritis and back problems among the most common, and 17.0% of people with disability used a hearing aid. So the people opening your pages include someone who can't comfortably grip a mouse, someone with the browser zoomed well past 200 per cent, someone hearing the page through a screen reader, and someone who needs captions on your welcome video.

On these sites accessibility isn't a courtesy for a handful of visitors. It decides whether the person you exist to support can read about your services without help.

The Web Content Accessibility Guidelines are published by the W3C, and version 2.2 became a W3C Recommendation on 5 October 2023. Its success criteria sit under four principles: content must be perceivable, operable, understandable and robust. Every criterion carries a level. Level A is the floor, Level AA includes all of A and adds more, and Level AAA is the most demanding. AA is the level the Style Manual asks federal agencies to measure their own content against, and the sensible target for a provider site.

Version 2.2 added nine criteria to version 2.1 and retired one, 4.1.1 Parsing, as obsolete. Six of the additions are at Level A or AA, and most of them land squarely on provider sites:

• Target size (minimum), AA. Buttons and links at least 24 by 24 CSS pixels, or spaced so a slightly off tap doesn't land on the wrong one. It matters for anyone with a tremor or stiff fingers.
• Consistent help, A. If your phone number, enquiry link or chat appears on several pages, it appears in the same relative order on each.
• Redundant entry, A. A multi-step referral form doesn't make the referrer type the participant's details a second time.
• Accessible authentication (minimum), AA. A client or family portal login can't depend on a memory test or puzzle without an alternative way through.
• Focus not obscured (minimum), AA. A sticky header or cookie banner can't completely cover the link a keyboard user has just moved to.
• Dragging movements, AA. Anything done by dragging, such as a slider for choosing hours of support, also works with single taps or clicks.

A WCAG 3 is on the way, but the W3C calls it an incomplete draft that's still a few years from becoming a standard, and says meeting WCAG 2.2 now is the best preparation. Version 2 won't be deprecated until several years after version 3 is finalised.

WCAG puts reading level at AAA: criterion 3.1.5 asks for a simpler version when text needs more than lower secondary reading ability. Few sites meet every AAA criterion, but the NDIS and aged care wording above is about information people can understand, which is a plainer test than a services page written in program language. Short sentences, the everyday name for each support before its funding category, and a few words explaining every acronym all help.

Easy Read is a different format again: short sentences paired with pictures, usually prepared by specialists and often tested with readers. If you have Easy Read versions of your service information, we publish them as pages on the site or link the files you provide. As with the rest of the site, the words and images come from you.

Uploaded documents are where otherwise accessible sites tend to slip. A scanned service agreement or price schedule is just a picture of text to a screen reader, and a long PDF is hard work on a phone at any zoom level. Where something affects a decision, such as prices, intake steps or how to raise a complaint, it reads better as a page on the site, with the PDF offered as a download beside it.

A provider is responsible for its own website, whoever built it. The parts of WCAG that live in the build go into every page we hand-code: a logical heading structure, labelled form fields, keyboard access with a visible focus outline, sufficient contrast, layouts that reflow on small screens and touch targets sized for unsteady hands. The site we built for Golden Years Aged Care Support, an in-home aged care provider in Northern Adelaide, uses large readable text and tap-to-call on every page for older readers and the relatives helping them.

Other parts depend on what goes onto the site over time: which photos you choose, what documents you upload, whether videos are captioned and how plain your wording is. Before launch we point out anything we notice in your material that would cause problems, such as scanned PDFs or words inside images. Once the site is live on our hosting, swapping an image, correcting a photo description or moving the text of a PDF onto one of your existing pages counts as a text and image change, so it's covered by the monthly fee.

We don't audit or certify sites. If a funding body, tender or contract asks for formal evidence of WCAG 2.2 AA conformance, an independent accessibility auditor is the right person to provide it. Many organisations also publish an accessibility statement saying which standard they aim for and how to report a barrier. The W3C has guidance on preparing one, and we'll set yours out as a page from the wording you supply.