ADF und Barrierefreiheit Einführung in die Entwicklung barrierefreier

Fachartikel 2012
ADF und Barrierefreiheit
Einführung in die Entwicklung barrierefreier Webanwendungen
von Patrick Olschewsky
ADF und Barrierefreiheit Einführung in die Entwicklung barrierefreier Webanwendungen Patrick Olschewsky 29.12.2012 Inhalt Einleitung ................................................................................................................................................ 1 Beispiele ................................................................................................................................................. 2 Aktivierung des barrierefreien Modus ........................................................................................... 2 Sortierung von Tabellenköpfen ...................................................................................................... 3 JAWS zeigt alle Ebenen auf der höchsten Ebene an, eine Schachtelung ist nicht vorhanden ........ 4 Elemente, die (visuell) nicht vorhanden sind, werden von JAWS vorgelesen ................................ 4 Auf Toolbar-­‐Buttons verzichten ...................................................................................................... 4 Aufführen der gefundenen Treffer sowie des fachlichen Hintergrunds bei der Fokussierung auf eine Tabelle .................................................................................................................................... 5 Vermeidung von outputText-­‐Elementen ........................................................................................ 5 Verwendung von Landmarks .......................................................................................................... 5 Hochkontrasttheme für LUNAR ...................................................................................................... 6 Verwendung eines Titels für das die Anwendung umschließende iFrame ..................................... 6 Einleitung Die Bundesregierung fordert, dass Webseiten und Software barrierefrei veröffentlicht werden sollen. Dies trifft auf Intranet, Internet und Softwareoberflächen zu, die öffentlich zugänglich sind.. Die Prüfung auf Barrierefreiheit führen wir hauptsächlich für zwei Personengruppen: Blinde sowie schwer Sehbeeinträchtigte. Für blinde Benutzer nutzen wir Vorlese-­‐Software JAWS, für schwer Sehbeeinträchtigte LunarPlus. JAWS liest den Bildschirminhalt aufgrund des aktuellen Fokus vor, LunarPlus/SuperNova ermöglicht es mittels einer Softwarelupe den Bildschirminhalt zu vergrößern (bis zu achtfache Vergrößerung) sowie verschiedene Kontrastthemes zu aktivieren, um den Inhalt besser lesen zu können. Ohne die Prüfung kann keine Veröffentlichung der Anwendung geschehen. Ein normaler Freigabeprozess ist wie folgt abgebildet: 1. Test -­‐> eventuelle Fehlerbeseitigung -­‐> 2. Test mit darauffolgender erfolgreicher Abnahme. Werden bei dem 2. Test wiederum Fehler gefunden, können sich weitere Tests bis zur endgültigen Abnahme anschließen. ADF verfügt von Haus aus über einen barrierefreien Modus – dennoch sind von den Entwicklern einige Schritte notwendig, um das Programm erfolgreich durch den barrierefreien Test zu führen. Beispiele Aktivierung des barrierefreien Modus Die Aktivierung des barrierefreien Modus erfolgt über die Angabe des Wertes screenReader im Attribut <accessibility-­‐mode> der Konfigurationsdatei trinidad-­‐config.xml. Um die Möglichkeit zur Verfügung zu stellen, zwischen den verschiedenen Ansichtsmodi zu wählen, hat es sich etabliert, eine eigene ManagedBean zu schreiben (z.B. UserSettingsBean), die im SessionScope liegt und die Information über den aktuellen Ansichtsmodus zwischenspeichert. In der trinidad-­‐config wird anschließend lediglich auf eine get-­‐Methode der Bean verwiesen, die den aktuellen Modus zurückgibt. Oberfläche: <af:commandLink text="Barrierefreien Modus ausschalten" id="cl1" action="#{usersettingsBean.toggleAccessibility}" rendered="#{sessionScope.usersettingsBean.accessibilityMode eq 'screenReader'}" inlineStyle="white-­‐space:nowrap"/> <af:commandLink text="Barrierefreien Modus einschalten" id="cl2" rendered="#{sessionScope.usersettingsBean.accessibilityMode eq 'default'}" action="#{usersettingsBean.toggleAccessibility}" inlineStyle="white-­‐space:nowrap"/> Trinidad-­‐config.xml: <accessibility-­‐mode>#{accessibility.accessibilityMode}</accessibility-­‐mode> <accessibility-­‐profile>#{accessibility.accessibilityProfile}</accessibility-­‐profile> UserSettingsBean (Auszug): public class UserSettingsBean { private boolean isAccessibilityModeOn = false; private volatile AccessibilityProfile _profile; private boolean highContrast = false; public String getAccessibilityMode() { if(isAccessibilityModeOn) { return "screenReader"; } else { return "default"; } } public String toggleAccessibility() { this.isAccessibilityModeOn = !this.isAccessibilityModeOn; this.highContrast = !this.highContrast; this._profile = null; refreshCurrentPage(); return null; } public AccessibilityProfile getAccessibilityProfile() { if (_profile == null) { synchronized (this) { if (_profile == null) { _profile = _createAccessibilityProfile(); } } } return _profile; } private AccessibilityProfile _createAccessibilityProfile() { AccessibilityProfile.ColorContrast colorContrast = isHighContrast() ? AccessibilityProfile.ColorContrast.HIGH : AccessibilityProfile.ColorContrast.STANDARD; AccessibilityProfile.FontSize fontSize = AccessibilityProfile.FontSize.MEDIUM; return AccessibilityProfile.getInstance(colorContrast, fontSize); } Sortierung von Tabellenköpfen Problem: „Die Tabellenköpfe sagen nur an, dass man sortieren kann, aber nicht, ob eine Sortierung für die Spalte vorliegt.“ Lösung: JAWS liest nur die Informationen vor, die einer Komponente hinterlegt sind. Das Standardverhalten einer ADF-­‐Tabelle hat keine (Fließtext-­‐) Informationen, die dem Benutzer sagt, welche Art der Sortierung vorliegt. Aus diesem Grund ist es notwendig, einen eigenen Sortierungs-­‐Listener zu schreiben und jeder sortierbaren Tabelle zu hinterlegen. ADF: sortListener="#{pageFlowScope.controller.tabellenSortierungListener}" Java: public void tabellenSortierungListener(SortEvent sortEvent) { final String ABSTEIGEND = " (absteigend sortiert)"; final String AUFSTEIGEND = " (aufsteigend sortiert)"; List<SortCriterion> criterias = sortEvent.getSortCriteria(); Object o = sortEvent.getSource(); if (o instanceof RichTable) { RichTable table = (RichTable)o; List<UIComponent> columns = table.getChildren(); for (UIComponent columnComponent : columns) { RichColumn column = (RichColumn)columnComponent; String columnSortProperty = column.getSortProperty(); String oldHeader = column.getHeaderText(); String newHeaderText; if (oldHeader == null) continue; if (oldHeader.contains(ABSTEIGEND)) { newHeaderText = oldHeader.substring(0, oldHeader.length() -­‐ ABSTEIGEND.length()); } else if (oldHeader.contains(AUFSTEIGEND)) { newHeaderText = oldHeader.substring(0, oldHeader.length() -­‐ AUFSTEIGEND.length()); } else { newHeaderText = oldHeader; } for (SortCriterion crit : criterias) { if (columnSortProperty == null ) continue; if (columnSortProperty.equals(crit.getProperty())) { newHeaderText = newHeaderText + (crit.isAscending() ? AUFSTEIGEND : ABSTEIGEND); } break; } column.setHeaderText(newHeaderText); } } } JAWS zeigt alle Ebenen auf der höchsten Ebene an, eine Schachtelung ist nicht vorhanden Problem: Die Informationsstruktur wird nicht korrekt wiedergegeben. Inhaltsboxen, die innerhalb einer übergeordneten Inhaltsbox gruppiert werden, werden nicht als Überschriften der zweiten Ebene kenntlich gemacht (h1, h2). Alle Überschriften sind auf der gleichen Ebene. Lösung: Auf die Verwendung von PanelBox-­‐Komponenten sollte verzichtet werden. JAWS erzeugt aus den PB-­‐Komponenten eine fehlerhafte Hierarchie. Stattdessen ist der Einsatz von PanelHeadern vorzuziehen; diese werden anstatt der PanelBoxen verwendet. <af:panelHeader size="-­‐1" […..]/> Elemente, die (visuell) nicht vorhanden sind, werden von JAWS vorgelesen Problem: Es werden teilweise Links „Informationen“ vorgelesen die in der Oberfläche gar nicht vorhanden sind (weder visuell noch ist ein auslösen der Links möglich). (Es scheint als ob das verlinkte Informationsicon für das Tooltipp Popup vorgelesen wird, auch wenn dieses gar nicht vorhanden ist.) Lösung: ADF erzeugt für jede Komponente eine Eingabehilfe, die z.B. bei Datumsfeldern als Symbol gekennzeichnet werden. Bei einem Klick auf dieses Symbol erschein der Kalender. Für Komponenten, die keine Hilfe angezeigt bekommen, erzeugt ADF trotzdem diese Symbole, kennzeichnet sie allerdings als visible: hidden. JAWS erkennt dies nicht von Haus aus und liest die Symbole trotzdem vor. Der Hersteller von JAWS hat das Programm mittels eines Patches nachgebessert, dieses Fehlverhalten sollte in Zukunft nicht mehr auftreten. Auf Toolbar-­‐Buttons verzichten Problem: „Visuelle Buttons“ werden nur als Link vorgelesen, obwohl JAWS durchaus zwischen Buttons und Links unterscheidet. Lösung: ADF-­‐Toolbar-­‐Buttons werden von JAWS intern fehlerhaft gerendert; JAWS erkennt wegen der von ADF erzeugten HTML-­‐DIV –Renderung keine Buttons. Aus diesem Grund ist auf die Verwendung von <adf:toolbarButton> zu verzichten, es werden <adf:commandButton> bevorzugt. Aufführen der gefundenen Treffer sowie des fachlichen Hintergrunds bei der Fokussierung auf eine Tabelle Problem: Dem Benutzer stehen keine Informationen über die gefundenen Treffer sowie dem fachlichen Kontext der Ergebnistabelle zur Verfügung, wenn eine Suche erfolgreich abgeschlossen wurde. Lösung: Eine Tabelle sollte dem Benutzer mittels des summary-­‐Attributs und ADF-­‐EL die Informationen liefern, wie viele Suchergebnisse die Tabelle sowie welche Art von Treffern die Tabelle enthält. ADF: summary="#{pageFlowScope.controller.summeBetriebeSucheTreffer} Treffer. Tabelle enthält alle nach ihren Suchkriterien gefundenen Betriebe" Java: public Integer getSummeBetriebeSucheTreffer() { if (betriebSucheResult != null) { return betriebSucheResult.size(); } return 0; } Vermeidung von outputText-­‐Elementen Problem: JAWS erkennt keinen Fokus auf Texte, die mittels outputText-­‐Elementen angezeigt werden und springt über diese Texte hinüber; dem Anwender werden diese Informationen nicht vorgelesen, sie gehen verloren. Lösung: Anstelle von outputText sollen inputText-­‐Elemente verwendet werden, deren Schreitattribut mittels readOnly=true deaktiviert wurden. Verwendung von Landmarks WAI ARIA Landmarks sind ein zukünftiger, vom w3c definierter Standard, der sich momentan in der Entwurfsphase befindet und der die Navigation für Benutzer mit Vorlesesoftware erleichtern soll. Landmarks werden in der Vorlesesoftware JAWS wie folgt dem Benutzer dargestellt und vorgelesen: Komponenten, denen man Landmarks zuweisen kann, sind panelGroupLayout, panelSplitter,
panelStretchLayout sowie decorativeBox.
Beispiel: <af:panelGroupLayout id="pt_pgl1" layout="vertical" landmark="main"> Hochkontrasttheme für LUNAR Schwer sehbeeinträchtigte Personen, die den Bildschirminhalt lediglich mittels einer Softwarelupe sowie hohen Kontrasts erkennen können, ist darauf zu achten, dass bei der Aktivierung des barrierefreien Modus ebenso der Kontrast sowie die Schriftgröße erhöht werden. Dies wird in der unter Punkt 1 angesprochenen UserSettingsBean sowie mittels des Attributs <accessibility-­‐profile> in der trinidad-­‐config.xml bewerkstelligt. Auszug: trinidad-­‐config.xml: <accessibility-­‐profile>#{accessibility.accessibilityProfile}</accessibility-­‐profile> UserSettingsBean: private AccessibilityProfile _createAccessibilityProfile() { AccessibilityProfile.ColorContrast colorContrast = isHighContrast() ? AccessibilityProfile.ColorContrast.HIGH : AccessibilityProfile.ColorContrast.STANDARD; AccessibilityProfile.FontSize fontSize = AccessibilityProfile.FontSize.MEDIUM; return AccessibilityProfile.getInstance(colorContrast, fontSize); } Verwendung eines Titels für das die Anwendung umschließende iFrame Problem: Auf allen Seiten gibt es einen Rahmen „faces / index“ und einen Link beginnend mit „faces/index?_adf.no-­‐new-­‐window-­‐redirect=true&_ …“ Lösung: Das iFrame, im dem die Anwendung läuft, wird standardmäßig nicht mit einem Titel erstellt. Dies hat zur Folge, dass beim Einstieg in eine beliebige Seite JAWS nicht den Titel der Seite vorliest, sondern „faces/index“. Um dieses Problem zu beheben, ist in der index.jsp das iFrame zu erweitern: <iframe src="${pageContext.servletContext.contextPath}/faces/index" class="full" frameborder="0" id="app" title="Anwendungstitel"/>