Australian law prohibits disability discrimination in providing goods and services, and websites are treated as part of that. The accepted technical benchmark is WCAG, usually at level AA. In practice it means making sure everyone can read, navigate and use your site, whether they use a screen reader, a keyboard, voice control, a phone in bright sunlight, or simply need larger text. Most of the fixes are inexpensive when they are built in from the start.
What website accessibility means
Website accessibility is the practice of building sites that people with a wide range of abilities and situations can use. That includes people who are blind or have low vision, people who are deaf or hard of hearing, people with limited mobility who navigate by keyboard or voice, and people with cognitive or learning differences.
It also covers situations that almost everyone experiences at some point: a broken wrist, a phone in bright sunlight, a noisy train carriage, a slow connection, or simply getting older and needing bigger text.
Why it matters for your business
- More customers can use your site. About one in five Australians lives with disability, according to the Australian Bureau of Statistics. An inaccessible site quietly turns away people who were ready to buy.
- It helps your search visibility. Accessibility and SEO overlap heavily: clear headings, descriptive link text, alt text, fast pages and clean code all help both people and search engines. See our glossary entry on alt text and Core Web Vitals.
- It builds trust. A site that is easy to use for everyone feels professional and considerate.
- It reduces legal and reputational risk. Complaints about inaccessible websites can be made under Australian law, and large customers and government buyers increasingly ask about accessibility in tenders.
The law in Australia, in plain English
This section is general information to help you understand the landscape. It is not legal advice, and you should talk to a lawyer about your own situation.
- The Disability Discrimination Act 1992 (Cth) makes it unlawful to discriminate against a person on the ground of disability when providing goods, services and facilities, including information and services delivered online.
- The Australian Human Rights Commission handles complaints under the Act and has published guidance telling website owners to follow the Web Content Accessibility Guidelines (WCAG). If a complaint cannot be resolved through conciliation, it can go to the courts.
- There is no general small business exemption. The law does recognise a defence of “unjustifiable hardship”, but it depends on the circumstances, and it is not something to rely on for a website, where the fixes are usually modest.
- State and territory laws have their own anti-discrimination Acts that work alongside the federal one.
- Government and large-customer work often requires WCAG AA conformance in tenders and contracts, so if you plan to sell to them you will be asked about it.
The practical takeaway is simple: aim for WCAG 2.2 level AA, fix problems promptly when people report them, and give visitors an easy way to contact you for help.
WCAG 2.2 in five minutes
The Web Content Accessibility Guidelines (WCAG) are the international standard published by the World Wide Web Consortium (W3C). Version 2.2 became an official W3C Recommendation in October 2023 and builds on versions 2.1 and 2.0, so a site that meets 2.2 also meets the earlier ones.
The four principles
- Perceivable: information must be presentable in ways people can perceive, such as text alternatives for images and captions for video.
- Operable: everything must work with a keyboard, give people enough time, and avoid content that causes seizures.
- Understandable: text should be readable, pages should behave predictably, and forms should help people avoid and fix mistakes.
- Robust: content must work with current and future browsers and assistive technology, which comes from clean, standard code.
Levels A, AA and AAA
Each requirement is graded. Level A is the minimum. Level AA is the standard target and the level most laws, guidance and contracts refer to. Level AAA is the highest, and the guidelines themselves note it is not realistic to meet for every kind of content, so it is not usually required across a whole site.
What is new in WCAG 2.2
- Focus not obscured: a sticky header or cookie banner must not completely hide the item that has keyboard focus.
- Dragging movements: anything that needs dragging, such as a slider, also needs a simple alternative like buttons.
- Target size (minimum): tap and click targets should be at least 24 by 24 CSS pixels, or have enough spacing.
- Consistent help: if you offer help, such as a phone number or chat, put it in the same place on every page.
- Redundant entry: do not make people re-type information they have already given in the same process.
- Accessible authentication: logging in should not depend on solving a puzzle or remembering and transcribing a code with no alternative.
The 12 most common barriers and how to fix them
These are the problems that most often block visitors on small business websites. For each one you will find what goes wrong, how to test for it in a minute or two, and how to fix it.
1. Low colour contrast
WCAG 1.4.3 and 1.4.11
Pale grey text on white, or text over a busy photo, is hard for many people to read, and for everyone in bright light. Normal text needs a contrast ratio of at least 4.5 to 1, and large text and interface parts such as buttons and form borders need at least 3 to 1.
- Test it: Run your text and background colours through a contrast checker, or use the contrast tool in your browser’s developer tools.
- Fix it: Darken text, avoid light grey placeholder text, and put a solid or darkened layer behind text that sits on images.
2. Missing or unhelpful alt text
WCAG 1.1.1
People who use screen readers hear the alt text in place of an image. A missing description, or a file name like IMG_4032.jpg, tells them nothing. Search engines also use alt text to understand images.
- Test it: Turn images off or hover over them with WAVE running. Every image that carries meaning should have a short description.
- Fix it: Describe what the image shows or why it is there. Leave the alt text empty only for decorative images such as background flourishes.
3. Keyboard traps and invisible focus
WCAG 2.1.1, 2.1.2 and 2.4.7
Many people cannot use a mouse and move through websites with the Tab key, a switch device or voice control. If a menu cannot be opened from the keyboard, or you cannot see where you are on the page, the site is unusable for them.
- Test it: Put the mouse away and press Tab through your key pages. You should reach every link, button and form field, in a sensible order, with a clearly visible outline on the one that is active.
- Fix it: Use real buttons and links, keep the default focus outline or replace it with a clearer one, and make sure pop-ups can be closed with the Esc key.
4. Unlabelled or confusing forms
WCAG 1.3.1, 3.3.1 and 3.3.2
A form with only placeholder text loses its instructions the moment someone starts typing, and a screen reader may not announce the field at all. Vague errors such as “Invalid input” leave people stuck, which means lost enquiries.
- Test it: Try completing your contact form using only the keyboard, and deliberately make a mistake to see what the error message says.
- Fix it: Put a visible label above every field, mark which fields are required, and write errors that say what is wrong and how to fix it, next to the field concerned.
5. Vague link text
WCAG 2.4.4
Screen reader users often pull up a list of all the links on a page. A list that reads “click here, click here, read more” is meaningless.
- Test it: Read your link text out of context. Does each link still make sense on its own?
- Fix it: Write links that describe where they go, such as “Download our pricing guide” rather than “Click here”.
6. Broken heading structure
WCAG 1.3.1 and 2.4.6
Headings are how screen reader users scan a page. Choosing a heading because it looks the right size, or skipping from a main heading to a tiny one, breaks that map. It also muddies the structure search engines read.
- Test it: Check that each page has a single main heading (H1) and that sections nest logically beneath it.
- Fix it: Use headings for structure and CSS for appearance. One H1 per page, H2 for sections, H3 within those.
7. Tiny tap targets
WCAG 2.5.8 (new in 2.2)
Small, crowded buttons and links are hard to hit for people with tremors or limited dexterity, and for anyone using a phone one-handed. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels.
- Test it: Try tapping your menu and footer links on a real phone. If you often hit the wrong one, they are too small or too close together.
- Fix it: Aim for about 44 pixels for main buttons and give links in lists some breathing room.
8. Video and audio without captions or transcripts
WCAG 1.2.1 to 1.2.5 and 1.4.2
Deaf and hard-of-hearing visitors cannot follow video without captions, and plenty of people watch with the sound off. Auto-playing audio or video is also disorienting and cannot be easily stopped by screen reader users.
- Test it: Play each video with the sound off. Can you follow it?
- Fix it: Add accurate captions (check auto-generated ones, which are often wrong), provide a transcript for audio, and never autoplay with sound.
9. Inaccessible PDFs
WCAG 1.1.1 and 1.3.1 (applies to PDFs too)
PDFs exported as flat images, or without tags, cannot be read by screen readers. Price lists, menus and forms are the usual offenders.
- Test it: Try selecting text in the PDF. If you cannot, it is probably an image. Try the Accessibility Checker in your PDF software.
- Fix it: Publish the same information as normal web page content wherever you can, and keep the PDF as an extra rather than the only version.
10. Content that breaks when zoomed
WCAG 1.4.4 and 1.4.10
People with low vision zoom in, sometimes to 200 or 400 per cent. If text overlaps, gets cut off or forces sideways scrolling, they cannot read the page.
- Test it: Zoom your browser to 200 per cent, then 400 per cent, and scroll through key pages. Everything should reflow into a single column without losing content.
- Fix it: Use a responsive layout, relative text sizes and avoid fixed-height containers that clip text.
11. Motion and flashing that cannot be controlled
WCAG 2.2.2 and 2.3.1
Moving carousels, parallax effects and flashing content can distract, cause nausea or, in the worst case, trigger seizures. People need to be able to pause moving content.
- Test it: Look for anything that moves on its own for more than five seconds. Can you pause it?
- Fix it: Provide pause controls for auto-moving content, avoid flashing more than three times a second, and respect the visitor’s “reduce motion” setting.
12. Missing page basics
WCAG 2.4.1, 2.4.2 and 3.1.1
A page with no descriptive title, no declared language or no way to skip past a long menu makes every visit harder for screen reader and keyboard users.
- Test it: Check that each page has a unique, descriptive title, that your site declares its language, and that a “Skip to content” link appears when you first press Tab.
- Fix it: Set the language on the page, write a clear title for every page, and add a skip link as the first focusable element.
How to check your own site in 15 minutes
- Keyboard test (3 minutes). Put the mouse away and press Tab through your home page, a service page and your contact form. Can you reach everything, and can you always see where you are?
- Zoom test (2 minutes). Zoom your browser to 200 per cent and then 400 per cent. Does the layout reflow without anything being cut off?
- Automated scan (3 minutes). Run the Accessibility audit in Lighthouse, which is built into Chrome, and a scan with WAVE or axe DevTools.
- Contrast check (2 minutes). Test your main text, button and link colours against their backgrounds.
- Screen reader try-out (5 minutes). Turn on VoiceOver, TalkBack or NVDA and try to find your phone number and submit an enquiry without looking at the screen.
Scanners are quick and useful, but they can only detect a portion of accessibility issues, and they cannot judge whether alt text is meaningful or whether a page makes sense to someone using a screen reader. A clean automated report is a good start, not proof of compliance. Combine it with the manual checks above.
On our own site we track this. At the time of writing (October 2026), Lighthouse scores our home, pricing, portfolio and blog post pages 100 for accessibility. That is a starting point rather than a guarantee of full WCAG conformance.
You can also run our free website health check, which includes accessibility questions alongside speed, SEO, trust and security.
Do you need an accessibility statement?
An accessibility statement is a short page that explains your commitment to accessibility and tells people how to get help. It is not usually required of private businesses in Australia, but it is good practice and costs little. A useful statement includes:
- The standard you aim for, for example WCAG 2.2 level AA.
- Any known limitations and what you are doing about them.
- A phone number or email address for accessibility feedback, and how quickly you will reply.
- The date the statement was last reviewed.
Link to it from your footer so it is easy to find on every page.
Eight questions to ask your web designer
Whoever builds or maintains your website, including us, should be able to answer these clearly:
- Which WCAG version and level do you build to, and can you show me your own site’s results?
- Do you test with a keyboard and a screen reader, or only with automated tools?
- Will my colours and fonts pass contrast checks before launch, or do we find out afterwards?
- Are forms, menus and pop-ups built with real, accessible elements?
- Who writes the alt text and the captions, and who keeps them up to date?
- What happens if someone reports an accessibility problem after launch?
- Do you use an accessibility “overlay” widget? (If the answer is yes, ask what is actually fixed in the code.)
- Can you give me an accessibility statement I can publish?