Verständlich

In Fällen, in denen der Inhalt einer Seite Wörter oder Phrasen in einer anderen Sprache als der Hauptsprache enthält, verwenden Sie das lang-Attribut auf einem um den betreffenden Begriff gewickelten Element (z. B. ein <span>, wenn kein semantisches Element verfügbar ist), um eine geeignete Sprache dafür festzulegen.

Sie müssen keine andere Sprache festlegen für Wörter oder Phrasen, die unabhängig von der Sprache gleich sind (zum Beispiel Eigennamen, technische Begriffe, die nicht zu einer bestimmten Sprache gehören).

Wo Abkürzungen verwendet werden, sollten Sie ihre vollständige Form oder eine Definition nach Bedarf bereitstellen.

Das <abbr>-Element wird oft als bevorzugte Methode angesehen, um die vollständige Form einer Abkürzung bereitzustellen — es nimmt ein title-Attribut auf, das die vollständige Form enthält, und diese erscheint, wenn das Akronym mit der Maus überfahren wird. Allerdings sind die Inhalte des Titels nicht über die Tastatur zugänglich, noch werden sie zuverlässig von Bildschirmlesern vorgelesen. Eine bessere Möglichkeit, damit umzugehen, besteht darin, erneut Links zu Glossarseiten bereitzustellen, die die Erklärung und Erläuterung des Akronyms enthalten, oder sie zumindest im umgebenden Text kontextuell einzuschließen.

Wenn Text bereitgestellt wird, der ein höheres Leseverständnis als das der unteren Sekundarstufe erfordert (typischerweise Kinder im Alter von 11-14 Jahren), sollten ergänzende erklärende Materialien bereitgestellt werden, um Personen zu helfen, die es nicht lesen können, oder eine alternative Version, die auf 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 der unteren Sekundarstufe 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 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 nötig ist, um den Inhalt vollständig zu verstehen.

Das HTML-Element <audio> kann verwendet werden, um eine Steuerung zu erstellen, die es dem Leser ermöglicht, eine Audiodatei mit der korrekten Aussprache abzuspielen. Es ist auch sinnvoll, eine Textaussprachenführung nach schwierigen Wörtern einzufügen, auf die gleiche Weise, wie Sie sie in Wörterbucheinträgen finden.

Wenn ein Steuerelement oder eine andere Seitenfunktion den Fokus erhält, sollte es den Kontext nicht auf eine Weise ändern, die den Benutzer verwirren oder desorientieren könnte.

Dies ist eine Frage des sinnvollen Designs – Menschen wollen nicht, dass Oberflächen sie überraschen; sie möchten, dass Dinge intuitiv sind und sich erwartungsgemäß verhalten. Beispielsweise sollte der Fokus auf eine Navigationsmenüoption die angezeigte Seite nicht ändern – sie sollte aktiviert werden, bevor die Anzeige wechselt.

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

Auch hier sollte sinnvolles Design umgesetzt werden. Zum Beispiel, wenn durch Drücken einer Taste die Anwendung die aktuelle Ansicht verlässt, sollte der Benutzer gebeten werden, diese Aktion zu bestätigen, seine Arbeit zu speichern, falls zutreffend, usw.

Navigationsmenü-/Steuerstil und Positionierung sollten zwischen verschiedenen Seiten oder Ansichten einer Webseite konsistent sein, und die vorhandenen Elemente sollten in derselben Reihenfolge erscheinen, selbst wenn beispielsweise neue Elemente hinzugefügt werden. Wenn der Benutzer eine Änderung initiiert hat, z. B. eine andere Farbgebung oder Position für die Navigation wählt, sollte diese über alle Seiten hinweg respektiert werden.

Wieder sinnvolles Design – machen Sie die Navigationssteuerungen auf allen Seiten oder Ansichten gleich.

Steuerelemente oder Komponenten, die dieselbe Funktionalität haben, sollten über verschiedene Seiten oder Ansichten hinweg auf dieselbe Weise identifiziert werden. Ein Währungsrechner, der auf jeder Seite einer Weltreise-Website erscheint, sollte zum Beispiel genau gleich sein, semantisch und in Bezug auf Beschriftungen.

Wieder sinnvolles Design!

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

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

Wenn Sie etwas wie ein Karussell auf einer Seite benötigen, bieten Sie eine Option, um es automatisch anzuhalten. Besser ist es, solche Funktionen nach Möglichkeit zu vermeiden.

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

Schauen Sie sich die dokumentierte konsistente Hilfe für diesen Standard an, um mehr zu erfahren.

Wenn ein Benutzer ein Formular ausfüllt oder zwischen Optionen wählt, sollte jeder festgestellte Fehler dem Benutzer klar gemeldet werden, zusammen mit dem Formular-Steuerelement, auf das sich der Fehler bezieht.

Es ist ratsam, die Fehlererkennung und -behandlung auf Clientseite zu implementieren, sei es über HTML-Formularvalidierungsfunktionen oder JavaScript, je nachdem, was für Ihre Situation am besten geeignet ist. Wenn ein Fehler festgestellt wird, sollte dem Benutzer eine intuitive Fehlermeldung neben dem Formularfeld angezeigt werden, das den Fehler verursacht hat, um dem Benutzer zu helfen, seine Eingaben zu korrigieren. Für Nutzer von Bildschirmlesern können Sie aria-live-Regionen verwenden, um den Benutzer auf eine Änderung auf der Seite hinzuweisen.

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

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

• Bedeutungsvolle Textbeschriftungen
• Wie man ein HTML-Formular strukturiert
• Textbeschriftungen 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 wählt und dieser bereits vergeben ist), es sei denn, dies würde ein Sicherheitsproblem verursachen (z. B. bei der Eingabe eines Passworts) oder ein Kontextproblem (z. B. wenn sie versuchen, eine Frage in einer Quiz-App zu beantworten).

In solchen Fällen, wenn dies angemessen ist, werden Sie wahrscheinlich eine Kombination aus JavaScript und serverseitiger Funktionalität verwenden, um zu überprüfen, ob der Eintrag korrekt ist, und, falls nicht, welche sinnvollen Vorschläge dem Benutzer gegeben werden können. Solche Vorschläge sollten kontextuell nützlich dargestellt werden, genau wie Fehlermeldungen (siehe 3.3.1).

Im Falle von Formularen, die mit der Eingabe sensibler Daten verbunden sind (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, sie zu korrigieren.
• Ein Mechanismus ist verfügbar, 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, bieten Sie eine gleichwertige Ansicht, die Ihnen erlaubt, einen Eintrag zu bearbeiten oder sogar zu löschen, sofern passend (siehe z. B. Django-Web-Framework).

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, die es ihm ermöglichen, seine Eingaben zu korrigieren.

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