Ich mache deine digitalen Produkte barrierefrei.
Ich prüfe sie nach WCAG und BFSG. Auf Wunsch behebe ich die Fehler selbst in Design und Code und schule dein Team, damit langfristig keine neuen dazukommen.
Sieht gleich aus. Aber was, wenn man schlecht sehen kann?
In diesem Fall nutzen viele einen Screenreader, der Inhalte vorliest. Damit er alles richtig ansagt, braucht er klare Strukturen im Code und manchmal zusätzliche Angaben, etwa ob ein Feld Pflicht ist oder eine Eingabe falsch.
Geh mit „Zurück“ und „Weiter“ durch das Formular oder wähl ein Element direkt darin aus. Zu jedem Element siehst du, was ein Screenreader ansagt: einmal mit einem typischen Fehler, einmal richtig gebaut. Warum der Fehler stört, erklärt „Warum ist das ein Problem?“.
Element 1 von 5
Symbol ohne Bedeutung
Häufiger Fehler
Bild, icon-shield-blue-2.svg
Richtig gebaut
Keine Ansage
Das Schild-Symbol ist reine Deko. Fehlt im Code der Hinweis darauf, lesen manche Screenreader stattdessen den Dateinamen vor.
Solche Ansagen enthalten keine Information. Sie sind Lärm, der das Zuhören mühsamer macht.
Richtig gebaut bekommt das Bild im Code eine leere Bildbeschreibung (alt=""). Dann überspringt der Screenreader es. Ob ein Bild nur Deko ist, entscheidet, wer die Seite erstellt. Bilder mit relevantem Inhalt brauchen eine kurze Beschreibung.
„Deine Angaben“ ist groß geschrieben und sieht aus wie eine Überschrift. Im Code ist es aber nur normaler Text.
Die meisten Screenreader-Nutzer suchen Inhalte über Überschriften und springen von einer zur nächsten. Das zeigt die große Umfrage von WebAIM (öffnet in neuem Tab) unter Screenreader-Nutzern. Fehlt die Überschrift im Code, überspringen sie manchmal diesen Abschnitt.
Richtig gebaut ist es auch im Code eine Überschrift. Wie sie aussieht, bestimmt weiter das Design.
Über dem Feld steht „Vor- und Nachname“. Für das Auge gehört beides zusammen, im Code aber nicht.
Der Screenreader sagt deshalb nur „Textfeld“, ohne Namen. Wer nicht (gut) sehen kann, muss raten, was hinein soll. Es trifft auch Menschen, die Maus und Tastatur schlecht bedienen können und ihren Computer stattdessen per Sprache steuern, etwa mit der Sprachsteuerung von macOS oder dem Sprachzugriff von Windows. Sie wählen ein Feld aus, indem sie seine Beschriftung aussprechen. Das klappt nur, wenn das Feld im Code so heißt.
Richtig gebaut ist die Beschriftung per Code mit dem Textfeld verbunden. Dann sagt der Screenreader sie mit an. Durch diese Verbindung kann man außerdem auf die Beschriftung klicken, um das Feld zu aktivieren und etwas einzutippen.
Das Feld ist rot umrandet, darunter steht in Rot, was fehlt. Für die meisten heißt das sofort: Fehler.
Aber was, wenn man das Rot nicht oder nicht richtig sieht? Das betrifft blinde Menschen, aber auch Menschen mit Farbsehschwäche, mit wenig Sehkraft und viele Ältere. Und der Screenreader sagt vom Fehler nichts.
Richtig gebaut ist das Feld auch im Code als fehlerhaft markiert, und der Hinweis darunter ist mit ihm verbunden. Dann sagt der Screenreader beides an: Hier ist ein Fehler, und das ist zu tun. Dazu gehört ein Symbol oder ein Wort, damit der Fehler nicht nur an der Farbe hängt.
Der Button zeigt nur ein Symbol. Sehende erraten aus dem Symbol und dem Zusammenhang, was er tut.
Das Symbol kann ein Screenreader nicht deuten, es ist nur eine Grafik. Einen Namen hat der Button im Code nicht. Der Screenreader sagt deshalb nur „Taste“. Ob der Klick weiterführt, etwas löscht oder abschickt, erfährt man nicht.
Richtig gebaut bekommt der Button im Code einen Text, den der Screenreader vorliest, zum Beispiel „Weiter zur Zusammenfassung“. Der Text muss nicht sichtbar sein, das Design bleibt gleich.
So kann ich helfen
Meist beginnen wir mit einer Prüfung, häufig wird daraus eine langfristige Zusammenarbeit. Ich übernehme so viel, wie du brauchst.
Prüfen
Ich prüfe deine Website nach WCAG 2.2, von Hand und mit Werkzeugen, die ich teils selbst entwickelt habe. Zu jedem Fehler bekommst du einen Lösungsvorschlag, mit dem dein Team sofort loslegen kann.
Beheben
Ich behebe die Fehler direkt selbst, im Code und im Design, egal mit welcher Technologie ihr arbeitet. Jede Änderung kommentiere ich und fasse sie zusammen, damit dein Team sie nachvollziehen kann und weiß, worauf es künftig achten muss.
Schulen
Mit Schulungen und Mentoring helfe ich deinem Team, Barrierefreiheit von Anfang an mitzudenken und Korrekturschleifen klein zu halten. Gern auch als Qualitätssicherung während Design und Entwicklung, zum Beispiel als eigener Schritt im Review jedes Sprints.
Das BFSG in Kürze
Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz, kurz BFSG. Danach müssen viele digitale Angebote für Privatkunden barrierefrei sein. Als technischer Maßstab dienen in der Praxis die europäische Norm EN 301 549 und die WCAG, die internationalen Regeln für barrierefreie Websites und Apps. Ich prüfe nach WCAG 2.2 (dem aktuellen Stand, auf dem auch die neue Fassung der Norm aufbaut).
Ob sich jemand daran hält, kontrolliert eine Behörde der Bundesländer, die Marktüberwachungsstelle. Sie wird nach Beschwerden aktiv, aber auch von sich aus. Sie kann eine Frist zum Nachbessern setzen, ein Bußgeld verhängen und im äußersten Fall das Angebot verbieten.
Meist betroffenOnlineshops, Online-Banking, Buchungs- und Ticketportale, Vertragsabschlüsse und Apps für Privatkunden
Meist nicht betroffenAngebote nur für Firmenkunden und Dienstleistungen sehr kleiner Firmen: weniger als 10 Beschäftigte und höchstens 2 Millionen Euro Jahresumsatz oder Bilanzsumme (§ 3 BFSG)
So kann es ablaufen
Jedes Projekt ist anders, deshalb stimmen wir den Ablauf auf dich ab. So kann er zum Beispiel für eine Prüfung aussehen.
Kennenlernen
Wir lernen uns kennen und sprechen über eure Produkte. Ich helfe dir, die Weichen richtig zu stellen.
Aufgaben definieren
Wir besprechen, was für euch möglich ist, mit euren Zielen im Vordergrund. Dazu gehören auch Preis und Zeitrahmen.
Prüfen
Ich prüfe die festgelegten Abläufe Schritt für Schritt von Hand und mit Werkzeugen, die ich teils selbst entwickelt habe. Am Ende steht ein Bericht mit einem Lösungsvorschlag zu jedem Befund, verständlich für den jeweiligen Fachbereich, für Entwickler zum Beispiel direkt als Code.
Besprechen
Entweder ihr geht den Bericht selbst durch und wir klären eure Fragen, oder wir gehen ihn gemeinsam durch. Danach kann dein Team direkt loslegen.
Prüfung und Umsetzung aus einer Hand
Ich komme aus UI/UX-Design und Frontend-Entwicklung. Deshalb endet ein Befund bei mir nicht mit einer Kriteriennummer, sondern mit einer Lösung, die in euer Designsystem passt und sich im nächsten Sprint umsetzen lässt.
Häufige Fragen
Bin ich überhaupt BFSG-pflichtig?
Sehr wahrscheinlich, wenn Privatkunden bei dir online etwas kaufen, buchen oder einen Vertrag abschließen.
Was kostet eine Prüfung?
Das hängt vom Umfang der Prüfung ab: wie viele unterschiedliche Seiten und Abläufe geprüft werden sollen, wie komplex die Seiten sind und in welchem Format ihr euch den Bericht wünscht. Nach einem unverbindlichen und kostenlosen Erstgespräch bekommst du ein konkretes Angebot.
Reichen automatische Prüftools nicht aus?
Sie sind ein guter Start und finden typische technische Fehler, etwa fehlende Bildbeschreibungen oder zu wenig Kontrast. Ob man per Tastatur durch den Bestellprozess kommt, ob eine Ansage verständlich ist oder eine Fehlermeldung hilft, kann nur ein Mensch beurteilen.
Was ist mit Barrierefreiheits-Plugins?
Solche Plugins legen nur eine Schicht über die Seite. Der Code darunter bleibt, wie er ist, und genau dort entstehen die meisten Barrieren. Wer einen Screenreader nutzt, bringt seine Hilfsmittel ohnehin selbst mit und braucht eine Seite, die richtig gebaut ist.
Melde dich bei mir.
Erzähl mir kurz und unverbindlich, worum es geht, und wir finden gemeinsam eine passende Lösung.