Hey Siri, schalte VoiceOver an!

In der heutigen digitalen Welt ist Barrierefreiheit nicht nur ein Schlagwort, sondern eine Notwendigkeit – spätestens mit dem Barrierefreiheitsstärkungsgesetz (BFSG), welches 2025 in Kraft tritt. Doch über gesetzliche Anforderungen hinaus geht es um das Etablieren eines “accessible mindset” – einer Einstellung, die Entwickler*innen, Designer und Manager gleichermaßen betrifft. Barrierefreiheit – auch “Accessibility” oder kurz “A11y” genannt – sollte nicht als optional angesehen werden, sondern als integraler Bestandteil jeder digitalen Anwendung. Unser Ziel ist es, sicherzustellen, dass alle Nutzer*innen uneingeschränkten Zugang zu unseren Anwendungen haben, ohne dabei auf Hindernisse zu stoßen.

Apple bietet mit seinem Accessibility Framework zahlreiche Möglichkeiten, barrierefreie Lösungen effizient umzusetzen. Allerdings können die vielen Optionen oftmals überwältigend wirken und die Frage aufwerfen, wo man am besten beginnt. Deshalb fangen wir heute klein an und starten mit der VoiceOver Technologie. Dieser Einstieg ermöglicht es uns, einen ersten Einblick in das Accessibility Framework von Apple zu gewinnen und zu verstehen, wie barrierefreie Lösungen praktisch umgesetzt werden können. Dazu vermittelt es einen Eindruck davon, wie die spätere Implementierung verschiedener Accessibility-Features aussehen könnte. Es handelt sich um einen praxisnahen Umsetzungsfall, der zeigt, wie wir durch gezielte Maßnahmen die Zugänglichkeit unserer Anwendungen verbessern können.

Beim VoiceOver handelt es sich um eine Bildschirmlesefunktion, die es ermöglicht, das Endgerät auch mit visuellen Einschränkungen nutzen zu können. Die Bildschirmelemente werden mit gesprochenem Feedback und hörbaren Beschreibungen ergänzt. Dazu gehören Icons, Schaltflächen sowie Text und Bilder, damit die Benutzer*innen einfach und präzise auf dem Gerät navigieren können.

Um einen Eindruck davon zu bekommen, wie die VoiceOver-Features funktionieren, gibt es verschiedene Möglichkeiten, diese auszuprobieren. Auf einem iPhone kann VoiceOver ganz einfach über die Einstellungen aktiviert oder deaktiviert werden. Dazu navigiert man zu den Bedienungshilfen und wählt dort die Option VoiceOver aus. Eine praktische Alternative ist es, einen Kurzbefehl einzurichten, der es ermöglicht, VoiceOver durch dreifaches Klicken der Home-Taste ein- oder auszuschalten. Zusätzlich kann VoiceOver auch über Siri aktiviert oder deaktiviert werden. Ein einfacher Sprachbefehl wie “VoiceOver einschalten” oder “VoiceOver ausschalten” genügt, um die Funktion bequem zu steuern.

Es gibt einen Pool von Quick-Wins, die es ermöglichen eine solide Basis für die weitere Integration von Accessibility Features zu legen. 

isAccessibilityElement: Bool

Dieser Boolean-Wert steuert, ob das Element von den Accessibility-APIs als zugänglich erkannt wird. Wenn dieser Wert auf true gesetzt ist, wird das Element von Hilfstechnologien wie VoiceOver berücksichtigt. Andernfalls wird es ignoriert.

accessibilityTraits: UIAccessibilityTraits

Dieses Attribut hilft den Accessibility-APIs, die Rolle des Elements zu verstehen. Es gibt Auskunft darüber, welche Art von Element es ist, wie z.B. eine Schaltfläche, ein statischer Text oder ein Schieberegler. Dadurch können Hilfstechnologien den Benutzer*innen besser vermitteln, was das Element macht oder darstellt.

accessibilityFrame: CGRect

Dieses Attribut beschreibt, wo sich das Element auf dem Bildschirm befindet und zwar in Bildschirmkoordinaten. Es ermöglicht den Accessibility-APIs, den genauen Bereich des Elements zu kennen, sodass z.B. ein Screenreader oder andere Hilfsmittel den richtigen Bereich ansteuern können.

accessibilityLabel: String

Eine kurze und prägnante Zeichenfolge, die das Element beschreibt. Diese Beschreibung sollte so gewählt sein, dass sie den Benutzer*innen sofort klar macht, worum es sich bei dem Element handelt. Wichtig ist, dass diese Beschreibung lokalisiert wird, damit sie für User in verschiedenen Sprachen verständlich ist.

accessibilityValue: String

Dieser String gibt den aktuellen Wert des Elements an, falls es einen solchen gibt. Zum Beispiel könnte ein Textfeld die Bezeichnung “Punktestand” haben, während accessibilityValue den tatsächlichen Punktestand enthält. Auch dieser Wert sollte lokalisiert werden, um für Benutzer*innen in verschiedenen Sprachen verständlich zu sein.

accessibilityHint: String

Ein kurzer Hinweis, der beschreibt, was passieren wird, wenn User mit dem Element interagieren. Dieser Hinweis sollte ebenfalls lokalisiert werden, damit Benutzer*innen in ihrer jeweiligen Sprache verstehen können, welche Aktion durchgeführt wird, wenn sie das Element auswählen.

Die sechs UIAccessibility Elemente bieten eine solide Grundlage, um den Kontext einer App klarer und verständlicher zu gestalten, insbesondere aus technischer Sicht. Obwohl viele Apps grundlegende Unterstützung für Accessibility “out of the box” bieten, ist diese Unterstützung oft auf einfache, standardisierte Elemente beschränkt. Ohne die gezielte Nutzung und Konfiguration von Accessibility-Attributen wie accessibilityLabel, accessibilityValue und anderen, fehlt es den assistiven Technologien häufig an der nötigen Tiefe, um den vollständigen Kontext einer App zu erfassen. Zum Beispiel könnte es für eine App schwierig sein, klar zu kommunizieren, welche Informationen zusammengehören oder welche Interaktionen sinnvoll sind. Hier kommt das UIAccessibilityElement ins Spiel. Es bietet Entwickler*innen die Möglichkeit, mehrere einzelne Informationen oder UI-Komponenten zu einem logischen Block zusammenzufassen. Dadurch können zusammengehörige Informationen als Einheit behandelt werden, was das Verständnis und die Navigation für Nutzer*innen von Hilfstechnologien erheblich verbessert.

Mit dem Release von SwiftUI 3 wurde eine erweiterte Accessibility API eingeführt, die die Navigation für Menschen mit Einschränkungen erheblich erleichtert. Ein zentrales Element dieser API ist der accessibilityRotor View Modifier, der es ermöglicht, wichtige Ankerpunkte innerhalb einer Anwendung gezielt anzusteuern. Während visuelle Nutzer*innen schnell den Kontext einer Anwendung erfassen können, etwa durch Überschriften, Formatierungen oder Layouts, bietet der Rotor Control für Nutzer*innen von Screenreadern eine vergleichbare Funktionalität. Er erlaubt es, bestimmte Kategorien von Inhalten – wie beispielsweise nur Überschriften, Links oder Schaltflächen – in einer schnellen, strukturierten Weise zu durchlaufen.

Die accessibilityRotor-Funktionalität geht jedoch über vordefinierte Kategorien hinaus. Entwickler*innen haben die Möglichkeit, eigene Rotoren zu implementieren und spezifische Ankerpunkte festzulegen, die auf die Anforderungen und den Kontext der jeweiligen App abgestimmt sind. Dadurch können Nutzer*innen mit Einschränkungen gezielt durch relevante Informationen navigieren, ohne sich durch irrelevante Inhalte durcharbeiten zu müssen.

Ein praktisches Beispiel: Mithilfe eines benutzerdefinierten Rotors könnte eine Shopping-App es ermöglichen, dass blinde oder sehbehinderte Nutzer*innen nur durch Produktbewertungen, Preisangebote oder Verfügbarkeitsinformationen navigieren. Dies verkürzt die Zeit zur Informationsfindung und verbessert die Usability.

Insgesamt trägt der accessibilityRotor erheblich zur Barrierefreiheit bei, indem er die Benutzererfahrung für eingeschränkte Nutzer*innen individualisierbar und effizienter gestaltet. Dies fördert eine integrativere App-Nutzung und gibt Entwickler*innen die Werkzeuge, um ihre Apps noch benutzerfreundlicher und zugänglicher zu gestalten.

Dieser Blogbeitrag hat durch den Überblick der Quick-Wins und dem Rotor Control einen ersten Einblick in die VoiceOver- und Accessibility-Welt von Apple gegeben. Als Entwickler*innen haben wir die Möglichkeit, durch gezielte Maßnahmen wie die Integration von VoiceOver und anderen Accessibility-Features Apps für alle Benutzer*innen zugänglicher zu machen. Apples Accessibility Framework bietet hier eine solide Basis, jedoch darf dies nicht als Endpunkt betrachtet werden. Ein integrativeres, barrierefreies Design sollte als Standard und nicht als Ausnahme betrachtet werden, um eine wirklich inklusivere digitale Welt zu schaffen.