W3C — Web Content Accessibility Guidelines (WCAG) 2.2
W3C WAI — WCAG 2 Overview
W3C WAI — The Business Case for Digital Accessibility
WHO — Disability and Health
European Commission — European Accessibility Act
Microsoft Inclusive Design
WebAIM — The WebAIM Million
Google web.dev — Learn Accessibility
When accessibility comes up, a lot of teams first care about it because of one word: “pass.” It has to pass a standard, pass a requirement, pass a checklist, pass the law, or pass an audit before the work ships.
And honestly, that's not wrong at all. Compliance is a great starting point, because it at least gives a team a frame, a standard, and enough of a reason to take accessibility seriously.
But if we treat accessibility as only a box to tick, we may miss something more valuable. It isn't just a matter for “some people,” and it isn't just about “following the rules.” It's a way of designing that asks us, from the very start:
“Who might be needlessly shut out of this experience?”
The question looks simple, but in real design work it changes how we see a product a lot. Instead of only asking “does this screen look good?”, we start asking: is it easy to read, can it actually be tapped, if you can't use a mouse can you still get through, if you can't understand the error can you fix it yourself — and in bright light, on a slow connection, with your hands full, or with tired eyes, does this experience still work well?
Once we ask these questions early, accessibility stops being an end-of-project task and becomes part of product quality.
Accessibility isn't just compliance — it's product quality
Compliance gives us a solid base. WCAG, for example, sets out four core principles of accessibility — often called POUR. In plain language: users must be able to perceive the content, operate it, understand it, and the system must be robust enough to support a range of technologies appropriately (W3C WCAG 2.2 / W3C WAI WCAG Overview).
Perceivable — content and UI must be seen / heard / sensed: enough contrast, alt text, captions.
Operable — everything should be tappable / focusable / passable, by mouse, keyboard, or touch.
Understandable — labels, flow, and errors must be easy to grasp and predictable, never confusing.
Robust — the structure must be solid enough for assistive technology like screen readers to read correctly.
Translated into design terms, it's all very close to home: is the text legible, is contrast enough, do buttons have a focus state, do forms have clear labels, does the error message say how to fix it, do meaningful images have alt text, can you get through with a keyboard, and is the content structure good enough for a screen reader to make sense of?
None of this is just a “requirement” — it's the baseline quality of the experience. An accessible product doesn't only mean a good audit score; it means real users aren't left behind along the way.
This is where compliance and UX differ slightly. Compliance can tell us which criteria we pass, but UX has to ask further: did the user actually finish their task, did they understand, were they confident, did they know what to do next, and if they slipped, did the system help them recover? Because even if a screen passes the checklist, if people still struggle to use it, it still isn't a good experience.
Accessibility affects more people than we think
Many still think accessibility is only about permanent disabilities — users who can't see, can't hear, or can't move easily. That group matters a great deal and should never be overlooked. The WHO notes that around 1.3 billion people — roughly 16% of the world's population — live with a significant disability (WHO — Disability and Health).
But accessibility also reaches temporary and situational limits. On some days we may have no permanent disability, yet still hit a situation that makes a product harder to use.
PermanentPermanent
Low vision, one usable hand, hard of hearing — a limit that's always with the user.
TemporaryTemporary
Tired eyes after a long day, a hurt arm so only one hand works, a noisy place so you can't use sound.
SituationalSituational
Looking at a screen in bright sun, one hand holding something, a slow connection, filling a form on the move.
Limits aren't only permanent — one hand busy, tired eyes, harsh light, or being in a hurry can make things harder to use too.
Microsoft Inclusive Design has a lovely idea: when we design to help one group's limitation, that often helps many other groups in other situations too (Microsoft Inclusive Design).
“Solve for one, extend to many.”
— Microsoft Inclusive Design
A simple example is video captions. They help people who can't hear — but also people in a noisy place, people who don't have sound on, people who read a language better than they hear it, and anyone scanning content quickly. Or a button that's easier to tap: it helps people with motor limitations, but also every mobile user, people in a hurry, people using one hand, and it cuts mis-taps overall.
So accessibility isn't about designing a “separate” experience for some people — it's about making the main experience more flexible and friendlier to real life.
From “make it pass” to “make it work better”
With a compliance mindset, we tend to meet accessibility at the end of the project — checking contrast just before handoff, asking about focus states just before dev, adding alt text just before launch, or fixing errors one by one after an audit. The result is that accessibility becomes rework, not design.
An accessibility-first mindset starts much earlier — when choosing colours in the design system, setting the type scale, writing button labels, laying out a form's flow, designing error states, thinking about how a modal opens, closes, and returns focus, all the way to asking whether a component can be used with a keyboard.
It doesn't mean a designer has to know as much as an accessibility specialist, and it doesn't mean the project has to be perfect from day one. It means we don't leave accessibility as the team's very last concern — because many things, thought through up front, add almost no time: picking a colour pair that passes contrast from the start, writing an error message that says how to fix things from the start, or building a focus state into a component from the start. Leave it to the end and you may have to go back and fix the design, the component, the frontend logic, or the whole flow.
How accessibility becomes a competitive advantage
“Competitive advantage” can sound very business, but in product terms it's simpler than that: a product that's easier to use, easier to understand, supports more people, and lets them finish faster is more likely to get chosen.
Wider market reach — you don't needlessly shut out groups of users. W3C WAI frames the business case around innovation, brand, market reach and reduced legal risk — not just compliance (W3C WAI Business Case).
Less friction in key flows — sign-up, forms, payment, search, contacting support. What makes accessibility better is usually the same thing that makes UX better.
More trust — a brand that cares about these details feels considered, especially for public services, finance, healthcare, or education.
A stronger design system — accessibility forces you to think through every state, so components aren't just pretty but behave clearly, reuse well, and are easier for dev to build on.
Lower cost of fixing later — start early and, even if it's not perfect, you greatly cut the odds of a giant rework at the end.
Put simply, accessibility isn't traded against other qualities — more often it moves in the same direction as conversion, adoption, support cost, and rework.
The small details that make UX better
What I love about accessibility is that it brings us back to the small details design sometimes skips over.
Contrast, typography, icons, tiny labels — details that look small but decide whether people can keep going.
Contrast — a colour that looks beautiful in a mockup can be very hard to read on a real screen, especially a phone in bright light. Checking contrast doesn't make a brand boring; it makes that beauty actually usable.
Font size and line height — text that's too small may look minimal in the design, but for a long article or important information it tires readers fast. Good typography isn't just aesthetics — it's care.
Error message — a line like “Invalid input” may be technically correct, but it doesn't help the user at all.
Before
“Invalid input”
Better
“Please enter a 10-digit phone number” — the user knows exactly what to fix
Keyboard navigation — many think keyboard support is only an accessibility thing, but power users rely on the keyboard to work faster, especially in back-office systems, dashboards, or enterprise software. And clear form labels help both screen-reader users and everyone else who faces long forms with many fields.
When we design these things better, the whole experience gets lighter: users guess less, slip less, and feel more confident.
Doing it later usually costs more
In real work, many teams don't dislike accessibility — they're just “out of time.” The problem is that if you wait for time at the end, it usually becomes more expensive, because accessibility doesn't live only in colours or fonts; it lives in the product's structure.
States are a good example. If at first you only design the default look, you'll later find you're still missing several states the user will actually face.
defaulthoverfocusactivedisabledloadingerror
If a form wasn't designed for error states from the start, if a modal didn't consider focus management, if the design system has no focus state, if components use div instead of button everywhere, if the content hierarchy isn't clear, or if a flow forces the user down one path only — then when it's time to fix, it's not one screen but a pattern reused across the whole system.
That's why accessibility-first doesn't mean everything has to be perfect on day one — it means we should lay the foundation in the right direction from the start, especially in the design system or component library. If the base pattern is good, the work that follows gets better with it.
If the team isn't ready, where can you start?
Accessibility can look huge if you stare at the whole system at once, but in practice you can start small. Begin by setting a baseline: important work should try to get close to WCAG 2.2 AA first, especially flows that affect real users — login, signup, checkout, contact forms, search, or a dashboard used every day (W3C WCAG 2.2).
Then add accessibility into design review, one item at a time.
Check contrast as you pick colours
Design a focus state for every interactive component
Write clear labels, helper text, and error messages — don't use placeholders as labels
Set touch targets large enough to tap easily
Think about the keyboard flow from the prototype stage
Add alt text to meaningful images
Design loading and empty states that are easy to understand
Add accessibility acceptance criteria to tickets, and keep issues as a backlog
Accessibility isn't one designer's job — semantic HTML, keyboard focus, and heading structure are work shared with dev.
Dev plays a big part too: semantic HTML, keyboard focus, form structure, heading structure, ARIA used only when needed, and testing with basic tools. Google web.dev itself treats accessibility as a topic spanning content structure, semantic HTML, keyboard focus, images, and JavaScript interaction — not the job of a designer alone (Google web.dev Learn Accessibility).
The key is not to wait until you're 100% ready, because if you do, many teams never start. Start with the most important flow, the most-used component, or the spot where users slip most. Accessibility that improves bit by bit still beats leaving it as a “someday” task.
Questions a designer should ask before handing off
Before a design handoff, try asking yourself these quick questions.
Is this colour actually readable, or just pretty in the mockup?
If you can't use a mouse, can you still get through — and does the keyboard tab order make sense?
If you can't see clearly, is the hierarchy still understandable?
Does this button clearly say what happens when you press it?
Does the form say which fields are required — and if you get it wrong, does the system say how to fix it?
Does the error message actually help the user, or just say “wrong”?
Is the focus state clearly visible?
Are the states complete — default, hover, focus, active, disabled, loading, error?
If you play a video without sound, do you still understand it — and if an image fails to load, do you still know what it meant?
If the user is rushed, tired, or not tech-savvy, can this flow still carry them forward?
These questions don't always slow design down. Often they help you decide more clearly.
Accessibility doesn't reduce beauty — it makes beauty more responsible
There's a common misconception that doing accessibility makes work ugly. In truth, accessibility doesn't forbid beautiful work — it doesn't forbid colour, animation, brand character, or designing for feeling. It just asks: is that beauty trading off by shutting someone out?
Colour can be beautiful, but it has to be legible. Fonts can have personality, but mustn't make important content hard to read. Animation is fine, but watch for motion that bothers some people. Layouts can be creative, but navigation mustn't get people lost. Micro-interactions can be charming, but shouldn't be the only way important information is conveyed.
For me, this is where design gets even more fun — because it's not only about making things “look good,” but about making that beauty stand on a real understanding of the people who use it.
From compliance to advantage
If accessibility starts from “it has to pass,” that's perfectly fine — but we shouldn't stop there. Once accessibility becomes part of how we design, it makes the product clearer, easier to use, supportive of more people, and lower-friction at the key moments of the experience.
Compliance is the base. Competitive advantage shows up when a team treats accessibility as part of product quality, the design system, customer experience, and brand trust. Put more simply, accessibility-first design doesn't only ask “have we met the standard?” — it asks:
“Are we needlessly making it hard for someone to use this?”
And if we fix that, the product doesn't just get better for one group — it usually gets better for the overall experience of many groups at once.
A note from Tarn
The way I see it, accessibility is something designers should slowly train themselves to notice as a habit — not something we wait for a requirement to start.
Designing for a wide range of people doesn't give design less freedom — it helps us decide more responsibly.
In a lot of real projects, we may not have the time, budget, or team to make everything perfect from the start. Sometimes all we can do is start by improving contrast, making labels clearer, making error messages more helpful, or filling in the focus states. But these small things mean more than they look, because they make the experience a little kinder to people, bit by bit.
I don't see accessibility as giving design less freedom — it helps us decide more responsibly. We don't pick a colour just because we like it, a font just because it's pretty, or a flow just because it looks tidy in Figma. We gradually ask more: how well does that choice actually work for a wide range of people?
Thank you to the many clients who've been open to talking about usability, accessibility, and the small details that look minor but matter a lot to real users. This article isn't trying to say every project must be perfect from day one — it's an invitation to gradually make the products we design not just beautiful on our screens, but better to use for a far wider range of people too.
References
W3C — Web Content Accessibility Guidelines (WCAG) 2.2
W3C WAI — WCAG 2 Overview
W3C WAI — The Business Case for Digital Accessibility
