Why designing for some users makes the product better for everyone
(An in-house project at Brand24. I led it end to end: audits, UI changes, planning, coordination with developers, and some of the simpler code fixes, done with AI. This piece is less a report of what we did and more a guide to how I'd approach it from scratch.)
A client from the US sends an email. They like the product, but before they sign, they need a VPAT. Half the team has never heard the word.
That's roughly how accessibility started for us at Brand24. US clients asked for a VPAT more and more often, because accessibility rules have been in place there for years. At the same time, the European Accessibility Act was coming into force in June 2025.
So we did it. Over 2–3 months, part-time, we brought the product to WCAG 2.1 AA. That covered around 70% of the screens. We skipped the legacy views, since they were scheduled for a rebuild anyway. AI made the whole thing much faster than I expected.
Curb cuts are the small ramps at street crossings. They were built for wheelchair users. Today they help anyone pushing a stroller, pulling a suitcase or riding a bike. This is the curb-cut effect. A solution designed for one group ends up helping everyone.
Digital accessibility works the same way. Most WCAG guidelines are simply good UX rules. Higher contrast helps people with low vision, and also anyone reading in full sunlight. Clear error messages help screen reader users, and save everyone time.
That's the idea behind this article. If you treat accessibility as a niche feature, you'll do the bare minimum. If you treat it as a UX audit with a ready-made checklist, the whole product gets better.
Below are six steps to implement it from scratch. Each one ends with a note on who else benefits.
You don't need to read all of WCAG before you begin. The full guidelines are long and dense. Summaries and checklists are enough to start. You'll go deeper as you fix things.
First, pick your target. For most products in the EU, that's WCAG 2.1 level AA. It's the level the European Accessibility Act points to through the EN 301 549 standard. Level A is the bare minimum. Level AAA is very strict and rarely expected for a whole product.
Then learn the four principles behind every guideline. Content must be perceivable, operable, understandable and robust (POUR). Remember these four words and most of the rules start to make sense.
Who else benefits: your team. Designers and developers get a shared vocabulary, so reviews go faster.
Before you change anything, check where you are. Use two kinds of testing, because each one catches different problems.
Automated tools like WAVE or Chrome Lighthouse are fast. In seconds they find missing alt text, low contrast and buttons without names. But they only catch part of the issues. A tool can tell you an image has alt text. It can't tell you whether that text makes sense.
Manual testing fills the gap. Put your mouse away and go through the main flows with the keyboard only. Can you reach every button? Can you always see where you are? Then turn on a screen reader (VoiceOver on Mac, NVDA on Windows) and listen to one page. For most designers, those ten minutes are the most eye-opening part of the whole project.
Write every issue down. Group them by screen and by type. This list is your backlog.
Who else benefits: the product. An audit often finds UX bugs nobody ever reported.
The list will be long. Don't fix everything at once. Start with the issues that block people completely.
<button>, not a styled <div>. Correct HTML gives you keyboard and screen reader support for free.autocomplete attribute, so the browser knows a field asks for an email or a name.Who else benefits: power users who live on shortcuts, anyone whose mouse just died, mobile users, and everyone who fills in a form faster thanks to autofill.
Accessibility work suits AI well. Much of it is repetitive, and the guidelines read like legal text.
AI can fix code. It adds missing attributes and labels, adjusts colors across many files and helps with keyboard handling. It helped me with the simpler fixes, and it helped our developers too.
AI can explain WCAG. Paste a success criterion and ask for a plain-language version with one example. Dense rules become a two-line brief you can share with the team.
AI can draft the VPAT. Give it your audit notes and it will produce a first version of the report, criterion by criterion.
Always check the output. AI likes to add ARIA attributes where plain HTML would do the job better, and bad ARIA is worse than no ARIA. Test every fix with a keyboard and a screen reader.
Who else benefits: your developers. Less time on repetitive fixes means more time for real features.
Your own audit is a good start, but you will miss things. If you have the budget, hire an external team. Experts know the edge cases. The good ones also run usability tests with people with disabilities, who use assistive technology every day. You learn more in one of those sessions than from any checklist.
Then document the result in a VPAT (Voluntary Product Accessibility Template). It lists each WCAG criterion and states whether your product supports it, partially supports it or doesn't. Be honest. A "partially supports" with a short note builds more trust than a page of perfect scores. Clients who ask for a VPAT know no product is perfect.
Who else benefits: sales. When a client asks about accessibility, the answer is one attachment away.
Accessibility doesn't end with the last fix. Every new feature can break it again. A new modal that traps the focus. A new brand color that fails contrast. Six months later you're back where you started, with fresh accessibility debt.
A few habits keep it in place:
Who else benefits: future you. Fixing accessibility in design takes minutes. Fixing it in production takes sprints.
Higher contrast is often the most visible change, and it can hurt the look of the product. Pale greys turn dark. Soft brand colors get heavier. If you darken every color that fails, the interface can start to feel harsh.
We took it as a chance instead. If the palette had to change anyway, it should change for the better. So we adjusted the whole palette, not only the colors that failed. The panel passed WCAG and got a fresher look at the same time.
If you have a design system, fix the color tokens rather than single screens. One change then reaches every component.
If you take one thing from this article, put your mouse away and try your own product for ten minutes.
Next case study
