Website Accessibility Checklist: Everything You Need to Check

This website accessibility checklist gives developers, content editors and project managers a practical list to test and fix web pages, web apps and attached documents. Use it during design, development, review and before launch to meet WCAG 2.1/2.2 success criteria and UK accessibility rules.

Quick pre-release checklist (fast sweep)

Run these checks before any release. They catch the most common barriers.

• Keyboard navigation works for all interactive elements. Tab order is logical and focus is visible.
• All images have appropriate alt text. Decorative images use empty alt attributes.
• Colour contrast meets at least WCAG AA for normal text (4.5:1) and large text (3:1).
• Form fields have labels, and errors are described clearly.
• Videos have captions and a text transcript. Audio controls are keyboard accessible.
• No pages trap focus or block screen reader navigation.
• Important content reachable without JavaScript enabled for critical flows.

WCAG basics and UK legal notes

WCAG sets technical criteria under levels A, AA and AAA. Most organisations target WCAG 2.1 or 2.2 level AA. In the UK, the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 require public sector websites and apps to meet accessibility rules and to publish an accessibility statement. The Equality Act 2010 applies to discrimination and reasonable adjustments for services.

Full checklist by accessibility principle

Perceivable — text, images, audio and video

• Alternative text
  • Provide concise, accurate alt for informative images.
  • Use empty alt=“” for purely decorative images so screen readers skip them.
• Text alternatives for non-text content
  • Provide transcripts for audio and full text alternatives for complex visuals like charts.
• Media accessibility
  • All prerecorded video has captions. Live video has captions where feasible.
  • Provide audio descriptions for essential visual information when it is not conveyed in audio.
• Colour and contrast
  • Ensure text contrast of at least 4.5:1 for normal text and 3:1 for large text.
  • Do not use colour alone to convey meaning. Add text labels or patterns.
• Resizable text
  • Content must remain usable at 200% zoom without loss of functionality or content.

Operable — keyboard, navigation and timing

• Keyboard access
  • All functionality available by keyboard alone. Test Tab, Shift+Tab, Enter, Space and arrow keys.
  • Interactive controls receive logical focus order and visible focus indicators.
• Skip links and navigation landmarks
  • Provide a skip link to main content. Use semantic landmarks (header, nav, main, footer) or ARIA landmarks.
• No keyboard traps
  • Users must be able to move focus away from modal dialogs, widgets and components.
• Timing and interruptions
  • Give users control over time limits or warnings before timeouts.

Understandable — content and input

• Readable content
  • Declare page language with the lang attribute. Change language where content switches.
  • Use plain language and clear headings that reflect page structure.
• Predictable navigation
  • UI elements behave consistently. Avoid unexpected changes of context on click.
• Form labels and instructions
  • Every input has a visible label. Use <label> or ARIA-labelledby, not placeholders alone.
  • Provide clear error messages with suggestions to fix and link errors to fields using aria-describedby or similar.

Robust — code, ARIA and compatability

• Semantic HTML
  • Use heading levels in order. Use lists for lists. Use buttons for actions and links for navigation.
• ARIA best practice
  • Use WAI-ARIA roles and properties only when native HTML cannot provide the semantics.
  • Keep ARIA labels and states in sync with DOM updates.
• Accessible documents and attachments
  • Publish accessible PDF versions. Provide HTML alternatives when complex documents are public-facing.

Component-level checklist (common UI elements)

• Navigation menus: keyboard accessible, readable focus, aria-expanded on toggles.
• Modal dialogs: focus trap management, labelled dialog, close control keyboard accessible.
• Custom widgets (tabs, carousels): announce role and state, keyboard controls, pause/stop for auto-rotate.
• Tables: include header cells (th) and scope attributes for complex tables.
• Charts: provide data tables or longdesc summaries for users who cannot see visuals.

Testing: automated and manual steps

Automated tools catch obvious code problems. Manual tests find real user issues. Use both.

Automated tools

• Run a scan with at least one of these: axe, WAVE or Lighthouse. Fix high-confidence failures first.
• Automate checks in CI for new pages and components.

Manual tests you must do

• Keyboard-only test: complete main user journeys without a mouse.
• Screen reader test: try NVDA on Windows and VoiceOver on macOS or iOS for key pages.
• Low-vision test: use browser zoom 200% and change system font sizes.
• Colour-blind simulation: check that information is not conveyed by colour alone.
• Mobile accessibility: test with TalkBack on Android and VoiceOver on iOS for interactive screens.

User testing

Test with at least two users who use assistive technology. Observe where they get stuck. Record tasks, success rate and time to complete.

Prioritise fixes: a simple severity and effort framework

Use priority to plan sprints. Combine impact on users with development effort.

Priority	What it means	Example fixes
High	Blocks core task or excludes many users	Missing alt for key images, keyboard trap, no captions on video used for instructions
Medium	Reduces usability but workarounds exist	Poor contrast in secondary UI, form error messaging improvements
Low	Cosmetic or rare impact	Minor ARIA role on a non-critical widget, decorative image alt text tidy

For each issue record: page URL, selector or component name, WCAG criterion, priority, estimated hours and test confidence (automated/manual). This keeps fixes trackable and auditable.

Checklist for content editors

• Set the page language and check heading structure.
• Add descriptive alt text for images and captions for videos.
• Write meaningful link text not just “click here”.
• Keep tables for tabular data only. Add captions and summaries where needed.
• Run contrast checks on brand colours before publishing new designs.

Accessibility statement and reporting

Public bodies must publish an accessibility statement showing conformance, known issues and contact details. For other organisations, publish a statement so users know how to request accessible formats or report issues. Include a review date and a remediation plan with timelines where possible.

Maintenance: monitoring and continuous checks

• Include accessibility checks in design reviews, code reviews and QA.
• Run automated scans weekly for large sites and on every deploy for apps.
• Log user feedback and periodically re-test critical journeys with assistive tech.

Common mistakes to avoid (practical examples)

• Using aria-hidden to hide content that should be available to screen readers.
• Relying solely on placeholder text as labels.
• Replacing native controls with custom ones without keyboard and screen reader support.
• Assuming automated reports mean a page is fully accessible.

Two quick templates you can copy

Developer quick-fix ticket template

• Title: [Accessibility] Short description
• Page / Component: URL or component path
• Issue: short description and WCAG reference
• Steps to reproduce: exact keyboard and screen reader steps
• Expected behaviour and suggested fix
• Priority and estimated hours

Editor publish checklist

• Alt text added and reviewed
• Headings checked and language set
• Links descriptive and open in same context unless necessary
• Media has captions or transcript

Use this website accessibility checklist every release cycle. It keeps routine problems small and gives you a repeatable path to meet WCAG standards and UK expectations.