Last updated on October 2nd, 2026 at 11:56 am
You’ve probably seen the claim that every Australian business website must, by law, meet WCAG 2.2 Level AA. That is too simple to be useful. There are real obligations to provide access to goods and services without disability discrimination, but a single automated score cannot tell you whether a customer can make a booking or pay an invoice.
This guide separates the law, the technical standard and the daily work of keeping a site usable. It is written for the café owner, solo consultant, online retailer and small team who need a defensible plan rather than an expensive badge.
What the law says – and does not say
The Australian Human Rights Commission’s 2025 digital-accessibility guidelines explain how the Disability Discrimination Act 1992 (Cth) applies to equal access to digital goods and services. A website, booking flow or app can be part of the way a business provides a service. A barrier in that flow may raise discrimination issues, depending on the facts.
The Act does not impose the words ‘all private business websites must pass WCAG 2.2 AA’. The Commission’s guidelines offer useful recommendations, but they are guidance, not a replacement for the Act or an automatic legal safe harbour. A conformance statement may help describe what was tested; it does not prove every person can use every task.
Government standards are a separate question. The Australian Government Architecture’s Web Content Management Standard identifies WCAG 2.2 AA but is marked non-mandatory. Other applicable policies, tenders and contracts can have their own accessibility requirements. Check what governs your particular project instead of treating either a sales email or a government standard as a universal statute.
WCAG 2.2, without the badge mythology
WCAG 2.2 is a W3C technical standard for accessible web content. Its testable success criteria sit under perceivable, operable, understandable and robust. A is the basic level; AA includes A and additional criteria; AAA adds further criteria. AA is a common practical target, not a magic certificate of equal access. W3C cautions that even AAA cannot address every user’s needs.
The 2.2 update added criteria that matter on everyday sites: focus not hidden behind sticky headers, alternatives to dragging, target sizes for pointer controls, consistent help, avoiding redundant entry and accessible authentication. A WordPress site with a contact form, booking plugin and account login can encounter these issues without ever building a bespoke app.
Conformance is about complete pages and processes under defined conditions. A checker saying ‘92% compliant’ is not a meaningful WCAG conformance claim. If a customer can browse a product but cannot operate the checkout or complete authentication, the process is still blocked. Start by testing the jobs people come to your site to finish.
Where small sites tend to create barriers
Forms: give each field an associated visible label, not a disappearing placeholder. Explain errors in text, show which field needs attention, and make sure the message can be announced by assistive technology. Complete a test enquiry or purchase with only a keyboard; if you cannot reach a control, neither can a keyboard-only customer.
Login and captcha: a visual puzzle or memory test without a usable alternative can block the very person you need to serve. WCAG 2.2’s accessible-authentication criteria are worth checking against your real sign-in, password reset and account recovery screens. Do not assume that installing an overlay or swapping one plugin makes the full journey accessible.
Documents and third-party widgets: a scanned menu, unstructured PDF, map-only directions or inaccessible booking embed can block the service just as effectively as a broken homepage. Prefer a structured HTML alternative for essential information. Ask vendors about keyboard operation and accessibility before buying a new checkout, theme or CRM integration.
Do the checks a scanner cannot do
Automated checkers are good at finding some detectable problems: missing text alternatives, certain colour-contrast failures and parts of form labelling. For WordPress, Accessibility Checker by Equalize Digital is one scanning option I use on this site. For the wider manual process, read the WordPress accessibility testing and repair guide. Run a checker on the pages that matter. But it cannot reliably decide whether the reading order makes sense, whether instructions are understandable, whether a dialogue traps keyboard focus or whether an error message tells a customer how to recover. That needs a person completing the journey.
Start with one contact or purchase task. Put the mouse aside and use Tab and Shift-Tab. Is focus visible and in the expected order? Can you activate every button with the keyboard? Submit the form with one field wrong. Can you find the error, understand it and correct it without restarting? Zoom the browser to 200 per cent and repeat. Then try a screen reader, ideally with someone who uses one routinely. W3C’s WCAG quick reference helps map an observed barrier back to a specific criterion.
If the site has several key journeys, test them separately: enquiry, checkout, booking, account creation and password recovery. Record the browser, device, assistive technology, steps and result. ‘The website is accessible’ is too broad to be a useful test record; ‘the booking form cannot be submitted by keyboard at step three’ gives you something to fix.
A practical order for a limited budget
- Find the blocked journeys. Combine an automated sweep with a keyboard and screen-reader walk-through of your most important pages.
- Fix barriers that prevent completion. Tackle keyboard traps, unlabeled fields, inaccessible captcha and unclear errors before cosmetic refinements.
- Offer an alternative while a fix is underway. Provide an accessible, monitored contact route so a customer can still ask for the service.
- Retest the full task. A code change may repair one control but break another stage of checkout or sign-in.
- Keep a short issue register. Write down the barrier, its effect, its owner, the fix and the date you confirmed it worked.
Don’t treat this order as permission to ignore people with less common needs. It is simply a way to use a small budget to remove the most immediate blocks first while keeping a route for feedback and further improvements.
Buying accessible tools is part of the job
When a vendor sells you a booking form, checkout, theme or client portal, ask them to demonstrate the critical path with a keyboard and screen reader. Request an accessibility statement or conformance report if they have one, but treat that as a starting point, not a substitute for your own task test. Put accessibility requirements and a remediation process into the contract where the purchase is important. A plugin’s accessible landing page tells you little about its actual payment form.
This is also where marketing claims deserve scrutiny. An overlay widget that changes fonts or contrast cannot by itself repair a broken form workflow, missing semantic labels or a vendor’s inaccessible checkout. Test the underlying service. If a provider promises instant compliance, ask them to demonstrate a full transaction using only a keyboard and to explain exactly what they tested.
Keep accessibility in the publishing routine
The site may pass a launch review and still become harder to use with the next PDF, promotional banner or plugin update. For each new article or page, use a real heading structure, descriptive link text and text alternatives for meaningful images. Caption video where needed, check colour contrast and keep tables for data rather than page layout. For a decorative image, an empty text alternative may be more useful than a redundant description. Your publishing checklist should explain that distinction.
Put a clear accessibility feedback route on the site, check the inbox and respond to reported barriers. A person telling you that a booking form failed has supplied a specific test case. Log the steps, offer a usable alternative while fixing the issue and confirm with the person if practical that the path now works. That is a better improvement process than waiting for a perfect scanner score.
Where SenseICT can help
SenseICT can help a small business map its critical website journeys, test a WordPress stack, prioritise barriers and work through technical fixes. Explore SenseICT’s solutions or talk to Matt about your site. DomainCastle provides managed WordPress hosting where that fits, but hosting alone does not make a booking form accessible. I’d rather be clear about that boundary than sell a hosting plan as a compliance certificate.
If your business also has remote workers, the accessible and secure remote-work guide covers the workplace tools behind the website. The same approach applies to both: test what people actually need to do, not what a dashboard says ought to work.
