Verständlich

In Fällen, in denen 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, das den betreffenden Begriff umgibt (z. B. einem <span>, wenn kein semantisches Element verfügbar ist), um eine geeignete Sprache dafür festzulegen.

Sie müssen keine andere Sprache für Wörter oder Ausdrücke festlegen, 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 Erweiterung oder eine Definition davon bereitstellen, falls erforderlich.

Das <abbr>-Element wird oft als bevorzugtes Mittel angesehen, um eine Erweiterung für eine Abkürzung bereitzustellen — es nimmt ein title-Attribut auf, das die Erweiterung enthält, und diese erscheint, wenn man mit der Maus über das Akronym fährt. Dennoch sind die Inhalte des Titelattributs über die Tastatur nicht zugänglich und werden von Screenreadern nicht zuverlässig vorgelesen. Eine bessere Handhabung ist es, Links zu Glossarseiten bereitzustellen, die die Akronymerweiterung und Erklärung enthalten oder diese zumindest im umgebenden Text in Kontext einzubinden.

Wenn Text bereitgestellt wird, der ein höheres Leseverständnis als auf einer niedrigeren Sekundarstufenebene (typischerweise Kinder im Alter von 11–14 Jahren) erfordert, bieten Sie zusätzliches Erklärmaterial an, um Personen zu helfen, die es nicht lesen können, oder bieten Sie eine alternative Version an, die auf einer niedrigeren Sekundarstufenebene verfasst ist.

Dies bedeutet nicht, dass alle Themen von jedem verstanden werden sollten, sondern dass der Schreibstil für alle zugänglich sein sollte. Es ist besser, alle Inhalte auf einer niedrigeren Sekundarstufenebene zu schreiben, 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 poetische Effekte), oder sie müssen in einem strikten Stil geschrieben werden (z. B. W3C-Spezifikationen).

Ein Mechanismus sollte bereitgestellt werden, um den Benutzern den Zugang zur Aussprache von Wörtern zu ermöglichen, wenn diese erforderlich ist, um den Inhalt vollständig zu verstehen.

Das HTML-<audio>-Element kann verwendet werden, um eine Steuerung zu erstellen, mit der der Leser eine Audiodatei mit der richtigen Aussprache abspielen kann, und es ist auch sinnvoll, nach schwierigen Wörtern einen textlichen Ausspracheleitfaden hinzuzufügen, so wie Sie sie in Wörterbuchartikeln finden.

Wenn eine Steuerung oder eine andere Seitenfunktion den Fokus erhält, sollte sie den Kontext nicht so ändern, dass dies den Benutzer verwirren oder desorientieren könnte.

Dies ist eine Frage des sinnvollen Designs — Menschen wollen keine Schnittstellen, die sie überraschen; sie wollen, dass Dinge intuitiv sind und sich wie erwartet verhalten. Zum Beispiel sollte das Fokussieren einer Navigationsmenüoption nicht die angezeigte Seite ändern — sie sollte aktiviert werden, bevor die Anzeige sich ändert.

Wenn Daten in eine Steuerung eingegeben oder eine Einstellung geändert wird, sollte sich der Kontext nicht unerwartet ändern. Der Benutzer sollte vor der Veränderung gewarnt/benachrichtigt werden.

Auch hier sollte sinnvolles Design implementiert werden. Wenn beispielsweise das Drücken auf einen Button dazu führt, dass die Anwendung die aktuelle Ansicht verlässt, sollte der Benutzer aufgefordert werden, diese Aktion zu bestätigen und seine Arbeit zu speichern, wenn es angebracht ist.

Der Stil und die Platzierung des Navigationsmenüs/der Steuerung sollten auf verschiedenen Seiten oder Ansichten einer Webseite konsistent sein, und die bestehenden Elemente sollten in derselben Reihenfolge erscheinen, auch wenn z. B. neue Elemente hinzugefügt werden. Wird die Änderung vom Benutzer initiiert, z. B. durch Auswahl eines anderen Farbschemas oder einer anderen Position für die Navigation, sollte seine Wahl auf allen Seiten respektiert werden.

Erneut sinnvolles Design — machen Sie die Navigationselemente auf allen Seiten oder Ansichten gleich.

Steuerungen oder Komponenten mit derselben Funktionalität sollten auf verschiedenen Seiten oder Ansichten gleich identifiziert werden. Ein Währungsumrechner, der auf jeder Seite einer Weltreise-Website erscheint, sollte zum Beispiel semantisch und hinsichtlich der Beschriftungen genau gleich sein.

Erneut sinnvolles Design!

Kontextänderungen, die Benutzer verwirren oder desorientieren könnten, sollten nur erfolgen, wenn sie vom Benutzer angefordert werden, ODER der Benutzer sollte in der Lage sein, sie zu deaktivieren.

Wenn Sie etwas haben müssen, das die aktuelle Ansicht erheblich ändert (z. B. Inhalte oder Steuerungen), lassen Sie den Benutzer steuern, wann er möchte, dass diese Änderung erfolgt (z. B. welche Seite angezeigt werden soll, wann zum nächsten Foto in der Galerie gewechselt werden soll...)

Wenn Sie etwas wie ein Karussell auf einer Seite haben müssen, bieten Sie eine Option an, es nicht automatisch weiterlaufen zu lassen. Besser solche Funktionalitäten zu vermeiden, wenn möglich.

Webseiten, die Hilfsmechanismen enthalten, einschließlich Selbsthilfeoptionen und menschlicher 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.

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

Wenn ein Benutzer ein Formular ausfüllt oder zwischen Optionen wählt, sollte jeder erkannte Fehler dem Benutzer deutlich mitgeteilt werden, zusammen mit dem Formularsteuerelement, das sich auf den Fehler bezieht.

Es ist ratsam, eine Erkennung und Handhabung von Fehlern auf der Client-Seite zu implementieren, über HTML-Formularvalidierungsfunktionen und/oder JavaScript, je nachdem, welches am besten für Ihre Situation geeignet ist. Wenn ein Fehler erkannt wird, sollte eine intuitive Fehlermeldung neben der fehlerhaften Formulareingabe angezeigt werden, um dem Benutzer zu helfen, seine Eingaben zu korrigieren. Für Screenreader-Benutzer können Sie aria live regions verwenden, um den Benutzer über eine Änderung auf der Seite zu informieren.

Klare Anweisungen sollten bereitgestellt werden, wenn eine Dateneingabe erforderlich ist. Wenn eine kurze Anweisung oder Aufforderung erforderlich ist, können Sie <label>-Elemente für einzelne Eingaben wie Name oder Alter verwenden, eine Kombination aus <label>s und <fieldset>s/<legend>s für mehrere Eingaben, die zusammengehören (wie die Elemente eines Geburtsdatums oder einer Postadresse).

Bei komplexerer Erklärung können Sie immer auch erklärende Absätze hinzufügen oder vielleicht müssen Sie Ihre Formulare intuitiver gestalten.

• Sinnvolle Textbeschriftungen verwenden
• Wie man ein HTML-Formular strukturiert
• Textbeschriftungen und Namen

Wenn ein Fehler erkannt und bekannte Korrekturvorschläge vorhanden sind, stellen Sie diese dem Benutzer zur Verfügung (z. B. Alternativen vorschlagen, wenn der Benutzer einen Benutzernamen auswählt und einen bereits vergebenen ausgewählt hat), es sei denn, dies würde ein Sicherheitsproblem verursachen (z. B. bei der Eingabe eines Passworts) oder ein Kontextproblem (z. B. sie versuchen, eine Frage in einer Quiz-App zu beantworten).

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

Im Fall von Formularen, die die Eingabe sensibler Daten betreffen (wie rechtliche Vereinbarungen, E-Commerce-Transaktionen oder persönliche Daten), sollte mindestens einer der folgenden Fälle zutreffen:

• Einsendungen sind umkehrbar.
• Daten werden auf Fehler geprüft, und dem Benutzer wird die Möglichkeit gegeben, diese zu korrigieren.
• Ein Mechanismus ist verfügbar, um Informationen vor der endgültigen Einsendung zu bestätigen und zu korrigieren.

Umkehrbar — für jede Ansicht, in der Daten eingegeben werden können, bieten Sie eine gleichwertige Ansicht, die es ermöglicht, einen Eintrag zu bearbeiten oder sogar zu löschen, wenn angebracht (siehe zum Beispiel Django-Web-Framework).

Datenprüfung — wie in 3.3.1 behandelt, sollte eine Kombination aus Validierung auf der Client-Seite und der Serverseite verwendet werden, um Fehler zu erkennen und dem Benutzer hilfreiche Nachrichten anzuzeigen, damit er seine Eingaben korrigieren kann.

Bestätigung und Korrektur — wo passend, nachdem eine Reihe von Formularfeldern ausgefüllt wurden, um eine Aufgabe zu erledigen (wie das Kaufen eines Produkts), sollte dem Benutzer eine Bestätigungsseite gezeigt werden, auf der er seine Eingaben prüfen und alles korrigieren kann, das nicht richtig aussieht. Dieses Muster wird häufig auf E-Commerce-Seiten wie Amazon verwendet.