_Wissens-Hub: Accessibility-Audit Appsoluts Website/*
Accessibility-Audit der eigenen Website: Was eine Prüfung sichtbar macht
- Zuletzt aktualisiert
- 11. Juni 2026
- Lesedauer
- 8 Minuten
Quick Win
Wir empfehlen Projektpartnern regelmäßig Accessibility-Audits. Deshalb haben wir die gleiche Tiefenprüfung bei uns selbst angesetzt. Die Prüfung von appsoluts.de gegen die Richtlinien WCAG und BITV, mit eigener Methodik, eigenem Tooling und manuellen Walkthroughs, ergab 193 dokumentierte Verbesserungspunkte auf 33 Seiten. Hier lest ihr, wie wir vorgegangen sind, was wir gefunden haben und was ihr für eure eigene Website mitnehmen könnt.
💡 Key Takeaways
-
Tiefenprüfung deckt auf, was Routine verbirgt.
Systematisches Auditing findet Stellen, an denen gepflegter Code an seine Grenzen stößt. Diese Klarheit macht jede einzelne Komponente schärfer.
-
Tastatur-Bedienbarkeit ist der größte Hebel.
Acht der 23 kritischen Punkte in unserem Audit betrafen Komponenten, die ohne Maus nicht erreichbar waren. Diese eine Klasse von Findings öffnet ganze Zielgruppen wieder.
-
ARIA gehört dosiert eingesetzt.
Wir haben mehrere Stellen entdeckt, an denen ARIA-Attribute mehr Schaden als Nutzen anrichteten. Sauberes semantisches HTML ist in den meisten Fällen die elegantere Lösung.
-
Audit ist Anfang, nicht Endpunkt.
Barrierefreiheit ist kein Projekt mit Abnahme, sondern ein laufender Modus. Wir haben einen Standard etabliert, an dem sich künftige Komponenten messen lassen.
-
Auch Nutzer ohne Einschränkung profitieren.
Klarere Hierarchien, funktionale Skip-Links, eine durchdachte Sitemap. Das macht die Website für alle besser, nicht nur für die, die darauf angewiesen sind.
Warum gerade jetzt alle über Barrierefreiheit sprechen
Seit dem 28. Juni 2025 ist das Barrierefreiheitsstärkungsgesetz (BFSG) in Deutschland in Kraft. Es verpflichtet Unternehmen, digitale Angebote barrierefrei zu gestalten, für Websites ohne Übergangsfrist [1]. Kleinstunternehmen mit weniger als zehn Mitarbeitenden und maximal zwei Millionen Euro Jahresumsatz sind teilweise ausgenommen [2]. Reine B2B-Angebote fallen nicht direkt unter das Gesetz, sobald aber auch Verbraucher angesprochen werden, greifen die Pflichten [2].
Das ist der rechtliche Druck. Wichtiger ist die Haltung dahinter. Eine Website, die jeder Mensch nutzen kann, ist schlicht eine bessere Website.
Was eine vollständige Prüfung sichtbar macht
Wer glaubt, ein gepflegter Codestand schützt vor Accessibility-Problemen, sollte einen Blick auf die Zahlen werfen. Die Organisation WebAIM analysiert jährlich die eine Million meistbesuchten Websites der Welt auf WCAG-Konformität. Das Ergebnis des aktuellen Reports: durchschnittlich 56,1 automatisch erkennbare Accessibility-Fehler pro Startseite [3].Low-Contrast-Text allein taucht auf 79,1 % aller getesteten Startseiten auf [3].
Das sind ausschließlich automatisch erkennbare Fehler. Manuelle Prüfungen, also Tastatur-Walkthroughs, Screenreader-Tests und Kontextprüfungen, legen erfahrungsgemäß ein Vielfaches davon frei. Die Lücke zwischen „sieht gut aus“ und „ist tatsächlich nutzbar“ ist in den meisten Codebases größer, als Teams erwarten.
Genau das hat unser eigenes Audit bestätigt. Unser Dev- & Design-Team hat alle Seitentypen, Templates und Komponenten von appsoluts.de durchleuchtet, alles, was nicht über bereits geprüfte Templates ausgespielt wird. Für die automatisierte Erstprüfung kam unser eigenes Accessibility-Scanner-Tool zum Einsatz. Die weiteren Findings haben wir manuell ergänzt: Tastatur-Walkthroughs, Screenreader-Tests, Kontrast- und Inhaltsprüfungen.
Das Ergebnis in Zahlen: 193 Verbesserungspunkte auf 33 geprüften Seiten, 23 kritisch, 84 serious, 86 minor, verteilt auf elf Kriterien-Kategorien.
Die fünf größten Cluster:
| Kategorie | Findings |
|---|---|
| Anpassbarkeit (Strukturierung, Listen, Überschriften) | 45 |
| Navigierbarkeit (Linktexte, Skip-Links, Fokus) | 34 |
| Unterscheidbarkeit (Kontraste, Farben) | 28 |
| Kompatibilität (Markup, ARIA-Korrektheit) | 20 |
| Textalternativen (Alt-Texte) | 15 |
Was diese Zahlen zeigen: Eine systematische Prüfung deckt Optimierungspotenzial auf, das im normalen Entwicklungsalltag schwer zu erfassen ist. Die meisten Findings sind kleine, gezielte Korrekturen. Ihre Summe macht den Unterschied zwischen einer Website, die rechtlich auf Kante steht, und einer, die als Reifebeispiel taugt.
Parallel zur Website haben wir auch automatisch generierte Audit-Berichts-Mails geprüft. Auch
ein Newsletter oder eine System-Mail kann WCAG-Verstöße enthalten: fehlende Lang-Attribute,
leere Title-Tags, Layout-Tabellen ohne role="presentation". Wer
Mail-Kommunikation betreibt, sollte sie konsequent mitprüfen.
Drei Findings, die an vielen Stellen auftauchen
Aus den 23 kritischen Punkten greifen wir drei heraus. Sie sind typisch und tauchen in nahezu jeder Website auf, die wir uns danach angeschaut haben.
Videos ohne Steuerung
Im Hero-Bereich unserer FohlenApp Case Study liefen Video-Inhalte automatisch ab, ohne Pause- oder Play-Steuerung. Menschen mit Aufmerksamkeitsstörungen, Störungen des Gleichgewichtssinns oder schlicht dem Wunsch, in Ruhe zu lesen, hatten keine Möglichkeit, das Bewegtbild anzuhalten.
Der Fix: sichtbare Play- und Pause-Buttons direkt am Video, per Tastatur und Touch bedienbar. Und auch mit Klick am Desktop. Wenig Aufwand im Frontend, klares Plus an Bedienbarkeit. Betrifft WCAG 2.2.2 (A): Bewegte Inhalte abschaltbar [4].
Vorher: Video-Karte im Feed ohne Steuerung.
Nachher: Steuerungselemente direkt am Video, per Tastatur und Touch bedienbar.
ARIA-Labels mit Platzhalterwerten
Ein ARIA-Label war auf den String „Label“ gesetzt. Ein Screenreader las also nicht den eigentlichen Inhalt vor, sondern wörtlich das Wort „Label“. Klingt absurd, taucht in Audits aber regelmäßig auf: kopierte Komponenten, Platzhalter im Code, fehlende Screenreader-Tests im QA-Prozess.
Der Fix: ARIA-Label an dieser Stelle optional gemacht. Sauberes semantisches HTML reichte aus. ARIA wird gerne überdosiert. Nun wird es nur noch dort verwendet, wo es nötig ist. Falsch oder überflüssig gesetzte Attribute schaffen neue Barrieren, statt alte zu beseitigen. Betrifft WCAG 4.1.2 (A): Name, Rolle, Wert verfügbar [4] [5].
Vorher: aria-label trägt den Platzhalter „Label“. Ein Screenreader liest wörtlich „Label“ vor.
Nachher: aria-label optional. Semantisches HTML liefert die korrekte Information.
Tastatur-Bedienung im Formular
Ein Radio-Button im Job-Formular auf der Kontaktseite war nur per Maus aktivierbar. Kein Fokus-Ring, keine Tastatur-Bedienbarkeit. Wer ausschließlich mit der Tastatur arbeitet, also Menschen mit motorischen Einschränkungen, Screenreader-Nutzer oder Power-User, konnte das Formular nicht abschicken.
Dieses Pattern war unser am häufigsten wiederkehrendes kritisches Thema: Acht der 23 kritischen Punkte betrafen genau diese Klasse von Findings.
Der Fix: native HTML-Radio-Buttons statt Custom-Komponente, plus sichtbarer Fokus-Ring im Designsystem. Wenige Zeilen Code. Eine ganze Bewerber-Gruppe ist damit wieder erreichbar. Betrifft WCAG 2.1.1 (A) und WCAG 2.4.7 (AA) [4].
Vorher: Auswahl nur per Maus. Tastatur-Nutzer sehen nicht, wo sie stehen und konnten nur den Default nutzen, was zu Informationsverfälschung in den Ergebnissen führte.
Nachher: Sichtbarer Fokus-Ring, vollständig per Tastatur bedienbar.
Was Design und Dev daraus gemacht haben
Wir teilen Audit-Arbeit klar zwischen Design und Entwicklung auf. Manche Themen betreffen Tokens und Komponenten, andere Markup und Verhalten. Diese Trennung hilft uns auch in Projekten mit Projektpartnern.
Design hat Hierarchien neu sortiert und Texte für Klarheit überarbeitet. Komponenten wurden angepasst: Videos und Animationen bekamen Play/Pause-Buttons, Formulare statische Labels statt Placeholder-only-Lösungen. Und anschließend aktiv umgesetzt vom Dev-Team.
Dev hat das Markup semantischer gemacht. Listen sind nun korrekt als solche ausgezeichnet, Header-Hierarchien stimmen. ARIA-Rollen wurden geprüft, korrigiert oder entfernt, wo sie überflüssig waren. Die Tastatur-Bedienung ist durchgängig nutzbar. Skip-Links auf der Startseite sind ergänzt, eine Sitemap als alternativer Zugangsweg erstellt, die Erklärung zur Barrierefreiheit veröffentlicht.
Aufwand auf Dev-Seite: rund 60 Stunden inklusive Dokumentation. Übersichtlich genug, um Code-Altlasten gleich mit aufzuräumen.
Lohnt sich ein Audit für euch?
Eine pauschale Antwort gibt es nicht. Zwei Faustregeln helfen.
Wenn eure Website Lead-Funktion hat oder Bewerbungen, Käufe oder Anmeldungen verarbeitet, lohnt sich ein Audit fast immer. Jede ausgeschlossene Person ist ein verlorener Kontakt. Wenn eure Website primär als Marketing-Bühne dient, hängt es von Volumen, Branche und Risikobereitschaft ab.
Die zweite Faustregel: Findings entfalten ihren Wert erst mit der Umsetzung. Wenn jemand benannt ist, der Folge-Maßnahmen verantwortet, lohnt der Aufwand sofort. Wenn nicht: erst Owner klären, dann auditieren.
Gute Kandidaten: Websites mit Lead-Funktion, Bewerbungen oder Buchungen. B2C-Angebote oder öffentlicher Sektor mit BFSG-Pflicht. Teams mit benanntem Owner für Folge-Maßnahmen. Plattformen mit hohem Bestand und vielen Komponenten.
Eher warten: Großer Redesign-Relaunch innerhalb der nächsten drei Monate. Reine Single-Page ohne Interaktion oder Lead-Pfad. Weder Budget noch Owner für die Umsetzung. Frühe Produktphase, in der sich Komponenten täglich ändern.
Fünf Fragen vorab:
- Erreichen Tastatur-Nutzer alle Funktionen? Tabuliert durch eure Website. Löst relevante Elemente aus. Wo ihr nicht hinkommt oder nichts reagiert, habt ihr einen klaren Hebel.
- Gibt es eine Erklärung zur Barrierefreiheit und eine HTML-Sitemap? Beides Pflicht, beides Vertrauenssignal.
- Sind Auto-Play-Inhalte pausierbar? Über 5 Sekunden lange Videos und Animationen ohne Pause-Option sind ein direkter WCAG-Verstoß.
- Haben Formulare echte, statische Labels? Robuster für Screenreader und für alle anderen.
- Wer ist Owner für laufende Accessibility-Pflege? Mit benanntem Owner entfaltet ein Audit seinen Wert. Ohne Owner versickert es.
Return on Invest: was Accessibility wirklich bringt
Der harte ROI eines Audits ist schwer zu beziffern. Der weiche ist deutlich spürbar.
Ihr reduziert Risiko: BFSG-Bußgelder, Reputationsschäden, Klagen. Ihr gewinnt Zielgruppen zurück, die heute durch Detailfehler ausgeschlossen sind. In Deutschland sind das rund 7,8 Millionen Menschen mit anerkannter Behinderung, plus eine deutlich größere Gruppe mit temporären oder situativen Einschränkungen.
Ihr baut auf sauberem Code, was Folgekosten in Wartung und Weiterentwicklung senkt. Und ihr sendet ein Reifezeichen an Projektpartner und Bewerber.
Ein Effekt hat uns zusätzlich überrascht: Auch User ohne Einschränkung profitieren. Klarere Hierarchien, Tastatur-Shortcuts, eine sinnvolle Sitemap. Das macht die Seite für alle besser. Wir selbst nutzen die neue Sitemap regelmäßig, obwohl wir nicht darauf angewiesen sind.
Fazit
Ein Accessibility-Audit ist kein einmaliges Projekt. Es ist der Eintritt in einen kontinuierlichen Prozess. Wer ihn ehrlich angeht, baut bessere Produkte: für mehr Menschen, mit weniger Reibung, auf saubererem Code.
Der Compliance-Druck durch das BFSG nimmt nur den Anstoß. Den Wert erzeugt die Umsetzung danach.
Aus 193 Findings ist bei uns ein Standard geworden. Jede neue Komponente, jedes neue Feature wird ab jetzt mit Accessibility gedacht. Genau diesen Schritt empfehlen wir jedem Projektpartner.
Quellen
W3C Web Accessibility Initiative. (2023). Web Content Accessibility Guidelines (WCAG) 2.2. World Wide Web Consortium.
W3C Web Accessibility Initiative. (2023). ARIA Authoring Practices Guide (APG). World Wide Web Consortium.
Bundesfachstelle Barrierefreiheit. (2025). Barrierefreiheitsstärkungsgesetz (BFSG).
bfsg-gesetz.de. (2025). Barrierefreiheitsstärkungsgesetz — aktuelle Fassung und FAQ.
WebAIM. (2026, Februar). The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages.
