Accessibility Audit

Ein Accessibility Audit, mit dem dein Entwicklungsteam arbeiten kann.

Finde heraus, wo Menschen mit Tastatur, Screenreader oder Zoom in deinem Produkt hängen bleiben. Wir prüfen eine vereinbarte Stichprobe gegen WCAG 2.2, schreiben Befunde, die dein Team nachstellen kann, beheben, was du beauftragst, und testen das Ergebnis erneut.

Accessibility Audit besprechen →

KURZ ERKLÄRT

Ein Accessibility Audit prüft eine definierte Stichprobe eines Produkts gegen die Erfolgskriterien der WCAG 2.2, mit automatisierten Checks und manuellen Tests per Tastatur, Screenreader und Zoom. Der Auftrag liefert nachvollziehbare Befunde, priorisierte Fixes und einen Retest; er ist keine Zertifizierung und keine rechtliche Konformitätserklärung.

Passt für

  • Web- oder Mobile-Apps, deren zentrale Abläufe nie über einen automatischen Scan hinaus getestet wurden
  • Teams, die technische Nachweise für ihre eigene Einschätzung zum European Accessibility Act brauchen

Eine andere Leistung passt besser

  • Eine rechtliche Einschätzung, ob Barrierefreiheitsgesetze für dich gelten
  • Laufende Funktions- und Regressionstests jedes Releases

Vollständige Abläufe prüfen, nicht nur Seiten

Ein Audit ist nur so gut wie seine Stichprobe. Wir wählen die vollständigen Aufgaben, die Menschen erledigen müssen (registrieren, etwas finden, bezahlen, ein Formular mit Validierungsfehlern absenden, ein Dokument herunterladen), und die Templates und Zustände, die diese Aufgaben berühren: Dialoge, aufklappbare Listen, Fehlermeldungen, leere Ergebnisse. Dann vereinbaren wir Browser, Geräte und assistive Technologien. Willst du das Briefing selbst vorbereiten oder Angebote vergleichen, hilft dir unser Leitfaden zur Barrierefreiheitsprüfung.

Automatische Checks finden manches. Menschen finden den Rest.

Wir prüfen gegen die WCAG 2.2 auf der Stufe, die du wählst, meist AA. Tools erkennen einen Teil der Probleme; der Rest braucht einen Menschen, der die Aufgabe durcharbeitet.

Automatische Checks

Scanner über die Stichprobe für Kontrast, fehlende Namen, Struktur und falsch eingesetztes ARIA. Jede Warnung wird bewertet, denn ein Tool-Ergebnis ist erst ein Befund, wenn jemand es bestätigt.

Tastatur und Fokus

Jede Aufgabe ohne Maus: Fokusreihenfolge, sichtbarer Fokus, Tastaturfallen in Dialogen, Sprunglinks und wohin der Fokus nach einer Aktion springt.

Screenreader und Zoom

Vereinbarte Kombinationen aus Screenreader und Browser (zum Beispiel VoiceOver mit Safari, NVDA mit Firefox), Textvergrößerung und Umbruch der Inhalte auf schmalen Bildschirmen.

Native mobile Apps

Wenn Mobile im Umfang ist: iOS- und Android-Screens mit den Screenreadern der Plattform, großen Systemschriften und Prüfung der Touch-Zielgrößen.

Befunde, die dein Team nachstellen und beheben kann

Jeder Befund nennt Seite und Zustand, Umgebung, Schritte, beobachtetes und erwartetes Verhalten, Auswirkung auf Nutzer, das WCAG-Kriterium und einen Lösungsvorschlag. Gereiht wird danach, wie stark ein Problem das Abschließen der Aufgabe verhindert, nicht nach der Zahl der Tool-Warnungen. Dazu bekommst du eine Erklärung zum geprüften Umfang: was geprüft wurde, wie, und was nicht. Das Audit betrifft die Nutzbarkeit für Menschen mit Behinderungen; allgemeine Funktions- und Regressionstests bleiben bei der Software-Quality-Assurance.

Illustrativer Befund: ein Dialog, der die Tastatur einsperrt

Illustrativ, keine geprüfte Kundenseite. Eine Tastaturnutzerin öffnet einen Filterdialog, erreicht aber das Schließen-Element nicht, und die Seite dahinter wird unerreichbar. Der Befund nennt Template und Zustand, Browser und Tastaturschritte, die Auswirkung, das erwartete Fokusverhalten und das WCAG-2.2-Erfolgskriterium 2.1.2 Keine Tastaturfalle, mit Lösungsvorschlag. Nach dem Fix wiederholt der Retest die ganze Aufgabe: öffnen, nutzen, schließen, und der Fokus kehrt zum auslösenden Element zurück.

Audit, Behebung, Retest. Jedes ist eine eigene Entscheidung.

Umfang und Angebot vereinbaren wir je Phase. Eine Stichprobe liefert Nachweise über den geprüften Umfang; sie zeigt nicht, dass jede Seite barrierefrei ist.

  1. Audit

    Du erhältst das Befundregister, die Erklärung zum geprüften Umfang, Methoden- und Umgebungsangaben sowie eine priorisierte Fix-Liste.

  2. Behebung

    Wir beheben die beauftragten Probleme in deinem Code, oder dein Team behebt sie mit unseren Befunden und Hinweisen zu Komponenten.

  3. Retest

    Die ursprünglichen Schritte und benachbarte Zustände werden erneut geprüft. Das Register verknüpft jeden Befund mit Fix und Retest-Ergebnis.
// beweise

Barrierefreiheit in der Produktumsetzung

Wir haben noch kein Kunden-Accessibility-Audit veröffentlicht. Diese Fälle sind angrenzende Arbeit, keine WCAG-Konformitätsaudits. Aniron: responsive Layouts und Barrierefreiheit parallel zur funktionalen Umsetzung eines Developer-Portals. Scramble Wallet: Barrierefreiheit als Teil der Grundlagenarbeit für Nutzer über 50 ohne Krypto-Erfahrung. Soundromeda: die Disziplin aus Nachstellen, Priorisieren und Retest, auf der das Befundformat beruht.

Aniron

Live
Entwicklerportal Kunden-Onboarding, API-Schlüsselverwaltung, Guthabenaufladung und Nutzungsübersicht umgesetzt.

Wavect war Hauptmitwirkender an Anirons Entwickleranwendung: API-Schlüssel, Guthaben, Nutzungsübersicht und Integrationen.

TypeScript Next.js React
AI 2026

Scramble Wallet

Live
50+ Zielaltersgruppe

Browserübergreifende Extension, Tron ergänzt, iOS + Android über mehrere Wege, aufgebaut auf einem Enkrypt-Fork, Schulden Release …

VueJS Typescript NestJS
FUNDS 2023

Soundromeda

Live
Produktion Vibe-Coded → gehärtet

QA-geführtes Härten brachte einen Vibe-Coded-Game-Prototypen in einen Zustand, den Förderkommissionen unterstützten.

BLOCKCHAIN 2025

Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 100+ Produkte ausgeliefert.

Fragen vor dem Start

Nein. Scans finden einen Teil der Probleme und helfen gegen Regressionen. Die wichtigen Aufgaben brauchen trotzdem Tests per Tastatur, Screenreader und Zoom durch einen Menschen.
Nein. Du bekommst ein Befundregister, eine Erklärung zum geprüften Umfang und Retest-Protokolle. Das W3C zertifiziert keine WCAG-Konformität, und wir erklären keine rechtliche Konformität.
Nur wenn du sie beauftragst. Audit, Behebung und Retest werden getrennt vereinbart, damit auch dein eigenes Team beheben kann.
Meist WCAG 2.2 Stufe AA. Zielstufe und zusätzliche Kriterien legen wir im Angebot fest.
Das ist ein eigenständig gescoptes, neueres Angebot, und wir haben noch kein Kunden-Accessibility-Audit veröffentlicht. Die Methode folgt den Prüfempfehlungen des W3C, und die Fälle auf dieser Seite zeigen angrenzende Produktarbeit, in der Barrierefreiheit Teil der Umsetzung war.

Der passende nächste Schritt

Accessibility Audit besprechen

Beschreibe das Produkt, die wichtigsten Abläufe und warum Barrierefreiheit gerade Thema ist. Für das erste Gespräch reicht ein kurzer Überblick ohne vertrauliche Details.

Accessibility Audit besprechen →