The Curb Cut: Accessibility

The sloped cut in a kerb at a crossing exists because disabled activists spent years demanding it, in some cities pouring concrete ramps themselves at night when the councils refused.

Today it's used by parents with prams, travellers with suitcases, couriers with trolleys, cyclists, people on crutches, and anyone dragging something heavy. It was designed for a minority and it turned out to serve nearly everyone — a pattern documented often enough to have a name, the curb-cut effect.

It repeats in software with unusual reliability. Captions were built for deaf viewers and are now used by everyone watching video in a quiet office or a noisy train. Voice control was built for people who couldn't use their hands and is now used by anyone whose hands are full. Keyboard navigation was built for people who can't use a mouse and is loved by power users.

Who "everyone" actually is

The WHO estimates that around 1 in 6 people worldwide live with a significant disability. That's not a rounding error in your user base; it's larger than most of the segments teams argue about.

The categories are broader than the stereotype:

• Vision — blindness, low vision, and colour vision deficiency, which affects roughly 8% of men.
• Hearing — from partial loss to deafness.
• Motor — tremor, limited reach, paralysis, pain, one-handed use.
• Cognitive — dyslexia, ADHD, memory impairment, and the vast ordinary territory of stress and tiredness.

But the framing that changes how designers think about this comes from Microsoft's inclusive design work, which splits every ability along three lines:

• Permanent — one arm.
• Temporary — a broken arm.
• Situational — holding a baby.

All three need the same one-handed design. That's the entire argument in one row: the permanent case is the extreme version of a situation everyone lands in. Design for the person with low vision and you've also designed for everyone reading in bright sunlight.

The four principles

WCAG — the international standard — is organised under four principles, mercifully memorable as POUR:

Perceivable. People must be able to sense the content. Text alternatives for images, captions for audio, sufficient contrast, no meaning carried by colour alone.

Operable. People must be able to use it. Keyboard access to everything, targets large enough to hit, no time limits that can't be extended, nothing that triggers seizures.

Understandable. Behaviour must be predictable, language plain, errors explained and recoverable.

Robust. It must work with assistive technology — which in practice means using standard, semantic elements rather than reinventing them.

WCAG has three conformance levels: A (minimum), AA (the practical and usually legal target), AAA (rarely required whole). If you remember one thing from the standard, remember "WCAG 2.2 level AA" — that's what regulations and contracts ask for.

Semantics is the interface for people who can't see it

Here's the mental shift that makes accessibility click for most designers and developers.

A screen reader doesn't see your layout. It reads your structure: headings in order, landmarks (navigation, main, footer), lists, tables with headers, buttons, links, form labels. A blind user navigates by jumping between headings and landmarks the way a sighted user's eye jumps around the page.

Which means: if your headings are chosen for size rather than level, the page has no navigable structure. If a button is a div with a click handler, it isn't announced as a button, can't be focused, and can't be activated by keyboard. If an input has no associated label, the screen reader says "edit text" and nothing else.

The corresponding rule from the ARIA specification is blunt and worth quoting: don't use ARIA if a native element will do the job. A real <button> arrives with focus, keyboard activation, the correct role and the correct announcements. A custom one starts with none of them and needs all of them re-implemented by hand.

The keyboard test

The single most valuable ten minutes you can spend: unplug your mouse and use your product.

You'll be checking four things:

Reachability. Can you get to every interactive element with Tab? Anything skipped is invisible to keyboard and screen reader users.

Visible focus. Can you always see where you are? Removing the focus outline because it "looks untidy" is among the most damaging things a designer does — if you don't like the default, replace it with something better, never with nothing.

Logical order. Does focus move in the order the content reads? Absolute positioning and modals are the usual culprits when it doesn't.

No traps. Can you get out of every component you get into? A modal that keeps focus behind it, or a widget you can enter and not leave, ends the session.

Add a skip link — "skip to main content" as the first focusable element — so keyboard users don't tab through forty navigation items on every page.

Vision, motor, cognition

Vision. Contrast at least 4.5:1 for body text and 3:1 for large text and interface components. Never carry meaning in colour alone. Support 200% text zoom without breaking, and never disable pinch zoom on mobile. Write alt text that describes the function, not the appearance — for a magnifier icon that opens search, the alt is "Search," not "magnifying glass." Decorative images get an empty alt so they're skipped rather than announced.

Motor. WCAG 2.2 requires targets of at least 24×24 CSS pixels; platform guidance recommends 44pt (Apple) or 48dp (Google). Anything that works only on hover is unavailable on touch and to many assistive technologies. Anything that requires dragging needs a non-dragging alternative — also WCAG 2.2. Time limits need a way to extend them.

Cognition. Plain language and short sentences. Navigation that stays where it was. Errors that are prevented, explained and recoverable. And respect prefers-reduced-motion: for people with vestibular disorders, large parallax and sliding transitions cause genuine nausea, not mild annoyance.

Automated tools catch about a third

WebAIM's annual survey of a million home pages consistently finds detectable WCAG failures on around 95% of them. The most common are dull and fixable: low contrast text, missing alt text, empty links, missing form labels.

Two conclusions. First, the baseline is so low that basic diligence puts you ahead of nearly everyone. Second — automated checkers find roughly a third of real problems. They can tell you the contrast is 3.9:1; they can't tell you the alt text is wrong, the focus order is nonsense, or the label says "Field 3."

A realistic routine: run the automated checker, then do the keyboard pass, then spend twenty minutes with a screen reader (VoiceOver and NVDA are both free), then zoom to 200% and look for what breaks.

It isn't extra work

Two arguments for the room where this gets deprioritised.

It's cheapest at design time. Contrast, target size, focus states, label placement, error text — every one of these is free while you're choosing it and expensive as a retrofit six months later. Accessibility done at the end is a rebuild; done in the design system, it's a default.

It's increasingly not optional. Public-sector requirements in most countries, the European Accessibility Act, and litigation under the ADA in the US all mean the question is arriving whether or not the team is interested.

And then the curb-cut argument, which is the honest one: semantic structure improves search indexing, captions get used by hearing people, keyboard access delights experts, and plain error messages reduce support load. Almost nothing here serves only the group it was built for.

Designing for the edge is how you find what everyone needed.

In practice

Unplug your mouse for ten minutes. Today. It's the fastest way to find out how your product treats a whole class of users.

Run a contrast check on your greys. Placeholder text, disabled states and secondary labels are where failures live.

Turn on a screen reader for one screen. Twenty minutes with VoiceOver or NVDA changes how you think about markup permanently.

Check your heading levels. Are they a real outline, or chosen by size? Fix the outline; style separately.

Zoom to 200% and look. Overlapping text, cut-off buttons and horizontal scrolling all show up immediately.

Add accessibility to your component library once. Focus states, target sizes, label patterns and contrast baked into shared components mean every future screen inherits them for free.

Check yourself

Close the article and answer in your own words:

1. What is the curb-cut effect and what are two software examples?
2. Explain permanent, temporary and situational with one ability as the example.
3. What are the four POUR principles and which conformance level should you target?
4. Why does a div with a click handler fail, and what's the ARIA rule about it?
5. What four things does the keyboard test check?
6. Why is removing the focus outline so damaging?
7. What share of problems do automated checkers find, and what must you do manually?

In short

• The curb-cut effect: what's built for a minority ends up serving nearly everyone. Captions, voice control and keyboard access all followed this path.
• About 1 in 6 people live with a significant disability, and every ability is permanent, temporary or situational — the same design serves all three.
• POUR: perceivable, operable, understandable, robust. Target WCAG 2.2 level AA.
• Screen readers read structure, not layout. Use real semantic elements; don't use ARIA where a native element exists.
• The keyboard test checks reachability, visible focus, logical order and no traps. Never remove focus styling without replacing it.
• Contrast 4.5:1 and 3:1, alt text describing function, targets of at least 24px, hover-free interactions, respect for reduced-motion.
• Automated tools catch roughly a third of issues; keyboard, screen reader and 200% zoom passes catch the rest.
• Built in at design time it's nearly free; retrofitted it's a rebuild — and it's increasingly a legal requirement.