Verständlich

Wenn der Inhalt einer Seite Wörter oder Ausdrücke in einer anderen Sprache als der Hauptsprache enthält, verwenden Sie das lang Attribut auf einem Element um den betreffenden Begriff (z.B. ein <span> für den Fall, dass kein semantisches Element verfügbar ist), um eine angemessene Sprache dafür festzulegen.

Es ist nicht erforderlich, eine andere Sprache für Wörter oder Ausdrücke festzulegen, die unabhängig von der Sprache gleich sind (z.B. Eigennamen, technische Begriffe, die nicht Teil einer bestimmten Sprache sind).

Wo Abkürzungen verwendet werden, sollten Sie eine Erklärung dieser Abkürzungen oder eine erforderliche Definition bereitstellen.

Das <abbr> Element wird oft als bevorzugte Möglichkeit angesehen, eine Erweiterung für eine Abkürzung bereitzustellen — es nimmt ein title Attribut auf, das die Erweiterung enthält, die angezeigt wird, wenn mit der Maus über die Abkürzung gefahren wird. Die Inhalte des title Attributs sind jedoch weder über die Tastatur zugänglich noch werden sie zuverlässig von Screenreadern vorgelesen. Es ist besser, Links zu Glossarseiten bereitzustellen, die die Erweiterung der Abkürzung und eine Erklärung enthalten, oder sie zumindest im umgebenden Text im Kontext zu inkludieren.

Wenn Texte bereitgestellt werden, die eine höhere Lesestufe als die niedrige Sekundarstufe (typischerweise Kinder im Alter von 11-14 Jahren) erfordern, stellen Sie zusätzliches Erklärungsmaterial zur Verfügung, um Personen zu helfen, die es nicht lesen können, oder bieten Sie eine alternative Version an, die auf niedrigem Sekundarstufenniveau geschrieben ist.

Das bedeutet nicht, dass alle Themen von allen verstanden werden sollten, aber der Schreibstil sollte für alle zugänglich sein. Es ist besser, alle Inhalte auf niedrigem Sekundarstufenniveau zu verfassen, selbst technische Dokumentationen wie Programmier-Tutorials, es sei denn, es gibt einen guten Grund, dies nicht zu tun (z.B. ein alternativer Stil für einen poetischen Effekt), oder sie müssen in einem strengen Stil geschrieben werden (z.B. W3C-Spezifikationen).

Es sollte ein Mechanismus bereitgestellt werden, um den Benutzern Zugang zur Aussprache von Wörtern zu geben, wo sie erforderlich ist, um den Inhalt vollständig zu verstehen.

Das HTML <audio> Element kann verwendet werden, um eine Steuerung zu erstellen, die dem Leser erlaubt, eine Audiodatei mit der korrekten Aussprache abzuspielen, und es macht auch Sinn, eine textliche Ausspracheanleitung nach schwierigen Wörtern einzufügen, ähnlich wie man es in Wörterbucheinträgen findet.

Wenn eine Steuerung oder ein anderes Seitenelement den Fokus erhält, sollte sich der Kontext nicht in einer Weise ändern, die den Benutzer verwirren oder desorientieren könnte.

Dies ist eine Frage des sinnvollen Designs — Menschen möchten nicht, dass sie von Schnittstellen überrascht werden; sie möchten, dass Dinge intuitiv sind und sich erwartungsgemäß verhalten. Beispielsweise sollte das Fokussieren einer Navigationsmenüoption nicht die angezeigte Seite ändern — sie sollte aktiviert werden, bevor sich die Anzeige ändert.

Wenn Daten in eine Steuerung eingegeben werden oder eine Einstellung geändert wird, sollte sich der Kontext nicht unerwartet ändern. Der Benutzer sollte über die bevorstehende Änderung gewarnt/benachrichtigt werden, bevor sie eintritt.

Auch hier sollte ein sinnvolles Design umgesetzt werden. Beispielsweise sollte der Benutzer gefragt werden, bevor er eine Schaltfläche betätigt, die die Anwendung dazu veranlasst, die aktuelle Ansicht zu verlassen, ob er dies wirklich möchte. Außerdem sollte er seine Arbeit speichern, falls erforderlich.

Der Stil und die Positionierung des Navigationsmenüs/der -steuerung sollte zwischen den verschiedenen Seiten oder Ansichten einer Webseite konsistent sein, und die bestehenden Elemente sollten in der gleichen Reihenfolge erscheinen, auch wenn beispielsweise neue Elemente hinzugefügt werden. Wenn der Benutzer eine Änderung vorgenommen hat, z.B. eine andere Farbschema oder Position für die Navigation ausgewählt hat, sollte seine Wahl auf allen Seiten respektiert werden.

Auch hier sinnvolles Design — gestalten Sie die Navigationssteuerungen auf allen Seiten oder Ansichten gleich.

Steuerungen oder Komponenten, die die gleiche Funktionalität haben, sollten auf allen verschiedenen Seiten oder Ansichten auf die gleiche Weise identifiziert werden. Beispielsweise sollte ein Währungsrechner, der auf jeder Seite einer Weltreiseseite erscheint, semantisch und in Bezug auf Beschriftungen exakt gleich sein.

Auch hier, sinnvolles Design!

Kontextänderungen, die Benutzer möglicherweise verwirren oder desorientieren könnten, sollten nur dann auftreten, wenn sie von dem Benutzer angefordert werden, ODER der Benutzer sollte in der Lage sein, sie zu deaktivieren.

Wenn etwas erheblich die aktuelle Ansicht ändern muss (z.B. Inhalt oder Bedienelemente), lassen Sie den Benutzer steuern, wann die Änderung auftreten soll (z.B. welche Seite angezeigt werden soll, wann zum nächsten Foto in der Galerie weitergeschaltet werden soll...).

Wenn Sie etwas wie ein Karussell auf einer Seite benötigen, bieten Sie eine Option, um das automatische Weiterblättern zu stoppen. Besser ist es, auf solche Funktionen zu verzichten, wenn möglich.

Webseiten, die Hilfemechanismen enthalten, einschließlich Selbsthilfeoptionen und menschlichen Kontaktdaten, die auf mehreren Webseiten wiederholt werden, müssen diese Mechanismen in derselben Reihenfolge auf allen Seiten platzieren, es sei denn, eine Änderung wird vom Benutzer initiiert.

Sehen Sie sich die Dokumentation zur konsistenten Hilfe für diesen Standard an, um mehr zu erfahren.

Wenn ein Benutzer ein Formular ausfüllt oder zwischen Optionen wählt, sollte jeder erkannte Fehler dem Benutzer klar mitgeteilt werden, zusammen mit der Formularsteuerung, auf die sich der Fehler bezieht.

Es ist ratsam, eine clientseitige Fehlererkennung und -behandlung zu implementieren, über HTML-Formularvalidierungsfunktionen und/oder JavaScript, je nachdem, was für Ihre Situation am besten geeignet ist. Wenn ein Fehler erkannt wird, sollte eine intuitive Fehlermeldung neben der Formulareingabe angezeigt werden, das fehlerhaft ist, um dem Benutzer zu helfen, seine Eingaben zu korrigieren. Für Screenreader-Benutzer können Sie aria Live-Regionen verwenden, um den Benutzer über eine Änderung auf der Seite zu informieren.

Klare Anweisungen sollten bereitgestellt werden, wenn die Eingabe von Daten erforderlich ist. Wenn eine kurze Anweisung oder Eingabeaufforderung erforderlich ist, können Sie <label> Elemente für Einzelangaben wie Namen oder Alter verwenden, eine Kombination aus <label>s und <fieldset>s/<legend>s für mehrere zusammengehörende Eingaben (wie die Elemente eines Geburtsdatums oder einer Postadresse).

Wenn eine komplexere Erklärung erforderlich ist, können Sie immer auch erläuternde Absätze einfügen, oder möglicherweise müssen Sie versuchen, Ihre Formulare intuitiver zu gestalten.

• Bedeutungsvolle Textlabels
• So strukturieren Sie ein HTML-Formular
• Textlabels und Namen

Wenn ein Fehler erkannt wird und Korrekturvorschläge bekannt sind, sollten diese dem Benutzer bereitgestellt werden (z.B. Alternativen vorschlagen, wenn der Benutzer einen Benutzernamen auswählt und dieser bereits vergeben ist), es sei denn, dies würde ein Sicherheitsproblem (z.B. bei der Eingabe eines Passworts) oder ein Kontextproblem (z.B. sie versuchen, eine Frage in einer Quiz-App zu beantworten) verursachen.

In solchen Fällen, wenn dies angemessen ist, verwenden Sie wahrscheinlich eine Kombination aus JavaScript und serverside-Funktionalität, um zu überprüfen, ob die Eingabe korrekt ist und, falls nicht, welche brauchbaren Vorschläge dem Benutzer gemacht werden können. Solche Vorschläge sollten nützlich im Kontext dargestellt werden, genau wie Fehlermeldungen (siehe 3.3.1).

Im Falle von Formularen, die die Eingabe sensibler Daten (z.B. rechtliche Vereinbarungen, E-Commerce-Transaktionen oder persönliche Daten) beinhalten, sollte mindestens eine der folgenden Bedingungen zutreffen:

• Eingaben sind umkehrbar.
• Daten werden auf Fehler überprüft, und dem Benutzer wird die Möglichkeit gegeben, diese zu korrigieren.
• Ein Mechanismus steht zur Verfügung, um Informationen vor der endgültigen Einreichung zu bestätigen und zu korrigieren.

Umkehrbar — für jede Ansicht, in der Daten eingegeben werden können, stellen Sie eine gleichwertige Ansicht bereit, die Sie bearbeiten oder sogar einen Eintrag löschen erlaubt, soweit dies angemessen ist (siehe z.B. Django-Web-Framework).

Überprüfung von Daten — wie in 3.3.1 behandelt, sollte eine Kombination aus clientseitiger und serverseitiger Validierung verwendet werden, um Fehler zu erkennen und hilfreiche Nachrichten anzuzeigen, um dem Benutzer zu ermöglichen, seine Eingaben zu korrigieren.

Bestätigen und korrigieren — wo dies angemessen ist, sollte der Benutzer nach dem Ausfüllen einer Reihe von Formularfeldern, um eine Aufgabe auszuführen (wie den Kauf eines Produkts), einen Bestätigungsbildschirm erhalten, auf dem er seine Eingaben überprüfen und alles korrigieren kann, was nicht richtig aussieht. Dieses Muster wird häufig auf E-Commerce-Websites wie Amazon verwendet.