WCAG 2.1 AA Checklist for Websites (Practical Guide)

WCAG 2.1 AA is the accessibility standard referenced by EN 301 549 and, through it, by the European Accessibility Act. It's organised around four principles — perceivable, operable, understandable, robust — each with specific, testable success criteria. This checklist walks through the ones that matter most for a typical commercial website, and how to check each one without specialist tools.

If you haven't already, it's worth reading what "accessible" means under the EAA and how EN 301 549 relates to WCAG before working through this list, so you understand why each item matters legally, not just technically.

Perceivable

Content and interface elements must be presented in a way users can perceive, regardless of sensory ability.

• Colour contrast — body text needs a contrast ratio of at least 4.5:1 against its background; large text (roughly 18pt+, or 14pt+ bold) needs at least 3:1. Check with a contrast checker on your actual rendered colours, not the design file.
• Alt text on images — every informative image needs a concise alt attribute describing its purpose, not just its content ("Q3 revenue chart showing 12% growth" rather than "chart.png"). Purely decorative images should have empty alt="" so screen readers skip them.
• Don't rely on colour alone — form errors, required fields, and status indicators need a text label or icon in addition to colour, since colour-blind users and screen reader users won't perceive colour differences.
• Captions and transcripts — any video with audio needs captions; audio-only content needs a transcript.
• Resizable text — text should remain readable and functional at 200% browser zoom without breaking layout.

Operable

Everything a user can do with a mouse must also be possible with a keyboard alone.

• Full keyboard access — tab through your entire page. Every link, button, form field, and custom widget (dropdowns, modals, date pickers) must be reachable and operable without a mouse.
• Visible focus indicator — as you tab, there should be a clearly visible outline or highlight showing which element currently has focus. Removing the default focus outline and not replacing it is one of the most common WCAG failures.
• No keyboard traps — a user must always be able to tab out of a component, such as a modal, the same way they tabbed in.
• Skip link — a "skip to main content" link, usable at the very start of tab order, saves keyboard and screen reader users from tabbing through the entire navigation on every page.
• No content that flashes more than three times per second, which can trigger seizures.
• Sufficient time — if a session or form has a time limit, users need a way to extend it.

Understandable

Content and interface behaviour need to be predictable and clear.

• Descriptive labels — form fields need real, programmatically-associated <label> elements, not just placeholder text (placeholders disappear once a user starts typing, and many screen readers handle them inconsistently).
• Clear error messages — when a form submission fails, tell the user which field is wrong and how to fix it, in text near the field, not just a colour change.
• Consistent navigation — the same navigation and identification patterns should behave the same way across your site.
• No unexpected context changes — moving focus to a field or making a selection shouldn't silently open a new page or submit a form.
• Language declared — set lang="en" (or the relevant language) on the <html> element so screen readers use the correct pronunciation rules.

Robust

Content must work reliably across current and future browsers, and with assistive technology.

• Valid, semantic HTML — use real <button>, <nav>, <main>, and heading elements instead of styled <div>s standing in for interactive controls.
• Correct heading hierarchy — one <h1> per page, with <h2>/<h3> nested logically underneath; screen reader users frequently navigate by jumping between headings.
• ARIA used correctly, not as a first resort — only add ARIA attributes where native HTML can't do the job, and keep aria-* attributes in sync with actual state, such as aria-expanded on a dropdown.
• Name, role, value exposed for every custom UI component, so assistive technology can announce what it is and what state it's in.

How to test (manual + automated)

Automated tools catch roughly a third to half of WCAG issues reliably — the rest need a human.

Automated first pass:

• Run an automated scanner across your key pages: home, product or category, checkout, account, and contact. Accessvera's free scan checks these against WCAG 2.1 AA and EN 301 549 and returns a prioritised issue list in about 30 seconds.
• Automated tools are reliable for contrast ratios, missing alt text, missing form labels, and invalid HTML — but they can't judge whether alt text is meaningful or whether a tab order makes sense.

Manual checks that matter:

• Unplug your mouse and navigate your checkout flow using only Tab, Shift+Tab, and Enter.
• Turn on a screen reader — VoiceOver on Mac, NVDA on Windows, both free — and listen to your homepage and one core flow.
• Zoom your browser to 200% and check nothing breaks or gets clipped.
• Review every form for a real <label> and a clear, text-based error message.

For a repeatable process that combines both, see how to check if your website is EAA compliant — it walks through prioritising and documenting fixes so you have a defensible conformance record, not just a one-off scan.