An Accessibility Checklist for Web Developers and UX Designers

An Accessibility Checklist for Web Developers and UX Designers: quick overview

This Accessibility Checklist for Web Developers and UX Designers gathers the practical checks you should run during design, development and QA. Use it for new pages, component work and releases. It targets WCAG requirements and common real-world problems so you can catch high-impact issues early.

How to use this checklist

Run the quick scan first. Fix critical failures immediately. Then follow the detailed checks. Keep a copy in your design system and your sprint definition so accessibility is repeatable.

Governance and standards

• Target level: set a project goal such as WCAG 2.1 or 2.2 Level AA unless a higher level is required.
• Assign roles: product owner, accessibility lead, developer, UX reviewer, QA tester.
• Keep an accessibility bug tracker with severity and reproduction steps.

Structure and navigation

Semantic HTML and page landmarks

• Use correct elements: header, nav, main, footer, section and proper heading order (h2 then h3). Avoid skipping heading levels.
• Include a visible or skip-to-main link for keyboard and screen-reader users.

Headings and document order

• Headings must describe the following content. Keep them short and unique per page.
• Verify DOM order matches visual order for linear reading by assistive tech.

Keyboard access and focus

• All interactive controls are reachable and usable with Tab, Shift+Tab, Enter and Space.
• Use a clear, visible focus indicator. Do not rely on outline: none without a replacement is a failure.
• Manage focus for single-page apps and after actions like submitting a form or opening a dialog.

Links, buttons and controls

• Use native <a> for navigation and <button> for actions. Avoid clickable non-semantic elements.
• Link text must be descriptive on its own. Avoid “click here” or duplicate link text pointing to different destinations.

Forms and validation

• Every input must have a programmatically associated label. Use label elements or aria-label/aria-labelledby correctly.
• Provide clear instructions and example format before input, not only after error.
• On error, present an accessible error message and set focus to the first erroneous field. Include aria-invalid when appropriate.

Images, icons and media

• Informative images need alt text that conveys purpose. Decorative images should have an empty alt attribute.
• Icons used as controls require accessible names via visible text or aria-label.
• Provide captions for video and transcripts for audio content. Offer controls to pause, stop or hide moving content.

Colour, contrast and typography

• Text contrast: normal text should meet at least 4.5:1 contrast ratio. Large text should meet at least 3:1.
• Do not rely on color alone to convey information. Add text, icons or patterns as alternatives.
• Allow text resizing to 200% without loss of content or functionality.

Interaction states and motion

• Visible focus, hover and active states must be obvious and consistent.
• For animations or motion that may trigger vestibular disorders, provide a user-controlled way to reduce motion. Avoid auto-play moving content.

ARIA and scripting: when and how

• Prefer native HTML before adding WAI-ARIA. ARIA must not change semantics incorrectly.
• Use roles, states and properties correctly: role=“dialog” with aria-modal for modal dialogs; aria-hidden=“true” for purely decorative fragments removed from accessibility tree.
• Avoid role conflicts and redundant ARIA on elements that already provide semantics.

Components: tables, dialogs and custom widgets

• Tables: use caption, thead, th and proper scope attributes for complex tables.
• Dialogs and modals: trap focus inside, restore focus to the trigger when closed, and ensure keyboard controls close them.
• Custom widgets: expose keyboard interaction, relevant ARIA roles, and clear accessible names.

Automated and manual testing

Automated checks

• Run an automated scanner (for example axe or Lighthouse) early and often. They catch many low-hanging issues but not everything.

Essential manual tests

• Keyboard-only walkthrough: Tab through all interactive elements, operate them, and confirm no keyboard traps.
• Screen reader smoke test: open the page with a screen reader such as NVDA or VoiceOver and try to understand the main content and navigation.
• Colour-blindness check: view key pages in grayscale and test contrast with a tool or built-in browser inspector.
• Resize text to 200% and check layout for overlap or clipped content.

Developer–designer handoff checklist (practical)

• Design tokens: provide explicit color tokens with contrast annotations and font-size tokens for large text.
• Component specs: include accessible name examples, keyboard interaction, and focus state styles in design files.
• Content guidance: supply examples of alt text, link text and labels in the content brief.
• Acceptance criteria: require automated and manual test pass for story closure.

Prioritise fixes by impact and effort (practical)

• High impact, low effort: missing form labels, non-descriptive links, alt text, keyboard focus. Fix these first.
• High impact, higher effort: complex component ARIA, modal focus management, inaccessible custom widgets. Schedule into development sprints.
• Lower impact: cosmetic contrast in decorative elements or optional microcopy improvements. Track these for later polish.

Common developer and designer mistakes

• Using role or aria attributes to “fix” broken HTML instead of correcting the markup.
• Hiding content visually but not from assistive tech, or vice versa.
• Relying only on automated tools and skipping manual keyboard and screen-reader checks.

Final QA sign-off and continuous monitoring

• Include an accessibility checklist in pull request templates and release criteria.
• Schedule periodic audits of core journeys and newly added components.
• Collect user feedback and accessibility bug reports and feed them into prioritised sprints.

Quick printable checklist

• WCAG target set and roles assigned
• Semantic HTML and landmarks
• Keyboard navigation and visible focus
• Labels for every form control
• Descriptive link text and alt text for images
• Contrast ratios: 4.5:1 normal, 3:1 large
• Captions/transcripts for media
• ARIA used only when necessary
• Automated scan plus keyboard and screen-reader manual tests

Core standards and guidance

• WCAG (Web Content Accessibility Guidelines) versions 2.0, 2.1 and 2.2 are commonly referenced. Target a specific version and level for the project.
• Mention applicable laws or regulations early in the project, such as national accessibility laws, Section 508, or the European Accessibility Act if they apply to your product.

Keep this checklist with your design system and sprint templates. Accessibility is easier and cheaper when it is part of the workflow rather than a late-stage audit.