Verständlich

In Fällen, in denen der Inhalt einer Seite Wörter oder Ausdrücke enthält, die in einer anderen Sprache als der Hauptsprache sind, verwenden Sie das lang-Attribut an einem Element, das um den betreffenden Begriff herum platziert ist (z.B. eine <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 Phrasen festlegen, die unabhängig von der Sprache dieselben sind (zum Beispiel Eigennamen oder technische Begriffe, die nicht zu einer bestimmten Sprache gehören).

Wenn Abkürzungen verwendet werden, sollten Sie eine Erläuterung dieser bereitstellen oder eine Definition, wenn erforderlich.

Das <abbr>-Element wird oft als bevorzugter Weg angesehen, eine Erläuterung für eine Abkürzung bereitzustellen — es nimmt ein title-Attribut auf, das die Erklärung enthält, und erscheint, wenn das Akronym mit der Maus berührt wird. Allerdings sind die Inhalte des Titels nicht über die Tastatur zugänglich, noch werden sie zuverlässig von Bildschirmlesern vorgelesen. Ein besserer Weg, damit umzugehen, ist es, erneut Links zu Glossarseiten zu geben, die die Erklärung und Erläuterung des Akronyms enthalten, oder sie zumindest im umgebenden Text im Kontext einzufügen.

Wenn Text bereitgestellt wird, der eine höhere Lesestufe als die untere Sekundarstufe (normalerweise Kinder im Alter von 11-14 Jahren) erfordert, sollten Sie zusätzliches Erklärmaterial bereitstellen, um Menschen zu helfen, die ihn nicht lesen können, oder eine alternative Version anbieten, die auf dem Niveau der unteren Sekundarstufe geschrieben ist.

Das bedeutet nicht, dass alle Themen von jedem verstanden werden sollten, aber dass der Schreibstil für jeden zugänglich sein sollte. Es ist besser, alle Inhalte auf dem Niveau der unteren Sekundarstufe zu schreiben, auch technische Dokumentation wie Programmieranleitungen, 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 strengen Stil geschrieben werden (z.B. W3C Spezifikationen).

Ein Mechanismus sollte bereitgestellt werden, der den Nutzern den Zugriff auf die Aussprache von Wörtern ermöglicht, wenn diese erforderlich ist, um den Inhalt vollständig zu verstehen.

Das HTML <audio>-Element kann verwendet werden, um eine Steuerung zu erstellen, die es dem Leser ermöglicht, eine Audiodatei abzuspielen, die die korrekte Aussprache enthält. Es ist auch sinnvoll, einen schriftlichen Ausspracheführer nach schwierigen Wörtern einzufügen, ähnlich wie in Wörterbucheinträgen.

Wenn ein Steuerelement oder eine andere Seitenfunktion den Fokus erhält, sollte der Kontext nicht so geändert werden, dass der Benutzer verwirrt oder desorientiert wird.

Dies ist eine Frage des sinnvollen Designs — Menschen wollen nicht, dass Benutzeroberflächen sie überraschen; sie wollen, dass Dinge intuitiv sind und sich wie erwartet verhalten. Zum Beispiel sollte die Fokussierung auf eine Navigationsmenüoption die angezeigte Seite nicht ändern — es sollte aktiviert werden, bevor die Anzeige wechselt.

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

Auch hier sollte sinnvolles Design umgesetzt werden. Zum Beispiel, wenn das Drücken eines Buttons die Anwendung dazu bringt, die aktuelle Ansicht zu verlassen, sollte der Benutzer gefragt werden, ob er diese Aktion bestätigen möchte, seine Arbeit, falls sinnvoll, speichern usw.

Der Stil und die Positionierung des Navigationsmenüs/der Steuerung sollten auf verschiedenen Seiten oder Ansichten einer Webseite konsistent sein, und die vorhandenen Elemente sollten in derselben Reihenfolge erscheinen, auch wenn zum Beispiel neue Elemente hinzugefügt werden. Wenn der Benutzer eine Änderung initiiert hat, z.B. die Wahl eines anderen Farbschemas oder der Position der Navigation, sollte diese Wahl auf allen Seiten respektiert werden.

Auch hier: sinnvolles Design — machen Sie die Navigationselemente auf allen Seiten oder Ansichten gleich.

Steuerelemente oder Komponenten, die dieselbe Funktionalität haben, sollten auf verschiedenen Seiten oder Ansichten auf dieselbe Weise identifiziert werden. Ein Währungsumrechner, der auf jeder Seite einer Webseite über Weltreisen erscheint, sollte zum Beispiel genau gleich sein, semantisch und in Bezug auf Beschriftungen.

Nochmals, sinnvolles Design!

Änderungen im Kontext, die Benutzer möglicherweise verwirren oder desorientieren könnten, sollten nur dann erfolgen, wenn dies vom Benutzer angefordert wird ODER der Benutzer sollte in der Lage sein, sie auszuschalten.

Wenn Sie etwas haben müssen, das die aktuelle Ansicht erheblich ändert (z.B. Inhalte oder Steuerungen), lassen Sie den Benutzer kontrollieren, wann sie diese Änderung vornehmen möchten (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, um das automatische Weiterblättern zu stoppen. Besser ist es, solche Funktionalität zu vermeiden, wenn möglich.

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

Sehen Sie sich die konsistente Hilfedokumentation zu diesem Standard an, um mehr zu erfahren.

Wenn ein Benutzer ein Formular ausfüllt oder zwischen Optionen wählt, sollten erkannte Fehler klar dem Benutzer mitgeteilt werden, zusammen mit dem Formularsteuerelement, auf das sich der Fehler bezieht.

Es ist ratsam, eine clientseitige Fehlererkennung und -behandlung über HTML-Formularvalidierungsfunktionen und/oder JavaScript zu implementieren, je nachdem, was für Ihre Situation am besten ist. Wenn ein Fehler erkannt wird, wird eine intuitive Fehlermeldung neben dem Formularfeld angezeigt, das dafür verantwortlich ist, um dem Benutzer zu helfen, seine Eingaben zu korrigieren. Für Benutzer von Bildschirmlesern können Sie Aria-Live-Regionen verwenden, um den Benutzer auf eine Änderung auf der Seite aufmerksam zu machen.

Klare Anweisungen sollten bereitgestellt werden, wenn die Eingabe von Daten erforderlich ist. Wenn eine einfache 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).

Wenn ausführlichere Erläuterungen erforderlich sind, können Sie immer auch erläuternde Absätze einschließen, oder Sie müssen möglicherweise versuchen, Ihre Formulare intuitiver zu gestalten.

• Aussagekräftige Textbeschriftungen
• Wie man ein HTML-Formular strukturiert
• Textbeschriftungen und -namen

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

In solchen Fällen werden Sie dies wahrscheinlich mithilfe einer Kombination aus JavaScript und serverseitiger Funktionalität umsetzen, um zu prüfen, ob die Eingabe korrekt ist, und wenn nicht, welche praktikablen Vorschläge dem Benutzer gegeben werden können. Solche Vorschläge sollten ansprechend im Kontext angezeigt werden, ähnlich wie Fehlermeldungen (siehe 3.3.1).

Im Fall von Formularen, die mit der Eingabe sensibler Daten zu tun haben (wie rechtliche Vereinbarungen, E-Commerce-Transaktionen oder persönliche Daten), sollte mindestens eines der folgenden zutreffen:

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

Umkehrbar — für jede Ansicht, in der Daten eingegeben werden können, sollte eine äquivalente Ansicht bereitgestellt werden, die es ermöglicht, einen Eintrag zu bearbeiten oder sogar zu löschen, falls geeignet (siehe zum Beispiel Django-Webframework).

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

Bestätigen und korrigieren — wo angebracht, nach dem Ausfüllen einer Reihe von Formularfeldern zur Durchführung einer Aufgabe (wie dem Kauf eines Produkts), sollte dem Benutzer ein Bestätigungsbildschirm angezeigt werden, auf dem er seine Eingaben überprüfen und alles korrigieren kann, was nicht richtig aussieht. Dieses Muster wird häufig auf E-Commerce-Seiten wie Amazon verwendet.