Web Accessibility: A Practical Checklist

01What web accessibility means and why it matters

Accessibility (often shortened to a11y) means designing and coding so that people with different abilities can see, hear, understand and operate your content. The group is not only people with permanent disabilities: a broken wrist, glare, a slow connection or a small screen all create temporary limits.

The international reference is the WCAG guidelines from the W3C Web Accessibility Initiative, built on four principles: perceivable, operable, understandable and robust. The good news is that following them also improves SEO and code quality as a side effect; heading structure and image alt text, for example, are useful signals for Google too (we cover this in our technical SEO guide).

02Semantic HTML: most of the work

Screen readers and keyboards rely on HTML structure. A <div onclick> is a button to a mouse but just a box to a keyboard or screen reader. Pick the right element and you get focus, Enter/Space activation and role announcement for free.

<!-- Bad: not focusable, no role -->
<div class="btn" onclick="save()">Save</div>

<!-- Good -->
<button type="button" onclick="save()">Save</button>

<header>…</header>
<nav aria-label="Main">…</nav>
<main id="main">
  <h1>Page title</h1>
  <section aria-labelledby="s1"><h2 id="s1">Section</h2></section>
</main>
<footer>…</footer>

• One <h1> per page and heading levels without skipping (h2 under h1, h3 under h2).
• Links go to a URL, buttons perform an action. Do not swap them.
• Landmarks such as header, nav, main and footer let screen-reader users jump straight to the part they want.
• Add a "skip to content" link at the top of the page.

03Keyboard and focus

Many users operate only with a keyboard: blind users, assistive-technology users and people with motor impairments. The simple test is to put the mouse aside and traverse the page with Tab and Shift+Tab. Focus order must match visual order, and you must always be able to see where focus is.

/* Never remove the outline without a replacement */
:focus-visible {
  outline: 3px solid #1a73e8;
  outline-offset: 2px;
}

/* Visually hidden but available to screen readers */
.sr-only {
  position: absolute; width: 1px; height: 1px;
  margin: -1px; padding: 0; overflow: hidden;
  clip: rect(0 0 0 0); white-space: nowrap; border: 0;
}

Another common failure is modals. When one opens, focus should move into it, not escape with Tab, close on Esc and return to the opening button afterwards. The native <dialog> element with showModal() handles most of this for you.

04Colour, contrast and text

At WCAG level AA, normal text should have a contrast ratio of at least 4.5:1 against its background, and large text (about 18pt, or 14pt bold) 3:1. Light grey on white is the most common place this is missed. The contrast checker built into browser DevTools measures it in seconds.

• Never convey information by colour alone; for errors add an icon and text, not just red.
• Size text in relative units (rem) so it scales with browser settings, and make sure the page works at 200% zoom without breaking.
• Touch targets should be roughly 44 by 44 pixels or larger, with enough spacing.
• Tone animations down with prefers-reduced-motion; see CSS and JavaScript animations for details.

05Images, forms and ARIA

Image alternative text

Every meaningful image needs an alt that states its purpose, not only its appearance. Decorative images should have alt="" so screen readers skip them. Skip phrases like "image of"; the screen reader already announces that it is an image.

Form labels and errors

Every field needs a real <label>; a placeholder is not a substitute because it vanishes when typing starts. Connect the error message to the field with aria-describedby.

<label for="email">Email</label>
<input id="email" type="email" name="email"
       autocomplete="email" required
       aria-invalid="true" aria-describedby="email-err">
<p id="email-err" role="alert">Enter a valid email, e.g. [email protected]</p>

ARIA only when needed

The first rule of ARIA is: if a native HTML element does the job, do not use ARIA. ARIA only tells assistive technology what something means; it adds no behaviour, so a role="button" still does not handle Enter on its own. For complex widgets such as tabs and menus, follow the documented patterns in MDN's accessibility docs.

06Quick testing without expensive tools

Automated tools such as Lighthouse and axe catch part of the problems, but judging whether an experience is usable needs a manual test. This order works for a ten-minute review:

1. Run an automated scan with Lighthouse or the axe extension and fix the obvious errors.
2. Walk the whole page by keyboard: is everything reachable, and is focus visible?
3. Zoom to 200% and view at 320px wide; does anything clip or overlap?
4. Listen with a screen reader (NVDA on Windows, VoiceOver on Mac and iOS) for the main flow, such as sign-up or checkout.
5. Check contrast, error states and loading states.

If you would like an expert look at your current site, reach out via the contact page. On new projects we build these checks into component design from the start, because fixing later is always more expensive.