The Accessibility Checklist Most Teams Skip (And Regret Later)

Accessibility is the work that small and medium teams almost universally defer. It is on everyone's roadmap. It is almost never the current quarter. Then a procurement team asks for your Voluntary Product Accessibility Template, or a large customer asks for WCAG AA evidence, or a regulator in one of your markets makes noises about enforcement, and suddenly it is urgent.

The good news is that most of the wins are boring and mechanical. You do not need to restructure your app. You need to fix a short list of specific things that almost every team gets wrong.

Here is the list we work through when we audit a site for accessibility. It is not comprehensive — the WCAG 2.2 specification and the MDN accessibility guide are your reference for that. It is what actually comes up, repeatedly, in real audits.

Keyboard Navigation

The single most common serious issue: parts of the interface that only work with a mouse.

Try navigating your site with only the Tab key. Can you reach every interactive element? Can you activate them with Enter or Space? Is the focus visible at every step? Can you dismiss modal dialogs with Escape?

The fixes are usually one of:

• A <div onClick> that should be a <button>. Use the right element and keyboard support comes for free.
• A custom component that manages focus poorly. When a modal opens, focus should move into it. When it closes, focus should return to where it came from.
• Focus indicators that have been styled away. outline: none without a replacement is an accessibility bug.

WebAIM's keyboard accessibility guide is concise and practical.

Colour Contrast

The second most common issue, and the easiest to audit mechanically.

WCAG AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text. Designers often choose colours that look elegant and fail this test by a wide margin — light grey text on white, light-on-light button states, disabled states that are indistinguishable from placeholder text.

The WebAIM contrast checker will tell you in seconds whether a given pair passes. Most browser dev tools will flag failures automatically. Running an automated audit (axe, Lighthouse) will catch the majority of contrast issues without any manual work.

Brand colours that fail contrast are a design problem, not a technical one, and the conversation with the designer is easier when the conversation is "this combination fails WCAG AA" rather than "I think this is a bit hard to read".

Form Labels

Every input needs a label. Not a placeholder. A label.

The common failure modes:

• An input with only placeholder text and no <label>. Screen readers cannot announce what the field is for. The placeholder disappears when the user starts typing, so they cannot re-check.
• A label that is not programmatically associated with its input (no for attribute, no wrapping).
• Error messages that are visible but not announced to screen readers when validation fails.

The fix for the first two is one-line HTML. The fix for the third is aria-live or aria-describedby on the input, pointing at the error message container.

Alt Text on Meaningful Images

Images that convey information need alt text that describes the information. Images that are purely decorative should have an empty alt="" attribute so screen readers skip them.

The common mistake is either missing alt text entirely or writing alt text for decorative images that describes the image ("a stock photo of a handshake") rather than leaving it empty.

A quick heuristic: if the image vanished and the meaning of the page did not change, the alt text should be empty. If the meaning did change, the alt text should describe what the image was communicating.

Semantic HTML

A large fraction of accessibility issues come from using the wrong HTML element for the job. Nested <div> trees instead of landmarks. <span> elements with click handlers instead of <button>. Headings that look right visually but skip levels (<h1> followed by <h3>) or are missing entirely.

Screen readers rely on semantic structure to help users navigate. A page with no headings, or inconsistent heading levels, is harder to use with a screen reader than a page with a messy visual hierarchy is to use with sight.

The fix is mechanical: use the correct element. <main> for the main content area. <nav> for navigation. <button> for buttons. Headings in order. This costs nothing and catches a surprising amount of what fails audits.

Focus Management in Dynamic UI

Every modern app has dynamic UI that changes without a full page load — modal dialogs, slide-over panels, inline editors. These are all common accessibility failure points.

The specific issues we see:

• Opening a modal does not move focus into the modal.
• Closing a modal does not return focus to the element that opened it.
• Tab can move focus out of an open modal into the (visually hidden) background content.
• A route change does not announce itself to screen readers.

The patterns for handling these are well-established. The ARIA Authoring Practices Guide has reference implementations for most of them. In React, libraries like Radix UI and React Aria handle most of this correctly by default, which is a strong argument for using them instead of rolling your own.

Motion and Animation

Users with vestibular disorders can be made physically unwell by motion effects. Users with attention-related conditions can be distracted to the point of being unable to use the site.

The fix is simple: honour prefers-reduced-motion.

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

This one media query, added globally, means that users who have asked for less motion actually get less motion. It is a very cheap fix for a very real problem.

What to Actually Do This Week

If you have no accessibility work on your roadmap and want to move the needle quickly:

1. Run axe DevTools against your most-visited pages. Fix the automated findings.
2. Navigate your main user flow using only the keyboard. Fix what does not work.
3. Check colour contrast on your primary text, buttons, and form fields. Fix the failures.
4. Audit your forms for proper labelling. Fix the missing labels.
5. Add the reduced-motion media query.

This is maybe a week of work for a small team, and it will pass you through the majority of common audits. It will not get you to full WCAG AAA. It will get you out of the "embarrassing baseline" tier that most sites are currently in, and it will remove most of the barriers that actually stop people from using your site.

The Business Case, Briefly

Accessibility is an ethical issue first, and that is the argument we would lead with. But if you need the commercial case: public-sector procurement requires it in most markets, large enterprise customers increasingly ask for it, and the European Accessibility Act came into force in June 2025 for a broad range of products and services.

The work does not get cheaper by being deferred. It gets more expensive, because it involves retrofitting, and retrofitting is always more expensive than building it in. The same is true of Core Web Vitals work — teams that treat both as first-class concerns from the start end up in a much better place than teams that patch them in later.

---

Looking at a WCAG audit and wondering how big the project actually is? Get in touch — accessibility work is a routine part of our custom development engagements, and we can scope it honestly.