Die Bedienung soll geräteunabhängig möglich sein. Das bedeutet: Sie muss sowohl mit der Maus als auch mit der Tastatur möglich sein. Denn auch andere Spezialgeräte verhalten sich so wie eine Maus oder wie eine Tastatur.

Probleme gibt es meistens mit der Tastaturbedienung, denn die Mehrzahl der Webnutzer arbeitet mit der Maus, daher wird oft nur an die gedacht.

Auf die Tastaturbedienbarkeit angewiesen sind zum Beispiel viele motorisch eingeschränkte Menschen oder Blinde.

Visuell werden Webseiten mit Mitteln wie Überschriften, Spalten oder Kästen strukturiert. Dank dieser Strukturierung weiß der Benutzer, was zusammengehört, kann das Angebot der Webseite leicht überblicken und gezielt auf die Inhalte zugreifen, die ihn interessieren.

Benutzer, die diese visuelle Ordnung nicht nutzen können – zum Beispiel, weil sie blind sind oder nur einen kleinen Ausschnitt der Seite sehen können – sind darauf angewiesen, dass die Struktur unabhängig von der Darstellung auf dem Bildschirm zugänglich und nutzbar ist. Die Verwendung von (oft unsichtbaren) Bereichsüberschriften, Sprunglinks oder HTML5 Elementen zur Auszeichnung von Regionen ist dafür eine wesentliche Voraussetzung.

Bei Frames ist ein sinnvoller Titel wichtig für die Orientierung mit Screenreadern. Gängige Screenreader werten das title- und das in der Programmierung gebräuchliche name-Attribut aus. Dabei wird das title-Attribut vorrangig ausgegeben. Sie sprechen beim Umschalten zwischen den Frames mit den Tastenkürzeln den Titel des aktiven Frames aus.

Der Einsatz von HTML5-Elementen für Regionen wird inzwischen gut von assistiven Technologien unterstützt. Die zusätzliche Berücksichtigung eines role-Attributs (WAI ARIA document landmarks) kann die Unterstützung von Regionen jedoch verbessern.

So können Benutzer die Bereichsüberschriften, Sprunglinks, HTML5-Elmente für Regionen bzwWAI-ARIA document landmarks anwenden:

• Konstante Bereiche am Seitenbeginn, etwa Navigation oder Seitenkopf, überspringen, um direkt zum Inhalt zu gelangen

• Zwischen Bereichen hin- und her wechseln

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.

Für blinde Benutzer oder für Benutzer, die für schnellere Zugriffszeiten das Laden von Grafiken abschalten, sind Grafiken nicht zugänglich. Die Textalternative tritt dann an die Stelle der Grafik, sie soll die Grafik ersetzen.

Icon Fonts sind Schriftarten, die Symbole statt Buchstaben beinhalten. Sie werden per CSS eingebunden und werden entweder von assistiven Technologien nicht ausgegeben oder es wird ein Unicode-Äquivalent wiedergegeben, was die Bedeutung im Kontext nicht vermittelt.

Sehbehinderte Nutzer vergrößern häufig Seiten-Inhalte über die Zoomfunktion, die in gängigen Desktop-Browsern vorhanden ist. Über eine responsive Gestaltung mittels CSS media queries sollen Webseiten die Nutzung mit starkem Zoom durch eine dynamische Anpassung des Seiten-Umbruchs unterstützen.

Responsive Seiten-Layouts ordnen die Inhaltsblöcke neu an. Mehrspaltige Inhalte werden dabei meist so umbrochen, dass sie bei starkem Zoom einspaltig untereinander angeordnet sind. Bei Fließtexten entstehen auch neue Zeilenumbrüche mit kürzeren Zeilen.

Der Vorteil: Nutzer müssen beim Lesen nur in eine Richtung scrollen (bei westlichen Sprachen: vertikal). Wenn Zeilen bei Zoomvergrößerung nicht umgebrochen werden, sind Nutzer dagegen gezwungen, beim Lesen jeder Zeile horizontal hin- und her zu scrollen, was die Aufnahme der Inhalte sehr stark beeinträchtigt und verlangsamt.

Visuell werden Webseiten-Inhalte durch Überschriften strukturiert. Dank dieser Strukturierung wissen Nutzende, was zusammengehört, können die Inhalte der Webseite leicht überblicken und gezielt auf Inhalte zugreifen, die sie interessieren.

Wenn Formularelemente sinngebend beschriftet sind, können Sie von Nutzenden als solche erkannt und bedient werden.

Spracheingabenutzer können Bedienelemente wie Links, Tasten oder Eingabefelder aktivieren, indem sie den sichtbaren Namen sagen, auch in der Verbindung mit Befehlen (z. B. Klick "Abschicken"). Wenn die sichtbare Beschriftung nicht in dem hinterlegten zugänglichen Namen des Bedienelements (also dem Text, der programmatisch als Beschriftung ermittelt wird) vorkommt, lässt sich das Bedienelement gegebenenfalls nicht oder nur über Umwege mittels Spracheingabe aktivieren.

Bedienelemente haben manchmal einen zugänglichen Namen, der von der sichtbaren Beschriftung abweicht, weil er über nicht sichtbare Attribute wie aria-label oder über nur bei Mausnutzung eingeblendete Attribute wie title festgelegt wird. So könnte etwa die sichtbare Beschriftung "AGB akzeptieren" durch den hinterlegten zugänglichen Namen "Allgemeine Geschäftsbedingungen annehmen" ersetzt werden. Wenn Spracheingabenutzer nun Klicke "AGB akzeptieren" diktieren, kommt dieser Text so nicht im zugänglichen Namen vor, die Eingabe schlägt deshalb fehl.

Manchmal wird versteckter Text benutzt, um sichtbare Beschriftungen zu erweitern, oft auch in der Absicht, Hilfsmittelnutzern zu helfen. Das ist dann in Ordnung, wenn die sichtbare Beschriftung durchgehend in dem zugänglichen Namen enthalten ist, am besten zu Beginn.

Bei Formulareingaben kommt es öfters zu Fehlern: Nutzer verschreiben sich oder überspringen benötigte Eingaben.

Wenn das Angebot Nutzereingaben überprüft, sollen die Felder mit fehlerhaften oder fehlenden Eingaben identifiziert werden. Dies erleichtert den Nutzern, Eingaben zu korrigieren.

Wenn sichtbare Beschriftungen zur Verfügung gestellt werden, wissen Nutzer, welche Eingaben erwartet werden. Fehler können so vermieden werden.

Die Anordnung von Beschriftungen direkt vor oder über dem Eingabefeld entspricht den üblichen Gestaltungskonventionen. Auch in ausschnitthaften Ansichten (etwa in Vergrößerungssoftware) wird schnell klar, welche Beschriftung zu welchem Feld gehört.

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 keyboard operation, because the majority of web users work with a mouse, so often only the mouse is considered.

Many people with motor impairments or blind people, for example, are dependent on keyboard operability.

Visually, web pages are structured using means such as headings, columns, or boxes. Thanks to this structuring, the user knows what belongs together, can easily survey what the website has to offer, and can specifically access the content that interests him.

Users who cannot take advantage of this visual order - for example, because they are blind or can only see a small section of the page - depend on the structure being accessible and usable regardless of how it is displayed on the screen. The use of (often invisible) area headers, jump links, or HTML5 elements to mark up regions is essential to this.

For frames, a meaningful title is important for orientation with screen readers. Common screen readers evaluate the title- and the name -attribute, which is commonly used in programming. The attribute title is given priority at that. Screen readers pronounce the title of the active frame when switching between frames with the keyboard shortcuts.

The use of HTML5 elements for regions is now well supported by assistive technologies. However, the additional consideration of a role attribute (WAI ARIA document landmarks) can improve region support.

This allows users to apply region headings, jump links, HTML5 elements for regions, and WAI-ARIA document landmarks, respectively:

• Skip constant areas at the top of the page, such as navigation or page header, to go directly to content.

• Switch back and forth between areas

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.

For blind users or for users who disable loading of graphics for faster access times, graphics are not accessible. The text alternative then takes the place of the graphic, it should replace the graphic.

Icon Fonts are fonts that contain icons instead of letters. They are included via CSS and are either not output by assistive technologies or a Unicode equivalent is rendered, which does not convey the meaning in context.

Visually impaired users often enlarge page content using the zoom feature available in popular desktop browsers. Using responsive design with CSS media queries, websites should support high zoom usage by dynamically adjusting the page break.

Responsive page layouts rearrange content blocks. Multi-column content is usually paginated so that it is arranged in a single column underneath each other when zoomed in heavily. For continuous text, new line breaks with shorter lines are also created.

The advantage: users only have to scroll in one direction when reading (in western languages: vertically). On the other hand, if lines do not wrap when zoomed in, users are forced to scroll back and forth horizontally while reading each line, which greatly impairs and slows down the absorption of the content.

Visually, web page content is structured by headings. Thanks to this structuring, the user knows what belongs together, can easily overview the contents of the web page and access specific content that interests him.

If form fields are labeled in a meaningful way, users can recognize and use them.

Language input users can activate controls such as links, buttons, or input fields by saying the visible name, even in conjunction with commands (e.g. Click "Submit" button). If the visible label does not appear in the stored accessible name of the control (i.e., the text that is programmatically determined as the label), the control may not be activated or may be activated only indirectly using speech input.

Sometimes controls have an accessible name that differs from the visible label because it is defined by non-visible attributes such as aria-label or via attributes that are only displayed when the mouse is used, such as title . For example, the visible label "Accept T&C" could be replaced by the stored accessible name "Accept General Terms and Conditions". When voice input users now dictate click "Accept T&C", this text does not appear in the accessible name, so the input fails.

Sometimes hidden text is used to extend visible labels, often with the intention of helping assistive technology users. This is fine if the visible caption is included throughout the accessible name, preferably at the beginning.

Errors often occur during form input: Users make mistakes or skip required entries.

When the service checks user input, it should identify fields with incorrect or missing input. This makes it easier for users to correct input.

If visible labels are provided, users know what inputs are expected. Errors can be avoided.

Placing labels directly in front of or above the input field conforms to standard design conventions. Even in partial views (e.g. in magnification software), it quickly becomes clear which labeling belongs to which field.