Website accessibility checklist for a business website

A website accessibility checklist an owner can run alone covers nine things: use the site with only a keyboard, zoom to 200%, check text contrast, check image alt text, check form labels, check the heading structure, check video captions, watch the focus indicator, and check the size of buttons and links. Each maps to a WCAG 2.2 success criterion, so a failure gives you something specific to send your developer.

You need a browser, a free contrast checker and about an hour. You won't find everything, but you will find the problems that stop people sending your enquiry form.

What is WCAG 2.2, and which level should a business site aim for?

WCAG is the Web Content Accessibility Guidelines, published by the W3C. Version 2.2 is the current one. Its rules are written as numbered success criteria, each at Level A, AA or AAA. A page conforms at Level AA under WCAG 2.2 when it meets every Level A and Level AA criterion.

Level AA is the sensible target for a business website, and it is what the Australian Human Rights Commission recommends (more on that below). AAA is worth reading but rarely set as a whole-site target.

Version 2.2 added criteria including Focus Not Obscured, Target Size, Redundant Entry and Accessible Authentication, and removed 4.1.1 Parsing. A checklist written for 2.0 or 2.1 misses the new ones.

How do you run the checklist in an hour?

Pick three pages: the home page, your main service page, and the page with your enquiry form. The form page matters most. Then work through the table.

Check	How to do it	WCAG 2.2 criteria
1. Keyboard only	Put the mouse away. Press Tab to move forward, Shift+Tab to go back, Enter to activate. Reach every link, menu, button and form field, and get back out of each one.	2.1.1 Keyboard (A), 2.1.2 No Keyboard Trap (A), 2.4.3 Focus Order (A)
2. Focus visible	While tabbing, you should always see where you are: an outline, underline or colour change. Check the focused item isn't hidden behind a sticky header or cookie banner.	2.4.7 Focus Visible (AA), 2.4.11 Focus Not Obscured (Minimum) (AA)
3. Zoom to 200%	Zoom the browser to 200%. Text should get larger, nothing should be cut off or overlap, and you shouldn't need to scroll sideways to read a sentence.	1.4.4 Resize Text (AA), 1.4.10 Reflow (AA)
4. Contrast	Run body text, button text and text over images through a contrast checker. Normal text needs 4.5:1, large text 3:1. Form field borders and icons you need to understand need 3:1.	1.4.3 Contrast (Minimum) (AA), 1.4.11 Non-text Contrast (AA)
5. Alt text	Look at each image's alternative text (a browser extension or the page source shows it). Informative images need a short description. Decorative ones should be marked so screen readers skip them.	1.1.1 Non-text Content (A)
6. Form labels	Every field needs a visible label that stays when you start typing. Placeholder text that disappears is not a label. Submit the form with an error and check the message says what to fix.	3.3.2 Labels or Instructions (A), 3.3.7 Redundant Entry (A)
7. Headings	Check that headings are real headings, not just bold text, and that they follow an order: one H1, then H2s, then H3s under them. A headings browser extension lists them.	1.3.1 Info and Relationships (A)
8. Captions	Play each video with sound off. If speech carries information, there should be captions you can turn on, and they should be accurate.	1.2.2 Captions (Prerecorded) (A)
9. Target size	On your phone, tap every small control: close buttons, carousel dots, social icons, footer links. Targets should be at least 24 by 24 CSS pixels, or spaced far enough apart that you don't hit the wrong one.	2.5.8 Target Size (Minimum) (AA)

Most of these come from the W3C's Easy Checks, a first-review method written for non-experts. W3C is clear about its limits: the checks are quick rather than definitive, and a page can pass them and still have serious barriers. Treat a pass as "no obvious problems", not as conformance.

Which failures should you fix first?

Fix what blocks a task before what slows it down.

A keyboard trap, an unlabelled field, or a form that can't be submitted without a mouse means someone cannot contact you at all. Those come first. Low body-text contrast and a missing focus indicator come next, because they affect every page. Missing alt text, a skipped heading level and a small footer link matter, but nobody is locked out by them.

Give extra attention to anything that floats over the page: a cookie or consent banner, a chat widget, a "WhatsApp us" button. Check that none of them covers the focused element (2.4.11), traps the keyboard, or has a close button smaller than 24 by 24 pixels. Test with every one of them switched on, the way a visitor sees the site, and test again whenever someone adds a new one after launch.

What should you ask your developer?

The checklist tells you what's wrong. These questions tell you whether the person building your site will keep it right.

• "Which WCAG version and level are you building to?" You want "WCAG 2.2, Level AA" as a plain answer. Put it in the requirements before you ask for a quote, alongside the other non-functional requirements in our guide to writing requirements before a software quote.
• "How do you test it?" Automated scanners catch some problems, such as missing alt attributes and low contrast. They can't tell you whether alt text is accurate, whether focus order makes sense, or whether a form error is understandable. Ask what manual testing happens, with a keyboard and a screen reader.
• "Who can break it after launch?" If your team edits pages through a CMS, they can upload images without alt text or style a heading as bold text. Ask whether the editor requires alt text and offers real heading levels. This is one of the practical questions in choosing between Next.js and WordPress, because the editing experience decides what non-developers can get wrong.
• "What about the login, if there is one?" WCAG 2.2 criterion 3.3.8 says login can't depend on a cognitive test, such as remembering or transcribing a code, unless an alternative or assistance is provided. In practice, allow password managers and paste.
• "Does this apply to the app too?" If a mobile app comes with the site, the same questions apply. Our post on hiring Flutter developers in Nepal covers how to check a mobile developer's accessibility habits.

The W3C's WCAG 2.2 Quick Reference is the page to send a developer who wants detail. It can be filtered to Level AA and to the criteria that are new in 2.2.

What does the Australian Human Rights Commission say?

If you sell to Australians, read the Commission's own guidance. Its Guidelines on equal access to digital goods and services, published April 2025, are written to help organisations meet their obligations under the Disability Discrimination Act. They count websites and apps as digital products and point to the latest published version of WCAG. The Commission's page on digital accessibility standards says organisations should conform with WCAG 2.2 at a minimum of Level AA.

The Commission states that the Guidelines are not legally binding and should be read with the Act. This post is not legal advice. If you need to know what the Act requires of your business, ask an Australian lawyer.

For a site aimed at Nepali customers, the case is practical. People read on small phones, in bright light, with older eyes. Every check above helps them too.

Frequently asked questions

Is an automated accessibility scanner enough?

No. Scanners are useful for catching missing alt attributes, contrast failures and empty links across many pages. They can't judge whether alt text describes the image, whether the tab order is logical, or whether an error message makes sense. Use one alongside the manual checks, not instead of them.

Do PDFs and other documents on the site count?

The Australian Human Rights Commission's guidelines include digital documents alongside websites and apps. If your price list, brochure or application form is a PDF, it needs the same attention: real text rather than a scanned image, headings, and readable contrast. Where you can, publish the content as a web page instead.

How often should we run the checklist?

Before launch, and again after any redesign, new template or new third-party widget. Content edits can break it too, so check new pages when they go live.

Can an accessibility toolbar or plugin replace these fixes?

Don't rely on one. The checks above are about the site itself: its labels, headings, focus styles and contrast. Fix those at the source, and if you already use a toolbar or plugin, run the checklist with it switched off to see what's underneath.

Getting accessibility into the build

Ask for WCAG 2.2 Level AA in the brief, before design starts, rather than after launch. Our web development team builds websites and web applications with Next.js and React. If you want this checklist run against a site you already have, or built into a new one from the start, tell us about the project.