Bei der Entwicklung von Applikationen sind neben User Experience (UX), Usability und Mobilfähigkeit zunehmend auch Kriterien für die Barrierefreiheit zu beachten. In einigen Bereichen, wie z.B. beim Webauftritt des Bundes, ist diese sogar gesetzlich geregelt. Für die Barrierefreiheit in SAPUI5 hat SAP bereits beim Design Prinzipien bedacht, um Screenreader Lesbarkeit sowie andere Barrierefreiheitskriterien zu unterstützen. Jedoch wurde dies leider nicht überall konsequent umgesetzt.

Wenn Sie für Ihre SAPUI5 Anwendung eine Zertifizierung auf Barrierefreiheit z.B. nach Überprüfung auf BITV 2.0 oder WCAG 2.0 anstreben, dann sollten Sie das idealerweise im ganzen Entwicklungsprozess berücksichtigen. Eine gezielte Schulung der Entwickelnden, Beratenden und Testenden ist hierbei essenziell. Schließlich sind Fehler aus der Konzeption und frühen Entwicklung in späteren Phasen nur mit sehr viel Aufwand zu korrigieren. Vergleichbar zur Entwicklung von barrierefreien Anwendungen mit anderen Frameworks muss auch bei SAPUI5 Anwendungen zum Erfüllen aller Kriterien auf Controls verzichtet, Controls umgebaut oder es müssen Workarounds gefunden werden.

Kriterium Anwendergruppe

Zunächst sollten Sie sich klar machen, wer Anwender Ihrer SAPUI5 Anwendung sein wird. Sind Ihre Anwender ggf. das ganze World Wide Web, Ihre eigenen Mitarbeiter oder nur einige speziell geschulte Power-User?
Beim Anstreben einer Zertifizierung müssen natürlich alle Kriterien der Barrierefreiheit abgedeckt sein und eine Anwendung sollte sich vergleichbar zu einer gewöhnlichen Website bedienen lassen. Sollte sich der Kreis Ihrer Anwendung jedoch „nur“ auf Ihre eigenen Mitarbeiter oder einige wenige Power-User beschränken, besteht die Möglichkeit, Hinweise zur Bedienung von SAPUI5 Anwendungen und Shortcuts bereits durch interne Schulungen zu vermitteln.

Es lassen sich beispielsweise Tabellenzeilen vom SAPUI5 Control sap.m.Table in denen das Löschen zulässig ist mithilfe der Entfernentaste löschen. Darauf würde ein in SAPUI5-Applikation nicht geschulter Screenreader Anwender aber nicht unbedingt kommen.
Für eine Anwendung, die einer breiten Masse zur Verfügung gestellt wird, könnte man wie folgt vorgehen:

1. Sie könnten auf den Löschenmodus gänzlich verzichten und das Löschen durch eine Spalte mit Löschbuttons ermöglichen
2. Auf das Löschen per Entfernentaste könnten Sie vor dem betreten der Anwendung hinweisen.

Zulässige Libraries für Barrierefreiheit in SAPUI5

Controls aus folgenden Libraries bieten Menschen mit Sehbeeinträchtigung einen Screenreader Support nach dem ARIA Standard (vgl. Quelle):

• sap.m
• sap.suite.ui.commons
• sap.tnt
• sap.ui.commons
• sap.ui.comp
• sap.ui.core
• sap.ui.generic
• sap.ui.layout
• sap.ui.suite
• sap.ui.table
• sap.ui.unified
• sap.ui.ux3
• sap.uxap
• sap.viz

Nach meiner eigenen Erfahrung sind aber auch hier viele Controls nicht optimal für Screen Reader Anwender ausgelegt. So erzeugt z.B. das Control sap.uxap.ObjectPageLayout so viele verschachtelte Seitenregionen pro Abschnitt und Unterabschnitt, dass der ursprüngliche Sinn von Seitenregionen einen schnellen Überblick zu gewinnen, ad absurdum geführt wird.

Navigierbarkeit und Erreichbarkeit von Elementen in SAPUI5

Die Tastennavigierbarkeit in SAPUI5 Anwendungen ist nicht nur für Screenreader Anwender von äußerster Wichtigkeit. Auch Menschen mit motorischen Beeinträchtigungen müssen sich darauf verlassen können alle Teile der Anwendung über die Tastatur erreichen zu können. Hier liegt jedoch die größte Schwäche bei SAPUI5 und leider sind viele Nachbearbeitungen nötig.

Das role application Problem

Da die SAPUI5 Anwendungen nicht zur klassischen redaktionellen Ausgabe von Texten, sondern als interaktive Webanwendung gedacht ist, wird das Anwendungs-Attribut role application ausgezeichnet.

Wenn man einen Text beispielsweise über die Controls sap.m.FormattedText oder sap.m.Text ausgibt, lassen sich die Texte von üblichen Screenreadern NVDA (NonVisual Desktop Access) und JAWS nicht ohne weiteres vorlesen. Das liegt daran, dass die Screenreader SAPUI5 Anwendung durch das Attribut role application per Standard im Anwendungsmodus öffnet. Hier müsste der Screenreader Anwender nun willentlich per Shortcut in den Dokumentenmodus wechseln, was dem größten Teil der Screenreader Anwender jedoch unbekannt ist.

Das Toolbar-Problem

Viele Controls wie z.B. sap.m.Toolbar kennzeichnen einen Bereich als Toolbar, obwohl die Deklaration als Toolbar gemäß W3C Richtlinien nicht berechtigt ist (vgl. Quelle).
Wenn ein Bereich als Toolbar gekennzeichnet ist, muss diese per Pfeiltaste navigierbar sein. Dies ist aber bei den meisten Controls, die das Attribut in SAPUI5 setzen, nicht gegeben. Auch hier muss Abhilfe geschaffen werden.

Fazit zur Barrierefreiheit in SAPUI5

Die angesprochenen Probleme sind nur eine kleine Übersicht auf die Sie bei der Vorbereitung auf eine Zertifizierung stoßen können. Aus meiner Sicht scheint der größte Makel der verpflichtende Anwendungsmodus zu sein. Denn den kann man standardmäßig nicht ausschalten. Ich hoffe, dass in der Zukunft ein größeres Bewusstsein dafür entsteht und der Dokumentenmodus auch für redaktionellen Content verfügbar gemacht wird. Selbst innerhalb der verschiedenen SAPUI5 Versionen gibt es im Ausmaß der Unterstützung von Barrierefreiheit große Unterschiede. Alle von mir genannten Punkte lassen sich jedoch glücklicherweise durch Custom Controls, JQuery, einbinden von nativen HTML Tags oder austauschen von Controls lösen.

Falls Sie weitere Informationen benötigen, wie Sie Ihre SAPUI5 Anwendung barrierefrei gestallten können, kontaktieren Sie uns gerne unter info@diokles.de.