Accessibility for Australian Businesses: Beyond Compliance

If you’re running a website in Australia in 2026, accessibility is no longer a “should.” It’s a legal expectation under the Disability Discrimination Act 1992, an SEO factor, a usability win, and - increasingly - a business differentiator.

But “accessibility” gets used as a vague aspiration. What does it actually mean to do it, day-to-day, in a real website project?

What the law actually says

The DDA doesn’t reference WCAG by name. But the Australian Human Rights Commission has long held that businesses providing goods or services online must make those services accessible to people with disabilities. The benchmark used in nearly every case has been the W3C’s Web Content Accessibility Guidelines, currently WCAG 2.1 at the AA level.

In practice:

• Public-sector websites must comply with WCAG 2.1 AA under the Digital Service Standard.
• Private-sector websites are exposed to DDA complaints if they’re inaccessible. Settlements have been reached. The risk is real.
• Larger businesses face heightened scrutiny - banks, telcos, retailers, anyone with a tribunal-relevant complaint history.

The “we’re a small business so this doesn’t apply to us” defence isn’t reliable. A 20-person plumbing company has been required to remediate a website after a DDA complaint. Size doesn’t immunise you.

Why most accessibility audits feel useless

Most agency accessibility audits we see fall into one of two camps:

• Tool-generated reports that flag 200 issues, of which 180 are noise (false positives, decorative alt="" attributes flagged as missing alt text, contrast issues on disabled elements).
• Checklist audits that tick off every WCAG criterion but never sit anywhere near a real user with a disability.

Neither tells you what to actually fix. Useful accessibility work starts from how people with disabilities actually use the web.

The 80/20 of accessibility

If you fix these eight things, you’ll cover most real-world barriers and pass most automated audits:

1. Colour contrast

Body text needs a 4.5:1 contrast ratio against its background. Large text (18pt+ or 14pt+ bold) needs 3:1. UI elements (form borders, icon buttons) need 3:1.

The pale grey body text trend of 2017–2019 left a generation of websites failing this test. Use WebAIM’s contrast checker on every text/background combination in your design system.

2. Keyboard navigation

Every interactive element - links, buttons, form fields, custom widgets - must be reachable and operable with keyboard alone. Try this on your own site: unplug your mouse and Tab through. Can you reach everything? Can you operate the menu? Can you submit the form?

The number of sites where the answer is “no” is depressing. Mega menus that only open on hover, custom dropdowns that don’t accept arrow keys, modals that trap focus or lose it - all common.

3. Focus indicators

The browser’s default focus ring is ugly. Designers remove it. Don’t. Or rather, replace it with something custom that’s more visible, not less.

A focus indicator should have a contrast ratio of 3:1 against the adjacent colour, be at least 2px thick, and be visible on every focusable element.

4. Semantic HTML

Use the elements browsers and screen readers actually understand:

• <button> for buttons (not <div onclick>)
• <a> for navigation
• <input> with associated <label>
• Headings in order (H1 → H2 → H3, not jumping to H4)
• Lists for lists, not <br> between <p> tags

This is the single most impactful change for screen reader users.

5. Alt text that’s actually useful

Every meaningful image needs descriptive alt text. Two rules:

• Decorative images (illustrative flourishes, background patterns) get alt="". Empty is correct here, not absent.
• Meaningful images (product photos, photos of people, charts, infographics) get alt text describing what the user would learn from the image. Not “image of a dog” - “Border collie playing fetch in a park.”

For charts and infographics, alt text alone is rarely enough. Include the data in a table or accessible long description.

6. Form labels and errors

• Every input has a programmatically associated <label>.
• Required fields are marked clearly (not just with a red asterisk; include text or aria-required).
• Errors are announced via role="alert" or aria-live="polite".
• Don’t disable the submit button while the form is invalid - explain what’s wrong instead.

7. Page titles and headings

Every page has a unique, descriptive <title>. The page’s H1 should describe the page’s content. Subsequent headings follow a logical order. This is how screen reader users navigate within a page - by jumping heading to heading.

8. Skip-to-content link

A <a href="#main">Skip to content</a> at the top of every page, visible on focus, lets keyboard users skip the navigation. Five lines of code, massive usability win for one of the most affected user groups.

What automated tools can and can’t catch

Tools like axe, Lighthouse, and WAVE are excellent for catching:

• Missing alt attributes
• Empty links and buttons
• Form fields without labels
• Colour contrast failures (on text only)
• Heading hierarchy issues
• Invalid ARIA

They can’t catch:

• Whether the alt text is useful
• Whether keyboard navigation actually flows logically
• Whether focus order matches visual order
• Whether the site is usable with a screen reader
• Whether dynamic content updates are announced
• Whether custom widgets behave correctly

Automated tools find roughly 30–40% of WCAG issues. The rest is human work.

How to actually test

We use a layered approach for every project:

1. Automated scan in CI. Axe DevTools or Pa11y on every page build. Block deployment if new accessibility errors appear.
2. Manual keyboard testing. Tab through every page. Note where focus disappears, traps, or skips.
3. Screen reader spot-check. VoiceOver on macOS (Cmd+F5) for the major flows. NVDA on Windows for thoroughness.
4. Browser zoom test. Zoom to 200% and 400%. Does the layout reflow? Are touch targets still tappable?
5. Reduced motion. Set OS to “prefer reduced motion” and verify animations respect it.
6. Live user feedback. For high-stakes sites (government, education, large e-commerce), commission accessibility user testing with people who actually use assistive tech.

That last step is where the real bugs live.

The business case beyond compliance

The “do this so you don’t get sued” framing undersells accessibility. The actual benefits:

• Bigger addressable market. Around 18% of Australians have a disability. Many use the web. Inaccessible sites are losing them.
• Better SEO. Search engines crawl websites the way screen readers do. Semantic structure, proper headings, alt text - all help rankings.
• Better mobile experience. Most accessibility wins (clear focus, large tap targets, no hover-only states) also help mobile users.
• Older users. Macular degeneration, declining motor skills, hearing loss - all become more common with age. Accessibility is also UX for everyone over 60.
• Edge cases for everyone. The temporary disabilities (broken arm, eye dilation drops, glare on a phone screen) that hit healthy users daily.

Accessible sites are simply better sites. Compliance is the floor, not the ceiling.

What this costs to do properly

For a new build, accessibility done right adds maybe 5–10% to the project cost. Most of it is design discipline, not extra labour. Hitting a fixed-grid system with strong contrast and obvious focus states is free if the designer cares.

Retrofitting an inaccessible site is much more expensive - often 25–40% of a rebuild. It’s almost always better to build it right than to fix it later.

For ongoing maintenance, accessibility just becomes part of the QA checklist. Build the habit and the cost is negligible.

---

Need an accessibility audit of your current site? Get in touch - we’ll run a full WCAG 2.1 AA review and send back a prioritised remediation plan.