Barrierefreiheitsfunktionen, die von der zu testenden Webseite (also nicht vom Betriebssystem oder dem Browser) bereitgestellt werden, sollen von ihrer potentiellen Nutzerschaft selbstständig aktivierbar sein.

Wenn die Webseite beispielsweise eine Funktion zur Verfügung stellt, mit derer die Kontrastverhältnisse innerhalb der Seite verbessert werden, müssen sämtliche Bedienelemente, die zur Aktivierung der Funktion bedient werden müssen, auch in der Standardansicht ein ausreichendes Kontrastverhältnis aufweisen. Damit wird sichergestellt, dass auch Nutzer, die mit kontrastarmen Inhalten und Bedienelementen Schwierigkeiten haben (also zur Zielgruppe der Barrierefreiheitsfunktion gehören), die Funktion zur Kontrasterhöhung selbstständig aktivieren können.

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.

Für blinde Benutzer oder für Benutzer von einfachen Textbrowsern sind Grafiken und Bilder nicht zugänglich. Die Textalternative tritt dann an die Stelle der Grafik, sie soll die Grafik ersetzen.

Wenn Objekte (etwa Video-Dateien, Audio-Dateien oder Applets) nicht angezeigt werden können, sollen kurze beschreibende Alternativtexte dem Nutzer eine Identifikation der Inhalte ermöglichen.

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.

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.

Die Festlegung des Eingabezwecks erlaubt es neuartigen Hilfsmitteln, bei Formularfeldern, welche sich auf Daten des Nutzers beziehen, zusätzliche Informationen anzuzeigen, und zwar unabhängig vom der jeweils gewählten Beschriftung des Feldes und unabhängig von der natürlichen Sprache des Angebots.

Zusätzliche Informationen können etwa Bilder bzw. Icons sein, die über ein Browser-Plugin oder eine externe assistive Technologie bereitgestellt werden und über bzw. vor dem jeweiligen Eingabefeld angezeigt werden, etwa wenn Nutzer eine bestimmte Tastenkombination drücken. Für Menschen, die Schwierigkeiten mit dem Lesen haben oder bevorzugt über Bilder kommunizieren, erleichtert dies eine Identifizierung von nutzerbezogenen Feldern in Formularen.

Darüber hinaus bietet autocomplete Eingabevorschläge für das Feld, welche Nutzer einfach übernehmen können. Das erleichtert die Texteingabe.

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.

Für Tastaturnutzende ist es wichtig, zu sehen, wo sich der Tastaturfokus gerade befindet, welcher Link also ausgelöst wird, wenn er sie die Enter-Taste drücken.

Viele Webseiten erleichtern Mausnutzenden die Bedienung, indem sie darauf reagieren, dass der Mauszeiger sich über einem Link befindet. Dann ändert sich zum Beispiel die Text- oder Hintergrundfarbe oder der Linktext wird unterstrichen. Diese Unterstützung soll auch für Tastaturnutzende funktionieren. Webseiten sollen sie gegenüber den zahlreicheren Mausnutzenden nicht benachteiligen.

Die vom Browser vorgesehene Kennzeichnung des Tastaturfokus hebt sich von dunklen Seitenhintergründen meist nicht so gut ab. Das muss dann durch eine entsprechende Gestaltung ausgeglichen werden.

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.

Blinde Nutzer, die von Link zu Link tabben, bekommen die Linktexte vorgelesen und können bei aussagekräftigen Linktexten leicht entscheiden, ob sie einem Link folgen möchten.

Falls der Linktext selbst nicht aussagekräftig ist, soll der unmittelbare Kontext für Screenreader-Nutzer wenigstens leicht ermittelbar sein.

Screenreader bieten die Möglichkeit der Auflistung sämtlicher Links der Seite und damit einen schnellen Überblick, selbst wenn die Seite ansonsten schlecht zugänglich ist. Diese Technik funktioniert allerdings nicht, wenn alle Linktexte gleich sind und nicht ausreichend Auskunft über das Linkziel geben.

Bei Links zu Angeboten in anderen Formaten als HTML (zum Beispiel PDF- oder Word-Dokumente) ist es für Nutzende sinnvoll zu wissen, in welchem Format Informationen angeboten werden, bevor sie einen Link aktivieren. Wenn Informationen zum Dateiformat visuell bereitgehalten werden (etwa über ein mittels CSS eingeblendetes PDF- oder Word-Icon) dann soll diese Information auch für blinde Nutzer verfügbar sein.

Menschen mit motorischen Beeinträchtigungen haben häufig Schwierigkeiten, Zeiger-Gesten auf Schnittstellen-Elementen zielgerichtet auszuführen. Die Ausführung beim Up-Event (etwa wenn die Maustaste losgelassen wird oder der Finger vom Touchscreen abgehoben wird) gibt diesen Menschen die Möglichkeit, Fehleingaben zu vermeiden, da es sie befähigt, vor Auslösen des Up-Events den Zeiger vom Interface-Element wegzubewegen. Wenn Down-Events bereits Funktionen auslösen, besteht diese Korrekturmöglichkeit nicht.

In Fällen, wo eine Zeiger-Eingabe mehrstufig ist, etwa bei Drag-and-Drop Aktionen, ist es wichtig, dass es einen Weg gibt, versehentlich ausgeführte Eingaben rückgängig zu machen. Dies kann auf verschiedene Weise geschehen, etwa über eine Schaltfläche zum Rückgängig-Machen der Aktion, einen Bestätigungsdialog, durch das Loslassen des Elements über dem Ausgangsort, oder durch das Loslassen des Elements über einem Ort, der nicht als Drop Target definiert ist und das Element zum Ausgangspunkt zurückspringen lässt.

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.