Most teams first hear about their accessibility problems not from an audit but from an email: someone could not finish an order because they could not tell which field held the error, or could not dismiss a modal without a mouse. Accessibility is not a separate mode for a separate audience — it tests whether the interface survives any deviation from the ideal scenario. What follows is the baseline we treat as non-negotiable on every project: contrast, keyboard, focus, semantics and alt text. No academic retelling of WCAG — just the numbers and the order to fix things in.

Who this actually affects

Framing accessibility as "something blind users need" shrinks the problem roughly tenfold. Permanent impairments — vision, hearing, motor control, attention — are only part of it. The rest is temporary or situational, and every one of your customers has been there.

• Sunlight on the screen. A 3:1 contrast that looked elegant in a dark studio is an empty rectangle outdoors.
• One hand occupied. Someone holding a child or a handrail thumbs at the screen — and misses a 20×20 pixel button.
• Sound off. Nobody in an open-plan office or on a train watches a video without captions.
• Keyboard instead of mouse. Not only people with motor impairments, but anyone filling a form with Tab — and every automated test you will ever write.
• Weak network, old phone. An interface that exists purely in JavaScript does not work when only part of it loads — see our piece on mobile-first design.

The formal target is WCAG 2.2 level AA. Level A is too permissive — it tolerates text sitting at the edge of legibility. AAA is close to unreachable on a commercial site and rarely worth chasing. AA is the threshold you can hit without rewriting the product, and the one most regulations point at.

Contrast and colour: the cheapest win available

Contrast is the one part of accessibility you can measure as a number and fix in a day, which is why it comes first. The rule is short: 4.5:1 for regular text, 3:1 for large text (from 24px, or 19px bold), and 3:1 for anything non-textual that carries meaning — icons, input borders, focus indicators.

A note for brands: test contrast while the palette is being chosen, not after the design is signed off. A brand colour that fails 4.5:1 against white either gets a darkened variant for text, or stays reserved for large areas and graphics — more on that in our piece on choosing brand colours.

Keyboard, focus and target sizes

One trial settles it: open your own site, push the mouse aside, and try to reach checkout using only Tab, Enter, Space and the arrow keys. Most sites break by the third step — the focus highlight vanishes, a modal will not close, or a dropdown opens on hover only.

/* Never do this: it removes focus for everyone not using a mouse */
*:focus { outline: none; }

/* Do this instead: a visible ring, keyboard navigation only */
:focus-visible {
  outline: 3px solid #0097b2;
  outline-offset: 2px;
  border-radius: 4px;
}

/* Respect the system-level reduced motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

• Tab order must match visual order. A block moved with CSS but left last in the markup makes focus jump around. Positive tabindex values make this worse — use only 0 and -1.
• A "skip to main content" link as the first element on the page. With a 25-item menu that saves 25 keystrokes on every page.
• Modals trap focus deliberately, close on Esc, and return focus to the control that opened them.
• Hover can never be the only interaction. A menu that opens on hover alone is unreachable by touch and by keyboard.
• Targets start at 24×24 pixels under WCAG 2.2 — in practice aim for 44×44. Expand the hit area with a pseudo-element rather than inflating the icon.

Semantics, alt text and forms

A screen reader does not see the design — it reads the markup. A div with a click handler therefore does not exist as a button: unreachable by keyboard, deaf to Enter, announcing no role. This is the most common structural failure, and one tag fixes it.

<!-- Unreachable by keyboard, announced as nothing -->
<div class="btn" onclick="submit()">Send</div>

<!-- Works out of the box: focus, Enter, Space, button role -->
<button type="submit">Send</button>

<!-- An icon-only control needs an accessible name -->
<button type="button" aria-label="Close dialog">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Alt text deserves its own note, because it is written badly more often than anything else. Good alt describes the purpose of the image in that position, not its contents: for a header logo, the company name; for a product photo, the product plus its key attribute; for an icon inside a labelled button, nothing at all. Do not begin with "image of" — the element type is announced anyway. And do not stuff keywords there; that stopped working fifteen years ago.

How to test, and why overlay widgets do not work

Order matters here. Automated scanners look for what can be formalised, and in our experience catch roughly a third of real problems. They find contrast failures and missing alt attributes. They do not find meaningless alt text, an illogical focus order, or a form that cannot be completed from the keyboard.

1. 1

   A keyboard-only run

   Home page to order confirmation without touching the mouse. The cheapest test there is, and the one that finds most. Repeat it whenever a new page template ships.

2. 2

   An automated scan

   Lighthouse or the axe DevTools extension: ten minutes per template, catching contrast, unlabelled buttons, duplicate id values and broken heading hierarchies.

3. 3

   Zoom and narrow viewport

   Zoom to 200%, then check at 320 pixels wide. Text that clips or forces horizontal scrolling is a failure — and a direct hit to mobile conversion.

4. 4

   A quick screen reader pass

   VoiceOver on macOS opens with Cmd+F5; NVDA on Windows is free. Listen through the home page and one service page: headings, links, the form. Twenty minutes teaches more than any checklist.

5. 5

   Guard against regression

   Accessibility rarely breaks at launch — it breaks six months of edits later. Fold the keyboard run and a contrast check into routine maintenance.

Frequently asked questions about website accessibility

In short

• Aim at WCAG 2.2 level AA: 4.5:1 for text, 3:1 for large text and interface elements, targets from 24 pixels up.
• Start with contrast and :focus-visible — one day of work for the biggest return per hour.
• Use real button, label and ordered headings. Most accessibility problems are missing semantics, not hard technology.
• Scanners catch about a third of issues. A keyboard-only run and twenty minutes with a screen reader find the rest.
• Overlay widgets do not make a site accessible. Fix the markup instead of masking it.