Website Accessibility Checklist: A Practical Guide for Australian Businesses

This is the checklist we work through on every audit, written so a marketing manager or a developer can actually run it. It is organised by the four principles behind WCAG, with the success criterion number next to each item so you can look up the official wording. If you want the background on what compliance means and why it applies to you in Australia, start with our guide to WCAG 2.1 AA compliance and our work on accessible healthcare website design. This article is the how.

Before you start: set up your test kit

You need four things and none of them cost money. The axe DevTools browser extension, the WAVE extension from WebAIM, Lighthouse (already built into Chrome DevTools), and a screen reader. On Windows that is NVDA, free from NV Access, an Australian organisation based in Brisbane. On Mac it is VoiceOver, already installed, turned on with Command plus F5.

Pick five pages that carry your business: the homepage, your main service page, the contact or booking form, one long content page, and one page with video or a slider. Fixing those five properly beats a shallow pass over sixty pages, because the same components repeat everywhere.

Perceivable: can people take the information in?

Colour contrast, with the actual numbers

This is the most commonly failed item on Australian small business sites, usually because a designer picked a light grey for body text because it looked calm. The AA thresholds are specific.

• Normal body text needs a contrast ratio of at least 4.5:1 against its background (SC 1.4.3).
• Large text needs at least 3:1. Large means 18pt (24px) and up, or 14pt (18.66px) and up if it is bold.
• Interface components and meaningful graphics need at least 3:1. That covers input borders, toggle switches, icon buttons and the important parts of a chart (SC 1.4.11).
• Logos and purely decorative graphics are exempt. Disabled controls are exempt too, though greying something into invisibility is still poor practice.

Test it with the colour picker in axe DevTools, or the WebAIM Contrast Checker if you are working from brand hex codes. A practical warning: mid grey on white, like #999999, comes in at 2.8:1 and fails. #767676 is the lightest grey that passes on pure white at normal size. Text placed over a photograph almost always fails somewhere in the image, so add a solid overlay or a text panel rather than hoping.

Colour is never the only signal

Required fields marked only in red, links distinguished from body text only by colour, a chart legend that depends on hue. All fail SC 1.4.1. Add an asterisk, an underline, a pattern, a label. Roughly one in twelve men has some form of colour vision deficiency, so this is not a rare edge case.

Alt text, including the decorative rule

Every image element needs an alt attribute (SC 1.1.1). What goes in it depends on the job the image does.

Do not begin alt text with "image of" or "picture of". The screen reader already announces that it is a graphic. Keep it under about 125 characters, and skip keyword stuffing; it reads as spam to a person listening and does nothing for search.

Video captions and transcripts

Prerecorded video with sound needs synchronised captions (SC 1.2.2). Auto captions from YouTube are a starting point, not a finish line, because they mangle names, suburbs and clinical terms. Someone has to correct them, and it takes about fifteen minutes for a five minute video.

Prerecorded audio, such as a podcast, needs a text transcript (SC 1.2.1). Video that conveys visual information not covered by the soundtrack needs audio description or an equivalent text alternative at AA (SC 1.2.5). If you are producing testimonial videos for an aged care marketing campaign, budget captioning into the production cost rather than treating it as an afterthought. Transcripts also get indexed, which is a pleasant side effect.

Text resizing and reflow

Zoom your browser to 200 per cent. Nothing should be cut off or overlap (SC 1.4.4). Then set your browser window to 320 CSS pixels wide, which is the same as zooming to 400 per cent on a desktop screen. Content should reflow into a single column with no horizontal scrolling (SC 1.4.10). Sticky headers that eat half the screen at high zoom are the usual offender.

Operable: can people actually use it?

Keyboard navigation

Put the mouse aside. Press Tab from the top of the page. Everything interactive must be reachable and usable with the keyboard alone (SC 2.1.1), and you must always be able to Tab back out of anything you Tab into (SC 2.1.2). The classic trap is a modal or a video embed that swallows focus and never gives it back.

Check that the order you move through matches the order things appear visually (SC 2.4.3). Check that a skip link appears when you first press Tab, letting people jump past the navigation to the main content (SC 2.4.1). Check that dropdown menus open on focus, not only on hover, and that custom components such as accordions and carousels respond to Enter, Space and the arrow keys.

Focus indicators

Whatever has keyboard focus must be visibly marked (SC 2.4.7). Somewhere in almost every theme is a line of CSS setting outline to none because a developer thought the default ring was ugly. Removing it without a replacement is the single most damaging one line change you can make to a website. If the default does not suit your brand, style it: a two pixel outline in a colour that meets 3:1 against the background, with a small offset, looks intentional and passes.

Motion, animation and autoplay

Nothing may flash more than three times per second (SC 2.3.1), because that can trigger seizures. Anything that moves, blinks or auto updates for more than five seconds needs a way to pause, stop or hide it (SC 2.2.2). That includes hero sliders, news tickers and animated statistics counters.

Beyond the letter of AA, respect the operating system setting for reduced motion. A CSS media query for prefers-reduced-motion lets you switch parallax and large scroll animations off for people who get motion sick. It is a AAA criterion in WCAG 2.1 (SC 2.3.3), so it is not strictly required for AA, but it takes ten minutes and it is the right call.

Touch target size

Be precise here, because a lot of blog posts get it wrong. In WCAG 2.1, Target Size at 44 by 44 CSS pixels is a AAA criterion (SC 2.5.5). WCAG 2.2 later added a AA level minimum of 24 by 24 pixels (SC 2.5.8). Our own practice is to build to 44 pixels regardless, because it matches the Apple and Google platform guidance and because tiny targets frustrate everyone, not only people with tremor or limited dexterity. Watch for icon only social links in footers and closely stacked menu items on mobile.

Understandable: does it make sense?

Heading order

One h1 per page, describing what the page is about. Then h2 for major sections, h3 for subsections beneath them. Do not skip from h2 to h4, and never pick a heading level because you liked the font size; that is what CSS is for. Screen reader users navigate by pulling up a list of headings, so a page with fourteen h3 elements and no structure is a wall of noise. This falls under SC 1.3.1 and SC 2.4.6.

Form labels and error messaging

Every input needs a visible label, programmatically tied to the field (SC 3.3.2 and SC 1.3.1). Placeholder text is not a label. It disappears the moment someone types, it usually fails contrast, and it leaves people who paused mid form with no idea what a box was for.

• Errors must be identified in text, not just a red border (SC 3.3.1).
• Where you know how to fix it, say so: "Enter a phone number including area code, for example 03 9000 0000" (SC 3.3.3).
• Move focus to the error summary on submit, or announce it via a live region so screen reader users know the submission failed (SC 4.1.3).
• Add autocomplete attributes to name, email, phone and address fields so browsers can fill them in (SC 1.3.5).
• Group related radio buttons and checkboxes in a fieldset with a legend.

Booking and referral forms are where accessibility failures cost real money, because the person cannot complete the one action your site exists for. If you run an NDIS website, this is the section to fix first.

Link text that means something on its own

"Click here", "read more" and "learn more" repeated eleven times give a screen reader user a list of identical links (SC 2.4.4). Write the destination into the link: "Read our pricing guide", "Download the participant handbook". Links that open a PDF or a new tab should say so. Add lang attributes on the page (SC 3.1.1) and a unique, descriptive page title (SC 2.4.2), which helps search visibility as well.

Robust: will assistive technology understand your code?

This is the fourth WCAG principle, and it is mostly about using the right HTML element for the job. A div with a click handler is not a button. Native elements come with keyboard behaviour, focus handling and the correct name, role and value already built in (SC 4.1.2). ARIA is there for the gaps, not as a substitute, and incorrect ARIA is measurably worse than none.

Use landmark elements: header, nav, main, footer. One main per page. Make sure any custom widget exposes its state, so an accordion announces whether it is expanded and a modal is marked as a dialog with focus contained inside it while open.

The checklist table

Testing with a screen reader without becoming an expert

You do not need to be fluent. You need enough to hear the obvious problems. On Windows, install NVDA, start it, and use Insert plus Down arrow to read from the cursor. Press H to jump between headings, K for links, F for form fields, and Insert plus F7 to open the elements list. On Mac, Command plus F5 starts VoiceOver, Control plus Option plus A reads continuously, and Control plus Option plus U opens the rotor.

Do one thing with it: complete your own contact form with the screen reader on and the monitor turned off or your eyes closed. Twenty minutes of that teaches more than a week of reading specifications. Then, if the site matters to your revenue, pay for testing by people who actually use assistive technology daily. Their feedback is different in kind, not just degree.

Automated tools and where they stop

Run all three, because they overlap but do not duplicate. axe DevTools gives the cleanest results with very few false positives and is the engine behind most commercial scanners. Lighthouse, in Chrome DevTools, gives a score out of 100 that is useful for tracking direction over time. WAVE overlays icons on the page itself, which makes it the easiest one to hand to a non technical colleague.

Here is the part vendors gloss over. Independent testing consistently finds automated tools detect somewhere between 30 and 40 per cent of accessibility problems. They can confirm an alt attribute exists; they cannot tell you it says "IMG_4471". They can find a missing label; they cannot tell you your error message is meaningless. They will never assess whether your reading order is sensible or whether your captions are accurate. A Lighthouse score of 100 is a floor, not a certificate.

Turning the checklist into a habit

Do a full pass once, fix what you find, then keep it from sliding back. Add three items to your content publishing routine: alt text on every image, headings in order, link text that stands alone. Add an axe scan to your deployment process so a broken build fails before it reaches the public. Re-run the full checklist twice a year and after any redesign.

One honest note on the legal side, and we are a web agency rather than lawyers, so take proper advice if you need certainty. In Australia the Disability Discrimination Act 1992 makes it unlawful to discriminate in the provision of goods, services and facilities, and the Australian Human Rights Commission has published guidance pointing to WCAG as the practical standard for websites. Working through this checklist is how you meet that expectation in practice. For a broader view of what compliance means for your organisation and what an audit costs, our allied health website design and pricing pages set out how we scope this work.

Frequently Asked Questions