This website accessibility checklist groups WCAG-aligned checks into perceivable, operable, understandable and robust, then adds an audit workflow your whole team can repeat. It pairs automated scans with manual keyboard and screen-reader checks and, where possible, representative user testing. Treat it as triage that finds and ranks problems, not as a certificate of conformance.
TL;DR:
- Audit each template after changes, prioritizing homepage, product or service, contact, and checkout pages; log the URL, WCAG criterion, owner, and severity.
- Normal text needs a 4.5:1 contrast ratio, large text needs 3:1, and meaningful interface parts such as input borders and icons need 3:1.
- Use WAVE, axe, or Lighthouse for an initial scan, but follow with keyboard and screen reader testing because automated tools miss meaning and usability.
- WebAIM found detectable errors on 94.8% of the top one million home pages, averaging 51 per page; a clean scan does not establish accessibility.
Table of Contents
- 1. Which checks go on your accessibility checklist at a glance?
- 2. What are the perceivable checks for alt text, headings, contrast and media?
- 3. How do you test keyboard navigation, focus, skip links and mobile use?
- 4. Which forms, labels, errors and link text checks make pages understandable?
- 5. What robust checks cover correct HTML, ARIA and landmarks?
- 6. How does a repeatable accessibility audit workflow run?
- 7. Which accessibility tools should you use, and what do they miss?
- 8. What do common failures tell us about where to start?
- 9. How should you build accessibility into every sprint?
- 10. Who can audit and fix your website for you?
- FAQ
- Sources
1. Which checks go on your accessibility checklist at a glance?
Keep one checklist per template and tick it off each time that template changes. Start with the pages that carry revenue or enquiries: the homepage, a product or service page, the contact page and checkout or booking. Then add the critical journeys that link them. Record every result with the URL, the WCAG success criterion, an owner and a severity rating.
- Informative images have meaningful alt text; decorative images use empty alt attributes.
- Each page has a unique title and one h1 followed by logical subheadings.
- Text and interface components meet the contrast ratios in the next section.
- Every task can be finished with the keyboard alone, with visible focus.
- Form fields have programmatic labels and clear error messages.
- Video and audio have captions and transcripts.
- A working skip link and sensible landmarks sit at the top of the page.
- ARIA appears only where native HTML cannot do the job.
2. What are the perceivable checks for alt text, headings, contrast and media?
Perceivable checks decide whether people can take in your content at all, whether they see it, hear it or use assistive technology. Designers and content teams own most of them, so record each finding in the same format developers use.
- Alt text: describe what an informative image communicates, not what it looks like. Use alt="" for purely decorative images so screen readers skip them. Charts and complex diagrams need a longer description nearby.
- Titles and headings: give each page a unique title, one h1 and subsections that never skip a level, such as jumping from h2 to h4.
- Contrast: normal text needs 4.5:1 against its background, large text needs 3:1, and meaningful interface parts such as input borders and icons need 3:1.
- Media: supply captions for video, transcripts for audio, and do not rely on colour alone to carry meaning in charts or status labels.
W3C guidance for visual designers makes the same point about colour and focus indicators: charts and infographics must not rely on colour alone, and focus indicators must be visible.
The WebAIM Million analysis found detectable WCAG failures on 94.8% of the top one million home pages. Low contrast and missing alt text are exactly the issues this section helps you catch before launch.
3. How do you test keyboard navigation, focus, skip links and mobile use?
Unplug the mouse and try to finish every task. This is where developers and QA do most of their work, and it is the quickest way to expose a page that only works for pointer users. Stanford's accessibility team describes the core test: complete each task without a mouse, with Tab and Shift+Tab following a logical order, every control reachable, focus always visible and no keyboard traps. Those checks map to WCAG 2.1.1, 2.1.2, 2.4.1, 2.4.3 and 2.4.7.
- Tab through the page: the order should match the visual layout and reach every link, button and field.
- Check that a visible focus style appears on each focusable element, using :focus-visible where appropriate.
- Open every modal, menu and date picker, then confirm you can leave it with the keyboard and that focus returns sensibly.
- Activate the skip-to-content link and check it lands on the main content, and that landmarks are not hidden or broken.
- On a phone, check touch targets are comfortably sized and that pinch-zoom is not disabled.
For mobile and responsive checks, WebAIM points to criteria such as text resizing, reflow and orientation (1.3.4, 1.4.4, 1.4.10 and 1.4.12): content must stay usable when text is enlarged and the layout must reflow at narrow widths.
Pro Tip: Run the keyboard test on a staging build before design sign-off, then again after launch. Focus problems often appear only once real scripts and cookie banners load.
4. Which forms, labels, errors and link text checks make pages understandable?
Understandable checks make forms and interactive flows predictable. Content teams write the labels and error messages, and front-end developers connect them, so both need to be in the same review.
- Every form control has a programmatic label, not just placeholder text that vanishes when someone starts typing.
- Required fields are marked in text or with a symbol explained on the page, never by colour alone.
- Instructions sit before the field, and error messages sit next to it and name the problem and the fix.
- Errors are announced to assistive technology, for example by moving focus to an error summary or using a live region.
- Link text makes sense out of context: "Download the pricing guide", not "click here".
- Use buttons for actions and links for navigation.
- The page language is declared, and interface wording stays consistent from page to page.
5. What robust checks cover correct HTML, ARIA and landmarks?
Robust means assistive technology can interpret the page reliably. A practical route is native HTML: a real button element carries keyboard behaviour, focus and a role without any extra work. W3C's guidance for front-end developers says the same: use correct semantics, keep DOM order matching visual order and label form controls programmatically.
- Prefer native elements over divs with scripts bolted on.
- Add ARIA only when no native element fits, then test the result with a screen reader. Use ARIA carefully, and test the result with a screen reader.
- Set the document language and include main, nav and banner landmarks.
- Mark table headers with scope so cell relationships are announced.
- Confirm the technologies you rely on are "accessibility supported" in the way WCAG defines it.
6. How does a repeatable accessibility audit workflow run?
A repeatable audit means a second person can follow your notes and reach the same findings. W3C's evaluation overview describes a practical sequence, and the numbered steps below follow it.
- Define the target WCAG version and conformance level.
- Inventory representative templates and critical journeys.
- Run automated checks with WAVE, axe or Lighthouse.
- Inspect DOM semantics and landmarks, then test with the keyboard only.
- Test with a screen reader, and check zoom and reflow.
- Record each issue, assign an owner and fix it.
- Retest after deployment and repeat.
Record every issue in a consistent table so nothing gets lost between design, development and content:
| Field | What to record |
|---|---|
| Location | URL and the steps to reproduce |
| Standard | The WCAG success criterion affected |
| Impact | Severity rating, based on the effect on core journeys |
| Owner | Designer, developer or content editor responsible |
| Status | Open, fixed or retested |
Prioritise fixes by their effect on journeys that matter most, such as booking or checkout. Chrome DevTools can produce a Lighthouse report in roughly 10 to 30 seconds, which makes the first pass cheap, but that report covers only the issues a tool can detect.
7. Which accessibility tools should you use, and what do they miss?
Use several tools, because each detects a different slice of problems. WebAIM recommends WAVE and axe for catching many common issues, and stresses that automated tools should be followed by keyboard and screen-reader testing.
- WAVE: overlays flagged issues on the page, which makes it friendly for content editors.
- axe extension: inspects a page quickly and links each result to the failing element and guidance.
- Lighthouse: built into Chrome DevTools, handy for a fast score and a baseline.
- axe-core in CI: runs on every build so regressions are caught before they ship.
- Contrast checkers and browser devtools: give exact ratio values when a visual check is borderline.
No single automated tool can determine whether a site is accessible. Automation cannot judge whether alt text is meaningful or whether a flow makes sense, so add manual screen-reader checks to every cycle.
8. What do common failures tell us about where to start?
Detectable failures are the norm, not the exception. The WebAIM Million analysis found errors on 94.8% of the top one million home pages, with 50,960,288 detected errors, an average of 51 per page. WebAIM also notes that WAVE detects only a subset of issues, so a clean scan does not prove a page is accessible.
This checklist is a triage instrument, not a conformance claim. W3C states that conformance claims must meet WCAG's conformance requirements and that testing needs automated checks plus human evaluation. At GridLock Digital we build and care for small business websites, so we see these failure patterns on real templates and fold the fixes into normal project work.
9. How should you build accessibility into every sprint?
Do not save accessibility for the end. Run light checks at design handoff, a full audit before launch and automated regression tests afterwards. Put accessibility acceptance criteria into tickets, give each issue an owner and schedule periodic manual reviews. Where you can, include people who use assistive technology, because they find problems no checklist anticipates.
— Dylan
10. Who can audit and fix your website for you?
If you would rather hand this over, we can help. Our team designs and develops websites with accessibility-aware QA built in, and our GridLock Care plan keeps a site maintained once it is live. Our Start, Grow and Pro packages are listed on our services page, and GridLock Care is available from R299 per month. Request a quote and we will tell you what your templates need.
FAQ
Does passing an automated scan mean my site is accessible?
No. Automated tools detect only a subset of issues and cannot judge meaning, such as whether alt text actually describes an image. W3C advises combining scans with keyboard testing, assistive technology checks and user testing.
What contrast ratio does WCAG require for text?
Normal text needs a contrast ratio of 4.5:1 against its background, and large text needs 3:1. Meaningful interface components such as input borders and icons also need 3:1.
How often should I run an accessibility audit?
Evaluate early and throughout development or redesign, as W3C recommends, because defects are easier to fix before they spread into templates and content. Then run automated regression checks on every release and schedule manual reviews periodically.
Which tools should I start with?
Start with WAVE or the axe extension for page-level scans and Lighthouse for a quick baseline. Add axe-core to your build pipeline, then back everything up with keyboard and screen-reader testing.