HTML Accessibility Checklist
Accessible HTML helps people use webpages with keyboards, screen readers, magnification software, voice controls, and other assistive technologies.
This checklist covers common accessibility considerations when creating and reviewing HTML webpages. Accessibility involves more than HTML alone, but using appropriate HTML elements and document structure provides an important foundation.
Document Structure
A well-structured HTML document gives browsers and assistive technologies useful information about the page and its content.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Include a valid <!doctype html> declaration. |
| ✓ | Set the primary language of the document with the lang attribute on the <html> element. |
| ✓ | Provide a descriptive and meaningful <title> for each page. |
| ✓ | Use semantic HTML elements when they accurately describe the purpose of the content. |
| ✓ | Keep the DOM and reading order logical so content makes sense when read sequentially. |
Headings
Headings organize content into sections and help users understand and navigate the structure of a page.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Use heading elements <h1> through <h6> to identify headings rather than using visual styling alone. |
| ✓ | Organize headings into a logical hierarchy that reflects the structure of the content. |
| ✓ | Make heading text descriptive of the content that follows. |
| ✓ | Do not choose a heading level simply because of its default visual size. |
Page Landmarks
Semantic sectioning elements can identify major areas of a page and provide useful landmarks for assistive technology users.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Use <header>, <nav>, <main>, <aside>, and <footer> where their semantics match the content. |
| ✓ | Provide one primary <main> landmark for the main content of the page. |
| ✓ | Give repeated landmarks, such as multiple navigation regions, accessible names when users need to distinguish between them. |
| ✓ | Provide a way for keyboard users to bypass repeated navigation and reach the main content, such as a skip link. |
Links
Links should clearly communicate their purpose and remain understandable when encountered without surrounding text.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Use meaningful link text that describes the link's destination or purpose. |
| ✓ | Avoid vague link text such as "click here" when more descriptive wording can be used. |
| ✓ | Use the <a> element with an href for navigation rather than non-link elements made to behave like links. |
| ✓ | Make links visually distinguishable from surrounding text and provide a visible keyboard focus indicator. |
| ✓ | Indicate unusual behavior, such as downloading a file or opening a new window, when users would benefit from knowing in advance. |
Images & Alternative Text
Images need appropriate text alternatives so their purpose or information is available when the image cannot be seen.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Provide meaningful alt text for informative images. |
| ✓ | Use an empty alt="" for decorative images that do not communicate information. |
| ✓ | Describe the purpose of an image used as a link or control rather than describing only its appearance. |
| ✓ | Provide the important information from complex images, charts, or diagrams in an accessible text form. |
| ✓ | Avoid placing essential text inside images when normal HTML text can be used instead. |
Forms
Form controls should have clear labels, instructions, and error information so users can understand what information is required and how to provide it.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Associate each form control with an appropriate <label> whenever the control requires a visible label. |
| ✓ | Use <fieldset> and <legend> for related groups of controls when the grouping needs a shared label. |
| ✓ | Clearly identify required fields and do not rely only on color to indicate that they are required. |
| ✓ | Provide understandable instructions for fields that require a particular format or type of information. |
| ✓ | Identify validation errors in text and associate error information with the affected control when appropriate. |
| ✓ | Do not use placeholder text as a replacement for a necessary form label. |
| ✓ | Use appropriate autocomplete values for fields that collect common user information when applicable. |
Tables
Data tables should identify the relationships between headers and data cells so tabular information can be understood by assistive technologies.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Use tables for tabular data rather than page layout. |
| ✓ | Use <th> elements for row and column headers. |
| ✓ | Use the scope attribute when it helps identify whether a header applies to a row or column. |
| ✓ | Provide a <caption> when the table needs a visible title or description of its purpose. |
| ✓ | For complex tables, ensure relationships between headers and data cells can be determined programmatically. |
Keyboard Accessibility
Interactive content should be usable without requiring a mouse or other pointing device.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Make all interactive functionality operable with a keyboard. |
| ✓ | Use native interactive elements such as <a>, <button>, <input>, and <select> when appropriate. |
| ✓ | Provide a clearly visible focus indicator for keyboard users. |
| ✓ | Keep keyboard focus order logical and consistent with the content order. |
| ✓ | Avoid positive tabindex values that create an artificial tab order. |
| ✓ | Ensure keyboard focus does not become trapped in a component unless the component requires temporary focus containment and provides a way to exit. |
Color & Contrast
Text and important interface components need sufficient visual contrast, and information should not depend on color alone.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Provide sufficient contrast between text and its background. |
| ✓ | Do not use color as the only way to communicate meaning, status, or instructions. |
| ✓ | Ensure links can be distinguished from surrounding text without depending only on a subtle color difference. |
| ✓ | Make focus indicators and important user-interface boundaries sufficiently visible against adjacent colors. |
Audio & Video
Multimedia content should provide alternatives that make important audio and visual information available to users who cannot perceive it directly.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Provide synchronized captions for prerecorded video containing meaningful audio. |
| ✓ | Provide a transcript or other appropriate text alternative for audio-only content. |
| ✓ | Provide audio descriptions or another appropriate alternative when important visual information is not available through the audio track. |
| ✓ | Provide accessible controls for starting, stopping, pausing, and adjusting media when those controls are needed. |
| ✓ | Avoid automatically playing audio when possible, particularly when users cannot easily stop or control it. |
ARIA
ARIA can provide additional accessibility information when native HTML cannot fully describe a custom interface or dynamic component.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Use native HTML semantics before adding ARIA whenever native elements provide the required functionality. |
| ✓ | Use ARIA roles, states, and properties only where they are valid and appropriate. |
| ✓ | Keep ARIA states such as aria-expanded and aria-checked synchronized with the actual interface state. |
| ✓ | Provide accessible names for controls when native text or labeling does not already provide them. |
| ✓ | Remember that ARIA does not automatically add keyboard interaction or functionality to an element. |
Page Content
Accessible content should be understandable, predictable, and usable at different text sizes and viewport dimensions.
| Check | Accessibility Guideline |
|---|---|
| ✓ | Use clear and descriptive page titles, headings, labels, and instructions. |
| ✓ | Identify changes in the human language of passages when necessary with the lang attribute. |
| ✓ | Do not rely solely on visual position, shape, size, or color when giving instructions. |
| ✓ | Allow text to be resized without losing important content or functionality. |
| ✓ | Design content so it remains usable when the viewport is enlarged, reduced, or reflowed. |
Accessibility Testing
Automated testing can identify many accessibility problems, but it cannot determine whether every page or interaction is understandable and usable. Manual testing is also important.
| Check | Testing Method |
|---|---|
| ✓ | Navigate the entire page using only the keyboard. |
| ✓ | Check that keyboard focus is visible and follows a logical order. |
| ✓ | Review headings, landmarks, links, form labels, and image alternatives. |
| ✓ | Test important pages and interactions with a screen reader when possible. |
| ✓ | Check text and interface color contrast. |
| ✓ | Zoom and resize the page to check whether content remains readable and usable. |
| ✓ | Use automated accessibility testing as one part of the review process rather than as the only test. |
