The website accessibility checklist: 44 checks you can do yourself

Run these checks on four pages: your home page, a typical content page, a page with a form, and your most important transaction. You need a browser, a keyboard, and the free tools named along the way. Each check lists the WCAG 2.2 criterion it relates to.

Page structure

• Each page has a unique, descriptive title that says what the page is and which site it's on (2.4.2).
• The page language is set — <html lang="en"> — so screen readers use the right pronunciation (3.1.1).
• There's exactly one H1, and headings follow a logical outline without skipping levels to look smaller (1.3.1, 2.4.6).
• Landmarks are used: header, nav, main and footer, so screen reader users can jump between regions (1.3.1).
• A "Skip to main content" link appears when you press Tab on a fresh page load (2.4.1).
• Lists are real lists and tables of data are real tables with header cells (1.3.1).
• Navigation is consistent across pages, and help links are in the same place everywhere (3.2.3, 3.2.6).

Images and media

• Every meaningful image has alt text that conveys its purpose, not "image" or the file name (1.1.1). See our alt text guide.
• Decorative images have empty alt (alt="") so screen readers skip them (1.1.1).
• Icon-only buttons and links have an accessible name — a search magnifier is announced as "Search," not "button" (1.1.1, 4.1.2).
• Charts and infographics have a text equivalent nearby or linked (1.1.1).
• Videos have accurate captions, not unedited automatic ones (1.2.2).
• Prerecorded videos have audio description or a descriptive transcript when visuals carry information that isn't spoken (1.2.5).
• Nothing plays automatically for more than five seconds without a pause or stop control (1.4.2, 2.2.2).
• Nothing flashes more than three times per second (2.3.1).

Keyboard

Put your mouse away for this section. Use Tab, Shift+Tab, Enter, Space, arrow keys and Esc.

• Every link, button, field and control can be reached and used with the keyboard alone (2.1.1).
• You can always see where focus is — a clear outline or highlight, never removed (2.4.7).
• Focus is never hidden behind a sticky header, cookie banner or chat widget (2.4.11).
• Focus order makes sense, following the visual reading order (2.4.3).
• You never get stuck — you can Tab out of every widget, embedded video and map (2.1.2).
• Menus, modals and accordions work with the keyboard, and Esc closes pop-ups and returns focus to where you were (2.1.1, 2.4.3).
• Single-key shortcuts can be turned off or remapped (2.1.4).

Forms

• Every field has a visible label that stays visible while typing — placeholder text is not a label (1.3.1, 3.3.2).
• Labels are programmatically connected to their fields: clicking the label puts the cursor in the field (1.3.1, 4.1.2).
• Required fields are identified in text, not only by color or an unexplained asterisk (3.3.2).
• Errors are described in words, next to the field and announced to screen readers, with a suggestion for fixing them (3.3.1, 3.3.3).
• Common personal fields use autocomplete (name, email, address) so browsers can fill them (1.3.5).
• Login doesn't require a memory or transcription test without an alternative; password managers and paste work (3.3.8).
• Users aren't asked for the same information twice in one process (3.3.7).
• Legal, financial or data submissions can be reviewed, corrected or reversed (3.3.4).

See designing accessible forms for code examples.

Color, text and layout

• Text contrast is at least 4.5:1 (3:1 for large text) against its background (1.4.3). See our contrast guide.
• Buttons, field borders, icons and focus indicators have at least 3:1 contrast (1.4.11).
• Color is never the only signal — errors, required fields, links in text and chart lines also use text, icons or patterns (1.4.1).
• At 200% browser zoom, nothing is cut off or overlapping (1.4.4).
• At 400% zoom (or a 320px-wide window), content reflows into one column without horizontal scrolling (1.4.10).
• Increasing letter, word and line spacing doesn't break the layout (1.4.12).
• Tooltips and pop-ups on hover can be dismissed and don't vanish when you move the mouse onto them (1.4.13).
• Click and tap targets are at least 24×24 pixels or well spaced (2.5.8).

Behavior and content

• Links make sense out of context — no bare "click here" or "read more" without context (2.4.4).
• Nothing changes unexpectedly when a field gets focus or a value changes, such as auto-submitting forms (3.2.1, 3.2.2).
• Time limits can be extended, and users are warned before a session expires (2.2.1).
• Status messages are announced — "Added to cart" or "5 results found" — without moving focus (4.1.3).
• Anything done by dragging can also be done with simple clicks (2.5.7).
• Linked PDFs and documents are accessible too. Follow our accessible PDF guide.

What to do with the results

Log each failure with the page, the element and the criterion number. Fix shared components first — one fix to the header or a form field component can solve the issue across the whole site. Then test with a screen reader, because that’s where the subtle problems surface.

If you find more failures than you can fix in-house, or you need documented evidence of conformance, an independent audit is the next step.