Bedienbar
Dieser Artikel bietet praktische Ratschläge, wie Sie Ihren Webinhalt so schreiben, dass er den Erfolgskriterien entspricht, die im Prinzip Bedienbar der Web Content Accessibility Guidelines (WCAG) 2.0 und 2.1 festgelegt sind. Bedienbar bedeutet, dass Benutzeroberflächenkomponenten und die Navigation bedienbar sein müssen.
Hinweis: Um die W3C-Definitionen für Bedienbar und seine Richtlinien und Erfolgskriterien zu lesen, sehen Sie Prinzip 2: Bedienbar — Benutzeroberflächenkomponenten und Navigation müssen bedienbar sein.
Richtlinie 2.1 — Tastaturzugänglich: Stellen Sie sicher, dass alle Funktionen von einer Tastatur aus verfügbar sind
Diese Richtlinie behandelt die Notwendigkeit, die Kernfunktionalität einer Website zusätzlich zu anderen Mitteln (z. B. Maus) über eine Tastatur verfügbar zu machen, damit Benutzer, die auf Tastatursteuerungen angewiesen sind, darauf zugreifen können.
Erfolgskriterien | Wie man die Kriterien erfüllt | Praktische Ressourcen |
---|---|---|
2.1.1 Tastatur (A) | Alle Funktionen sollten über Tastatursteuerungen zugänglich sein, es sei denn, dies ist mit der Tastatur nicht möglich (z. B. Freihandzeichnung). Eingebettete Steuerungen sollten nach Möglichkeit verwendet werden (z. B. durch Tabulatoren durch Formularelemente), und Sie sollten nur dann eigene Funktionen einbauen, wenn es notwendig ist. | Siehe Verwenden Sie nach Möglichkeit semantische UI-Steuerelemente und Tastaturzugänglichkeit wiedereinbauen |
2.1.2 Keine Tastaturfalle (A) |
Wenn Sie mit der Tastatur einen Funktionsbereich betreten, sollten Sie diesen Bereich auch nur mit der Tastatur wieder verlassen können. Wenn Sie zum Beispiel Enter/Return auf einer fokussierten Schaltfläche drücken, um ein Optionsfenster zu öffnen, sollten Sie dieses Fenster ebenfalls wieder schließen und mit der Tastatur zum Hauptinhalt zurückkehren können. Dies ist sehr wichtig, damit Tastaturbenutzer nicht auf bestimmten Bereichen Ihrer Apps feststecken. |
|
2.1.3 Tastatur — alle Funktionen (AAA) | Dies ist ein Schritt über Kriterium 2.1.1 hinaus. Um AAA-Konformität zu erreichen, sollten alle Funktionen ohne Ausnahmen über Tastatursteuerungen zugänglich sein. | Siehe Verwenden Sie nach Möglichkeit semantische UI-Steuerelemente und Tastaturzugänglichkeit wiedereinbauen |
2.1.4 Zeichen-Tastenkürzel (A) | Wenn es ein Tastenkürzel mit einem einzelnen Zeichen gibt, dann muss mindestens eine der folgenden Aussagen zutreffen: Einzel-Zeichen-Tastenkürzel können deaktiviert, neu zugeordnet oder sind nur aktiv, wenn das entsprechende Benutzeroberflächenelement im Fokus ist. | Verstehen von Zeichen-Tastenkürzeln |
Hinweis: Sehen Sie auch die WCAG-Beschreibung für Richtlinie 2.1 Tastaturzugänglich: Stellen Sie sicher, dass alle Funktionen von einer Tastatur aus verfügbar sind.
Richtlinie 2.2 — Genügend Zeit: Stellen Sie Benutzer ausreichend Zeit zur Verfügung, um Inhalte zu lesen und zu nutzen
Diese Richtlinie behandelt Situationen, in denen Funktionen möglicherweise eine Zeitbegrenzung haben. Zum Beispiel müssen Käufe manchmal aus Sicherheitsgründen innerhalb einer bestimmten Zeitspanne abgeschlossen werden.
Erfolgskriterien | Wie man die Kriterien erfüllt | Praktische Ressourcen |
---|---|---|
2.2.1 Anpassbare Zeit (A) |
Für Funktionen mit Zeitbegrenzung (z. B. das Abschließen einer Hotel- oder Flugbuchung hat oft eine Zeitvorgabe) sollte dem Benutzer Steuerelemente gegeben werden, die es ihm ermöglichen, die Zeitbegrenzung anzupassen, zu verlängern oder abzuschalten. Ausnahmen von dieser Regel sind Aktivitäten mit Zeitbegrenzungen von mehr als 20 Stunden, Echtzeitereignisse (z. B. Live-Multiplayer-Spiele) und jede andere Aktivität, die eine Zeitbegrenzung erfordert und ungültig wäre, wenn sie abgeschaltet würde. |
|
2.2.2 Pausieren, stoppen, ausblenden (A) |
Für sich bewegende oder blinkende Inhalte, die automatisch starten, länger als 5 Sekunden dauern und neben anderen Inhalten gezeigt werden, sollten Steuerelemente bereitgestellt werden, um sie zu pausieren, zu stoppen oder auszublenden. Dies gilt nicht für sich bewegende oder blinkende Inhalte, die für die Erfahrung wesentlich sind. Beispiele sind scrollender Text und Videos. Für automatisch aktualisierende Informationen, die automatisch starten und neben anderen Inhalten gezeigt werden, sollten Steuerelemente bereitgestellt werden, um sie zu pausieren, zu stoppen oder auszublenden oder um die Häufigkeit der Aktualisierungen zu kontrollieren. Dies gilt nicht für automatisch aktualisierende Inhalte, die für die Erfahrung wesentlich sind. Beispiele sind Karussells oder rotierende Ankündigungen. |
|
2.2.3 Keine Zeitbegrenzungen (AAA) | Dies baut auf Kriterium 2.2.1 auf und besagt, dass Inhalte, die die AAA-Konformität erreichen möchten, keine Zeitbegrenzungen haben sollten. | |
2.2.4 Unterbrechen unterdrücken (AAA) | Alle Unterbrechungen wie Warnungen oder überlagerte Werbung sollten Funktionen enthalten, um sie zu unterdrücken oder zu verschieben, es sei denn, es handelt sich um eine Notfallbenachrichtigung. | |
2.2.5 Wiederautorisierung (AAA) | Wenn eine Authentifizierungssitzung während der Nutzung einer Web-App abläuft, sollte der Benutzer sich erneut authentifizieren und seine Nutzung fortsetzen können, ohne Daten zu verlieren. | |
2.2.6 Laufzeitende (AAA) |
Wenn es ein Laufzeitende (verursacht durch Benutzerinaktivität) gibt, sollten Benutzer zu Beginn eines Prozesses gewarnt werden, damit sie nicht überrascht werden, dass ein Laufzeitende existiert (oder nur nach 20 Stunden Inaktivität eintreten). |
Verstehen von Laufzeitenden |
Hinweis: Sehen Sie auch die WCAG-Beschreibung für Richtlinie 2.2 Genügend Zeit: Stellen Sie Benutzern ausreichend Zeit zur Verfügung, um Inhalte zu lesen und zu nutzen.
Richtlinie 2.3 — Anfälle und physische Reaktionen: Gestalten Sie Inhalte nicht so, dass sie Anfälle oder physische Reaktionen auslösen
Dies bezieht sich auf Inhalte, die, wenn sie nicht geändert werden, Anfälle bei Benutzern mit Erkrankungen wie Epilepsie auslösen könnten ODER physische Reaktionen (wie Schwindel) bei Benutzern mit Erkrankungen wie vestibulären Störungen hervorrufen könnten.
Erfolgskriterien | Wie man die Kriterien erfüllt | Praktische Ressourcen |
---|---|---|
2.3.1 Drei-Blitz-Grenze (A) | Der Inhalt enthält keinen Aspekt, der mehr als dreimal pro Sekunde blinkt, oder blinkende Inhalte liegen unter den akzeptablen Blitz- und Rot-Blitz-Grenzen. | |
2.3.2 Drei Blitze (AAA) | Der Inhalt enthält keinen Aspekt, der mehr als dreimal pro Sekunde blinkt. | |
2.3.3 Animationen bei Interaktionen (AAA) | Erlauben Sie Benutzern, Animationen von Interaktionen zu deaktivieren (es sei denn, die Animation ist wesentlich). | Verstehen von Animationen bei Interaktionen |
Hinweis: Sehen Sie auch die WCAG-Beschreibung für Richtlinie 2.3 Anfälle und physische Reaktionen: Gestalten Sie Inhalte nicht so, dass sie Anfälle oder physische Reaktionen auslösen
Richtlinie 2.4 — Navigierbar: Bieten Sie Möglichkeiten, die Benutzern helfen, zu navigieren, Inhalte zu finden und festzustellen, wo sie sich befinden
Die Konformitätskriterien unter dieser Richtlinie beziehen sich auf Möglichkeiten, wie Benutzer erwartet werden können, sich zu orientieren und die Inhalte und Funktionen zu finden, nach denen sie auf der aktuellen Seite oder anderen Seiten der Website suchen.
Erfolgskriterien | Wie man die Kriterien erfüllt | Praktische Ressourcen |
---|---|---|
2.4.1 Blocke überspringen (A) |
Es sollte ein Mechanismus bereitgestellt werden, der es dem Benutzer ermöglicht, direkt zum Hauptinhalt oder zur Hauptfunktionalität auf der Seite zu springen, vorbei an den wiederholten Features (wie dem Firmenlogo oder der Navigation). Dies wird oft durch "Skip-Links" erreicht — Links, die am Anfang des Seitenquellcodes platziert werden, um auf den Hauptinhalt zu verlinken und durch CSS versteckt werden.
Wenn eine ordentliche Struktur von Überschriften und semantischen Containern bereitgestellt wird, um mit (zum Beispiel |
Es muss ein Abschnitt zu "Skip-Links" hinzugefügt werden. |
2.4.2 Seitentitel einfügen (A) |
Jede Webseite sollte einen informativen <title> enthalten, dessen Inhalt den Inhalt/Zweck der Seite beschreibt.
|
Siehe Einen Titel hinzufügen. |
2.4.3 Logische Fokusreihenfolge (A) | Die "Tab-Reihenfolge" von fokussierbaren Seitenelementen (z. B. Links, Schaltflächen, Formulareingaben) sollte logisch sinnvoll sein, sodass die Seite auch für nicht sehende/Tastaturbenutzer bedienbar bleibt. | Siehe Verwenden Sie nach Möglichkeit semantische UI-Steuerelemente für allgemeine Ratschläge zum Tabben zu Steuerelementen. Wenn Sie Elemente in einem ungewöhnlichen Layout platzieren müssen, ist es besser, dafür zu sorgen, dass die Quellreihenfolge sinnvoll ist, und dann CSS-Features wie Positionierung zu verwenden, um das Layout zu steuern. |
2.4.4 Link-Zweck (im Kontext) (A) | Der Zweck/die Zielsetzung eines Links kann aus dem Linktext oder aus seiner Umgebung bestimmt werden (z. B. dem umgebenden Text). Ausnahmen sind, wo der Linkzweck für alle Benutzer mehrdeutig ist (siehe mehrdeutig für Benutzer im Allgemeinen für eine nützliche Erklärung dazu). | Siehe Verwenden Sie aussagekräftige Textbeschriftungen. Beachten Sie auch, dass Sie Instanzen minimieren sollten, bei denen mehrere Kopien desselben Textes zu verschiedenen Orten verlinken. Dies kann Probleme für Bildschirmleser-Benutzer verursachen, die oft eine Liste der Links außerhalb des Kontexts aufrufen — mehrere Links, die alle mit "hier klicken", "hier klicken", "hier klicken" beschriftet sind, wären verwirrend. |
2.4.5 Mehrere Navigationsmechanismen (AA) |
Sie sollten mindestens zwei allgemeine Navigationsmechanismen bereitstellen, um Seiten auf Ihrer Website zu finden, beispielsweise Navigationsmenü, Breadcrumb-Trail, Websitesuche, Sitemap, Liste verwandter Links usw. Die einzige Ausnahme hierbei ist, wenn eine Seite einen Schritt in einem Prozess darstellt und daher nur logisch Links zu den vorhergehenden und nächsten Schritten haben sollte. |
Die meisten dieser Mechanismen können mit vollständig unterstützten HTML-Funktionen erstellt werden, siehe zum Beispiel Suchfeld, Erstellen eines Navigationsmenüs, Styling von Links als Schaltflächen. |
2.4.6 Überschriften und Beschriftungen (AA) |
Überschriften (z. B. <h2>) und <label> -Elemente beschreiben klar den Zweck der Inhalte und Formularelemente, die sie beschreiben sollen.
|
Siehe Verwenden Sie nach Möglichkeit semantische UI-Steuerelemente, Verwenden Sie aussagekräftige Textbeschriftungen, Die Grundlagen von Überschriften und Absätzen, Das <label>-Element. Beachten Sie, dass Sie die Duplizierung von Überschriften oder Beschriftungen vermeiden sollten (z. B. mehrere Instanzen von "Weitere Informationen"), es sei denn, die Struktur ermöglicht es Ihnen, zwischen ihnen leicht zu unterscheiden. |
2.4.7 Sichtbarer Fokus für fokussierbare Elemente (AA) | Beim Wechsel zwischen fokussierbaren Elementen wie Links oder Formulareingaben sollte es einen visuellen Indikator geben, der anzeigt, welches Element aktuell den Fokus hat. Dies ist normalerweise standardmäßig ein gepunkteter oder blauer Umriss (abhängig vom Browser, der Plattform usw.), kann jedoch durch CSS überschrieben werden. | Siehe Verwenden Sie nach Möglichkeit semantische UI-Steuerelemente. |
2.4.8 Standort innerhalb der Website (AAA) | Wenn sich der Benutzer auf einer Seite innerhalb einer komplexen Website oder eines Schrittsatzes befindet, sollte ihm ein Indikator darüber gegeben werden, wo er sich auf der Website befindet, beispielsweise ein Breadcrumb-Trail, eine Sitemap oder ein Text wie "Formularseite 2 von 10". | |
2.4.9 Link-Zweck (nur Link) (AAA) | Dieses Kriterium baut auf 2.4.4 auf und besagt, dass, um AAA-konform zu sein, der Zweck/die Zielsetzung eines Links allein aus dem Linktext bestimmt werden sollte, selbst wenn er aus dem Kontext gerissen ist. | Siehe Verwenden Sie aussagekräftige Textbeschriftungen. Beachten Sie auch, dass Sie Instanzen minimieren sollten, bei denen mehrere Kopien desselben Textes zu verschiedenen Orten verlinken. Dies kann Probleme für Bildschirmleser-Benutzer verursachen, die oft eine Liste der Links außerhalb des Kontexts aufrufen — mehrere Links, die alle mit "hier klicken", "hier klicken", "hier klicken" beschriftet sind, wären verwirrend. |
2.4.10 Abschnittsüberschriften (AAA) |
Überschriften sollten nicht nur eine nützliche Dokumentenstruktur schaffen, sondern auch die Inhalte genau beschreiben und in logische Abschnitte unterteilen. Beachten Sie, dass sich dieses Kriterium auf Überschriften und Titel in allgemeinen Webinhalten bezieht (z.B. Überschriften innerhalb von Textinhalten). Überschriften und Titel für Benutzeroberflächen sind ein spezieller Fall, der in Kriterium 4.1.2 behandelt wird. |
|
2.4.11 Fokus nicht verdeckt (Minimum) (AA) |
Wenn eine Benutzeroberflächenkomponente den Tastaturfokus erhält, wird die Komponente nicht vollständig durch autorenerstellte Inhalte verborgen. Hinweis: Wenn der Inhalt der Schnittstelle vom Benutzer neu positioniert werden kann, wird für Tests zur Einhaltung dieses Standards nur die anfängliche Position der benutzerbewegbaren Inhalte berücksichtigt. Außerdem können Inhalte, die vom Benutzer geöffnet wurden, die Komponente verdecken, die den Fokus erhält. Weiterhin, wenn der Benutzer die fokussierte Komponente sichtbar machen kann, ohne den Tastaturfokus zu ändern, wird die Komponente mit Fokus nicht als verborgen in Bezug auf Konformität und Tests angesehen. |
Sehen Sie sich Verständnis von Fokus nicht verdeckt (Minimum) an, um mehr über diesen Standard zu erfahren. |
2.4.12 Fokus nicht verdeckt (Verbessert) (AAA) |
Folgt den Regeln wie 2.4.11, außer wenn eine Benutzeroberflächenkomponente den Fokus erhält, kann kein Teil der Komponente durch autorenerstellte Inhalte verdeckt werden. Wenn die Oberfläche konfigurierbar ist, werden für Tests und die Einhaltung dieses Standards nur die anfänglichen Positionen von benutzerbewegbaren Inhalten berücksichtigt. |
Sehen Sie sich Verständnis von Fokus nicht verdeckt (Verbessert) (Level AAA) an, um mehr über diesen Standard zu erfahren. |
2.4.13 Fokuserscheinung (AAA) |
Wenn der Tastaturfokus-Indikator sichtbar ist, erfüllt der Bereich des Fokus-Indikators alle folgenden Eigenschaften:
Die Ausnahmen sind:
|
Sehen Sie sich Verständnis der Fokuserscheinung (Level AAA) an, um mehr über diesen Standard zu erfahren. |
Hinweis: Sehen Sie auch die WCAG-Beschreibung für Richtlinie 2.4 Navigierbar: Bieten Sie Möglichkeiten, die Benutzern helfen, zu navigieren, Inhalte zu finden und festzustellen, wo sie sich befinden.
Richtlinie 2.5 Eingabemodalitäten: Erleichtern Sie es Benutzern, Funktionen über verschiedene Eingabemethoden jenseits der Tastatur zu bedienen
Die Konformitätskriterien unter dieser Richtlinie stellen sicher, dass Benutzer in der Lage sind, mit digitaler Technologie mittels verschiedener Eingabemethoden jenseits einer Tastatur oder Maus (einschließlich Touchscreen, Sprachsteuerung, Gerätebewegung oder alternativen Eingabegeräten) zu interagieren.
Erfolgskriterien | Wie man die Kriterien erfüllt | Praktische Ressourcen |
---|---|---|
2.5.1 Zeigergesten (A) | Alle Funktionen, die mit einem Zeiger bedient werden können, können auch mit Einpunkt-Aktionen bedient werden. Pfadbasierte oder Mehrpunkt-Gesten sind zur Bedienung keiner Funktion erforderlich. Es gibt Ausnahmen. | Verständnis von Zeigergesten |
2.5.2 Zeigerabbruch (A) | Für Funktionen, die mit einem einzelnen Zeiger bedient werden können, trifft mindestens eine der folgenden Aussagen zu: kein nach unten-Event, Abbruch/Rückgängig, Aufwärtsumkehr oder wesentlich. | Verständnis von Zeigerabbruch |
2.5.3 Beschriftung im Namen (A) | Für jede Benutzeroberflächenkomponente, die eine sichtbare Textbeschriftung enthält, stellen Sie sicher, dass der zugängliche Name mit dem sichtbaren Text im Beschriftungstext übereinstimmt (oder diesen beinhaltet). | Verständnis von Beschriftung im Namen |
2.5.4 Bewegungsaktivierung (A) | Stellen Sie sicher, dass für Funktionen, die durch a) Gerätebewegung (wie Schütteln, Neigen) oder b) vom Gerät erfasste Benutzerbewegungen ausgelöst werden können (einschließlich einer Kamera), dass beide folgenden Aussagen zutreffen: 1) Bewegungsaktivierung kann deaktiviert werden, und 2) die Funktion kann bedient werden, ohne Gerätebewegung oder Benutzerbewegungen zu verwenden. Es gibt Ausnahmen. | Verständnis von Bewegungsaktivierung |
2.5.5 Zielgröße (AAA) | Die Größe des berührungsempfindlichen Ziels eines bedienbaren Elements muss mindestens 44 CSS-Pixel in Breite und Höhe betragen. Es gibt Ausnahmen. | Verständnis von Zielgröße |
2.5.6 Gleichzeitige Eingabemechanismen (AAA) | Stellen Sie sicher, dass Personen verschiedene Eingabemodi verwenden und zwischen diesen wechseln können, wenn sie mit digitalen Inhalten interagieren, einschließlich Touchscreen, Tastatur, Maus, Sprachbefehlen oder alternativen Eingabegeräten. Es gibt eine wesentliche Ausnahme. | Verständnis von gleichzeitigen Eingabemechanismen |
2.5.8 Mindestzielgröße (AA) | Die Zielgröße für Zeigereingaben sollte mindestens 24px breit und 24px hoch sein, außer in den folgenden Bereichen:
| Sehen Sie sich Understanding target size minimum an |
Hinweis: Sehen Sie auch die WCAG-Beschreibung für Richtlinie 2.5: Eingabemodalitäten: Erleichtern Sie es Benutzern, Funktionen über verschiedene Eingabemethoden jenseits der Tastatur zu bedienen.
Siehe auch
-
- Wahrnehmbar
- Bedienbar
- Verständlich
- Robust