I make your digital products accessible.
I check them against WCAG and the European Accessibility Act. If you like, I fix the issues myself in design and code and train your team so no new ones creep in over time.
Looks the same. But what if you can't see well?
In that case, many people use a screen reader that reads content out loud. To announce everything correctly, it needs clear structure in the code and sometimes extra information, such as whether a field is required or an entry is invalid.
Use “Back” and “Next” to step through the form, or pick an element right in it. For each element you see what a screen reader announces: once with a common mistake, once built right. “Why is this a problem?” explains why the mistake matters.
Element 1 of 5
A symbol that means nothing
Common mistake
image, icon-shield-blue-2.svg
Built right
Nothing announced
The shield symbol is pure decoration. If the code doesn't say so, some screen readers read out the file name instead.
Announcements like that carry no information. They're noise that makes listening harder.
Built right, the image gets an empty description in the code (alt=""). Then the screen reader skips it. Whether an image is just decoration is up to whoever creates the page. Images with relevant content need a short description.
“Your details” is set large and looks like a heading. In the code, though, it's just plain text.
Most screen reader users look for content through headings and jump from one to the next. That's what WebAIM's large survey of screen reader users (opens in a new tab) shows. If the heading is missing in the code, they sometimes skip this section.
Built right, it's a heading in the code too. How it looks is still up to the design.
Above the field it says “Full name”. To the eye, the two belong together, but not in the code.
So the screen reader only says “edit text”, with no name. Anyone who can't see well has to guess what goes in. It also affects people who find a mouse and keyboard hard to use and control their computer by voice instead, for example with Voice Control on macOS or Voice Access on Windows. They pick a field by saying its label. That only works if the field has that name in the code.
Built right, the label is connected to the text field in the code. Then the screen reader reads it out too. Thanks to this connection, people can also click the label to activate the field and type into it.
The field has a red border, and below it, in red, it says what's missing. To most people, that says “error” right away.
But what if you can't see the red, or can't see it properly? That affects blind people, but also people with color blindness, people with low vision and many older people. And the screen reader says nothing about the error.
Built right, the field is also marked as invalid in the code, and the hint below it is connected to it. Then the screen reader announces both: there's an error, and here's what to do. An icon or a word belongs with it, so the error doesn't depend on color alone.
The button only shows a symbol. Sighted people guess from the symbol and the context what it does.
A screen reader can't interpret the symbol, it's just a graphic. And in the code, the button has no name. So the screen reader only says “button”. Whether the click moves on, deletes something or sends the form, you don't find out.
Built right, the button gets a text in the code that the screen reader reads out, for example “Continue to summary”. The text doesn't have to be visible, the design stays the same.
How I can help
We usually start with an audit, which frequently turns into a long-term collaboration. I take on as much as you need.
Audit
I test your website against WCAG 2.2, by hand and with tools, some of which I built myself. For every issue you get a suggested fix your team can start on right away.
Fix
I fix the issues myself, right in the code and in the design, whatever technology you use. I comment on and sum up every change, so your team can follow it and knows what to watch for in the future.
Train
With training and mentoring, I help your team build accessibility in from the start and keep rounds of fixes small. Also as quality assurance alongside design and development, for example as a step of its own in each sprint review.
The European Accessibility Act in short
Since June 28, 2025, many digital services for consumers in the EU have to be accessible. In Germany that's the BFSG. In practice, the technical benchmark is the European standard EN 301 549 together with WCAG, the international guidelines for accessible websites and apps. I test against WCAG 2.2 (the current version, which the new edition of the standard builds on).
Public authorities check whether companies comply, after complaints and on their own initiative. They can set a deadline for fixes, impose a fine and, as a last resort, stop the service.
Usually affectedOnline shops, online banking, booking and ticketing, contract sign-ups and apps for consumers
Usually not affectedServices only for business customers, and services from very small companies: fewer than 10 employees and no more than €2 million in annual turnover or balance sheet total (Section 3 BFSG)
How it can go
Every project is different, so we shape the process around you. This is what it can look like for an audit, for example.
Getting to know each other
We get to know each other and talk about your products. I help you set the right course.
Defining the tasks
We talk about what's possible for you, with your goals first. That includes price and timeline.
Testing
I test the agreed flows step by step, by hand and with tools, some of which I built myself. The result is a report with a suggested fix for every finding, written for the team that handles it, for developers for example directly as code.
Talking it through
Either you go through the report yourselves and we answer your questions, or we go through it together. Afterwards your team can get started right away.

Audit and fixes from one person
I come from UI/UX design and frontend development. So an issue doesn't end with a criterion number for me. It ends with a fix that fits your design system and can ship in the next sprint.
Frequently asked questions
Does the law apply to me?
Most likely, if consumers buy, book or sign up for something from you online.
What does an audit cost?
It depends on the scope of the audit: how many different pages and flows should be tested, how complex the pages are and what format you want the report in. After a free first call, you get a concrete quote.
Aren't automated testing tools enough?
They're a good start and catch typical technical issues like missing image descriptions or low contrast. Whether you can get through checkout with a keyboard, whether an announcement makes sense or an error message helps, only a person can judge.
What about accessibility plugins?
These plugins only put a layer on top of the page. The code underneath stays the same, and that's where most barriers come from. People who use a screen reader bring their own tools anyway and need a page that's built right.
Get in touch.
Tell me briefly what it's about, with no strings attached, and we'll find the right solution together.