Website Accessibility Testing Checklist: A Practical Guide

Website Accessibility Testing Checklist: a practical guide

This website accessibility testing checklist gives a step by step set of tests you can run today. Use it during design, development and before releases. The checklist follows WCAG principles and focuses on checks you can automate and checks you must do by hand.

Standards, scope and target

Choose a measurable target before you test. Most organisations aim for WCAG 2.1 or 2.2 level AA. Mention other requirements if they apply, for example ADA, Section 508, or national accessibility laws. Also note whether you will test the whole site or a sample of templates and key user journeys.

When to test

• Design stage: test colour, layout and component accessibility early.
• Development: run automated scans and manual checks on components and pages.
• Before release: run a regression pass and user testing on the final build.
• Regular audits: schedule audits after major feature changes or quarterly for active sites.

Testing process overview

Run tests in this order for speed and clarity. Start with automated scans, then manual keyboard and assistive technology tests, then user testing. Finish with a prioritised remediation plan and regression checklist.

Automated scanning

Automated tools catch many technical issues fast. They do not find everything, but they save time.

• Run a page-level scan for WCAG violations.
• Check single-page app routes and dynamic content.
• Export results and mark duplicates to avoid noise.

Manual testing: keyboard

Keyboard testing finds operability and focus order problems automated tools miss.

1. Tab through the page from top to bottom. Every interactive element must receive focus in a logical order.
2. Where a modal opens, focus must move into the modal and not the page behind it.
3. All functionality must be available from keyboard alone (enter, space, arrow keys when applicable).

Manual testing: screen reader

Use a current screen reader and browser combination. Test the main journeys: navigation, forms, shopping cart, and content pages.

• Confirm meaningful order of headings and landmarks.
• Check that images and controls have correct text alternatives.
• Listen for redundant or missing announcements when dynamic content changes.

Assistive technology and alternate input

Test with at least one alternative input or assistive tech besides a screen reader.

• Voice control: ensure commands map to visible labels and buttons.
• Switch control or on-screen keyboard: confirm sequential access works.
• High contrast mode and system text size increases: verify layout holds and text remains readable.

Perceivable checks (content)

• Images: all meaningful images must have text alternatives; decorative images should use null alt.
• Colour contrast: normal text at least 4.5:1, large text at least 3:1.
• Media: captions for speech, transcripts for audio-only, and audio descriptions where required.
• Text resize: text must reflow without loss of content or functionality at system zoom levels.

Operable checks (interaction)

• Keyboard focus: visible focus indicator and logical tab order.
• Navigation: skip links, clear heading structure and landmark elements.
• Timing: provide controls to extend or pause time limits.
• Error prevention: confirm undo or confirmation for destructive actions.

Understandable checks (content and forms)

• Clear labels and instructions for form fields. Each input must have a label or accessible name.
• Validation: error messages must be specific and programmatically associated with the field.
• Language: declare page language and mark changes in language in content.

Robustness and code-level checks

• ARIA: use WAI-ARIA roles, states and properties only when native HTML is insufficient.
• Semantic HTML: headings, lists, buttons and links must use correct elements.
• Validity: check for broken landmarks, duplicate IDs and malformed controls.

Documents and other assets

• PDFs: check that PDFs have a document language, proper reading order and text alternatives for images.
• Third-party widgets: verify they expose accessible names and keyboard support or replace them.

Practical test scripts you can copy

Quick keyboard plus screen reader script

1. Open the page in a supported browser. Enable your screen reader.
2. Listen to the page load announcement; note any extraneous repeated labels.
3. Tab to the main navigation, then use arrow keys where appropriate. Confirm headings announce correctly.
4. Navigate to a form. Move by label and field, submit with empty required fields, and note error announcements and focus placement.
5. Trigger a modal and close it. Confirm focus returns to the originating control.
6. Use skip links to jump to main content and verify they work from keyboard only.

Mobile touch and zoom script

1. Open the page on a mobile device. Enable large text in system settings.
2. Zoom to 200 percent and confirm content reflows without overlap or horizontal scrolling for reading areas.
3. Interact with controls and confirm all are reachable and labelled in touch mode.

Prioritise fixes fast: impact and effort matrix

Use a simple table to decide what to fix first. Mark each issue by severity and cost.

Severity	Example	Priority
High (blocks use)	Keyboard or screen reader cannot complete purchase	Urgent
Medium (hurts flow)	Missing form labels or poor error handling	High
Low (cosmetic)	Minor contrast on decorative text	Plan

Reporting format: what to include in each ticket

• Page or component URL and environment (staging/production).
• Steps to reproduce with keyboard and screen reader steps where relevant.
• Expected result and observed result.
• WCAG reference (for example WCAG 2.1 AA criterion number).
• Screenshots, screencasts or exported automated results.
• Suggested fix or developer notes where you can.

Regression checklist (run before releases)

• Run automated scans on changed pages and critical flows.
• Run the quick keyboard plus screen reader script on the checkout or signup flows.
• Verify previously fixed defects are still resolved.
• Confirm new third-party scripts do not break accessible names or focus.

Common mistakes testers make

• Relying only on automated tools. They miss focus, semantics and user experience issues.
• Using ARIA instead of proper HTML elements. ARIA can add complexity if misapplied.
• Not testing dynamic content announcements. Live regions must notify assistive tech correctly.
• Skipping real user testing with people who use assistive tech for daily tasks.

Next steps and maintenance

Create a small accessibility acceptance test that is part of every pull request for UI changes. Run a full audit annually or after major redesigns. Keep a short backlog of accessibility bugs and check them in sprint planning.

Where this checklist adds value

This checklist pairs automated scans with two practical scripts and a prioritisation table. That combination reduces false positives and makes remediation decisions faster. Use the scripts as a minimum for regression testing and add user sessions for the highest confidence.