Die diesjährige Worldwide Developers Conference (WWDC) von Apple war ein echtes Highlight! Unter den zahlreichen Ankündigungen stellte Apple das neue Apple Vision Pro-Headset vor, das in diesem Jahr wohl verständlicherweise die Show gestohlen hat. Auch wenn Vision Pro nach der WWDC vielleicht das große Gesprächsthema ist, gab es doch auch eine Vielzahl weiterer spannender Neuheiten bei der Apple-Hardware und -Software.
Unter den zahlreichen Ankündigungen gehören die Neuerungen im Bereich Barrierefreiheit jedes Jahr zu meinen Lieblingsaspekten der WWDC, und auch in diesem Jahr gab es wieder eine ganze Reihe von Neuerungen im Apple-Ökosystem, die Entwicklern neue Werkzeuge an die Hand geben, um ihre Apps barrierefrei zu gestalten. Erfahren Sie im Folgenden alles über die diesjährigen Neuerungen im Bereich Barrierefreiheit!
Apple Vision Pro
Das brandneue Apple Vision Pro-Headset war in diesem Jahr mit Abstand einer der größten Stars der Messe. Laut Apple wird das Headset mit den bereits vorhandenen assistiven Technologien der Plattform wie VoiceOver kompatibel sein, und viele der Barrierefreiheitsfunktionen, die auch in anderen Produkten verfügbar sind, werden auf dem Vision Pro-Headset verfügbar sein – allerdings speziell für Spatial Computing neu konzipiert. Die Details zur Barrierefreiheit des Vision Pro sind äußerst spärlich, aber wir hoffen, dass sich das Gerät bei seiner Veröffentlichung tatsächlich als barrierefrei erweisen wird.
Barrierefreier Zugang
„Assistive Access“ ist eine brandneue assistive Technologie für Menschen mit kognitiven Beeinträchtigungen. Diese Technologie ermöglicht es, auf dem iPhone und iPad nur die Funktionen anzuzeigen, die der Nutzer wünscht, wodurch die kognitive Belastung für den Nutzer erheblich reduziert wird. Wenn ein Nutzer beispielsweise nur das Telefon, Fotos und Nachrichten nutzen möchte, kann „Assistive Access“ so eingerichtet werden, dass auf seinem Gerät nur diese Apps verfügbar sind.
„Assistive Access“ ermöglicht nicht nur die Anpassung der App-Verfügbarkeit, sondern auch die Anpassung bestimmter Funktionen innerhalb der Apps. Wenn ein Nutzer beispielsweise ausschließlich mit Worten kommunizieren möchte, kann die Emoji-Tastatur aus der Nachrichten-App entfernt werden, sodass nur noch die Text-Tastatur übrig bleibt.
Wenn der barrierefreie Zugriff aktiviert ist, wird das Geräte-Layout durch eines von zwei Layouts ersetzt: ein rasterartiges Layout, bei dem alle Apps in einem Raster angeordnet sind und das Symbol jeder App stärker hervorgehoben ist als der Text, oder ein zeilenbasiertes Layout, bei dem die Apps eher wie in einer Liste angeordnet sind und Symbol sowie Text gleichermaßen hervorgehoben sind. Der barrierefreie Zugriff kann in den Einstellungen aktiviert und angepasst werden.
Barrierefreiheitsprüfungen
Entwickler können nun bei jedem Build direkt in Xcode Barrierefreiheitsprüfungen für ihre App durchführen. Zwar verfügt der Barrierefreiheits-Inspektor von Xcode über eine Funktion zur Barrierefreiheitsprüfung, doch handelt es sich dabei um einen manuellen Vorgang. Zudem werden die Ergebnisse einer Prüfung im Barrierefreiheits-Inspektor angezeigt, was bei der Behebung von Problemen zu einem häufigen Hin- und Herwechseln zwischen dem Inspektor und Xcode führt … Der Prozess ist also definitiv verbesserungswürdig.
Da Xcode nun über die Möglichkeit verfügt, Barrierefreiheitsprüfungen durchzuführen, ist der Prozess optimiert, automatisiert und effizient. Entwickler können Barrierefreiheitsprüfungen direkt aus den UI-Tests heraus durchführen, und es sind keine Assertions erforderlich, da der Test fehlschlägt, sobald bei der Prüfung Probleme festgestellt werden. Die Ergebnisse einer Barrierefreiheitsprüfung sind leicht verständlich: Fehler werden direkt im Code zusammen mit einer Beschreibung angezeigt, und weitere Details finden sich im Berichtsnavigator.
Im Folgenden finden Sie ein Codebeispiel, das veranschaulicht, wie man im Rahmen eines UI-Tests eine Barrierefreiheitsprüfung durchführt.
func testAccessibility() throws {
let app = XCUIApplication()
app.launch()
try app.performAccessibilityAudit()
}
isToggle-Barrierefreiheitsmerkmal
Lernen Sie .isToggle() kennen, das neue Barrierefreiheits-Merkmal für Steuerelemente mit Umschaltfunktion. Stellen Sie sich ein Szenario vor, in dem eine App ein Element enthält, mit dem Sie einen bestimmten Modus ein- und ausschalten können. Wenn derzeit ein Element vom Typ „Umschalter“ verwendet und barrierefrei gestaltet wird, liest VoiceOver es als „Elementname, Wert, Schaltfläche“ vor.
Schauen wir uns das einmal genauer an … Sicher, ein Steuerelement mit einer Ein-/Aus-Funktion als „Schaltfläche“ zu bezeichnen, ist nicht falsch, aber es ist auch nicht so präzise oder aussagekräftig, wie es sein könnte. Wendet man das Barrierefreiheitsmerkmal .isToggle() auf dieses Element an, liest VoiceOver es als „Elementname, Umschalt-Button, durch Doppeltippen die Einstellung umschalten“ vor; das ist eine viel informativere und genauere Beschreibung des Elements. Aber Moment, es kommt noch besser… das Barrierefreiheitsmerkmal .isToggle() ist sowohl in SwiftUI als auch in UIKit verfügbar!
Hinweise zur Barrierefreiheit
Die neue „Accessibility Notifications“-API ermöglicht es Entwicklern, plattformübergreifende Benachrichtigungen zu erstellen, um Nutzern, die assistive Technologien verwenden, wichtige Informationen zu übermitteln. Wenn diese API implementiert ist, kann Ihre App Benachrichtigungen beispielsweise über Layout- oder Bildschirmänderungen senden, sodass der Nutzer stets über den aktuellen Status der App auf dem Laufenden gehalten wird.
Stellen Sie sich eine App vor, die über eine Schaltfläche verfügt, mit der die Kamera des Geräts geöffnet wird. Mithilfe der Barrierefreiheits-Benachrichtigungs-API können wir dem Nutzer eine Ansage senden, um ihn darüber zu informieren, dass die Kamera geladen wird. Sobald die Kamera geladen und aktiv ist, können wir eine weitere Benachrichtigung senden, um den Nutzer darüber zu informieren, dass die Kamera derzeit aktiv ist.
Diese API bietet sogar die Möglichkeit, Benachrichtigungen eine Priorität zuzuweisen, um Warnmeldungen und Aktualisierungen zu behandeln, die für die Nutzer wichtig sind; dadurch wird sichergestellt, dass VoiceOver wichtige Ankündigungen stets vorliest, während weniger wichtige Ankündigungen übersprungen werden, falls VoiceOver sie nicht rechtzeitig ansagt.
.accessibilityZoomAction-Modifikator
Apple hat uns in diesem Jahr einen sehr coolen neuen Ansichtsmodifikator zur Verfügung gestellt: .accessibilityZoomAction. Wenn eine assistive Technologie aktiviert ist, kann das Vergrößern und Verkleinern von Inhalten schwierig sein; hier kann der .accessibilityZoomActionModifier Abhilfe schaffen. Bei Verwendung dieses Modifikators lassen sich Elemente auch bei aktivierter assistiver Technologie vergrößern oder verkleinern, und es wird sogar eine Barrierefreiheitsansage ausgegeben, wenn sich der Zoom ändert.
„Direct Touch“-Eigenschaft in SwiftUI
Mit dem neuen Merkmal „.allowsDirectInteraction“ können Sie einen Bereich des Bildschirms festlegen, der ein Objekt darstellt, mit dem Benutzer direkt interagieren können, beispielsweise ein Musikinstrument. Stellen Sie sich eine App vor, die ein virtuelles Klavier enthält, bei dem der Benutzer die entsprechende Note hört, wenn eine Taste gedrückt wird; das Standardverhalten von VoiceOver bei der Navigation durch die Klaviertasten wäre, den Namen der Taste anzusagen und anschließend den Klang abzuspielen, der mit dem Drücken der Taste einhergeht.
Dieses Verhalten erschwert es, Tasten in schneller Folge zu drücken. Dies ist ein idealer Anwendungsfall für das Merkmal „.allowsDirectInteraction“, da Sie damit einen Bereich der App festlegen können, in dem VoiceOver-Gesten direkt an die App weitergeleitet werden, so als würde der Nutzer direkt mit einem Element interagieren.
Neben dem Merkmal „.allowsDirectInteraction“ werden zwei neue Optionen für die direkte Berührung unterstützt: „silentOnTouch“ und „requiresActivation“. Kehren wir zu unserem Beispiel einer App mit einem virtuellen Klavier zurück: Die Benutzererfahrung wäre deutlich besser, wenn ein Benutzer eine Klaviertaste berühren und einfach die entsprechende Note hören könnte, ohne dass VoiceOver dies ansagt.
Wenn wir die Option „silentOnTouch“ verwenden, bleibt VoiceOver stumm, sobald eine Klaviertaste berührt wird, sodass der Benutzer den Klang der Taste hören kann, ohne dass zusätzliche Audioansagen von VoiceOver zu hören sind.
Die Option „requiresActivation“ für direkte Berührungen sorgt dafür, dass VoiceOver das Element aktivieren muss, bevor die Berührung an die App weitergeleitet wird. Wenn diese Option festgelegt ist, empfängt ein Element für direkte Berührungen das Berührungsereignis des Benutzers erst dann, wenn es mit VoiceOver aktiviert wurde. Diese Eigenschaft ist in diesem Jahr neu in SwiftUI, ist jedoch bereits in UIKit verfügbar.
Barrierefreiheit – Inhaltstyp
Der neue Typ „accessibilityContentShape“ in SwiftUI ermöglicht es Entwicklern, den Barrierefreiheitspfad eines Elements auf eine vom Entwickler bereitgestellte, bereits vorhandene SwiftUI-Form anzupassen. Betrachten wir ein Szenario, in dem sich kreisförmige Schaltflächen auf dem Bildschirm befinden: Wenn wir mit dem Typ „accessibilityContentShape“ eine Kreisform festlegen, können wir vermeiden, dass der Standard-VoiceOver-Cursor Elemente auf dem Bildschirm verdeckt, da sich die Form des Cursors von der des Elements unterscheidet. Das Tolle am Typ „accessibilityContentShape“ ist, dass seine Verwendung keinen Einfluss auf die Form für die Treffererkennung hat, sondern sich ausschließlich auf die Form des Barrierefreiheitsinhalts auswirkt.
Blockbasierte Attribut-Setter
Blockbasierte Attribut-Setter ermöglichen es Entwicklern, eine Closure anzugeben, die bei Bedarf ausgewertet wird, anstatt den Wert direkt zu speichern. Jedes Mal, wenn eine Ansicht von einer assistiven Technologie aufgerufen oder abgerufen wird, wird die Closure im blockbasierten Attribut-Setter neu ausgewertet; dies erleichtert die Pflege aktueller und korrekter Barrierefreiheitsattribute erheblich. Blockbasierte Attribut-Setter werden für UIKit verfügbar sein.
Zusammenfassung
Die diesjährige WWDC brachte zahlreiche spannende Neuerungen für das Apple-Ökosystem mit sich – vom brandneuen Apple Vision Pro-Headset bis hin zu Erweiterungen der Barrierefreiheitsfunktionen in UIKit und SwiftUI, die Entwicklern dabei helfen werden, ihre Apps barrierefreier zu gestalten. Trotz all der in diesem Jahr vorgestellten neuen Barrierefreiheitsfunktionen ist es wichtig, sich vor Augen zu halten, dass nichts das Testen Ihrer App mit Hilfsmitteln aus erster Hand ersetzen kann! Ich hoffe, ihr habt die WWDC und all die neuen Barrierefreiheits-Features für Entwickler genauso genossen wie ich! Vielen Dank fürs Lesen und viel Spaß beim Programmieren!
