[:de]Accessibility im Web I – Semantische Bedienungselemente[:en]Accessibility on the web I – semantic control elements[:]

[:de]Bis vor einigen Jahren wurden die meisten Websites für eine Bedienung mit der Maus auf einem PC oder Notebook entwickelt. Sich um Zugänglichkeit für Blinde, Sehbehinderte, Hörbehinderte, motorisch oder kognitiv Behinderte zu bemühen galt als lobenswert, aber nicht zwingend notwendig. Auch heute gibt es noch Entscheider und Entwickler, die unter dieser Prämisse arbeiten. Anhand eigener Erfahrungsbeispiele  im Kontext der Entwicklung des Wissensportals der ETH-Bibliothek und des Webauftritts des NEBIS-Verbundes wollen wir aufzeigen, dass die Realität im Web zu einem anderen Vorgehen zwingt. Denn Accessibility, also die barrierefreie Zugänglichkeit von Webinhalten, ist mit Aspekten der Usability (Anwenderfreundlichkeit) des mobilen Webs aufs Engste verwoben.

Abbildung 1: Das Wissensportal der ETH-Bibliothek und die Website des NEBIS-Verbunds

Dieser Beitrag betrachtet exemplarisch ein grundlegendes semantisches Bedienungselement: den Button. Er kann z. B. eine Suche auslösen oder ein Formular abschicken. Das ist soweit intuitiv verständlich. Was passiert aber wenn einem Webdesigner eine Lupe im Suchfeld visuell ansprechender erscheint? Er integriert das Bild der Lupe, jedoch nicht als Button. Die Suche lässt er durch Javascript-Konstrukte beim Drücken der Eingabetaste im Suchfeld auslösen. Optisch ist das elegant.

Abbildung 2: Die Lupe im Suchfeld des Wissensportals

Der Nachteil dieses Vorgehens ist, dass es Software wie Screenreader – also Vorlese-Anwendungen für Blinde und Sehbehinderte – als alternative Benutzerschnittstellen unbrauchbar macht. Darüber hinaus gibt es weitere Implikationen. Derzeit erleben wir den Erfolgszug mobiler Endgeräte, die mit Touchscreens arbeiten. Hier kann uns die vom Webdesigner ansprechend gestaltete Lupe wiederbegegnen. Drückt man mit dem Finger auf das Bild, bleiben zwar Abdrücke auf dem Bildschirm, die Suche löst aber nicht aus. Das hinterlässt den Nutzer ratlos. Ein überflüssiges Ärgernis, denn durch die Implementierung eines Buttons wäre das vermeidbar gewesen. Zumal auch semantische Buttons wie eine Lupe aussehen können.

Echte Buttons sind noch für ein weiteres „magisches“ Verhalten verantwortlich. Selbst eingefleischte Mausbenutzer verwenden ein Login-Formular meist so, dass sie nach der Eingabe des Passwortes direkt die Eingabetaste drücken, um sich anzumelden. Bemühen wir wieder unseren visuell orientierten Webdesigner, so hat dieser ein attraktives Bild eines Buttons genommen und es in einen Link (<a>-Element) eingebettet. Klickt man mit der Maus auf das Bild, funktioniert das durchaus. Die alternative Nutzung der Eingabetaste nach Ausfüllen des Login-Formulars bleibt jedoch verwehrt. Dies hat auch Konsequenzen für die Anwenderfreundlichkeit der Bildschirmtastatur von Smartphones oder Tablets. In ihre Tastaturen ist ein Eingabefeld „Öffnen“ integriert, das Nutzerinnen und Nutzer nach dem Eintippen (z. B. des Passwortes) direkt anwählen können. Auch diese Funktion kann nur dann genutzt werden, wenn ein echter Button verwendet wurde.

Abbildung 3: Beispiel Bildschirmtastatur iPhone

Für viele mag die Bedienung einer Seite mit Tastatur die Ausnahme sein. Für andere ist sie jedoch eine Notwendigkeit. Eine Vielzahl assistiver Technologien für Webanwender mit motorischen oder visuellen Behinderungen basieren auf der Tastatur-Bedienung. Daneben zeichnet sich ab, dass im Rahmen zunehmender Verbreitung mobiler Endgeräte die Finger als Bedienungselement von Touchscreens immer öfter die Maus ersetzen. Auch für Blinde bieten diese Geräte mit dem Screenreader VoiceOver neue Möglichkeiten der digitalen Teilhabe.

Die Aktualisierung des Wissensportals und der Neuaufbau des Webangebots des NEBIS-Verbundes haben uns gezeigt, dass es notwendig ist, schon bei der Planung von Webprojekten barrierefreies Webdesign als Anforderungskriterium klar zu definieren. Idealerweise wird dann das Zusammenspiel von Website-Struktur, Inhalt, Aussehen und Funktionalität während des gesamten Umsetzungsprozesses berücksichtigt. Das bedeutet einen Mehraufwand. Im Ergebnis stehen so jedoch bereits ab dem „Go Live“ eines Webangebots die Zugangshilfen zur Verfügung, die Menschen mit Behinderung benötigen, um dessen Inhalte zu verstehen und sich auf der Website zurecht zu finden. Gleichzeitig können bestimmte Usability-Probleme im Bereich der mobilen Nutzung von Webapplikationen von vorneherein ausgeschlossen werden.

Autor: Bernd Uttenweiler
Koautorin: Maximiliane Okonnek

Dieses Werk unterliegt einer Creative Commons Attribution-ShareAlike 4.0 International Public License.

[:en]Until a few years ago, most websites were designed to be operated via a mouse on a PC or notebook. Efforts to achieve accessibility for the blind, the visually impaired, the deaf or the motorically or cognitively disabled were deemed commendable, but not absolutely necessary. Even today, there are still decision-makers and developers who work according to this principle. Based on examples from our own experience in the context of developing ETH-Bibliothek’s Knowledge Portal and the Website of the Network of Libraries and Information Centres in Switzerland (NEBIS), we aim to illustrate that the reality on the web compels you to adopt a different approach. After all, accessibility – i.e. unhampered access to web contents – is tightly intertwined with aspects of the usability (user-friendliness) of the mobile web.

Figure 1: The Knowledge Portal of ETH-Bibliothek and the Website of NEBIS Network

As an example, this article examines a fundamental semantic control element: the button. It can trigger a search or submit a form, for instance. So far, that’s self-explanatory. But what happens if a magnifying glass in the search field seems more visually appealing to a web designer? He integrates the image of a magnifying glass, but not as a button, and enables the search to be launched via Javascript constructs when the enter key is pressed in the search field. Visually, it’s elegant.

Figure 2: the magnifying glass in the Knowledge Portal’s search field

The drawback with this approach is that it renders software programmes such as screen readers – i.e. reader applications for the blind and visually impaired – unusable as alternative user interfaces. Moreover, there are other implications. We are currently witnessing the success story of mobile terminal devices that work with touchscreens. We might encounter the magnifying glass again here, designed accordingly by the web designer. Touching the image might well leave marks on the display but the search is not launched, which baffles the user – an unnecessary nuisance that could have been avoided by implementing a button, especially since semantic buttons can also look like a magnifying glass.

Real buttons are also responsible for another kind of “magic” behaviour. Even die-hard mouse-users usually utilise a login form in such a way that they press the enter key directly after entering the password to register. Turning to our visually oriented web designer again, he has taken an attractive image of a button and embedded it in a link (<a>-Element). If you click on the image with the mouse, it works fine. The alternative use of the enter key after filling in the login form, however, remains off limits. This also has consequences for the user-friendliness of the display keypad on Smartphones or tablets. An entry field “Open” is integrated in their keypads, which users can select immediately after typing (e.g. the password). This function, too, can only be used if a real button has been utilised.

Figure 3: example of an iPhone Display keypad

For many, operating a page with a keypad might be an exception. For others, however, it’s a necessity. A wealth of assistive technologies for web users with motoric or visual disabilities are based on keypad controls. Besides, it is also apparent that, in light of the growing prevalence of mobile terminal devices, fingers are increasingly replacing the mouse as the control element for touchscreens. These devices also offer new digital participation possibilities for blind people with the screen reader VoiceOver.

The Knowledge Portal upgrade and the reconstruction of the NEBIS website have shown us that it is necessary to already define accessible web design as a requirement in the planning phase for web projects. Ideally, the interplay between the website structure, content, appearance and functionality will then be considered throughout the entire realisation process, which means extra effort and expense. Ultimately, however, this already provides the access aids that people with a disability need to understand the contents of and navigate around a website as soon as it “goes live”.At the same time, this enables certain usability problems involved in the mobile use of web applications to be ruled out from the start.

Author: Bernd Uttenweiler
Coauthor: Maximiliane Okonnek

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International Public License.
[:]