Website accessibility basics for Australian businesses

Start with one question: can a person with disability complete the same task on your website that anyone else can? Book the job, buy the product, find the phone number. If the answer is no or you have never checked, this guide is for you. No scare campaign and no magic plugin, just what accessibility actually involves, what Australian law says and where to start.

The straight answer: your website should be usable by people with disability

Website accessibility means building your site so people with disability can actually use it. Not a separate version. Not a widget bolted on afterwards. The main website, working for more people.

That includes people who:

• are blind or have low vision

• are Deaf or hard of hearing

• have limited movement or dexterity

• use a keyboard instead of a mouse

• use a screen reader or voice control

• live with a cognitive or learning disability

• live with a neurological condition

• need larger text, stronger contrast or reduced motion

The Australian Human Rights Commission’s 2025 guidance frames it around task completion. Someone should be able to understand the product, buy it, receive the confirmation and use the service. The whole journey, not just the homepage.

Here is the uncomfortable part. Most accessibility problems are invisible to the people who built the site, because they never test the way other people browse. Those same problems are also a quiet reason why a site can get traffic and still get no enquiries. A visitor who cannot complete your form does not complain. They leave.

Does Australian law require websites to be accessible?

Short version: there is no line in Australian law that says your website must pass WCAG 2.2 AA. There is something broader and arguably stronger. Here is how the pieces fit.

The Disability Discrimination Act

The Disability Discrimination Act 1992 is Commonwealth legislation that prohibits discrimination against people with disability across public life, including the supply of goods, services and facilities. The Australian Human Rights Commission’s position is that those obligations extend to digital goods and services. Its current guidelines are written specifically for organisations providing them.

The practical reading: if your website is how customers buy from you, book you or get information and the way it is built locks people with disability out of doing those things on an equal basis, that can become a discrimination issue. This is not a new idea. A complaint about the Sydney Olympics website was upheld back in 2000, so the DDA reaching web content has been settled thinking for a quarter of a century.

What that can look like in practice:

• an online store that cannot be operated with a keyboard

• a booking form a screen reader cannot make sense of

• videos carrying essential information with no captions

• important instructions communicated only through images

• controls that only work with a mouse

The Act also has nuances, including exceptions, which is exactly why specific concerns belong with a lawyer rather than a blog article or a web designer.

Does the DDA specifically say WCAG 2.2 AA?

No and the distinction matters. The DDA is legislation. WCAG is a technical standard written by the W3C, the body that maintains web standards. The law does not name a checklist.

What connects them is the Australian Human Rights Commission. Its Guidelines on equal access to digital goods and services, released in April 2025, recommend organisations conform to WCAG 2.2 at minimum Level AA. The same guidelines say, in plain terms, that they are not legally binding, that they should be read alongside the DDA and state and territory discrimination laws and that following them does not by itself guarantee an organisation could never be found to have discriminated. They replaced the Commission’s 2014 advisory note, so anything you read citing the old note is out of date.

What about Australian Government websites?

Government runs to a higher, more explicit bar. Under the Digital Experience Policy that took effect in January 2025, agencies work to the Digital Inclusion Standard, which requires accessible design and delivery, points agencies at the current WCAG requirements and calls for testing with automated tools and real users rather than scans alone.

If you run a private business, that standard does not bind you. It is still the clearest picture available of what current Australian accessibility practice looks like and it is a useful benchmark to borrow from. When a government agency will not launch a service without keyboard testing, that tells you something about where the bar sits.

What is WCAG?

WCAG stands for Web Content Accessibility Guidelines. It is developed by the World Wide Web Consortium’s Web Accessibility Initiative and the current version is WCAG 2.2. Rather than a pile of rules, it is organised around four principles. If you remember nothing else, remember these, because every specific requirement hangs off one of them.

Perceivable

People need to be able to take in the information, whatever senses they are using. In practice:

• images have useful text alternatives

• text has enough contrast against its background

• videos provide captions

• information is never communicated through colour alone

• content can be enlarged without falling apart

Operable

People need to be able to use the interface, not just look at it. In practice:

• navigation works with a keyboard

• keyboard focus is visible at all times

• buttons are large enough to hit

• nobody gets trapped inside a popup

• carousels can be paused and controlled

• nothing depends on complex dragging gestures alone

Understandable

People need to understand what is in front of them: the navigation, the labels, the instructions, the error messages and the content itself. Plain language does more for accessibility than most design flourishes, which is why we bang on about it in writing website copy that does not sound like a robot. In practice:

• button labels that say what the button does

• menus that stay consistent from page to page

• form errors that explain the fix

• instructions written for humans, not lawyers

• interactions that behave predictably

Robust

The site should work reliably across browsers, assistive technologies, screen readers, keyboard input and voice control, including technology that has not been invented yet. Clean, semantic HTML does most of the heavy lifting here. A button coded as a real button announces itself to every tool. A styled div pretending to be a button announces nothing.

What do WCAG A, AA and AAA mean?

WCAG requirements, called success criteria, are grouped into three levels. Level A covers the fundamentals. Failing these tends to create major barriers, the kind that stop someone using a page at all. Level AA builds on A and addresses most of the serious problems people hit day to day. It is the level the Human Rights Commission currently recommends organisations aim for at minimum. Level AAA adds further improvements again and not every piece of content can realistically satisfy every AAA criterion, which is why nobody sensible demands blanket AAA.

What we recommend at Elev8d

Pick WCAG 2.2 Level AA as the design target and write it into the brief before anyone opens a design file. Treat Level A as non-negotiable, aim for AA across the board and adopt AAA criteria where they are cheap and sensible. Stronger contrast on your primary buttons is the obvious one. A target everyone agrees on at the start costs nothing. Retrofitting one nobody agreed on costs plenty and the argument about whose job it was costs even more.

Website accessibility basics every business should understand

This is the working heart of the guide: 24 things that decide whether real people can use your site. None of them require you to become a developer. All of them are worth understanding well enough to check, brief and question.

1. Add useful alt text to meaningful images

Alt text is the written alternative a screen reader announces when an image cannot be seen. Good alt text carries the same useful information the image does. Bad alt text carries a filename or worse, a keyword dump.

Do not stuff keywords into alt text. It reads as spam to search engines and as gibberish to a person listening to the page. We see this constantly on trade sites where photos went up in bulk, which is one of the habits we unpick in our web design guide for tradies.

Purely decorative images are the exception. Background textures, flourishes and meaningless icons should be marked so assistive technology skips them entirely. The test is one question: would someone lose useful information if they could not see this image? If yes, describe it. If no, mark it decorative and move on.

2. Make text easy to read against its background

The usual offenders:

• light grey text on white

• pale brand colours used for small text

• text sitting over busy photography

• placeholder text with barely any contrast

• footer links nobody can read

Your brand colours were chosen for a logo, not for paragraphs. Some will work beautifully as backgrounds and borders and fail badly as small text. Ours do exactly that. Elev8d gold is great behind black text on a button and hopeless as body copy on white. Check, do not assume.

3. Do not use colour as the only way to communicate something

The classic mistake is a form note that reads fields shown in red are required. Someone who cannot distinguish that colour just lost the instructions. The fix is redundancy: a visible Required label, an icon plus text, error messages written in words.

The same trap shows up in chart categories that only differ by colour, stock levels shown as green or red dots, selected tabs marked by tint alone and pricing tables where the highlighted column is the only clue. Colour can reinforce meaning. It should never carry it alone.

4. Use readable text

Readable typography is not a taste question, it is a usability one. Get the basics right: a sensible body text size, comfortable line height and line length, real paragraph spacing, a clear heading hierarchy and enough contrast throughout.

Avoid tiny legal text, long passages in uppercase, decorative fonts pressed into body copy duty and paragraphs parked permanently over busy imagery. If a design choice makes you lean toward the screen, it is making someone else give up.

5. Let users zoom

Never block pinch zoom on mobile and make sure the site survives 200 per cent browser zoom, larger system text and different display scaling. Surviving means the layout reflows rather than breaks: no overlapping buttons, no clipped sentences, no navigation that quietly disappears, no forms that become unusable. Zooming is one of the most common assistive behaviours there is and plenty of people doing it would never describe themselves as having a disability. They just want to read your prices.

6. Use a logical heading structure

Headings are not font size choices. They are the structure of the page and screen reader users jump between them to navigate the same way sighted users skim. A sensible structure looks like this:

H1: Emergency plumbing services

H2: What we do

H3: Blocked drains

H3: Hot water repairs

H2: Service areas

H2: Get a quote

Avoid choosing an H4 because it happens to look nicer, skipping levels for no reason, turning every second sentence into a heading or styling ordinary text to look like a heading without the markup behind it. That hierarchy is also the backbone of the homepage structure that turns visitors into enquiries, so getting it right pays twice.

Search engines lean on the same structure to understand your pages, which is one of many places accessibility and search overlap. We cover that side properly in our complete guide to SEO for Australian businesses.

7. Make link text meaningful

Screen reader users often pull up a list of every link on a page, stripped of its surrounding text. Ten links that all say read more are ten mysteries. Link text should describe the destination.

This one is free to fix and improves the site for everyone, including search engines, which read link text as a signal of what the destination page is about.

8. Make the website work without a mouse

This is the big one. A visitor should be able to run your entire site using keys alone: Tab and Shift plus Tab to move, Enter and Space to activate, arrow keys where menus expect them, Escape to close anything dismissible.

Test the things that make you money, not just the homepage: navigation, dropdown menus, buttons, forms, accordions, modals, cookie banners, booking widgets, carousels and checkout. The Digital Inclusion Standard for government services calls out compatibility with keyboard input, screen readers and voice control specifically. It is not a fringe requirement, it is table stakes.

9. Make keyboard focus visible

When someone presses Tab, they need to see where they are. The bad habit is deleting the browser’s default focus outline because a designer found it ugly and replacing it with nothing. That leaves keyboard users navigating blind. The good habit is a deliberate focus style: a clear outline, border, underline or background change that is obvious at a glance. Ugly and visible beats elegant and invisible, but you can have handsome and visible if you actually design it.

10. Do not let sticky elements hide focus

WCAG 2.2 added criteria for a modern problem: keyboard focus disappearing behind sticky headers, chat widgets, cookie banners and fixed mobile CTAs. The user is on a button, they just cannot see it, because your floating element is sitting on top. Check every layer that floats: if focus can land behind it, fix the layout or the focus behaviour.

11. Make buttons easy to identify and use

Avoid tiny icon buttons with no accessible name, links styled identically to plain text, vague labels like submit on their own and controls packed so tightly that thumbs hit the wrong one. WCAG 2.2 includes a Level AA minimum target size of 24 by 24 CSS pixels, with defined exceptions.

Our advice: do not design to the technical minimum. 24 pixels is the floor, not the goal. Comfortable targets sized for thumbs on a bumpy tram cost you nothing and quietly lift conversion on every device.

12. Give every form field a real label

Every input needs a visible, persistent label: the words Email address sitting above or beside the field, not just inside it. Forms are where accessibility failures cost the most, because a form nobody can finish is an enquiry nobody sends. We go deep on layout, length and friction in our full guide to building forms people actually finish.

13. Explain form errors clearly

An error message has one job: tell the person what to fix. Invalid does not do that job.

Good errors identify the field, explain the fix, stay visible until resolved and never rely on red colouring alone. Vague errors quietly kill paid traffic too, since every abandoned form is a click you paid for. We pulled that apart in why Google Ads campaigns fail at the landing page.

14. Make required fields clear

Mark required fields with the word Required or an asterisk explained once at the top of the form and set the required state in the code so assistive technology announces it. Do not rely on colour, position on the page or placeholder text to carry that information. Better yet, delete every field that is not genuinely required and the problem shrinks on its own.

15. Avoid making users enter the same information repeatedly

WCAG 2.2 added criteria around redundant entry and accessible authentication and they exist because re-typing is a genuine barrier for people with motor or cognitive disability, not just an annoyance. Where practical: prefill what you already know, reuse details entered earlier in the same process, let password managers do their job, support copy and paste in every field and avoid puzzles or memory tests at login. If your checkout asks for the delivery address twice, that is a bug wearing a form’s clothing.

16. Keep navigation consistent

Visitors should not have to relearn your site on every page. Keep the menu in the same place with the same labels, keep search where people expect it, keep account access, breadcrumbs and support links consistent throughout. Consistency is an accessibility requirement precisely because unpredictability taxes memory and attention. It taxes everyone else too, they just complain about it less precisely.

17. Include a skip link where appropriate

A skip to main content link lets keyboard and screen reader users jump past your header and menus instead of tabbing through forty links on every single page. It can stay invisible until focused, so it costs the design nothing. The bigger your header, the more it matters: sites with mega menus and stacked utility navigation are the worst offenders.

18. Caption important video content

Captions serve Deaf users and people who are hard of hearing first and then quietly serve everyone else: people watching on mute in a waiting room, on a noisy site or in a language they read better than they hear. Video carrying essential information may also need a transcript or audio description depending on the content. A two minute explainer with automatic captions you have actually corrected is a fine start. Uncorrected automatic captions on a technical video can be genuinely worse than none.

19. Do not autoplay audio

Unexpected sound talks over screen readers, disorients people and creates real sensory difficulty for some visitors. It also makes everyone else scramble for the mute button, usually while closing your tab. Give people a play button and let them choose.

20. Respect reduced motion preferences

If your site uses parallax, animated backgrounds, scroll effects or large transitions, remember that some visitors set a reduced motion preference at the operating system level, often because motion makes them dizzy or ill. Respect it. The technical hook is the prefers-reduced-motion setting, which lets the site tone animation down for those users. The design principle is simpler: animation should decorate the experience, never be required to understand or operate it.

21. Avoid flashing content

Rapidly flashing content can trigger seizures in people with photosensitive epilepsy. This is one of the few accessibility issues with direct physical harm attached, so treat it as a hard line. No strobe animations, no flashing banner components, no rapidly cycling imagery. If a designer proposes something that flashes more than a few times per second, the answer is no.

22. Build actual tables for tabular data

Data belongs in real table markup with proper headers and rows, not in a screenshot of a spreadsheet or columns faked with spacing. A screen reader can walk a real table cell by cell and announce which header each value belongs to. It can do nothing with a picture of one. Keep complex comparison tables usable on mobile too, because a table that forces horizontal scrolling with no cues is a barrier of its own.

23. Remember that PDFs need accessibility too

A beautifully accessible page that links to an inaccessible PDF has not solved the customer’s journey, it has just moved the wall. Common PDF failures: scanned images with no real text, no document structure or headings, broken reading order, unlabeled form fields, missing alt text and tables that fall apart.

The practical rule: publish important information as accessible HTML first and reserve PDFs for things that genuinely need to be documents. PDF menus are the classic offender, which is why they get their own section in our restaurant and café website guide.

24. Check cookie banners, chat widgets and popups

Third party overlays fail in predictable ways: keyboard focus gets trapped inside them, the close button cannot be reached, the popup cannot be dismissed without a mouse, screen readers are never told a dialog opened and the page behind stays wrongly interactive. Your customer does not know or care that the chat widget came from a vendor. It is on your site, so it is part of your customer experience and it deserves the same testing as anything you built.

Common website accessibility problems we see

Reviewing small business sites across trades, professional services, hospitality and ecommerce, the same problems come up again and again. Ranked roughly by how often we find them:

Notice what is missing from that list: exotic technical failures. Almost everything above is a basic decision made without thinking about who else has to use the result. Which is good news, because basic decisions can be remade.

Accessibility fixes many businesses can make quickly

Not everything needs a developer or a budget line. Split the work by who can actually do it and a surprising amount clears in a week.

Can an accessibility plugin or overlay make my website compliant?

Not by itself. An overlay is a toolbar that offers interface options on top of your existing site: larger text, contrast toggles, reduced motion. Some of those options are genuinely handy for some visitors and that is roughly where the good news ends.

What an overlay cannot reliably repair:

• broken HTML structure underneath

• keyboard behaviour that traps or skips

• custom widgets built without accessibility

• meaningless or missing alt text

• forms with no real labels

• inaccessible PDFs

• confusing content and instructions

Some overlay products are marketed as one line of code that makes you compliant. Treat that claim the way you would treat a paint product marketed as one coat that fixes rising damp. It covers the wall. The problem is still in the wall.

How to test your website for accessibility

No single test tells you the truth. Use layers, cheapest first and let each layer catch what the previous one cannot.

Layer 1: automated testing. Scanners are excellent at the mechanical stuff: missing labels, contrast failures, some markup errors, missing page language, duplicate IDs. Start with our free accessibility quick check tool for a two minute read on the obvious problems, then go deeper with the tools below.

Layer 2: manual checks. A human tests what a scanner cannot judge: keyboard navigation, whether alt text actually says anything useful, focus order, error recovery, zoom behaviour, the video experience.

Layer 3: assistive technology testing. Run the core journeys with a screen reader, keyboard only, magnification and voice control where relevant. This is where problems that passed every scan finally show themselves.

Layer 4: user testing. Where accessibility genuinely matters to your business, test with people who use assistive technology every day. Government guidance says the same thing: automated tools plus real users, never scanning alone.

The testing pyramid, top to apex value: automation is the starting point, not the finish line.

What we recommend at Elev8d

Layer the testing and match the effort to the risk. For a typical service business site, half a day covers it: automated scans, a full keyboard pass on the money pages, a screen reader run through the contact form and a zoom test at 200 per cent. For ecommerce, bookings, client portals or anything in health, finance or education, bring in specialist accessibility testers and people who use assistive technology daily. And never buy an overlay as a compliance shortcut. Put that money into fixing the site instead.

Free website accessibility testing tools

Every tool here is free and every tool here has limits it is honest about. Use them in combination, not in isolation.

Google Lighthouse

Built into Chrome DevTools, Lighthouse audits accessibility alongside performance, SEO and best practices. It is good for an initial technical scan: missing labels, contrast, some semantic issues. It is not good for proving a site is accessible and Google says as much. Its performance tab also reports Core Web Vitals, which we translate in Core Web Vitals in plain English for business owners.

WAVE

WAVE paints its findings directly onto the page, which makes it the friendliest option for people who do not read code. Strong for visualising page structure, contrast errors, heading order, labels and alt text review. WebAIM, who make it, state plainly that WAVE cannot determine whether a page is truly accessible and that human evaluation remains necessary. Believe them, they built the thing.

axe DevTools browser extension

Deque’s free axe browser extension is the developer’s pick: precise, technical, low on false positives. Good for component review and catching accessibility defects during a build rather than after one.

The keyboard test

Cost: $0. Time: ten minutes. Unplug or ignore the mouse and try to become a customer. Open the menu, follow a link, expand an accordion, complete the enquiry form, dismiss the cookie banner, operate the booking tool, add something to a cart, reach the checkout. Watch where the focus goes and where it vanishes. This single test finds more real problems than most paid audits people never act on.

A screen reader test

Free screen readers already live on your devices: VoiceOver on Mac and iPhone, Narrator on Windows, TalkBack on Android and NVDA as a free download for Windows. At minimum, learn enough to check the page title, headings, links, buttons, forms, errors and image alternatives. One honest caveat: a developer poking at a screen reader for an afternoon is not equivalent to testing with someone who uses one every day. It still beats never having listened to your own website.

W3C Easy Checks

The W3C publishes Easy Checks, a first review of web accessibility, a guided set of preliminary checks anyone can run. The W3C itself warns these cover only some issues and are not a complete evaluation, which is exactly the right way to use them: a structured first pass, not a verdict.

Why an accessibility score is not a compliance certificate

Here is what no scanner on earth can judge: whether your alt text actually says anything useful, whether the heading hierarchy makes sense to a human, whether instructions are understandable, whether the keyboard order is logical, whether a screen reader experience holds together, whether a real transaction can genuinely be completed. Scanners check the presence of things. Accessibility lives in the quality of things.

The W3C recommends combining tools with broader evaluation and WAVE’s own makers say automated results still require human judgment. When the people who build the scanners tell you scanners are not enough, that settles the question.

A practical website accessibility audit

You do not need a consultant to run a first serious pass. Here is the process we use, scaled for a small business. It pairs nicely with the 30 minute DIY website audit for the general health side of the site.

Step 1: pick representative pages. Homepage, your main service page, one article, the contact page, your key form and if relevant a product page, checkout, booking journey, login and one PDF.

Step 2: run the automated scans. Lighthouse, WAVE and axe across the sample. Log everything, fix nothing yet.

Step 3: run the keyboard test. Tab order, visible focus, menus, modals, forms, checkout. Note every place you get lost or stuck.

Step 4: test zoom and reflow. Browser zoom to 200 per cent, larger system text, a narrow viewport. The layout should reflow, not collapse.

Step 5: run a screen reader through the core journeys. Can a listener understand the page, find the form, finish it and know it worked?

Step 6: review the content manually. Headings, link language, alt text quality, instructions, error wording, captions.

Step 7: prioritise by user impact. Sort every finding into the severity bands below, not by how easy it is to fix.

Step 8: fix and retest. Accessibility fixes need QA like anything else, so fold them into the launch checklist we run before a site goes live rather than treating them as a side quest.

Accessibility is much cheaper to build in than retrofit later

Retrofitting accessibility into a finished site means reopening design decisions, rebuilding components and re-testing everything that touches them. Building it in means each phase carries a few extra questions. The gap between those two bills is large and it grows with every custom component.

The visual way to think about it: Content → Visual design → Interaction → Code → Assistive technology → Real user. Every layer either passes accessibility down to the next or breaks it for everyone after. Government guidance says the same thing about its own services: accessibility considered throughout design and delivery, not checked at the end.

If you are at the very start, fold the target into how to plan a small business website from scratch and it will barely register as extra work.

Mid rebuild? Keep the redesign checklist we work through with clients beside you so accessibility gets checked at every stage instead of remembered at the end.

Weighing a retrofit against a rebuild and unsure which way the maths falls? Run the numbers through our website cost estimator before anyone quotes you either way.

And in some sectors this is not optional polish. Health businesses serve exactly the people accessibility exists for, which shapes how we approach healthcare website builds from the first wireframe.

Your website can be accessible until a third party widget breaks the journey

Booking systems, payment gateways, live chat, review widgets, maps, embedded forms, cookie consent tools, captchas, social feeds, account portals. Every one of them renders inside your customer’s journey and every one of them can undo your good work in a single step.

The Human Rights Commission’s guidelines are blunt on this point: organisations can contract out the provision of a digital service, but they cannot contract out the equal access obligation that comes with it. In plainer words, the vendor’s widget is still your problem.

Questions worth asking any vendor before you embed their product:

• Which WCAG version and level do you support?

• Has the product been independently tested?

• Can it be fully operated by keyboard?

• Does it work with screen readers?

• Can you provide an accessibility conformance report?

Government procurement guidance takes the same line, requiring accessibility to be considered when buying digital products, not just when building them. Checkout and booking widgets fail most often in our experience, which is why they are the first thing we pressure test in our ecommerce web design work.

If you sell online, the wider sweep before launch lives in the full Australian ecommerce website checklist.

Platform and theme choice sets your ceiling here too. Some platforms ship accessible components out of the box, others fight you the whole way, so it is worth a look before you commit: compare website platforms side by side.

Should your website have an accessibility statement?

For many businesses, yes, a short one. A good statement explains your commitment, the standard you are working toward, known limitations you are honest about, how to reach you another way, how to report a problem and when accessibility was last reviewed.

What it should never say is this website is 100 per cent accessible, unless you can genuinely stand behind that claim, which almost nobody can. A workable structure:

We aim to make this website accessible to as many people as possible and are working toward WCAG 2.2 Level AA. If you experience difficulty accessing information or completing an action, contact us on [phone or email] and we will work with you to provide an alternative.

Have the wording reviewed where compliance matters to you. And take the alternative contact line seriously: a phone number that is easy to find is the simplest accessibility feature there is and it converts. We covered that angle in turning website visits into phone calls.

Website accessibility checklist for Australian businesses

Work through this against your real site, one area at a time. Mark each item pass, fail or needs review and be honest, because the checklist only helps if the answers are true.

Content

Visual design

Navigation

Forms

Technical

Documents

Testing

A printable accessibility audit worksheet

For the audit itself, use one row per finding so nothing lives in someone’s head. The columns below give you a complete paper trail: what was checked, where, how bad it is, who owns the fix and whether it was retested.

Status values: Pass, Needs review, Fail, Not applicable. Severity values: Critical, High, Medium, Low. Reuse the sheet every time the site changes and you have an accessibility history instead of a vague memory.

What should you fix first?

Fix in order of what blocks people, not what is easiest to tick off. This ranking keeps the effort honest:

Priority 1 deserves urgency for a commercial reason as well as a human one. If those pages carry paid traffic, every blocked task is a click you paid for and a customer you lost and a quick look at what Google Ads actually costs in Australia makes that maths uncomfortable fast.

Common accessibility myths

“Only government websites need accessibility.” No. The DDA applies to discrimination across Australian public life and the Human Rights Commission’s guidelines are written explicitly for organisations providing digital goods and services, private businesses included. Some sectors carry higher expectations again. It is a big part of the way we build websites for education providers, where inaccessible content locks out the exact people the organisation exists to serve.

“My customers are not disabled.” You have no reliable way of knowing that. Disability is often invisible, assistive technology use is not reported to your analytics and around one in five Australians live with disability. Accountants, lawyers and consultants tell us this one most often, usually right before a keyboard test fails on their own enquiry form. It is one of the essentials every professional services website needs to take seriously.

“If Lighthouse gives me 100, I am compliant.” No. Automated tests cannot evaluate meaning, usefulness or whether a real task can be completed and compliance is a legal question, not a score.

“Accessibility ruins good design.” Accessible interfaces can still be distinctive, minimal, animated and visually sophisticated. Accessibility constrains usability failures, not creativity. If a design only works when nobody with a disability visits, it was never a good design.

“We can add accessibility after launch.” You can, the same way you can add a bathroom to a finished house. It is just slower, dearer and messier than putting it in the plans.

“An accessibility widget fixes the problem.” Not reliably. The underlying structure, controls, content, forms and navigation still need to be accessible and no toolbar reaches that deep.

Accessibility is also good website design

We will not insult you with invented conversion statistics. The honest version is overlap: most accessibility improvements make the site easier for people who would never call themselves disabled. Older users. People on phones in full sun. Someone browsing with a sprained wrist. Anyone watching video on mute. People reading in their second language.

The pattern repeats everywhere you look. Captions help commuters. Clear error messages help everyone finish forms. Stronger contrast helps mobile readability. Logical headings make pages scannable. Bigger buttons help every thumb on every phone. Descriptive links help everyone decide what to click.

Speed belongs in the same bucket, because slow pages punish people on older devices and patchy connections hardest and making your website noticeably faster is usually cheaper than a redesign. Half of these fixes double as bounce killers too, for reasons we unpack in why visitors leave your website within seconds.

Search engines read your site much the way assistive technology does: through structure, headings and link text. That is why accessibility work keeps showing up as a quiet win inside our senior SEO team’s technical audits and why the government’s own inclusion standard treats accessible design as simply designing well for everyone.

Our honest take: accessibility is a quality standard, not a checkbox

A website does not become accessible because a plugin was installed, because Lighthouse said 100, because a badge appeared in the footer or because every image technically has alt text. Those are artefacts. Accessibility is how the whole experience behaves: the design, the code, the content, the forms, the navigation, the third party tools, the documents and the testing that ties them together.

It is also never finished. Every new page, template change and embedded widget can introduce a new barrier, which is why the businesses that do this well treat it like uptime or security: a standard you maintain, not a project you complete.

FAQs

Do Australian business websites have to be accessible?

There is no statute that names WCAG for private businesses. The Disability Discrimination Act prohibits discrimination in goods and services, the Human Rights Commission applies that to digital and WCAG 2.2 AA is its recommended benchmark. Treat AA as the target and take specific compliance questions to a lawyer.

Does the Disability Discrimination Act apply to websites?

The Commission’s position is yes, where digital goods and services create discriminatory barriers and that position has history behind it going back to the Sydney Olympics website complaint in 2000. How it applies depends on the circumstances.

What is WCAG 2.2?

The current version of the Web Content Accessibility Guidelines, published by the W3C. It organises accessibility into four principles, perceivable, operable, understandable and robust, with testable requirements at levels A, AA and AAA.

What is WCAG Level AA?

The middle conformance level, which includes everything in Level A plus requirements covering most of the serious barriers people hit in practice: contrast, visible focus, target size and more. It is the Human Rights Commission’s recommended minimum.

Does every Australian business need WCAG 2.2 AA?

There is no single rule that says so. It is the sensible benchmark to design toward, expectations vary by sector and risk and if compliance genuinely worries you, get legal and accessibility advice rather than relying on any article, including this one.

How can I test my website for accessibility?

In layers: automated scans first, then a keyboard pass, then zoom and reflow, then a screen reader through the core journeys, then real users where the stakes justify it. No single layer is enough on its own.

Is Lighthouse enough to test accessibility?

No. It catches a useful slice of technical problems and cannot judge meaning, usefulness or task completion. Use it as the first pass, never the verdict.

What is the best free website accessibility checker?

There is no single best. WAVE suits visual review, axe suits developers, Lighthouse suits a quick scan and the free keyboard test finds problems all three miss. Use them together.

What does alt text do?

It provides a written alternative for an image, which screen readers announce and browsers show when images fail to load. Good alt text conveys the same useful information the image does.

What colour contrast does WCAG require?

At Level AA, generally 4.5:1 for normal text and 3:1 for large text, with defined exceptions. Free contrast checkers will test any colour pair in seconds.

Does my website need to work without a mouse?

Yes. Keyboard operability is core WCAG territory and one of the most common real barriers. Tab through your own enquiry form today and you will know within a minute where you stand.

Do videos need captions?

Video carrying important information should be captioned and automatic captions should be corrected before you rely on them. Depending on the content, transcripts or audio description may matter too.

Do PDFs need to be accessible?

If they carry information customers need, yes. Better again, publish that information as an accessible web page first and let the PDF be the optional copy.

Can an accessibility plugin make my website compliant?

No. Overlays can add display options and they cannot repair broken structure, keyboard behaviour, labels or content underneath. Compliance is a legal question no plugin can answer.

Should my website have an accessibility statement?

Usually worth it: a short, honest note on your target standard, known limitations and an alternative way to reach you. Never claim to be 100 per cent accessible unless you can prove it.

How often should accessibility be tested?

At every launch and redesign, after significant template changes, whenever a new third party widget goes in and on a standing rhythm of roughly every 6 to 12 months so drift gets caught early.

Should third party booking and checkout tools be tested too?

Yes. They render inside your customer journey and the Commission’s guidance is clear that outsourcing the tool does not outsource the obligation. Ask vendors for their accessibility conformance information before you commit.

Can a web designer guarantee DDA compliance?

No and be wary of anyone who says otherwise. A good team designs and tests to WCAG and documents the work. Whether something complies with the DDA is a legal question that depends on circumstances only a qualified adviser can assess.

Next steps: pick your path

Path 1: fix it yourself this week. Run the keyboard test on your money pages, work through the checklist above and hand the content fixes, alt text, link wording, headings, to whoever writes for you. Zero budget, real progress and you will know exactly where the deeper problems live.

Path 2: you are planning a rebuild. Write WCAG 2.2 AA into the brief before you talk to anyone, then read the full guide to planning and building a business website so accessibility slots into the same plan as design, content and conversion instead of arriving as an afterthought with an invoice.

Path 3: you want it handled. Talk to a web design team that builds accessibility into design, development and QA rather than bolting it on after launch. If paid traffic lands on those pages, get them checked before you spend another dollar, because Google Ads management without the junior handballing starts with landing pages people can actually use. Either way, tell us what your website needs to do and we will give you a straight answer on where it stands.

Sources and further reading

Australian Human Rights Commission, Guidelines on equal access to digital goods and services (2025). The Commission’s current digital accessibility guidance, recommending WCAG 2.2 Level AA at minimum.

Disability Discrimination Act 1992 (Cth), Federal Register of Legislation. The legislation itself, covering discrimination in goods, services and facilities.

W3C, Web Content Accessibility Guidelines (WCAG) 2.2. The full technical standard behind everything in this guide.

Australian Government, Digital Inclusion Standard. The accessibility and inclusion requirements government agencies design to.

General information only. Rules vary by situation, particularly around advertising claims, privacy, reviews and consumer law. If you’re unsure about compliance, get professional advice.