What Website Accessibility Actually Means
Accessibility is the practice of designing and building websites that people with disabilities can use. That includes people who are blind or have low vision, deaf or hard of hearing, have motor impairments that make using a mouse difficult, or have cognitive disabilities that affect how they process information.
Many use assistive technologies like screen readers, keyboard navigation, switch devices, or screen magnification to browse the web.
If your website does not support these tools, those customers cannot use it. And under Australian law, that is a problem.
The Legal Situation in Australia
The Australian Disability Discrimination Act 1992 (DDA) prohibits discrimination against people with disability in the provision of services. The Australian Human Rights Commission has explicitly confirmed that websites are covered.
The standard Australian courts and regulators reference is the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA.
There have been cases in Australia where individuals have complained to the Human Rights Commission about inaccessible websites. While enforcement has been light compared to the US, where ADA lawsuits are common, the legal risk is real and the reputational risk is significant.
Beyond compliance, accessibility expands your market. A site that works for someone using a screen reader also works better for someone using their phone in bright sunlight, someone with a temporary hand injury, and someone on a slow connection.
The WCAG 2.1 AA Standard: What It Requires
WCAG is organised around four principles. Every requirement exists under one of them.
1. Perceivable: All content must be presentable in ways users can perceive. If something only communicates visually, users who cannot see it are excluded.
2. Operable: Users must be able to operate the interface. If something only works with a mouse, keyboard users are excluded.
3. Understandable: Information and UI operation must be understandable. This covers clear language, predictable behaviour, and helpful error messages.
4. Robust: Content must work reliably with current and future assistive technologies. This is largely about clean, semantic HTML.
The WCAG 2.1 AA Standard at a Glance
| Principle | What it means | Common failures |
|---|---|---|
| Perceivable | Content must be presentable in ways users can perceive | Missing alt text, no captions on video |
| Operable | Users must be able to operate the interface | Mouse-only interactions, tiny tap targets |
| Understandable | Information and UI must be understandable | Confusing error messages, inconsistent navigation |
| Robust | Content must work with current and future assistive tech | Invalid HTML, poor ARIA usage |
Quick Wins: Fix These Today
These fixes require no developer involvement and address the most common issues.
1. Alt text on images
Every meaningful image needs an alt attribute describing what it shows. Decorative images should have an empty alt attribute (alt="") so screen readers skip them.
Wrong: <img src="team.jpg"> Right: <img src="team.jpg" alt="The Sonder Digital team at their Da Nang studio"> Decorative: <img src="divider.png" alt="">
2. Colour contrast
Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text at 18px or 14px bold). Light grey text on white background is one of the most common failures.
Check yours: Use the free WebAIM Contrast Checker at webaim.org/resources/contrastchecker.
3. Keyboard navigation
Every function on your site must be accessible using only a keyboard. Press Tab to move through interactive elements, Enter or Space to activate them. Can you navigate your entire site, including menus, forms, and modals, without touching a mouse?
If elements disappear, lose focus, or behave unexpectedly when using the keyboard, that is a failure.
4. Visible focus indicators
When a keyboard user tabs through your site, they need to see which element is currently selected. Many sites set outline:none on focused elements to "clean up" the appearance, which makes the site unusable for keyboard users.
Fix: Never remove focus styles. If the default browser focus ring does not suit your design, replace it with a custom style that is equally visible.
5. Form labels
Every form field needs a visible label that is programmatically associated with the field. Placeholder text that disappears when you type does not count as a label.
Wrong: <input type="email" placeholder="Enter your email"> Right: <label for="email">Email address</label><input type="email" id="email">
6. Heading structure
Headings (H1 through H6) must follow a logical hierarchy. Do not skip from H1 to H3 because H3 looks better. Do not use headings purely to make text bigger. Screen reader users navigate pages primarily by jumping between headings.
7. Link text
Links should describe their destination, not just say "click here" or "read more." Screen reader users often pull all links out of context and read them as a list.
Wrong: Click here to learn about our services. Right: Learn about our web design services.
The seven quick wins, in one place
Developer-Level Fixes Worth Knowing About
If you have a developer relationship, ask them to check these:
- ARIA labels on icon buttons. Any button that has only an icon (no visible text) needs aria-label="what it does".
- Landmark regions. <header>, <nav>, <main>, and <footer> should be used semantically so screen readers can jump between regions.
- Error handling in forms. When a form field has an error, the error message should be linked to the field programmatically using aria-describedby.
- Skip navigation link. A "Skip to main content" link that appears when a keyboard user first presses Tab lets them bypass navigation and get straight to the content.
- Motion and animation. Any animation should respect the prefers-reduced-motion media query. Users who set this preference have reported motion sickness or seizure risk.
How to Check Your Own Site
Free tools: - WAVE (wave.webaim.org): Overlays visual indicators of accessibility issues on your page - axe DevTools (browser extension): Technical audit from the axe accessibility engine - Lighthouse (in Chrome DevTools): Built-in accessibility audit with scored results - NV Access NVDA (free screen reader for Windows): Test your site as a screen reader user would experience it
Target score: Lighthouse Accessibility 90 or higher. 95 or higher before launching a new site.
The Business Case Beyond Compliance
Accessible websites tend to rank better on Google. Semantic HTML, clear heading structure, descriptive links, and alt text all directly overlap with SEO best practices.
They also perform better on mobile, load faster (because they rely on HTML structure rather than visual hacks), and are easier to maintain as the codebase grows.
One in five Australians lives with disability. An inaccessible website does not just risk a complaint, it turns away a fifth of your potential market before they reach your contact form.
Accessibility is not a feature you add at the end. It is a quality baseline that makes everything else work better.
Want to know how accessible your website is? Request a free accessibility audit and we will send you a prioritised list of issues and fixes.
References
- Australian Human Rights Commission: "World Wide Web Access: Disability Discrimination Act Advisory Notes", humanrights.gov.au
- Australian Bureau of Statistics: "Disability, Ageing and Carers, Australia: Summary of Findings", abs.gov.au
- W3C: Web Content Accessibility Guidelines (WCAG) 2.1, w3.org/TR/WCAG21
- WebAIM: Screen Reader User Survey, webaim.org/projects/screenreadersurvey
- Deque: "The Business Case for Digital Accessibility", deque.com
Need help with your website?
We help Australian small businesses build websites that actually work. No jargon, no fluff.
Book a Free Discovery Call Back to Blog