Seitenhistorie

Die Bedienung soll geräteunabhängig möglich sein. Das bedeutet: Sie muss sowohl mit einem Zeiger (Maus, Touch-Geste) als auch mit der Tastatur möglich sein. Auch adere Eingabeformen, etwa die Spracheingabe oder Schaltersteuerung, sind auf eine gute Tastaturbedienbarkeit und eine sinnvolle Fokusreihenfolge angewiesen.

Probleme gibt es meistens mit der Tastaturbedienung, denn die Mehrzahl der Webnutzenden arbeitet mit der Maus, daher wird oft nur an sie gedacht. Auf die Tastaturbedienbarkeit angewiesen sind zum Beispiel viele motorisch eingeschränkte Menschen oder Blinde.

Bei einer nicht nachvollziehbaren Fokusreihenfolge laufen Nutzende Gefahr, die Orientierung zu verlieren, die Tastaturbedienbarkeit kann dadurch erheblich beeinträchtigt sein.

Manche Seiten präsentieren mittels JavaScript dynamische Inhalte. Rückmeldungen bei fehlerhaften Formular-Eingaben werden beispielsweise dynamisch unter dem Feld angezeigt oder Dialoge werden eingeblendet. Während diese Änderungen der Seite für sehende Nutzende unmittelbar wahrnehmbar sind, werden sie von Screenreader-Nutzenden gar nicht oder erst mit Verzögerung wahrgenommen.

Werden weitere Elemente über DOM-Scripting in den Quellcode einer Seite dynamisch eingefügt (d.h. ohne dass die Seite neu lädt), soll diese Einfügung unterhalb des auslösenden Elements geschehen, damit Screenreader hinzugefügte Elemente bemerken und vorlesen.

Werden Elemente an anderer Stelle im DOM eingefügt, etwa am Seitenende (das ist oft bei Modalen Dialogen der Fall), müssen Scripte für ein sinnvolles Fokusmanagment sorgen und damit eine sinnvolle Fokusreihenfolge gewährleisten.

Standard-HTML-Bedienelemente wie Links (a-Element) und Formularelemente (input, button, checkbox etc.) haben Namen, Rollen, Wert und Zustände, sofern sie gemäß Spezifikation umgesetzt sind und sind für Hilfsmittel wie Screenreader generell erkennbar. So bekommen etwa blinde Nutzer mit, wenn sie auf einen Link tabben und können diesem dann folgen. Auch Zustände, beispielsweise einer Checkbox (ausgewählt oder nicht ausgewählt) werden vermittelt. Interaktive Schaltflächen sollten deshalb mit Hilfe von geeigneten nativen HTML-Elementen umgesetzt werden, damit ihre Bedeutung klar wird.

Falls ungeeignete (weil nicht semantische) Elemente (etwa div oder span) mithilfe von JavaScript zu Links oder Bedienelementen umfunktioniert werden, kann die Semantik mit Hilfe von WAI-ARIA bereit gestellt werden. Dies betrifft auch Komponenten (Widgets wie z. B. Tabpanels, Akkordeons etc.), die in nativem HTML so nicht zur Verfügung stehen und mit Hilfe von nicht semantischen Elementen und Scripten umgesetzt sind. WAI-ARIA Attribute helfen, diese zu verstehen, indem semantische Informationen vom Browser an die Hilfsmitteltechnologien übermittelt werden.

The operation should be possible independent of the device. That means: It must be possible with the mouse as well as with the keyboard. Because also other special devices behave like a mouse or like a keyboard.

There are mostly problems with the keyboard operation, because the majority of the web users works with the mouse, therefore often only the mouse is thought of. Many people with motor impairments or blind people, for example, are dependent on keyboard operability.

If the order of links and form elements is not comprehensible, keyboard usability can be significantly impaired.

Some pages use JavaScript to present dynamic content, such as feedback for incorrect form input or news teasers that alternate. While dynamic changes to the page are immediately noticeable to sighted users, they are often not noticed at all or only with a delay by screen reader users.

When additional elements are inserted into the source code of a page via DOM scripting after the page has been loaded, this insertion should be below of the triggering element, so that screen readers notice and read aloud added elements.

In some cases, if understandable in context, they may be inserted or modified further down the page (i.e., not immediately after the triggering element).

If elements are inserted elsewhere, for example at the bottom of the page (this is often the case with modal dialogs), scripts must ensure that a sensible focus order is created and that blind users also notice the change.

Standard HTML controls such as links (a-element) and form elements (input, button, checkbox etc.) have names, roles, value and states, provided they are implemented according to specification and are generally recognizable for tools such as screen readers.  For example, blind users can see when they tab to a link and can then follow it. States, for example of a checkbox (selected or not selected), are also conveyed. Interactive buttons should therefore be implemented using suitable native HTML elements so that their meaning is clear.

If unsuitable (because non-semantic) elements (such as div or span) are converted to links or controls using JavaScript, the semantics can be provided using WAI-ARIA. This also applies to components (widgets such as tab panels, accordions, etc.) that are not available in native HTML and are implemented using non-semantic elements and scripts. WAI-ARIA attributes help to understand them by passing semantic information from the browser to the assistive technologies.