In most projects accessibility sits at the bottom of the list. Something for the end, if there is time and budget left, with a checkbox next to it. We used to look at it that way ourselves. It is exactly backwards.
Who you do it for
The picture is usually: a blind user with a screen reader. They exist, and they count. But the group is far wider. The colleague of sixty who has turned up the text size on his phone. Someone with a broken wrist working left-handed for two weeks. The technician opening your app in full sun on a building site. The nurse filling in a form between two patients, with half an eye and one hand. Almost everyone is a user with a disability now and then. A product that was not built for that shuts those people out, and there are far more of them than you think.
And since 28 June 2025 it is no longer a choice. The European Accessibility Act applies from that date to web shops, banking, transport and most other services you use online. Municipalities and other public bodies were already held to it, and noticeably more strictly this year. We see it in conversations: a client who wants accessibility in order first, before any new features are started. That is the right order.
It makes everything better
This is the part the checklist misses. Accessible design is simply good design, and you notice it in the users who have no disability at all.
Take contrast. Look at an app you like: the lines between the panels are often almost white. Calm, until you open it in the sun, or share it on a video call, and everything turns into one flat surface. The accessibility guidelines, WCAG, say the edge of an input field or a button has to be clearly visible, otherwise you do not know where you are typing. Follow that rule and the screen also works for the technician on the building site.
Keyboard operation is there for people who cannot use a mouse. It is the power users who benefit most: someone filling in the same form two hundred times a day does not want to reach for the mouse. A clear order of headings and text helps someone with an attention disorder, and the busy manager who scans the screen in four seconds. An error message in words instead of only a red border helps the one in twelve men who cannot see red, and everyone who can see the red but does not know what is wrong.
The field has a name for this: the curb-cut effect, after the lowered curb. It was made for wheelchairs, and it is used most by people with a pram, a suitcase or a bike at their side. Every accessibility choice we make works like that.
Google reads your site the way a screen reader does
There is one more user without eyes, and that one decides how many visitors you get. A search engine does not see your page. It reads the structure underneath, and that is exactly the structure a screen reader leans on.
A heading that is built as a heading, not as bold text, tells Google what the page is about. A description on every image is the only thing a search engine understands about that image. A link called "see the pricing" instead of "click here" says where it goes, for the screen reader and the search engine alike. And a page you can move through with the keyboard is also a page a crawler gets through without getting stuck in a menu.
So we never write separately for SEO. The work that makes a page accessible also makes it findable, and it is no accident that the most accessible sites we build are also the ones that get found best.
From the start it is almost free
Most of the work is invisible. A button is a real button, not a box that looks like one. Every input field has a name. Colors come from a set that was checked for contrast up front. None of that takes extra time if you do it while you build: choosing the right element takes as long as choosing the wrong one.
Fixing it afterwards costs a multiple. By then the wrong choice sits in forty screens, and every screen has to be opened. That is why it is not a separate phase on our list. It sits in how we build a component, and we check it at one moment, when a piece of work is finished and goes into the product. Not after every change, because a check that goes off too often, nobody reads after day two.
Where to start
Start with the basics rather than everything at once. Those fit in a week:
- Go through your most important flow with the keyboard only. Wherever you get stuck, that is your first job.
- Check the contrast of text and of the edges of fields and buttons, on a screen other than your own.
- Have a screen reader read your form out loud and listen for whether every field has a name and every image a description.
- Run an automated check, such as axe or Lighthouse, and know that it finds about a third of the problems. The rest you only see by doing it yourself.
Build it in from the start and it costs almost nothing. Add it later and it costs a fortune, usually right when the budget has run out.
A thorough review of your product's user experience and interface that finds the friction and inconsistencies, and shows what to improve first.