Accessibility Is a Feature, Not a Checklist

When did accessibility first come up in your last project? For most teams I've worked with, the answer is a sprint number, and it's never sprint one. It shows up late, as a list of things to verify before launch, usually owned by whoever drew the short straw. Contrast ratios. Alt text. Focus states. Tick, tick, tick, ship.

That's the whole problem, and it isn't the checklist's fault. A checklist is a fine way to verify something. It's a terrible way to design something. When accessibility only exists as a list you run at the end, you've already decided it's a cost to minimize rather than a feature to build. And the thing about treating a feature as a cost is that it always loses the argument, every time, to anything the team decided to build on purpose.

So let me make the opposite case. Accessibility is a feature. Designed in from the start, it makes the product better for people who have no disability at all, and the evidence for that is sitting in plain sight.

The curb-cut effect is not a nice story, it's the default outcome

You've heard the curb-cut story: ramps cut into sidewalks for wheelchair users turned out to help everyone with a stroller, a suitcase, a delivery cart. People tell it like a happy accident. It isn't an accident. It's what happens almost every time you solve a problem at the hard edge instead of the comfortable middle.

Captions are the cleanest modern version. Stagetext, drawing on Ofcom data, found that of the roughly 7.5 million people in the UK who use TV subtitles, only about 1.5 million are deaf or hard of hearing (Stagetext / YouGov). The other 80% turned them on for other reasons: noisy rooms, quiet babies, a second language, mumbled dialogue, watching with the sound off. A feature built for a specific group became the default for a huge one. Nobody designing captions as a last-minute compliance item would have predicted that, because compliance thinking stops the moment the box is ticked. Feature thinking keeps going and asks who else this helps.

This is the argument I keep coming back to in the case for inclusive design as something broader than compliance: when you design for the edge, the middle comes along for free. When you design for the middle and bolt on the edge, you usually get neither.

The checklist approach isn't even working on its own terms

Here's the uncomfortable part for anyone who thinks the checklist is at least getting the basics done. It isn't. WebAIM's 2026 scan of the top million home pages found low-contrast text, the single most common failure, on 83.9% of them, up from 79.1% a year earlier, and it has been the number-one problem seven years running (WebAIM Million, 2026). Contrast is the most checklist-able item on the entire list. It's a number. A machine can catch it. And we're getting worse at it, not better.

That's what a decade of checklist culture buys you: the easiest possible item, failing on four out of five of the most-visited pages on the internet. The list didn't fail because it was wrong. It failed because running a list at the end is not the same as caring about the outcome, and users feel the difference immediately. I've written before about getting contrast and legibility genuinely right across light and dark modes, and the posts that stick with people aren't the ones that recite the ratios. They're the ones that treat legibility as something you design toward, not something you measure after.

There's also a deadline now, which is the wrong reason to care but a real one

As of November 2026, the European Accessibility Act has been in force for over a year (it applied from June 28, 2025), and enforcement across EU member states is ramping rather than theoretical. Plenty of teams are discovering that their products sell into the EU and their checklist is now a legal exposure, not just a QA step.

I'm genuinely glad the pressure exists, and I also think it's the wrong primary motivation. If the only reason you make something accessible is that a regulator might fine you, you'll do the minimum, late, grudgingly, and you'll get exactly the 83.9% outcome above. Build it because it's a better product and you clear the legal bar on the way past it, without the bar ever being the point.

What "treat it as a feature" actually means in practice

It's less about new skills and more about when accessibility enters the conversation. A feature gets a spot in the kickoff, a line in the spec, a place in the design review, and an owner who isn't the person who lost a coin toss. It gets considered when you're choosing the color palette, not after it's locked. It shows up in the component, so every team that uses the component inherits it, which is the quiet reason design systems are the highest-leverage accessibility tool most companies already own and underuse.

I got into this properly building the EqualWeb accessibility widget, and the lesson that stuck wasn't any specific WCAG criterion. It was that accessibility bolted onto a finished product is always a worse version of accessibility designed into an unfinished one. The retrofit can only paper over decisions that were made without it in the room. If you want the real thing, and the curb-cut upside that comes with it, it has to be in the room when the decisions get made.

If you're new to this, the foundations of inclusive design are a good place to start, and none of them require you to be an expert. They require you to stop treating the people at the edges as an afterthought.

So go back to that first question. When does accessibility come up in your next project? If the honest answer is still "near the end, on a list," you don't have an accessibility problem. You have a feature you've decided not to build. Move it to sprint one and watch what it does for everyone else.