Accessibility Checklist for Developers

Use this checklist when building or updating websites, applications, components, and digital services. Accessibility should be part of development and the definition of done.

Semantic HTML and Structure

  • Use semantic HTML elements for their intended purpose.
  • Use native HTML controls whenever possible instead of recreating them with custom components.
  • Maintain a logical heading hierarchy and identify major page regions appropriately.
  • Give each page a unique, descriptive title and specify the page language.
  • Use links for navigation and buttons for actions.

Keyboard and Focus

  • Make all interactive functionality operable with a keyboard.
  • Ensure focus order follows the logical reading and interaction order.
  • Provide a clearly visible focus indicator and do not create keyboard traps.
  • Manage focus appropriately when dialogs and other interactive components open and close.
  • Make sure focused elements are not obscured by sticky content or overlays.
  • Provide a way to bypass repeated content, such as a skip link.

Forms and Controls

  • Give every form control an accessible name and programmatically associate visible labels.
  • Do not use placeholder text as the only label.
  • Clearly identify required fields and provide instructions before users need them.
  • Identify errors in text, associate errors with affected fields, and explain how to correct them.
  • Use appropriate autocomplete attributes for common personal-information fields.
  • Make sure icon-only controls have an accessible name and that accessible names include visible labels.

ARIA and Dynamic Content

  • Use ARIA only when native HTML cannot provide the needed semantics or behavior.
  • Use valid roles, states, and properties and keep states synchronized with the visual interface.
  • Do not add ARIA that conflicts with native HTML semantics.
  • Communicate important dynamic updates and status messages to assistive technology when needed.
  • Make custom widgets follow established accessible interaction patterns.

Visual, Responsive, and Multimedia

  • Meet required contrast for text and meaningful visual content and do not rely on color alone.
  • Support text resizing, browser zoom, and responsive reflow without loss of content or functionality.
  • Support portrait and landscape orientation unless a specific orientation is essential.
  • Provide accessible alternatives to complex images, charts, diagrams, and maps.
  • Make media players keyboard accessible and support captions and audio descriptions when required.
  • Give users control over moving, flashing, scrolling, or automatically updating content when required.

Testing and Definition of Done

  • Run automated accessibility testing and review the results.
  • Test complete functionality using only the keyboard.
  • Verify visible focus, logical focus order, zoom, and responsive reflow.
  • Test forms, validation, errors, dialogs, menus, and other interactive components.
  • Test critical user journeys with a screen reader or other appropriate assistive technology.
  • Document and track known accessibility defects that cannot be resolved before release.
  • Do not rely on automated testing alone.

Accessibility is a shared responsibility. Use this checklist as a practical starting point and seek additional accessibility expertise when needed.

Off