Accessibility checklist

Accessibility means people using screen readers, keyboard-only navigation, voice control or low-vision settings can actually use your site. It's also good practice generally—accessible sites tend to be cleaner, more semantic, and easier for search engines to understand too.

Semantic HTML & structure

• Real HTML elements are used for their purpose—<button> for buttons, <nav> for navigation, proper heading tags—rather than styled <div>s pretending to be interactive
• Heading levels are in a logical, unskipped order (see the SEO checklist)
• Page language is declared correctly in the HTML, and any section written in a different language declares that too
• Landmarks (header, nav, main, footer) are used so screen-reader users can jump between page regions
• Lists are marked up as actual <ul>/<ol> elements rather than visually styled paragraphs with manual bullet characters

Color & contrast

• Text has sufficient contrast against its background, meeting WCAG AA contrast guidelines at minimum
• Color is never the only way information is conveyed (for example, error states also use an icon or text label, not just red text)
• Links are distinguishable from surrounding text by more than color alone (underline, weight, or a clear visual pattern)
• Contrast has been checked in both light and dark presentations if the site supports both

Keyboard navigation

• Every interactive element—links, buttons, form fields, menus—can be reached and operated using only a keyboard
• A visible focus indicator is present when tabbing through the page (never removed with outline:none and nothing put in its place)
• Tab order follows a logical, visual reading order
• A "skip to main content" link is available for keyboard and screen-reader users to bypass repeated navigation
• Custom widgets (dropdowns, modals, carousels, tabs) trap and return focus correctly—a keyboard user can never get silently stuck or lose their place

ARIA usage

• ARIA attributes are used to add meaning that native HTML can't express—not as a first resort in place of a native element that already does the job
• Custom interactive components (custom dropdowns, tab panels, accordions) expose the correct role, state and label so assistive technology announces them correctly
• Live regions are used sparingly and only where a genuine dynamic update (a form error, a status message) needs to be announced without moving focus
• ARIA labels are checked for accuracy—a mislabeled control is often worse than an unlabeled one, since it actively misleads

Documents & downloadable content

• PDFs and other downloadable documents that carry meaningful content are checked for basic accessibility—a real heading structure, tagged reading order, and text that's actually selectable rather than a scanned image
• Where practical, important information isn't locked exclusively inside a PDF with no equivalent presented as an accessible web page
• Downloadable file type and size are indicated in the link text, so a visitor knows what they're about to open before they click

Images & media

• Every meaningful image has descriptive alt text; purely decorative images use an empty alt="" so screen readers skip them
• Video content has captions; audio content has a transcript where practical
• Content doesn't rely on autoplaying audio or video that a visitor can't easily pause or stop

Forms

• Every form field has a properly associated, visible label—not just placeholder text that disappears on input
• Error messages are specific, programmatically associated with their field, and not conveyed by color alone
• Required fields are clearly marked, not just implied
• Forms can be completed and submitted using only a keyboard
• Related fields (like a billing address) are grouped with a proper fieldset and legend where it aids understanding

Data tables

• Tables used for genuine tabular data use real <table> markup with <th> header cells, not a grid of styled divs
• Column and row headers are associated with their data cells so a screen reader can announce what each cell relates to
• Tables are never used purely for visual page layout—that's what CSS layout is for

Motion & interaction

• Content respects a visitor's reduced-motion preference for non-essential animation
• Timeouts (for forms, sessions) give users a way to extend the time if needed
• Interactive elements have touch/click targets large enough to hit reliably (see the mobile checklist)

Testing & tools

• The site has been tested using keyboard-only navigation, unplugging the mouse entirely
• An automated checker such as WAVE or axe DevTools has been run and flagged issues addressed
• At least a basic pass has been done with a screen reader to confirm the page makes sense read aloud
• Automated tools are treated as a floor, not a guarantee—they catch a meaningful minority of real accessibility issues, and manual review still matters
• Testing has been folded into the general QA & cross-browser checklist rather than treated as a one-off, separate pass

See also the mobile & responsive checklist for touch-target sizing, and the content checklist for writing clear, plain-language copy that helps every reader, not just some.