Accessible Web Design: Color Contrast, Screen Readers, and Keyboard Navigation Best Practices

The site that was beautiful in a mockup and unusable in a car park

A design studio delivered a site with a pale grey palette: light grey text on white cards, hairline borders, an elegant thin typeface, and hover states that revealed the navigation.

In the studio, on a large calibrated monitor, it looked superb. On a phone in a car park in the sun, the navigation was invisible, the grey text was illegible, and the "hover to reveal" menu was unreachable because there is no hover on a touchscreen.

Three of the most common accessibility failures, all introduced by a single aesthetic decision, none of them noticed because nobody tested where the customers actually were.

Accessible design isn't a layer of extra features. It's building the thing so it works when the conditions aren't ideal, which is most of the time.

Pillar 1: Contrast and colour

Contrast is the most commonly failed criterion and the cheapest to fix.

The actual thresholds, with the conversion people skip

WCAG 2.2 requires:

• 4.5:1 for normal text at Level AA.
• 3:1 for large text at AA. "Large" means 24 pixels, or 18.66 pixels if bold.
• 7:1 and 4.5:1 at Level AAA.

Note those numbers. Most guides repeat "18pt or 14pt bold" without converting, and because 1pt equals 1.333px, writers then apply the threshold to the wrong element. If you're checking in a browser inspector, you're measuring pixels, so use 24px and 18.66px.

Ratio is calculated from relative luminance. Black on white is 21:1. Mid grey on white often sits around 3:1, which passes for a heading and fails for a paragraph.

Where it typically fails

Placeholder text. Light grey hints inside inputs are the most common failure on the web. There's a subtlety: the contrast requirement technically exempts inactive components, and placeholder text sits in a grey area people argue about. Practically it doesn't matter, because a hint you can't read is useless, and the correct fix is a real label anyway.

Body text in a trend colour. Muted grey on off-white is the default of every modern design system, and a lot of them land just under 4.5:1.

Text over photographs. Variable backgrounds mean the ratio changes across the image. Fix with a solid scrim or a gradient, not with a text shadow.

Links distinguished only by colour. A blue link in black text fails for a reader with deuteranopia. Underline them, or add another indicator such as weight or an arrow.

Disabled buttons. Not required to meet contrast, and worth designing properly anyway. A greyed-out button at 1.5:1 tells nobody why it's unavailable. Pair the disabled state with a reason in text.

Colour blindness is not a niche

Around one man in twelve and one woman in two hundred has some form of colour vision deficiency. The rule that follows is simple: never use colour alone to carry information.

• An error field gets an icon and a message, not only a red border.
• A chart gets patterns, direct labels, or shapes, not only a legend of colours.
• A status gets a word, not a green dot.

Checking it

WebAIM's contrast checker for spot checks. A browser extension that audits a whole page is faster. The important habit is checking the pair you're actually using, not the pair the design system claims, because opacity and overlays change the effective colour.

Pillar 2: Screen readers

A screen reader converts content into speech or braille. The ones that matter are NVDA (Windows, free), JAWS (Windows, commercial), VoiceOver (Apple, built in), and TalkBack (Android). Testing with VoiceOver or NVDA covers the vast majority of real failures.

What actually breaks

Unlabelled controls. "Edit text, edit text, edit text" is the sound of a form nobody can use. The fix is a real label, associated programmatically.

Structure made of styling. If headings are bold paragraphs and lists are divs, the reader hears one long stream of text with no outline to navigate. Use the actual elements.

Wrong reading order. CSS can visually reorder content while the underlying source order stays different. A sighted user sees the phone number first; a screen reader user hears it last. Fix the source order rather than patching with tabindex.

Images with no alternative. Every meaningful image needs a description. Every decorative image needs an empty alt attribute so it's skipped. Both are decisions a person makes, and auto-generated descriptions are frequently wrong in ways that mislead.

ARIA used as a shortcut. The industry saying exists for a reason: no ARIA is better than bad ARIA. Incorrect roles actively break things that would otherwise work. Use the native element and reach for ARIA only when the native element genuinely can't do the job.

Silent changes. Content that updates without a page load (a validation message, a cart count, a chat notification) is invisible to a screen reader unless it's announced. This is what live regions are for, used sparingly: an announcement for every keystroke is worse than none.

The twenty-minute test

Turn on VoiceOver on your phone, close your eyes, and try to book something. You'll hear the real problems in the first two minutes, and they'll be different from what an automated scan found.

Pillar 3: Keyboard navigation

Some people use a keyboard because they can't use a mouse. Others use switch devices, head pointers, or voice control, which simulate keyboard input. Every one of them depends on the same handful of behaviours.

What has to work

Everything reachable. Tab through the page. Every link, button, field, and control should be reachable, in a sensible order.

Focus always visible. WCAG 2.4.7 requires an indicator, and 2.2 added 2.4.11, which requires that the focused element isn't hidden behind a sticky header, cookie banner, or chat widget. If the default outline is unattractive, design a better one; never remove it without a replacement.

No traps, and no escapes. A modal should keep focus inside it while open and return focus to the trigger when it closes. Tab should never disappear into a widget with no way out.

A skip link. First thing in the tab order: "skip to main content". It's the cheapest accessibility win available and it helps every keyboard user.

No hover-only functionality. Menus that open on hover, tooltips that contain the only explanation, buttons that appear on hover. All unusable on touch and on keyboard. Make them open on focus and on click.

Visible targets. WCAG 2.2's 2.5.8 requires a minimum target size of 24 by 24 CSS pixels. Small close buttons and tightly packed links fail.

Dragging needs an alternative. 2.5.7, new in 2.2: anything requiring a drag gesture, a slider, a sortable list, a crop tool, needs a single-pointer alternative such as buttons.

What to do first on an existing site

1. Keyboard pass on your main flow. Ten minutes. Write down what breaks.
2. Fix the contrast of your body text and placeholders. Probably a single token change.
3. Add a skip link and restore focus outlines. Twenty minutes, both.
4. Label every form field. One component, fixed once.
5. Check heading structure on the three pages that matter. One h1, logical h2s.
6. Screen reader pass on the enquiry or booking flow. The one that produces a claim if it's broken.
7. Write an accessibility statement with real known issues, not a generated one.

That list covers the majority of what a small business site actually fails, and none of it requires an enterprise budget.

Where to start

Open your site on a phone, outside, at 60 percent brightness. Then press Tab five times and see whether you can tell where you are.

A free digital presence audit on Webcheckhub includes accessibility basics in website health, alongside conversion readiness and SEO, which shows whether the failures are concentrated in one component or spread across the build. When you want the fixes implemented properly in the code, Solutions Elites handles accessible design and remediation for small businesses.