Accessibility Audits

Festpreis-Pakete basierend auf Umfang und Komplexität des Produkts. Ein fokussierter Audit auf einen einzelnen Flow oder eine mobile App beginnt im unteren vierstelligen Bereich. Ein vollständiger Audit einer komplexen Web-Anwendung liegt höher. Audits im öffentlichen Sektor mit BITV-2.0-Konformitäts-Vorbereitung werden individuell skopiert.

WCAG 2.2 (Web Content Accessibility Guidelines) ist der aktuelle internationale Standard, gegliedert in drei Konformitätsstufen (A, AA, AAA). Gegenüber 2.1 kommen neun Kriterien dazu, etwa ein Fokus, der nicht verdeckt wird, Mindestgrößen für Klickziele und eine barrierefreie Anmeldung. AA ist das typische Ziel für die meisten Produkte. BITV 2.0 ist die deutsche Verordnung, die für digitale Produkte des öffentlichen Sektors gilt – sie verlangt mindestens WCAG 2.1 AA-Konformität plus zusätzliche deutsche Anforderungen wie Gebärdensprache und Leichte-Sprache-Inhalte. In der Praxis baut BITV auf WCAG auf, und wer nach 2.2 prüft, deckt 2.1 automatisch mit ab.

Ich bin ausgebildete UX-Designerin mit umfangreicher Accessibility-Praxis in Projekten im öffentlichen Sektor und in Enterprise-Kontexten seit 2017 – einschließlich Produkten zur digitalen Identität bei der Bundesdruckerei und Barrierefreiheits-Arbeit an der Deutschen Telekom Magenta-App. Meine Audits sind gründlich und standardbasiert, aber formale BITV-2.0-Konformitäts-Zertifizierung muss durch eine offiziell benannte Prüfstelle erfolgen. Meine Audits bereiten Produkte auf diesen Schritt vor.

Ja. WCAG 2.2 enthält Kriterien für kognitive Barrierefreiheit (vorhersagbare Navigation, klare Sprache, Fehlervermeidung, keine doppelten Eingaben, Anmeldung ohne Merkaufgaben). Wo BITV 2.0 greift, werden zusätzliche Anforderungen für Leichte Sprache und Gebärdensprache evaluiert. Für Produkte, die spezifisch Nutzer:innen mit kognitiven Bedarfen bedienen, kann tiefere spezialisierte Arbeit empfohlen werden.

Die Fixes können designt werden, wenn sie Design-Probleme sind. Für die Umsetzung wird mit dem Entwicklungsteam des Kunden zusammengearbeitet oder es werden vertrauenswürdige Entwickler:innen empfohlen. Viele Accessibility-Probleme sind nicht im Design sichtbar – sie liegen im Code, in semantischem HTML, in ARIA-Attributen – und diese Fixes passieren in der Entwicklung.

Bis das Produkt sich substanziell ändert. Kleine Änderungen (Content-Updates, kleinere UI-Anpassungen) invalidieren den Audit typischerweise nicht. Große Releases, Redesigns oder Framework-Wechsel rechtfertigen einen Re-Audit. Für Produkte in aktiver Entwicklung halten periodische Re-Audits (alle sechs bis zwölf Monate) die Barrierefreiheit auf Kurs.

Ja. Accessibility-Training und Workshops können Teil eines Engagements sein oder separat arrangiert werden. Das Ziel ist meist, Designer:innen und Entwickler:innen das Wissen zu geben, Barrierefreiheit kontinuierlich zu erhalten, nicht nur an Audit-Meilensteinen.

Das ist das normale Ergebnis – kaum ein Produkt ist beim ersten Audit vollständig WCAG-konform. Der Punkt ist, zu identifizieren, was gefixt werden muss und in welcher Reihenfolge. Kritische Probleme (Blocker für Nutzer:innen mit Behinderungen) kommen zuerst. Ein nicht-bestandener Audit ist der Beginn der Accessibility-Arbeit, nicht das Ende.

Das hängt davon ab, was das Produkt tut und an wen es sich richtet. Das BFSG gilt für Produkte und Dienstleistungen für Verbraucher:innen, etwa Onlineshops, Banking, Telekommunikation, E-Books und Ticketing. Reine B2B-Software fällt in der Regel nicht darunter, und Kleinstunternehmen sind bei Dienstleistungen ausgenommen. Im Scoping-Gespräch kläre ich, welche Anforderungen greifen. Eine verbindliche rechtliche Einschätzung ersetzt das nicht, dafür braucht es eine juristische Beratung.