Hi, der Ziel vorweg, ich starte mit Kopfschmerzen und höre dann ohne Kopfschmerzen auf.

Bei euch ist das umgekehrt.

Das wird jetzt durchaus ein bisschen technischer als die drei Vorträge zuvor.

Ich arbeite bei der Deutschen Telekom an der Heimautomationslösung KiliCon und im Rahmen

dieses Home Automation Systems beschäftige ich mich mit den Web UIs zur Konfiguration

des Smart Homes.

Vor knapp anderthalb Jahren haben wir angefangen, eine neue Applikation aufzuziehen und im Vorfeld

schon dazu entschlossen dieses Mal auf Accessibility zu achten.

Keiner von uns war zu dem Zeitpunkt irgendwie in der Nähe.

Dieses Weltraums Accessibility, wir hatten alle keine Ahnung von.

Wir fangen mal mit etwas Einfachem an, etwas was jedem, also auch uns etwas nützen würde,

nämlich der Tastaturbedienbarkeit.

Jetzt haben wir eine Applikation, die sich recht ähnlich zum Finder verhält.

Wir haben so Spaltenlayout, eine Hierarchie, die irgendwie navigiert wird und wie wir hier

sehen lässt sich der Finder vollständig mit der Tastatur bedienen.

Das ist cool.

Das machen wir in unserem realen Nutzungsunfall auch andauernd, aber mit unseren Web Applikationen

war das irgendwie, da war es nicht so weit her mit der Tastatur.

Dieses Problem wollten wir angehen.

Jetzt ist es aber so, dass wir ungern Sachen produzieren, die irgendwie so halblewig anfänglich

tun was sie sollen.

Also nochmal, von uns hatte keiner Ahnung von Accessibility.

Wir wussten nur, das ist nicht unbedingt das was wir bauen wollen.

Also stellte sich mal ziemlich schnell die Frage, wo fangen wir denn überhaupt an?

Wir sind alles Leute, die viel an Konferenzen unterwegs sind und an diesen Konferenzen gibt

es natürlich auch den einen oder anderen Talk rund um Accessibility, spezifisch Area, was

dann auch die Spezifikation ist, wo man das erste Mal einsteigt in diese Thematik.

Also eine UI Komponente, die quasi jede Applikation hat, ist halt ein Dialog, so ein modaler Dialog

und das ist jetzt ein Auszug aus Area Practices, also eine Erweiterung zu der eigentlichen Area

Spezifikation, die sich mit dem Verhalten eines solchen Dialogs auseinander lässt.

Welche Tastaturkombinationen machen was?

Wie muss sich dieser Dialog ansonsten verhalten, abseits der Semantik, also der Beschreibung,

das ist ein Dialog.

Area steht dann im Übrigen für Accessible Rich Internet Applications, sollte das noch

erlend werden.

Das was wir hier in Textform sehen, sieht dann ungefähr so aus, wenn wir das in einem

Word Screenshot nachbilden, im Prinzip wird einfach nur beschrieben, welche Tastenkombinationen

welche Auswirkungen haben.

Von diesen fünf Tastenkombinationen, die hier relevant sind, behandeln drei den Fokus.

Da stellt sich die Frage, was das überhaupt ist und dieses fokussierte Element oder was

Fokus eigentlich ist, das ist das was wir die nächsten 35 Minuten tiefer untersuchen.

Wir fangen jetzt mal an mit den Grundlagen, was bietet uns HTML, JavaScript, CSS überhaupt

um Fokus abzubilden.

Wir nähern uns über den Verlauf des Vortrags daran an was Fokus enthält.

In HTML haben wir das tabindex Attribut, mit diesem Attribut lässt sich ein nichts beliebiges

Element fokussierbar machen.

Fokussierbar bedeutet, ich kann mit der Maus draufklicken und das Element hat einen bestimmten

Zustand erreicht, nämlich den, dass es Tastatureingaben entgegen nimmt.

Also wenn immer ich eine Taste drücke im Web Kontext, das fokussierte Element ist das Element,

das dieses Keydown Keyup Event empfängt.