Schlagwort-Archiv: HTML

Woher kommen eigentlich die Ellen langen Seiten?

Wenn man in seinem Browser mit einem Screenreader gefühlt unendlich oft nach unten wandern kann, wenn die Liste an Links, Schaltern, Registerkarten und Tabellen im mittleren zweistelligen Bereich ist, dann befindet man sich in einer Webanwendung. Machen sich die Entwickler die Mühe so lange Seiten zu erstellen? Können sie nicht einfach kurze und übersichtliche Dialoge entwerfen?

Nein, denn die Seiten werden i.d.R. aus einer Reihe von Bausteinen generiert. Natürlich entscheiden die Entwickler darüber, welche Komponenten an welcher Stelle ihrer Anwendung angezeigt werden, aber sie sind dabei immer mehr vom HTML-Text entfernt, der beim Anwender im Browser angezeigt wird. Aus wenigen Skriptaufrufen oder deklarierten Komponenten werden dadurch im nu lange und komplexe HTML-Dokumente, die vom Browser einerseits und vom Screenreader andererseits interpretiert werden müssen.

Während bei der Verwendung von PHP der Entwickler den generierten HTML-Code noch relativ gut beeinflussen kann und ungefähr weiß, wie der Code an Ende aussieht, ist dies bei Frameworks wie JSF anders. Der Entwickler deklariert in XML- und XHTML-Dokumenten den Seitenaufbau, deren Verknüpfung und bettet Aktionen etc. ein. Die Objekte mit denen er hantiert sind direkt an die Anwendungslogik gekoppelt, die in Java erstellt wird. Was am Ende tatsächlich im HTML-Code steht, entscheidet die JSF-Implementierung (JSF ist nämlich nur eine Spezifikation). Die Seiten werden also eher komponiert und durch abstrakte Regeln wird ihre Verknüpfung festgelegt.

Beratung bei der Gestaltung von Barrierefreien Seiten

Bislang haben sich die Spezialisten den HTML-code der Seiten angesehen und darauf basierend gezielt Hinweise gegeben, wie die Barrieren entfernt werden können. Das können sie zwar auch bei Webanwendungen tun, aber die verantwortlichen Entwickler haben kaum Kenntnis über den HTML-code, den sie generieren. Sie können ihn auch nur im Rahmen der Möglichkeiten von JSF und den Implementierungen beeinflussen. Damit sind sie in der gleichen Situation, wie die Entwickler von Desktop-Anwendungen. Damit solche Webanwendungen möglichst zugänglich bzw. barrierefrei sind, müssen zunächst die JSF-Implementierungen wie
Prime Faces korrekten Code im Sinne der WCAG erstellen.

JSF-Anwendungen kommen vor allem bei beruflichen Anwendungen zum tragen, weil sie eine komplexe Infrastruktur benötigen und auf verteilte und komplexe Logik ausgerichtet sind. Weil sich in diesem Kontext meistens keine Alternativen Anwendungen verwenden lassen (Ein Unternehmen installiert solche Anwendungen aus handfesten Gründen), wiegen Barrieren hier schwerer als bei Anwendungen im privaten Umfeld.

Wie bei Desktopanwendungen auch, ist die Zugänglichkeit durch das zugrundeliegende Framework eine Grundvoraussetzung, aber alleine nicht ausreichend. Nur der Entwickler weiß, welche Bereiche der Anwendungen mit welchen ARIA-Rollen ausgestattet werden müssen – welche Semantik die Informationen in einem bestimmten Bereich haben. Erst mit der neuesten JSF-Spezifikation ist es möglich geworden, solche Informationen über die Komponenten in den generierten HTML-Code einzuwerfen. Dies muss nun von den Implementierungen unterstützt und umgesetzt werden.
Der folgende Link beschreibt die Situation der Webanwendungen und die technischen Abhängigkeiten recht gut und nachvollzieh bar.
http://blog.akquinet.de/2013/07/26/the-state-of-web-accessibility-in-the-javaee-world/

Der folgende Link verweist auf ein Buch zu JSF und macht die Mächtigkeit und Tragweite von JSF für Webanwendungen deutlich.
http://jsfatwork.irian.at/book_de/jsf.html

Barrieren liegen auf der Lauer

Nun könnte man meinen, dass sich erst bei komplexen Tabellen und überfrachteten Seiten ernsthafte Probleme einstellen. Die Hindernisse finden sich aber schon in viel banaleren Situationen. Z.B. dann, wenn man einen Baum (z.B. ein Inhaltsverzeichnis oder eine Ordnerstruktur) darstellen möchte. Wenn man Glück hat, dann wird die Struktur aus wild in einander geschachtelten Listen zusammengesetzt. Das ist zwar nicht übersichtlich, aber wenigstens kann man den Inhalt lesen. Weil parallele Knoten in einzelnen Listen dargestellt werden, können hier Teile der Navigationstasten des Screenreaders nicht mehr helfen. Wenn man pech hat, und das erwähnte Prime Faces zum einsatz kommt, dann erkennt der Screenreader, dass eine Baumstruktur vorhanden ist, kann sie aber überhaupt nicht auslesen. Das wäre dann i.d.R. ein Knockout-Kriterium für die Zugänglichkeit einer Anwendung, weil sich in solchen Bäumen oft zentrale Informationen wiederfinden.