How to check your website's accessibility: a practical first check

Why accessibility is a business question

An accessible website is one that people with disability can read, navigate and use, including people who are blind or have low vision, are Deaf or hard of hearing, can't use a mouse, or find dense pages hard to follow. That's a lot of potential customers. The Australian Bureau of Statistics found that 5.5 million Australians (21.4%) had disability in 2022, and 52.3% of people aged 65 and over.

Not every disability changes how someone uses a website, but when a page doesn't work for a person, the result is simple: they can't read your prices, can't find your phone number or can't finish your enquiry form. You lose the enquiry and usually never find out why.

There's a legal side too. Section 24 of the Disability Discrimination Act 1992 makes it unlawful for a person who provides goods or services, whether for payment or not, to discriminate against someone on the ground of their disability, including "in the manner in which" those goods or services are provided. The Act doesn't mention websites or set a technical standard, and it has an unjustifiable hardship exception, so how it applies to a particular site is a question for legal advice. The practical point stands: if your website is how people find and contact you, it's part of how you provide your service.

The recognised technical standard is the Web Content Accessibility Guidelines (WCAG) from the W3C. WCAG 2.2 was published on 5 October 2023 and updated on 12 December 2024, and it's also an ISO standard, ISO/IEC 40500:2025. Its success criteria sit at three levels, A, AA and AAA. The checks below mostly come from levels A and AA.

What a do-it-yourself check can and can't tell you

You don't need to be a developer to find the most obvious barriers. The W3C's own Easy Checks are written for exactly this, but they're honest about the limits: "These checks cover just a few accessibility issues and are designed to be quick and easy, rather than definitive. A web page could seem to pass these checks, yet still have significant accessibility barriers."

Automated scanners have the same limit. The W3C says that "Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so," and that some checks can't be automated at all. So treat this as a first look that finds problems worth fixing, not a certificate that your site is accessible.

Start with the pages that matter most for enquiries rather than the whole site:

• Your home page, because it's where most people land first.
• Your main service page, or the two or three that bring in most of your work.
• Your contact or enquiry page, including the form and its thank-you message.
• Any page your ads or email campaigns send people to.

Put the mouse away and use the Tab key

Many people navigate with a keyboard or a device that works like one, including screen reader users and people who can't hold a mouse steadily. WCAG requires that "All functionality of the content is operable through a keyboard interface" (Level A), and that the keyboard focus indicator is visible (Level AA).

Open a page, click in the browser's address bar and press Tab repeatedly. Shift+Tab moves back, Enter follows a link or presses a button, Space ticks a checkbox and the arrow keys move through options in a list. Work through the page from top to bottom, including the menu, any pop-ups and the enquiry form. As you go, check that:

• You can always see which link, button or field you're on, usually shown by an outline or highlight.
• Focus moves in a sensible order that follows the page, rather than jumping around.
• Every link, button, menu and form field can be reached and used, including the mobile menu and any booking or chat widget.
• You never get stuck. WCAG's No Keyboard Trap rule means you must be able to move focus away from anything you can tab into.
• A sticky header, cookie banner or chat button never completely covers the item you're on. WCAG 2.2 added this as Focus Not Obscured.

Zoom in and check it on a small screen

People with low vision often enlarge text rather than use special software. WCAG asks that text can be resized "up to 200 percent without loss of content or functionality" (Level AA). Its Reflow rule (Level AA) asks that content works at a width equivalent to 320 CSS pixels without scrolling in two directions, which is roughly a small phone screen.

WCAG 2.2 also added Target Size (Minimum) at Level AA: a target for a tap or click should be at least 24 by 24 CSS pixels, with some exceptions, such as small targets that have enough space around them. Zoom your desktop browser to 200%, then repeat the check on a phone, and look for these problems:

• Text that overlaps, gets cut off or disappears when you zoom in.
• Pages where you have to scroll sideways to read a line of text on a phone.
• A menu, button or form that stops working or goes off screen once the page is enlarged.
• Links and buttons so small or so close together that it's easy to tap the wrong one.

Check pictures, colour and wording

Screen readers read images out using their text alternative, often called alt text. WCAG's first rule is that "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose" (Level A). Purely decorative images are the exception: they should be set up so assistive technology can ignore them. Your content management system usually has an alt text field for each image, so you can check this without touching code.

Low contrast is easy to miss when you know what the page says, especially light grey text on white. WCAG's Level AA minimum is a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. A free contrast checker will give you the ratio when you enter the text and background colours. Work through the page and check for these:

• Photos that carry information, such as a before-and-after or a price table saved as an image, have alt text that gives the same information.
• Text is easy to read against its background, including text placed over photos.
• Colour is never the only way information is shown. WCAG's Use of Color rule covers things like a form error shown only by a red border.
• Headings describe what follows them, and link text says where the link goes, such as "See our bathroom renovation prices" rather than several links that just say "Click here".
• Videos with speech have captions. WCAG requires captions for prerecorded audio in video at Level A.

Test your enquiry form properly

Your enquiry form is where an inaccessible website costs you most directly. Two Level A rules do much of the work here. Labels or instructions must be provided "when content requires user input". And when an input error is automatically detected, "the item that is in error is identified and the error is described to the user in text."

Test the form with the keyboard only, then again on a phone. Leave a required field empty and try to send it, then enter an email address with a typo. Only send a real submission if you're happy for it to reach your team as a test. Check that:

• Every field has a visible label that stays in place once you start typing, rather than grey placeholder text that disappears.
• Required fields are marked in words or a symbol that's explained, not by colour alone.
• Error messages say what went wrong and how to fix it, and appear next to the field or at the top of the form.
• Your answers are kept when there's an error, so nobody has to type everything again.
• The confirmation message after sending is clear and can be reached with the keyboard.

Keep readingMake your enquiry form easier to finish

Turn what you find into a fix list

For each problem, note the page address, what you did, what happened and what you expected, with a screenshot where it helps. That's far more useful to a developer than "the site isn't accessible", and it lets you check each fix yourself afterwards.

A quick check will miss issues that need a trained tester, such as how the site sounds to a screen reader. If your site is important to your enquiries, ask your developer to go further. Demandify's Custom Websites service checks forms, key journeys and accessibility before launch. This guide is general information, not legal advice.

When you brief your developer or agency, ask for these in writing:

• A target standard, such as WCAG 2.2 Level AA, for new work and for fixes.
• Testing with a keyboard, a screen reader and an automated checker, with the results shared with you.
• Fixes for the problems on your list, prioritised by the pages that bring in enquiries.
• A recheck whenever you add a new page, form, pop-up, booking tool or chat widget, since third-party tools can introduce new barriers.

Keep readingPut accessibility into your website brief