Barrierefreiheit ist keine Nacharbeit

Ende 2017 bekam ich über T-Systems MMS einen klar umrissenen Auftrag: Die Barmer-App sollte Dokumente automatisch erkennen, ihre Nutzer besser führen und sich mit VoiceOver besser bedienen lassen. Für die Erkennung gab es seit iOS 11 das Vision Framework. Für VoiceOver gab es vor allem eines: Handarbeit.

Was VoiceOver von einer App braucht

VoiceOver liest vor, was auf dem Bildschirm steht – aber nur das, was die App ihm mitteilt. Ein Knopf, der nur ein Symbol zeigt, heißt für VoiceOver schlicht „Taste“. Damit eine App bedienbar wird, braucht jedes Element:

• eine Beschriftung, die sagt, was es tut („Dokument fotografieren“ statt „Kamera“),
• eine Eigenschaft, die sagt, wie es sich verhält – Taste, Überschrift, ausgewählt,
• eine sinnvolle Reihenfolge, in der VoiceOver die Elemente ansteuert,
• und bei dichten Ansichten eine Gruppierung, damit nicht jede Zahl einzeln vorgelesen wird.

Was ich daraus mitgenommen habe

Nachrüsten kostet mehr als Mitdenken. Wer Barrierefreiheit erst am Ende prüft, baut Ansichten um, die längst fertig waren. Wer Beschriftungen gleich beim Bauen einer Ansicht vergibt, braucht dafür Minuten.

Mit geschlossenen Augen testen. Kein Prüfwerkzeug ersetzt den Selbstversuch: VoiceOver einschalten, Bildschirmvorhang an und die wichtigste Aufgabe der App einmal vollständig erledigen. Wo man selbst hängen bleibt, bleiben auch die Nutzer hängen.

Barrierefreiheit hilft allen. Klare Beschriftungen, große Schrift über Dynamic Type und ausreichende Kontraste machen eine App auch für Menschen besser, die kein VoiceOver nutzen.

Wie ich heute arbeite

Seitdem war Barrierefreiheit in fast jedem großen Projekt Teil meiner Arbeit: bei DENT und von 2021 bis 2026 in der TK-App, an der elektronischen Patientenakte und am TI-Messenger. Dort ging es um VoiceOver mit Labels, Hints, Traits und einer sinnvollen Fokusreihenfolge, um Dynamic Type und ausreichende Kontraste – geprüft mit VoiceOver und dem Accessibility Inspector.

Mit SwiftUI ist vieles leichter geworden: Standard-Elemente bringen Beschriftungen und Eigenschaften mit, und Modifikatoren wie accessibilityLabel sitzen direkt am Element. Trotzdem gehört Barrierefreiheit bei mir in jede Ansicht und nicht in die letzte Woche vor dem Release:

• Beschriftungen entstehen beim Bauen, nicht beim Prüfen.
• Dynamic Type ist von Anfang an eingeschaltet, auch in den größten Stufen.
• UI-Tests finden Elemente über ihre Beschriftung. Fehlt eine, schlägt der Test fehl.
• Seit Xcode 15 läuft in den UI-Tests zusätzlich die automatische Accessibility-Prüfung mit.

Für viele Apps ist das inzwischen auch rechtlich gefordert: Seit Mitte 2025 verlangt das Barrierefreiheitsstärkungsgesetz barrierefreie Angebote etwa im Online-Handel und bei Bankdienstleistungen. Wer von Anfang an mitdenkt, muss dafür nichts umbauen.