Nobody asks about accessibility. Ninety percent of the time it doesn’t come up in a project at all. The other ten percent, someone asks if I can “just add” it, like it’s a plugin.
Neither one is close to the truth.
Why this matters more than it looks like
In 2022, 1 in 5 Australians, 5.5 million people, were living with disability. That’s up from 17.7% in 2018. Among people over 65, it’s more than half. If your visitors skew older, and most regional community and business audiences do, a real slice of them are already dealing with vision, hearing, or dexterity changes that affect how they use a website.
It’s also not trending the right way. The 2026 WebAIM Million report, which scans the top million home pages on the internet every year, found 95.9% of them still have detectable accessibility failures, up from 94.8% the year before. Most businesses, most of the internet, are quietly going backwards on this. That’s the gap a well-built site actually closes.
What accessibility actually is
It means someone can use your site regardless of how they’re interacting with it. Someone tabbing through with a keyboard because a mouse doesn’t work for them. Someone using a screen reader because they can’t see the screen at all. Someone who’s zoomed the page to 200% because their vision isn’t what it was. Someone with a tremor who needs a button big enough to actually land on. Someone who gets motion sickness when there are too many animations on the page.
There’s a real standard behind this called WCAG, and most sites that take it seriously aim for what’s known as AA level, one notch below the strictest tier. I work towards that standard on every build I do. Contrast ratios, text size, spacing, button sizing, skip links so a keyboard user can jump straight past the menu, a menu structure that actually makes sense without a mouse.
That’s not a box I tick once. It’s a set of decisions I make on every page.
Fiona has difficulty seeing. She uses a screen reader to get through her day online, banking, appointments, ordering groceries. She lands on your homepage and it starts reading the page aloud. If your menu isn't built properly, what she hears is a wall of unlabelled links with no way to skip past them to the actual content. She's gone within ten seconds, not because your business was wrong for her, but because she never got past the menu.
Who actually controls what
Here’s the part most web people won’t say out loud. I can build a site that genuinely meets AA level, top to bottom, and it can drift out of that the first month someone at the organisation uploads a scanned PDF with no text layer, or posts a video with no captions.
That’s not a gap in what I did. It’s the ongoing, operational side of accessibility, and it belongs to whoever’s adding content after launch, not to the build itself.
So the honest split is: I control the structure, the contrast, the code. You control what goes on top of it once the site is live. If you’d rather that ongoing part didn’t sit entirely on your plate, that’s exactly what a website care plan covers.
Margaret is 68 and has macular degeneration. She's exactly the kind of member your community group is trying to reach. She can still read, just not small text, and not scanned documents. When she opens the PDF newsletter your office uploaded last week, really just a photo of a printed page, her screen reader has nothing to read and her zoomed-in browser can't sharpen it. The website did its job. The PDF didn't.
What working towards AA actually gets you
On a build I do, that’s font size that doesn’t force anyone to squint, contrast that holds up in bright light or on a cheap monitor, spacing that gives buttons and links room to breathe, buttons sized for someone whose hands don’t move the way they used to, skip links, and a menu that works the same whether you’re clicking, tapping, or tabbing. I say that it’s at least 80% compliant (probably closer to 90%), depending on the site.
Put together, that’s a site a genuinely wide range of people can actually use. Someone browsing on their phone in full sun. Someone with a vision impairment using browser zoom. Someone who’s never used a mouse and never will. Most regional business sites don’t do any of this on purpose. Mine do, as a default, not an add-on.
What full WCAG compliance actually takes
Building towards AA on the front end is not the same thing as a certified accessibility audit, and I won’t tell you it is.
A proper audit is its own specialised engagement: automated scanning to catch the obvious issues, then manual testing by someone who actually uses assistive technology day to day, because scanners miss most of what matters. Then remediation of whatever that testing turns up, a re-test to confirm it’s actually fixed, and ongoing monitoring, because a site that passes today can fail again the moment new content goes on it. That’s usually done by a specialist, not a web designer, and it’s not a one-off project. It’s a standing commitment.
I build a strong foundation for that work. I don’t do that work myself.
Is 80% compliant enough for you?
For most regional organisations, a well-built site working towards AA is genuinely enough. But a few questions are worth asking yourself honestly, not hopefully:
Do you have a legal or contractual obligation, a government tender, a funding body, to meet a certified accessibility standard?
Do you know of a current member, customer, or staff member who relies on assistive technology to use your site?
Are you regularly uploading PDFs, forms, or video, and are they captioned and properly tagged?
Would a discrimination complaint cost you more than a proper audit would?
If none of those land, my standard build is more than enough. If one of them does, that’s your signal to bring in a specialist for the parts I don’t cover.
If you’re not sure which side of that list you’re on, a full website audit is the plain way to find out where your site actually stands before you spend on anything further.
