Website Accessibility Audit Checklist: What to Look For

This website accessibility audit checklist gives a practical, testable list of what to look for when you evaluate a site. Use it to plan the audit, run automated scans, complete manual checks with keyboard and screen reader, and turn findings into a prioritised remediation plan.

Before you start: scope, standards and success criteria

Decide the scope first. Choose pages, templates and document types. Typical scopes are: all public pages, high-traffic pages, forms, and PDFs. Record the target WCAG level. Most organisations aim for WCAG 2.1 or 2.2 level AA.

Document the audit brief

• Pages and templates to test
• Assistive technologies to use (NVDA, VoiceOver)
• Testing devices and browsers
• Legal or policy requirements (for example the Equality Act 2010 and the Public Sector Bodies accessibility regulations in the UK)
• Acceptance level (A, AA or AAA)

Quick checklist overview

• Automated scans for obvious failures
• Manual keyboard navigation checks
• Screen reader checks for content order and labelling
• Colour contrast and text sizing checks
• Images and alternative text review
• Forms and error handling checks
• ARIA and role usage review
• PDFs and other documents checked for accessibility
• Mobile and responsive behaviour tested
• Reporting with severity and remediation guidance

Automated testing: what to run and why

Automated tools find obvious code issues quickly. They do not replace manual tests. Run automated checks early to find missing attributes, broken ARIA, and contrast failures.

What to include

• Page-level scanner (for example browser extensions that list failures)
• Command-line or CI integration for regression checks
• Contrast analyser for large batches of pages

What automated checks commonly miss

• Whether alt text is meaningful in context
• Logical focus order and keyboard traps
• Whether dynamic updates are announced to assistive tech

Manual testing: core areas and tests

Manual testing proves whether the website works for real users. Run keyboard and screen reader tests, plus human reviews of content and media.

Keyboard navigation

Test using only Tab, Shift+Tab, Enter, Space, arrow keys and Esc. Include these checks.

1. Page can be navigated to all interactive elements using Tab
2. Focus order follows visual order and reading order
3. No keyboard traps. You can always move focus away
4. Focusable elements have a visible focus indicator
5. Custom widgets are operable with keyboard controls

Screen reader testing

Test with at least one Windows and one macOS/mobile screen reader. Common choices are NVDA on Windows and VoiceOver on macOS or iOS. Use real tasks rather than random page reading.

• Does heading structure provide a clear outline of the page?
• Are form labels announced and associated correctly?
• Are links meaningful when read out of context?
• Does dynamic content announce updates via live regions or role alerts?

Colour contrast and readable text

Check contrast ratios. For normal text ensure at least 4.5:1. For large text the minimum is 3:1. Also check that text can be resized to 200 percent without loss of function.

Images, media and alternative text

• All informative images have useful alt text that conveys the purpose
• Decorative images use null alt attributes so screen readers skip them
• Videos offer captions and transcripts
• Audio controls are accessible and labelled

Forms and error handling

• Every form control has an explicit label or accessible name
• Errors are presented in text and associated with the relevant control
• Instructions and examples are available before submission
• ARIA attributes are only used when native semantics are insufficient

Semantic structure and headings

Headings must follow a logical order. Use native HTML elements for lists, tables and buttons. Avoid using role attributes to mimic semantics that native HTML already provides.

Focus management and dynamic content

When the page updates or a modal opens, manage focus so keyboard and screen reader users are moved to the new content. Return focus when the component closes.

Documents, PDFs and downloadable files

Include documents in the audit scope. Check document language, tag structure, and reading order. Record files that need remediation or replacement with HTML alternatives.

Mobile and responsive behaviour

Test on small screens and touch devices. Check touch targets are at least 44 by 44 CSS pixels. Ensure orientation changes do not hide content and that focus and virtual keyboard behaviour is consistent.

Reporting: what to include in findings

Each finding should say what failed, why it matters, exact pages or components affected, WCAG reference, and suggested remediation. Include screenshots and a short code example when helpful.

Essential report fields

• Unique issue ID
• Severity (critical, major, minor)
• WCAG criterion reference
• Steps to reproduce
• Expected behaviour
• Suggested fix and code sample

Prioritise fixes: a simple decision framework

Use impact and effort to decide what to fix first. High impact and low effort should go to the top of the backlog. Low impact and high effort can be scheduled later.

Priority	How to decide	Example
High	Large number of users affected and simple code fix	Missing label on primary search field
Medium	Few pages impacted or requires moderate dev work	Contrast issues on a specific banner
Low	Rarely used feature or heavy redesign work	Complex interactive visualisation needs refactor

Common mistakes to avoid

• Relying only on automated tools
• Using ARIA to fix broken HTML instead of fixing the HTML
• Failing to test real tasks such as completing a form or paying
• Not testing with assistive technologies and mobile devices
• Not including content authors when reviewing alt text and link text

Practical audit checklist: step-by-step

Run this checklist on each page or template in scope. Mark Pass, Fail, or Needs review and add notes.

1. Run an automated scanner and save the report
2. Manual check: test keyboard navigation across the page
3. Manual check: verify heading order and landmark roles
4. Screen reader test: complete a core task with NVDA or VoiceOver
5. Contrast check on primary text elements
6. Inspect images for meaningful alt text or null alt where decorative
7. Test forms for labels, error messages and field instructions
8. Test modals and dynamic updates for correct focus handling
9. Check PDFs and documents for tagging and language settings
10. Record findings, assign priority and recommend fixes

Sample keyboard test cases

• Tab to main navigation, open and close submenus with Enter and Esc
• Tab into a modal, ensure focus stays inside and Esc closes it
• Use form fields in sequence and submit with keyboard only
• Operate any custom widgets using arrow keys and Space or Enter

Screen reader test steps (short)

1. Turn on the screen reader and navigate by headings to check structure
2. Navigate links using the link list or by tabbing through key links
3. Fill and submit a form while noting announcements and error messages
4. Trigger dynamic content and verify it is announced or reachable

Tools to use

• Browser-based automated extensions and scanners
• Contrast checkers for single elements
• Screen readers: NVDA, VoiceOver
• Keyboard-only testing on desktop and mobile
• Document accessibility checkers for PDFs

Next steps and ownership

Make accessibility an ongoing activity. Integrate automated checks into CI. Train designers and content authors on accessible patterns. Assign owners for fixes and track them in your delivery process.

Use this checklist as a working document. Add organisation-specific rules, custom components, and templates to the scope. Keep results public when required by regulation, and update the checklist as WCAG or platform behaviours change.