Website accessibility checklist: what to test before you launch

Run these checks first: colour contrast, keyboard access, visible focus, alt text, form labels, and captions on any video. Aim for WCAG 2.2 AA, the current benchmark most public and commercial sites are expected to meet. Pair an automated scanner with a manual keyboard test and a few minutes with a screen reader, because no single tool catches everything on its own.

TL;DR:

Automated contrast checks, keyboard navigation testing, and focus visibility are the most time-efficient ways to catch major WCAG failures early.

Manual checks like reading order, focus traps, and alt text quality reveal accessibility gaps that automation alone cannot detect.

Prioritize fixing high-impact, low-effort issues such as contrast and missing labels to achieve quick wins in compliance.

Regular re-testing with keyboard and screen reader tools should be integrated into every update cycle to ensure ongoing accessibility.

Building accessibility into templates and workflow from the start reduces costly retrofitting and promotes consistent compliance.

Website accessibility checklist: the quick tasks to run in one sitting
Perceivable checks: images, media, colour and readable content
Operable checks: keyboard, focus, navigation and touch targets
Understandable checks: headings, language, links and forms
Robustness checks: semantic HTML, ARIA and accessible names
Testing methodology: automated scans, manual checks and real assistive tech
Prioritisation and remediation: fixing what you find
Tools, templates and where to find the standards
A developer's view: building accessibility in from the start
Get started building an accessible site today
Why most accessibility checklists undersell the manual work
Sources

Website accessibility checklist: the quick tasks to run in one sitting

You don't need a week to find your worst accessibility problems. Most of the serious ones surface in under an hour if you work through the same tasks a proper audit uses, just compressed. Here's the order that catches the most issues fastest, based on the checks that turn up again and again in practical 25-point audits.

Check colour contrast on body text and buttons (WCAG 1.4.3). Automated. Critical. 10 minutes.
Tab through the entire page with no mouse (WCAG 2.1.1). Manual. Critical. 15 minutes.
Confirm focus is visible on every interactive element (WCAG 2.4.11, new in 2.2). Manual. Critical. 10 minutes.
Add or audit alt text on every image (WCAG 1.1.1). Mostly manual. Critical. 20 minutes per template.
Check every form field has a linked label (WCAG 1.3.1, 3.3.2). Automated plus manual. Critical. 15 minutes.
Add captions to any video content (WCAG 1.2.2). Manual. High. Varies by video length.
Run an automated scan across your key templates. Automated. High. 10 minutes.
Check heading order is logical, not just styled to look right. Manual. High. 10 minutes.
Test zoom to 200% and check nothing breaks. Manual. High. 10 minutes.
Check touch target size on mobile buttons and links (WCAG 2.5.8, new in 2.2). Manual. High. 15 minutes.
Read link text out of context and check it still makes sense. Manual. Medium. 10 minutes.
Disable your stylesheet and check the page still reads in order, a technique Gov for quick manual audits. Manual. Medium. 5 minutes.
Check the page has a unique, descriptive title. Manual. Low. 2 minutes.
Test a modal dialog or dropdown with keyboard only. Manual. High. 15 minutes.
Check error messages actually explain what went wrong and how to fix it. Manual. Medium. 10 minutes.
Confirm the page language attribute is set correctly. Automated. Low. 2 minutes.

Many home pages have at least one detectable WCAG failure when tested by automated scanning across a large sample of sites, according to research cited in the A11y Project's checklist background. Run this list against your own homepage before you assume yours is the exception.

That's roughly two and a half hours for the full run on a single template, and most of it is manual, which is exactly why teams skip it. Don't. The manual checks are where the real barriers live.

Perceivable checks: images, media, colour and readable content

Perceivable means a person can actually take in your content, whatever sense they're using to do it. That covers sight, obviously, but also hearing and how content behaves when it's resized or restructured.

Alt text is where most sites fall down first, and the mistake usually isn't a missing attribute, it's a lazy one. "Image123.jpg" or "photo of team" tells a screen reader user nothing useful. Decorative images, the ones adding no information (a background swirl, a divider graphic), should carry an empty alt="" so screen readers skip them entirely. Informative images need alt text that describes their purpose in context: not "man on ladder" but "electrician fitting a smoke alarm during a home safety check." If you're compressing and resizing images anyway, that's the right moment to write proper alt text at the same time, covered in more detail in this image optimisation guide.

Hands typing alt text for website images

Video and audio content need more than a play button. Any pre-recorded video needs captions (WCAG 1.2.2), and if it conveys information visually that isn't spoken, it needs audio description too. Transcripts matter for podcasts and audio-only content, partly for accessibility and partly because search engines can't watch a video but they can read a transcript. Check the player controls themselves: can someone operate play, pause, and volume using only a keyboard?

Colour contrast is the easiest fix and the most commonly failed check. WCAG 2.2 AA requires a 4.5:1 contrast ratio for normal body text against its background, and 3:1 for large text (18pt or 14pt bold and above). Light grey text on a white background is the classic offender, it looks clean in a design mockup and fails instantly for anyone with low vision or an older monitor.

Run these before you sign off any template:

Test contrast on body text, placeholder text, and button labels, not just headings.
Zoom the page to 200% in the browser and check text doesn't get clipped or overlap other elements.
Resize the browser window to simulate reflow and confirm content stacks sensibly rather than requiring horizontal scrolling.
Disable the stylesheet entirely and read the page top to bottom. If the order still makes sense without any visual styling, your underlying HTML structure is sound.
Check that meaning never depends on colour alone, a red asterisk marking a required field needs the word "required" too, not just the colour.

Pro Tip: Disabling your stylesheet is the single fastest way to catch a badly ordered page. If your navigation, main content, and footer read in a logical sequence with zero styling, a screen reader user will experience the same logical flow. If it reads like alphabet soup, so will they.

Meaningful sequence matters more on complex layouts, dashboards, multi-column pricing tables, anything with cards or tiles. A sighted user scans visually and picks up the structure instantly. A screen reader user hears it in the order it appears in the DOM, so if your CSS visually reorders content away from its source order, you've created a mismatch that only shows up in testing, never in a design review.

If a site can't be operated without a mouse, it fails for a significant chunk of visitors before you even get to screen reader users, think anyone with a motor impairment, a temporary injury, or simply someone using a laptop trackpad awkwardly on a train. Keyboard access is the fastest test to run and the one that catches the most severe issues.

Here's the walkthrough, step by step:

Unplug your mouse or trackpad, or just don't touch it.
Press Tab repeatedly from the top of the page and watch where focus lands each time.
Check every interactive element gets a turn, links, buttons, form fields, and any custom widget like a dropdown or accordion.
Try Enter and Space on buttons, and arrow keys on any menu or tab component.
Open a modal dialog and try to Tab out of it. If focus escapes to the page behind it, that's a bug. If you can never get back out with Escape or Tab, that's a keyboard trap, and it's one of the most severe failures a site can have.
Check Shift+Tab moves backwards through the same elements in reverse, cleanly.
Look for a skip link at the very start of Tab order that jumps past repeated navigation straight to the main content.

Focus visibility is where WCAG 2.2 tightened the rules noticeably. The new Focus Not Obscured criterion means a sticky header or cookie banner can't hide the element currently focused, a real problem on sites with fixed navigation bars that cover the top of the page. Target Size (Minimum) now requires interactive targets to be at least 24 by 24 pixels, unless there's enough spacing around a smaller target to prevent mis-taps. Both are new checks the W3C added specifically in the 2.2 update, so if your last accessibility pass predates that, these two are worth testing explicitly.

Menus and custom widgets are where ARIA either helps enormously or makes things worse. A dropdown built with plain links and aria-expanded on the trigger button tends to work reliably. A dropdown built from scratch with div elements and heavy custom JavaScript, no semantic roles, often breaks completely for screen reader users even when it looks fine visually. Test any custom widget with a screen reader after building it, not just with a keyboard, because the two failure modes are different.

Pro Tip: If you're short on time, test focus order and modal escape first. A keyboard trap in a booking form or checkout flow doesn't just annoy a user, it stops them completing the task entirely, which is the worst possible outcome for a business site.

Mobile brings its own version of these problems. Touch targets need generous spacing, not just minimum size, because fingers are far less precise than a mouse cursor. Dragging gestures, a slider, a swipe-to-dismiss card, need a non-drag alternative such as buttons, since some people physically cannot perform a drag gesture reliably. If your site relies on responsive breakpoints, the mobile-friendly guidance for small business sites is worth checking alongside your accessibility pass, since the two overlap more than most teams expect.

Understandable checks: headings, language, links and forms

Understandable is about whether someone can follow what's happening on the page and complete a task without confusion, and it's the principle that content creators, not just developers, have the most control over.

Heading order matters more than most writers assume. A page should have one H1, and headings below it should nest logically, an H3 sitting under its parent H2, not jumping from H2 straight to H4 because it looked right in a design tool. Screen reader users often navigate by heading alone, skipping straight through a long page by jumping from heading to heading, so a broken hierarchy makes a page feel disorganised even when the visual design is fine. Page titles need to be unique and descriptive too, "Home" tells a user nothing when they've got a dozen browser tabs open.

Link and button text has to survive being read out of context. A screen reader can generate a list of every link on a page, and if that list is full of "click here" and "read more" repeated a dozen times, it's useless. "Read more about our booking widget" beats "read more" every time, and it barely costs any extra words.

Run through these on any form or content-heavy page:

Every link and button label makes sense when read on its own, disconnected from surrounding text.
Every form field has a visible label, not just placeholder text that disappears the moment someone starts typing.
Instructions for a field, "must be 8 characters," "format DD/MM/YYYY," appear before the person submits, not only after they've failed.
Error messages explain what went wrong and how to fix it, "Enter a valid email address" beats a bare "Invalid input" every time.
The page's language attribute (lang="en-GB" or similar) is set correctly, and any section written in a different language carries its own lang attribute.

That last point trips up more multilingual sites than you'd expect. A screen reader uses the language attribute to choose pronunciation rules, so a French phrase sitting in an English-tagged page gets read with English pronunciation, which sounds wrong and sometimes becomes genuinely hard to understand.

Robustness checks: semantic HTML, ARIA and accessible names

Robust means your markup works reliably with the tools people actually use to access it, screen readers, switch devices, voice control, browser extensions, and whatever comes next. The single best move here is boring but effective: use semantic HTML before reaching for ARIA.

A native <button> comes with keyboard support, focus handling, and a role built in for free. A <div onclick="..."> styled to look like a button has none of that until you manually rebuild every piece of behaviour a real button already has. The same logic applies to <nav>, <main>, <header>, and proper <label> elements tied to form inputs, each one does work you'd otherwise have to reinvent with ARIA attributes and JavaScript.

Where ARIA is genuinely needed, on custom widgets HTML has no native equivalent for, check these:

Every interactive element has an accessible name a screen reader can announce, not just a visual label sitting nearby with no programmatic link.
The role matches what the element actually does, don't mark something role="button" if it behaves like a link, or vice versa.
The value or state, expanded, checked, selected, updates and gets announced when it changes, not just visually.
Dynamic content updates, a form validation message, a cart total, a live search result count, use aria-live so screen reader users hear the change without needing to hunt for it.
Markup validates cleanly, unclosed tags and duplicate IDs are a common, avoidable cause of assistive technology misreading a page.

Test any ARIA change with an actual screen reader afterwards. It's the step most teams skip, and it's the one that catches the mistakes automated scanners genuinely cannot see, because a scanner checks that an attribute exists, not that it behaves correctly once a user interacts with it.

Testing methodology: automated scans, manual checks and real assistive tech

A defensible accessibility test combines three layers, and skipping any one of them leaves a blind spot. Automated tools are fast and consistent but only catch what's programmatically detectable, roughly a third of WCAG success criteria by most estimates. Manual testing catches structural and interaction problems a scanner has no way to judge. Assistive technology testing, actually using a screen reader or switch device, catches the gap between what the code says and what a real device announces.

Here's a workable split:

Check type	Catches	Misses
Automated scan	Missing alt attributes, contrast ratios, missing form labels, broken ARIA syntax	Whether alt text is meaningful, logical reading order, keyboard trap behaviour
Manual keyboard test	Focus order, keyboard traps, visible focus, skip links	Screen reader announcement accuracy, voice control compatibility
Screen reader test	Whether names, roles and states announce correctly, reading order as heard	Nothing significant if done thoroughly, it's the closest proxy to a real user experience

Build your test plan around a sampling strategy rather than testing every single page, which rarely scales. Pick your homepage, your most-used template (a services page, a blog post layout), and every unique component, forms, navigation, modals, sliders, since a component bug repeats itself on every page that uses it. Then walk two or three representative user journeys end to end: booking an appointment, submitting a contact form, reading a blog post, testing each one with keyboard only and then again with a screen reader.

Follow a repeatable process for each round:

Run an automated scan across your sampled pages and log every flagged issue.
Complete a full keyboard walkthrough of each unique template and component.
Test the same pages with a screen reader, NVDA and VoiceOver both, if you can manage it.
Capture evidence for each issue found, a screenshot, the specific WCAG criterion it fails, and if possible a short screen reader recording or transcript of what was announced.
File each issue with a severity rating, critical, high, medium, or low, so remediation work can be triaged rather than tackled in the order it happened to be found.
Decide whether a formal third-party audit is warranted, typically once you're dealing with a public sector site, a large e-commerce platform, or anywhere legal exposure around accessibility is a genuine concern.

A proper accessibility report should state the WCAG version and conformance level tested against, list every issue with its specific success criterion, include severity and reproduction steps, and note what still needs manual verification versus what's been confirmed. That level of documentation is what separates a defensible audit from a quick scan result nobody can act on with confidence.

Prioritisation and remediation: fixing what you find

Not every issue deserves the same urgency, and treating them all equally is how remediation backlogs stall. A triage matrix weighing impact against effort sorts most findings into four honest categories fast.

High impact, low effort: missing alt text, poor contrast, missing form labels. Fix these within the current sprint, most take minutes each.
High impact, high effort: a custom widget with no keyboard support, a modal with a genuine keyboard trap. These need dedicated development time, but they block task completion entirely, so they can't sit in a backlog for months.
Low impact, low effort: a slightly ambiguous link label, a heading one level out of sequence. Batch these into routine content or design tickets.
Low impact, high effort: rebuilding an entire legacy component for a marginal gain. Worth scheduling, rarely worth an emergency fix.

Recommended 25-point checklists suggest most colour contrast and alt text issues take under 30 minutes each to fix, while keyboard trap and custom widget failures can take a full day or more depending on how the component was originally built, a pattern consistent with the priority checks outlined in accessibility testing guides.

Build a re-test step into every fix, not just an initial sign-off. Regression is common, a developer fixes a contrast issue, then a later CSS change quietly reintroduces it three sprints later. Hooking an automated scanner into your CI/CD pipeline catches obvious regressions before they reach production, and a quarterly manual and screen reader pass catches what automation can't.

If your site handles bookings, payments, or serves a public sector or NHS-adjacent audience, the bar for evidence is higher, and that's usually the point where a formal third-party audit becomes worth the cost, particularly where the legal requirements for UK business websites intersect with accessibility obligations under the Equality Act.

Tools, templates and where to find the standards

Start with the primary source rather than a summary of it: the W3C's WCAG 2.2 quick reference lets you filter by conformance level and technique, which is genuinely faster to search than most third-party checklists once you know what you're looking for.

For day-to-day work, mix these:

An automated scanner run across your build or CI pipeline for baseline coverage.
A dedicated colour contrast checker for anything a design tool's built-in checker doesn't cover.
A manual test script covering keyboard walkthroughs and screen reader spot checks, written once and reused every audit.
The A11y Project's checklist and WebAIM's WCAG checklist, both organised by content area rather than raw success criterion number, which makes them easier to work through in practice.
The NHS accessibility resources and gov.uk's basic accessibility check guidance, both useful downloadable references built for teams without a dedicated accessibility specialist.

Lean on tools for speed and consistency, but never let a clean scan result stand in for a genuine keyboard and screen reader pass. The two layers catch different things, and only one of them tells you what a real person actually experiences.

A developer's view: building accessibility in from the start

Every aceSites template starts from semantic HTML, proper heading structure, and colour combinations that clear AA contrast by default, so a business owner building their own site isn't starting from a blank, inaccessible canvas. Built-in image handling encourages alt text at the point of upload, and the booking widget and contact form components carry labelled fields and visible focus states out of the box, rather than relying on the person building the site to know WCAG by heading number.

That doesn't mean every site built on any platform is automatically compliant, no template guarantees that, since content choices, custom colour overrides, and added images all shift the picture. What it does mean is the starting point is stronger than a blank page or a hand-coded template with no accessibility consideration baked in. Embedding accessibility at the template and workflow level avoids the expensive rework that comes from bolting it on after launch, when every fix means retrofitting instead of simply adjusting a setting.

The practical takeaway for anyone building a site fast: treat accessibility as a baseline requirement across design, development, and content from the first draft, not a final QA pass squeezed in before launch.

Get started building an accessible site today

A checklist only helps if the platform underneath it doesn't fight you. If you're building a small business site and want accessible defaults handled from the ground up, rather than retrofitted later, the aceSites AI Website Builder gets a professionally structured, semantically sound site live in under a day, with built-in SEO tools and a blog manager included from the start. If you'd rather hand the build over entirely, the done-for-you website service means you only pay once you've seen the finished site, and accessibility fundamentals are handled as part of the build rather than left for you to chase down afterwards.

Why most accessibility checklists undersell the manual work

The industry's favourite shortcut is running one automated scan, fixing the flagged items, and calling it done. That approach clears maybe a third of what WCAG actually requires, because contrast ratios and missing alt attributes are trivial for a scanner to catch, while keyboard traps, illogical reading order, and confusing error messages simply aren't things a machine can judge.

What gets underrated is how cheap the manual checks actually are once you know what to look for. A full keyboard walkthrough of a template takes fifteen minutes. Disabling a stylesheet to check reading order takes five. Neither requires special tooling, just a willingness to actually do it rather than trust a green tick from a scanner.

If you take one thing from this checklist, make it this: run the keyboard test and the screen reader spot check before you trust any automated report, and fold both into your definition of "done" for every template, not just at launch but every time a component changes. That habit, more than any single tool, is what separates a site that passes a scan from one that actually works for the people using it.

— Gabbi