Barrierefreie Gestaltung von User Interface-Elementen

Vorwort

Online betrachten

Im Rahmen der Ziele der “Barrierefreie Informationstechnik Verordnung” (BITV 2.0) soll moderne Informations- und Kommunikationstechnik möglichst umfassend und grundsätzlich uneingeschränkt barrierefrei gestaltet werden.

Bei der Umsetzung stößt man schnell auf Unklarheiten, da bestehende Vorgaben viel Interpretationsspielraum lassen.

Diese Unstimmigkeiten führen oft zu unterschiedlichen Auslegungen der bestehenden Vorgaben und spätestens bei der Abnahme von Artefakten oder ganzen IKT-Systemen zu Verdruss bis hin zu juristischen Auseinandersetzungen.

Die Autorinnen und Autoren dieses Dokuments haben sich der Aufgabe angenommen, diese Kluft zwischen den gesetzlichen Anforderungen, Richtlinien, Normen und bestehenden Design Guides oder Styleguides – auch von Software Hersteller – zu schließen.

Die in DIN EN ISO 9241-161 beschriebenen visuellen User-Interface-Elemente wurden dafür betrachtet, um weitere Elemente ergänzt und hinsichtlich der Anforderungen an die Barrierefreiheit gemäß EN 301 549 v3.2.1 erweitert. Für jedes UI-Element wurden Anforderungen in Bezug auf Darstellung, Bedienung sowie Programmierung/Schnittstellen definiert.

Dieses nachschlagewerk dient als Ergänzungshinweis zur DIN EN ISO 9241-161 und als Hilfsmittel zur Umsetzung der EN 301 549 v3.2.1 und soll keinesfalls aktuell gültige gesetzliche Vorgaben oder Richtlinien ersetzen. Im Gegenteil, diese Sammlung basiert darauf und unterliegt einem entsprechenden Aktualisierungsprozess.

Inhaltsverzeichnis

• Zielsetzung und Zielgruppe

• Geltungsbereich

• Lesehinweise

Zielsetzung und Zielgruppe

Online betrachten

Das Dokument versucht folgende Lücken in den Veröffentlichungen zur Barrierefreiheit zu schließen:

• Für Web-Dokumente gibt es beim W3C viele konkrete Beispiele, wie barrierefreie Seiten gestaltet sein müssen (siehe z. B. How to Meet WCAG (Quickref Reference) (w3.org) (Externer Link)). Entsprechende Dokumente fehlen für Software.

• Die EN 301 549 enthält im Kapitel 11 Anforderungen an Software. Diese Anforderungen sind allgemeiner Natur. Es wird nicht beschrieben, wie UI-Elemente konkret umgesetzt werden müssen, um den Anforderungen zu genügen. Für Desktop-Software fehlt ein Äquivalent zu den WAI-ARIA Authoring Practices ( WAI-ARIA Authoring Practices 1.2 (w3.org) (Externer Link)).

• Das W3C hat mit WCAG2ICT ( Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT) (w3.org) (Externer Link)) im Jahr 2013 ein Dokument veröffentlicht, welches beschreibt, in welcher Weise die WCAG-Anforderungen auf Software und Dokumente angewendet werden können. Das Dokument ist veraltet und enthält nicht die Anforderungen der aktuellen WCAG 2.1.

Das Dokument richtet sich vorrangig an Entwickler*innen von Software.

Weitere Rollen in der Software-Entwicklung, für die das Dokument hilfreich sein kann, sind u. a.

• Design (insbesondere bezüglich der Anforderungen an Schriften, Farben und Kontraste sowie der Ausführungen in den Abschnitten „Darstellung“ bei jedem UI-Element),

• Redaktion für die Textinhalte der Software und Hilfe,

• Barrierefreiheitstest,

• Beeinträchtigte Menschen, die Software nutzen (um sich z. B. mit gängigen Tastaturkonventionen vertraut zu machen, siehe dazu die Abschnitte „Tastaturbedienung“ bei jedem UI-Element).

Geltungsbereich

Online betrachten

Geltungsbereich

In diesem Dokument werden Barrierefreiheitsanforderungen an Web- und Desktop-Software sowie an hybride Anwendungen (die Web- und Desktop-Technologien vereinen) beschrieben, die auf der Plattformsoftware Microsoft Windows laufen und eine offene Funktionalität aufweisen. Die Anforderungen leiten sich vor allem aus der EN 301 549 (Version 3.2.1, Abschnitt 9 und 11) ab.

Das vorliegende Dokument gilt zunächst nicht für folgende Software:

• Software mit geschlossener Funktionalität (Abschnitt 5.1 der EN 301 549),

• Software für Zweiwege-Sprachkommunikation (Abschnitt 6 der EN 301 549),

• Software mit Videofunktionalität (Abschnitt 7 der EN 301 549),

• Autorenwerkzeuge (Abschnitt 11.8 der EN 301 549),

• Software mit Zugang zu Umsetzungs- oder Notfalldiensten (Abschnitt 13 der EN 301 549),

• Software, die auf anderer Plattformsoftware als Microsoft Windows läuft (wie z. B. Unix, Linux, Chrome OS, macOS, iOS, Android),

• Assistenztechnologien,

• Plattformsoftware,

• Apps für Mobilgeräte (für z. B. Tablets oder Smartphones).

Darüber hinaus gilt das Dokument nicht für:

• Hardware (Kapitel 8 der EN 301 549),

• Dokumente (Kapitel 10 der EN 301 549), selbst wenn die Dokumente interaktiv sind (z. B. Tabellenkalkulation mit Makros, PDF mit Formular),

Viele der hier beschriebenen Anforderungen können auf Software anderer Plattformen übertragen werden.

Lesehinweise

Online betrachten

Aufbau des Dokuments

Das Dokument gliedert sich in folgende Bereiche:

• Anwendungsbezogene Anforderungen, die für die gesamte Software gelten,

• Elementübergreifende Anforderungen, die für alle oder mehrere UI-Elemente gelten,

• Textelemente,

• Grafische Elemente,

• Strukturelle Elemente (die der Strukturierung der Dialogmasken in einzelne Bereiche dienen),

• Bedienelemente,

• Zusammengesetzte Bedienelemente (komplexe Bedienelemente, die aus mehreren einfachen Bedienelementen bestehen).

Jeder Bereich enthält mehrere Abschnitte, „Bedienelemente“ gliedert sich bspw. in je einen Abschnitt pro konkretem Bedienelement.

Die einzelnen Unterkapitel sind unterteilt in:

• Einleitung:

  • Synonyme: Andere Bezeichnungen für das beschriebene UI-Element, über die das Element auch im Index auffindbar ist,

  • Verweis auf ähnliche Elemente oder verwandte Themen,

  • Beschreibung des Elements oder Themas,

• Darstellung (Anforderungen an die visuelle Darstellung)

• Bedienung (Anforderungen an die Bedienung, insbesondere mit Tastatur und Zeigeinstrumenten)

• Programmierung/Schnittstellen (Anforderungen an Informationen, die an die Accessibility API übermittelt werden).

Die Anforderungen werden in Tabellenform dargestellt:

Hinweis: Die Gültigkeit der Anforderungen wird wie folgt angegeben:

• Web-Anwendungen: „Web:“

• Desktop-Anwendungen: „Desktop:“

• Hybride Anwendungen: „Desktop:“

• Für alle Anwendungen gültig: Keine Angabe

Klassifizierung der Anforderungen

Die Anforderungen sind wie folgt klassifiziert:

Die konkreten Anforderungen an die Tastaturbedienung, d. h. welche Tasten zur Bedienung zu verwenden sind, werden wie folgt klassifiziert:

Hinweis: Die Anforderungen an die Tastaturbedienung können nicht mit „Muss“ oder „Soll“ klassifiziert werden, da die EN 301 549 lediglich die Möglichkeit der Tastaturbedienung verlangt, nicht jedoch konkrete Tasten festgelegt, da diese z. B. von der jeweiligen Plattform abhängen.

Der Elementleitfaden enthält darüber hinaus Hinweise, Empfehlungen und Praxistipps. Diese sind nicht-normativ. Allerdings wird auch in den Hinweisen, Empfehlungen und Praxistipps „muss“, „darf nicht“, „soll“ und „soll nicht“ verwendet, sofern sich auf eine Anforderung bezogen wird.

Abdeckung der Anforderungen

In den Abschitten zu allgemeinen Themen („Anwendungsbezogene Anforderungen“ und „Elementübergreifende Anforderungen“) wird auf dialogbezogene Anforderungen der EN 301 549 (insbesondere Abschitt 9 zu Web und 11 zu Software) eingegangen. Die Anforderungen werden hier allgemein (d. h. nicht in Bezug auf konkrete UI-Elemente) und weitgehend allumfassend erläutert (d. h. mit möglichen Sonderfällen, Ausnahmen etc.).

In den Abschitten zu einzelnen UI-Elementen (Text, Grafik, Struktur, Bedienelemente) werden lediglich die relevanten Anforderungen für das jeweilige UI-Element aufgeführt. Hier wird darauf eingegangen, was eine allgemeine Anforderung für ein konkretes Element bedeutet. Die Anforderungen werden dabei jedoch nicht unbedingt allumfassend erläutert, d. h. für Sonderfälle und Ausnahmen wird auf den jeweiligen allgemeinen Abschitt verwiesen

Beispiel:

• Im Abschnitt zum UI-Element Checkbox wird nicht auf die Anforderung der visuellen Vergrößerung der Checkbox eingegangen, weil keine Checkbox-spezifischen Probleme oder Anforderungen in Bezug auf das Zoomen existieren. Die Anforderungen an die Vergrößerung sind jedoch im Abschitt „Vergrößerung“ zu finden und gelten somit auch für Checkboxen.

• Im Abschnitt zum UI-Element Checkbox werden spezifische Kontrastanforderungen beschrieben, um genauer zu erläutern, inwieweit die allgemeinen Kontrastanforderungen aus dem Abschitt „Farben und Kontraste“, auf die Checkbox anzuwenden sind. Es wird hier jedoch nicht auf den Sonderfall der deaktivierten Checkbox eingegangen, weil Ausnahmen für deaktivierte Elemente im Abschitt „Farben und Kontraste“ beschrieben sind.

Abdeckung der Elemente

Folgende Elemente werden im vorliegenden Dokument aufgrund ihrer geringen Relevanz für Software nicht beschrieben:

• Rich Text Editor,

• Video,

• Audio,

• Image map,

• Landkarten.

Es ist jedoch vorgesehen, diese Anforderungen und Elemente in einer zukünftigen Version des Dokuments aufzunehmen.

Technologiespezifische Besonderheiten

Einige Programmiersprachen oder Frameworks ermöglichen es aufgrund von Beschränkungen der jeweiligen Technologie nicht, alle Anforderungen zu erfüllen. In diesem Fall soll geprüft werden, ob eine andere Programmiersprache oder anderes Framework verwendet werden kann. Alternativ sollen die Anforderungen so gut wie möglich erfüllt werden. Alle Abweichungen sollen in der Hilfe sowie in der Erklärung zur Barrierefreiheit dokumentiert werden.

Das vorliegende Dokument behandelt keine technologiespezifischen Besonderheiten, sondern konzentriert sich auf das erwartete Verhalten von UI-Elementen.

Anwendungsbezogene Anforderungen

Online betrachten

Inhaltsverzeichnis

• Konforme alternative Version

• Anwendungssprache und Sprachwechsel

• Fehlervermeidung und -korrektur

• Hilfe und Support

• Vergrößerung

• Accessibility API

• Authentifizierung

• Animationen

• Navigationsreihenfolge

• Kontextänderungen

• Zeitbegrenzungen

Konforme alternative Version

Online betrachten

Sofern die Anwendung nicht alle Anforderungen an die Barrierefreiheit erfüllt, kann eine konforme Alternativversion zur Verfügung gestellt werden. Dabei müssen jedoch folgende Anforderungen eingehalten werden:

• Die konforme Alternativversion erfüllt alle Anforderungen, d. h. ist vollständig barrierefrei. Werden mehrere Alternativversionen angeboten, ist mindestens eine Alternativversion vollständig konform. Es ist somit nicht zulässig, für einzelne Benutzergruppen spezifische Alternativversionen anzubieten, die jeweils nur die Anforderungen der jeweiligen Gruppe erfüllen, solange es keine Alternativversion gibt, die alle Anforderungen aller Benutzergruppen erfüllt.

• Die konforme Alternativversion ist bezüglich aller Inhalte und Funktionen äquivalent mit der Version, die nicht barrierefrei ist. So darf die Alternativversion z. B. nicht veraltete Informationen erhalten. Sofern die Standardversion in verschiedenen Sprachen angeboten wird, muss auch die Alternativversion in den Sprachen angeboten werden.

• Die konforme Alternativversion kann auf barrierefreie Weise erreicht werden. Dies bedeutet:

  • Die Funktion zum Wechsel zur konformen Alternativversion muss barrierefrei sein.

  • Die Standardversion darf keine Tastaturfallen oder blitzende Inhalte enthalten. Darüber hinaus darf die Standardversion keine sich bewegende, blinkende, automatisch aktualisierende oder akustische Inhalte enthalten, die nicht gestoppt werden können (https://www.w3.org/TR/WCAG21/#cc5).

  • Alternativ kann über eine barrierefreie Maske (z. B. die Login-Maske) sowohl die konforme als auch die Standardversion erreicht werden oder die konforme Alternativversion ist die Standardversion.

• In der Dokumentation wird der Zweck und das Erreichen der konformen Alternativversion erläutert.

• Der Support-Service kann den Zweck und das Erreichen der konformen Alternativversion erläutern (um EN 301 549, Abschitt 12.2.2, zu erfüllen). Es wird empfohlen, immer nur eine Version der Anwendung anzubieten und diese barrierefrei zu gestalten.

Hinweis 1: Ein typischer Anwendungsfall für eine konforme alternative Version ist, wenn die Standardversion der Web-Anwendung aufgrund des Corporate Design die Kontrastanforderungen für Text oder grafische Inhalte nicht erfüllt. In diesem Fall kann die konforme alternative Version eine CSS-Auszeichnung verwenden, die für ausreichende Kontraste sorgt.

Hinweis 2: Bei ausgewählten Web-Anwendungen, die bereits weitgehend barrierefrei sind, kann ein Overlaytool dazu in der Lage sein, eine konforme Alternativversion zu generieren, die die oben formulierten Anforderungen vollständig erfüllt. In der Regel ist dies allerdings nicht der Fall, insbesondere wenn die Web-Anwendung Probleme aufweist, die nicht automatisiert gefunden und behoben werden können. Ein Overlaytool kann somit nicht pauschal verwendet werden, um eine konforme alternative Version zur Verfügung zu stellen ( Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik - Publikationen - Gemeinsame Einschätzung der Überwachungsstellen des Bundes und der Länder für die Barrierefreiheit von Informationstechnik zur Verwendung von Overlay-Tools (bfit-bund.de) (Externer Link))

Hinweis 3: Für Desktop-Anwendungen trifft die EN 301 549 keine Aussagen zu alternativen Versionen. Es kann jedoch davon ausgegangen werden, dass für Desktop-Anwendungen die gleichen Anforderungen gelten.

Anwendungssprache und Sprachwechsel

Online betrachten

Synonyme: Language

Siehe auch: Beschriftung, Beschreibung, Text, Schrift

Fremdsprachige Inhalte können für beeinträchtigte Menschen schwer verständlich sein. Dies gilt insbesondere, wenn diese von der Sprachausgabe mit der falschen Aussprache ausgegeben werden.

Darstellung

Programmierung/Schnittstellen

Fehlervermeidung und -korrektur

Online betrachten

Synonyme: Error message, Fehlermeldungen, Eingabehinweise, kontextspezifische Hilfe

Siehe auch: Pflichtfeldkennzeichnung, Beschreibung, Hilfe und Support, Authentifizierung, Formular

Fehlermeldungen informieren Benutzende über Fehleingaben oder Fehlbedienungen. Fehlermeldungen unterstützen bei der Fehlerkorrektur. Fehlermeldungen können

• nach dem Absenden eines Formulars,

• beim Ausfüllen eines Formulars oder

• bei der Bedienung der Software

angezeigt werden.

Eingabehinweise helfen Benutzenden beim Vermeiden von Fehlern. Sie können

• beim Formular,

• beim jeweiligen Formularfeld oder

• bei der Bedienung der Software

angezeigt werden.

Darstellung

Programmierung/Schnittstellen

Hilfe und Support

Online betrachten

Synonyme: Handbuch, Dokumentation, Support, Help

Siehe auch: Beschreibung, Fehlermeldungen

Beispiele:

Darstellung

Bedienung

Tastaturbedienung Hilfe

Vergrößerung

Online betrachten

Synonyme: Skalierung, Schriftgrößenanpassung, Zoom

Siehe auch: Schrift, Text

Die folgenden Anforderungen sollen die Anpassung der Schriftgröße an die Nutzungspräferenzen ohne Assistenztechnologie gewährleisten.

Darstellung

Accessibility API

Online betrachten

Synonyme: Barrierefreiheits-Schnittstelle, Interoperabilität mit Assistenztechnologie, Kompatibilität mit Assistenztechnologie, Plattformunterstützung von Barrierefreiheitsdiensten für Assistenztechnologien, Programmierschnittstelle für Assistenztechnologien

Siehe auch: Elementstatus, Kontextänderungen, Kontrastanpassung

Assistenztechnologien, wie Screenreader, Bildschirmlupen, Windows-Kontrastanpassung oder Spracheingabe-Software, interagieren in der Regel nicht direkt mit der Software oder dem Browser, sondern mittels einer Schnittstelle für die Barrierefreiheit, die z. B. vom Betriebssystem zur Verfügung gestellt wird: die Accessibility API (Application Programming Interface). Die Software bzw. der Browser übermittelt alle relevanten Informationen in standardisierter Form an die Accessibility API und die Assistenztechnologie greift auf die in der Accessibility API zur Verfügung gestellten Informationen zu. Die Assistenztechnologie nutzt jedoch nur die Informationen aus der Accessibility API, die entsprechend den Bedürfnissen der Benutzenden relevant sind. Wenn Anwendungen mittels Assistenztechnologie bedient werden, erfolgt die Bedienung teilweise nicht direkt, sondern auch vermittelt über die Accessibility API.

Die bekanntesten Accessibility APIs unter Microsoft Windows sind:

• IAccessible2,

• MSAA (Microsoft Active Accessibility, Standard 1997-2005),

• UIA (Microsoft UI Automation, Standard seit 2005).

Windows-Anwendungen sollen die aktuelle Accessibility API UIA verwenden.

Software, die nicht die Accessibility API des Betriebssystems nutzt, kann eigene Schnittstellen für die Übermittlung von Informationen an die Assistenztechnologie implementieren. So nutzen Java-Anwendungen die Java Accessibility API (JAAPI).

Die folgenden Informationen werden bspw. von der Software bzw. dem Browser an die Accessibility API übermittelt und bei Bedarf durch die Assistenztechnologie ausgelesen:

• Rolle eines Objekts (z. B. Überschrift, Checkbox, Tabellenzelle),

• Status eines Objekts (z. B. fokussiert, fokussierbar, deaktiviert, geöffnet),

• Beschriftung eines Objekts,

• Beschreibung eines Objekts,

• Wert eines Objekts (z. B. bei Formularfeldern),

• mögliche Werte (z. B. Maximal- und Minimalwert bei bestimmten Formularfeldern),

• Position in der Objekthierarchie (z. B. Eltern- und Kindobjekte, Anzahl der Geschwisterobjekte, Position in Bezug auf die Geschwisterobjekte),

• räumliche Größe und Lage in Bezug auf den aktuellen Bildschirmausschnitt,

• Ereignisse (z. B. Änderung von Objekteigenschaften).

Hinweise:

• Die meisten Programmiersprachen, die für die Entwicklung von Software genutzt werden können, unterstützen eine Accessibility API. Dies gilt analog für Browser.

• Die Unterstützung der Accessibility API erfolgt dabei meist automatisch, solange die Standardelemente der Programmiersprache oder Auszeichnungssprache (z. B. HTML) verwendet werden. Wenn die Sprache z. B. Eingabefelder als Bedienelement anbietet, dann werden Rolle, Wert, Status, Position in der Objekthierarchie, Größe und Lage des Eingabefeldes korrekt an die Accessibility API übermittelt. Meist muss die sichtbare Beschriftung korrekt mit dem Eingabefeld verknüpft werden, damit sie ebenfalls als Beschriftung des Eingabefeldes an die API übermittelt wird.

• Dies gilt analog für Standardeigenschaften der Programmiersprache oder Auszeichnungssprache, die automatisch an die Accessibility API übermittelt werden. Wird z. B. ein Eingabefeld mit der Eigenschaft „deaktiviert“ versehen, so werden automatisch die Eigenschaften „deaktiviert“ und „nicht tastaturfokussierbar“ an die API übermittelt.

• Je nach verwendeter Programmiersprache oder Auszeichnungssprache kann es sein, dass bestimmte Eigenschaften des Objekts, die an die Accessibility API übermittelt werden sollen, explizit (d. h. in Textform) angegeben werden müssen, weil sie anders nicht übermittelt werden können.

• Sofern kein Standardelement der Programmiersprache oder Auszeichnungssprache verwendet wird, muss entwicklungsseitig sichergestellt werden, dass alle relevanten Objektinformationen korrekt an die Accessibility API übermittelt werden. Wenn die Sprache keine Möglichkeit bietet, um diese Informationen explizit zu definieren, sollen nur Standardelemente verwendet werden.

• Wenn eine Programmiersprache weder eine Accessibility API unterstützt noch einen alternativen Zugriff der verschiedenen Assistenztechnologien auf die benötigten Informationen anbietet, soll sie nicht verwendet werden oder die Software muss dann die Anforderungen aus Abschnitt 5.1 (geschlossene Funktionalität) der EN 301 549 erfüllen.

Programmierung/Schnittstellen

Praxistipp Accessibility API bei Desktop-Anwendungen

Die Standardelemente der Plattformsoftware oder des verwendeten Frameworks übermitteln in der Regel automatisch die korrekten Informationen an die Accessibility API. Diese sollen somit bevorzugt verwendet werden.

Beispiel 1:

• In der folgenden Abbildung wird der Dialog „Speichern unter“ der Anwendung „Windows-Fax und -Scan“ gezeigt.

• Abgebildet ist außerdem eine vollständige Liste der Informationen, die für das Eingabefeld „Dateiname“, welches sich in diesem Dialog befindet, an die Accessibility API übermittelt werden (ausgelesen mit Accessbility Insights for Windows).

• Daneben wird die Sprachausgabe des Screenreaders JAWS bei Fokussierung des Eingabefeldes „Dateiname“ gezeigt. JAWS nutzt für die akustische Ausgabe nur die im aktuellen Kontext relevanten Informationen der Accessibility API (z. B. Beschriftung, Rolle, Wert, Tastaturkürzel), übersetzt diese Informationen teilweise in die Anwendungssprache (z. B. die Rolle „Edit(50004)“ in „Eingabefeld“) und ergänzt diese Informationen mit einem eigenen Bedienhinweis („Geben Sie Text ein“), der aus der übermittelten Rolle abgeleitet wird.

Werden benutzerdefinierte Elemente verwendet, so soll insbesondere auf Folgendes geachtet werden:

• die übermittelte Rolle entspricht der visuellen Darstellung und Bedienweise (insbesondere der Tastaturbedienung),

• der Wert und Status sollen an die Accessibility API übermittelt werden,

• die Beschriftung wird als Accessible Name an die Accessibility API übermittelt,

• sofern vorhanden, werden auch Tastaturkürzel, Beschreibungen (als Accessible Description) und Beschriftungen der Gruppen an die Accessibility API übermittelt,

• Aktualisierungen hinsichtlich Wert, Status, Beschriftung etc. werden an die Accessibility API übermittelt (Hinweis: Die Rolle eines Elements soll nicht verändert werden).

Wird ein benutzerdefiniertes Element implementiert, empfiehlt es sich häufig, ein verwandtes Standardelement zu verwenden und entsprechend anzupassen, weil dann die Grundfunktionalität des Standardelements genutzt werden kann.

Für die Übermittlung der Informationen sollen die entsprechenden Eigenschaften der Accessibility API verwendet werden. Wenn es für eine Information keine entsprechende Eigenschaft in der Accessibility API gibt oder das verwendete Framework diese Eigenschaft nicht unterstützt, muss die Information in Textform (d. h. als Teil des Accessible Names oder der Accessible Description) übermittelt werden.

Beispiel: Deaktivierte Elemente

• Deaktivierte Elemente können meist mit einem Attribut als disabled ausgezeichnet werden. In der Accessibility API UIA entspricht dies der Eigenschaft IsEnabled:false. Assistenztechnologie erkennt aufgrund dieser Eigenschaft, dass das Element deaktiviert ist.

• Wenn eine programmatische Auszeichnung als deaktiviert nicht möglich ist, können alternativ folgende Möglichkeiten angewendet werden:

  • Das Element wird entfernt.

  • Das Element wird nicht fokussierbar gestaltet (sofern es keine Informationen übermittelt und sich nicht innerhalb eines Bereichs befindet, der mit dem virtuellen Cursor gelesen werden kann).

  • Das Element wird im Accessible Name oder in der Accessible Description als „deaktiviert“ benannt.

Beispiel: Schalter mit Wert

• Ein Schalter kann standardmäßig keinen Wert besitzen. Unter Windows ist es jedoch möglich, basierend auf dem Standardelement Schalter ein benutzerdefiniertes Element „Schalter mit Wert“ zu erstellen. Der Wert wird dann als Wert der Eigenschaft Value an die Accessibility API UIA übermittelt.

• In HTML und ARIA ist es nicht möglich, einem Schalter einen Wert zuzuweisen. Soll der „Schalter mit Wert“ in einer hybriden Anwendung, die auf Web-Technologien basiert, eingesetzt werden, dann muss der Wert in Textform als Teil des Accessible Names oder der Accessible Description übermittelt werden.

Die Übermittlung von Informationen über die entsprechenden Eigenschaften der Accessibility API ist gegenüber der Übermittlung dieser Informationen in Textform (als Teil von Accessible Name oder Accessible Description) aus folgenden Gründen immer zu bevorzugen:

• die Assistenztechnologie kann die Eigenschaften, die über die API übermittelt werden, auf eine durch die Anwendung oder von den Benutzenden definierte Art und Weise ausgeben,

• die Assistenztechnologie kann die Eigenschaften, die über die API übermittelt werden, in die korrekte Sprache übersetzen,

• die Assistenztechnologie kann passend zu den Eigenschaften, die über die API übermittelt werden, Bedienhinweise ausgeben oder Bedienmodalitäten anbieten,

• die Assistenztechnologie kann basierend auf den Eigenschaften, die über die API übermittelt werden, eine bestimmte Darstellungsweise anbieten (z. B. eine bestimmte Farbe bei der Kontrastanpassung),

• die Assistenztechnologie kann die Eigenschaften (wie Rolle, Status, Wert) in einer bestimmten Reihenfolge ausgeben, die sicherstellt, dass relevante Informationen zuerst ausgegeben werden und dass die Benutzenden erkennen können, welche Informationen zu welchem Eigenschaftstyp gehören,

• die Benutzenden können in ihrer Assistenztechnologie ggf. konfigurieren, dass sie bestimmte Eigenschaften nicht ausgegeben bekommen möchten.

Dies ist alles nicht möglich, wenn die Information lediglich in Textform übermittelt wird.

Beispiel 2: In der folgenden Abbildung sind drei Schalter mit den Beschriftungen „Absenden“, „Prüfen“ und „Löschen“ zu sehen.

• Der „Absenden“-Schalter ist visuell als bedienbar zu erkennen (schwarze Textfarbe).

• Der „Prüfen“-Schalter ist visuell als deaktiviert zu erkennen (graue Schriftfarbe). Der Schalter ist programmatisch als deaktiviert ausgezeichnet. Diese Umsetzung ist für deaktivierte Schalter zu bevorzugen.

• Der „Löschen“-Schalter ist visuell ebenfalls als deaktiviert zu erkennen (graue Schriftfarbe). Der Schalter ist aber programmatisch nicht als deaktiviert ausgezeichnet, sondern besitzt nur einen Tooltip mit dem Wort „disabled“. Diese Umsetzung darf für deaktivierte Schalter nur gewählt werden, wenn in der verwendeten Technologie keine programmatische Auszeichnung als deaktiviert möglich ist.

In der folgenden Abbildung sind die selben Schalter aus der vorhergehenden Abbildung dargestellt, nun allerdings bei Verwendung der Windows-Kontrastanpassung (Kontrast Nr. 1).

• Der „Absenden“-Schalter ist visuell korrekt als bedienbar zu erkennen (weiße Textfarbe).

• Der „Prüfen“-Schalter ist visuell korrekt als deaktiviert zu erkennen (grüne Schriftfarbe).

• Der „Löschen“-Schalter wird als bedienbar dargestellt (weiße Textfarbe), obwohl er deaktiviert ist. Die Ursache für die Fehldarstellung ist, dass er nicht programmatisch als deaktiviert ausgezeichnet wurde, sondern nur farblich als deaktiviert. Die Farbinformation geht jedoch bei Nutzung der Windows-Kontrastanpassung verloren, so dass hier eine andere visuelle Darstellung verwendet werden müsste, um den Status „deaktiviert“ zu erkennen (z. B. eine Durchstreichung).

In der folgenden Abbildung wird die akustische Screenreader-Ausgabe der drei Schalter aus der vorhergehenden Abbildung dargestellt (am Beispiel der Elementübersicht von JAWS).

• Der „Absenden“-Schalter wird korrekt als bedienbar ausgegeben (Rolle „Schalter“).

• Der „Prüfen“-Schalter wird korrekt als deaktiviert ausgegeben (Status „nicht verfügbar“).

• Der „Löschen“-Schalter wird inkorrekt als bedienbar ausgegeben (Rolle „Schalter“), weil der Status „deaktiviert“ nur per Tooltip übermittelt wird und der Tooltip-Inhalt vom Screenreader nur bei bestimmten Navigationsmethoden ausgegeben wird.

In den drei folgenden Abbildungen wird die Ausgabe der drei Schalter aus den vorhergehenden Abbildungen auf der Braillezeile dargestellt (am Beispiel von JAWS).

• Der „Absenden“-Schalter wird korrekt als bedienbar ausgegeben (Rolle „Schalter“, die mit der Kurzform „sltr“ angezeigt wird).

• Der „Prüfen“-Schalter wird korrekt als deaktiviert ausgegeben (Status „nicht verfügbar“, die mit der Kurzform „xx“ angezeigt wird).

• Der „Löschen“-Schalter wird zwar als deaktiviert ausgegeben (Beschreibung „disabled“), allerdings erfolgt die Ausgabe nicht in Kurzform, nicht an der erwarteten Position und nicht übersetzt in die Sprache des Benutzenden.

Authentifizierung

Online betrachten

Synonyme: Anmelden, Abmelden, Login, Logout

Siehe auch: Kontextänderungen, Zeitbegrenzungen, Kennwort-Eingabefeld

Die Authentifizierung umfasst die Vorgänge des Anmeldens und Abmeldens bei einer Anwendung oder innerhalb einer Anwendung. Die Anmeldung kann erforderlich sein, um eine Anwendung oder bestimmte Teile der Anwendung nutzen zu können.

Hinweis: Anforderungen an Bedienelemente zur Authentifizierung (z. B. Eingabefelder, Kennwort-Eingabefelder und Schalter) werden bei dem jeweiligen Element beschrieben.

Darstellung und Bedienung

Programmierung/Schnittstellen

Animationen

Online betrachten

Synonyme: Blitzen, Blinken, Aktualisierungen, Flash

Siehe auch: Zeitbegrenzungen, Karussell, Video, Fortschrittsanzeige

Animationen sind:

• automatische visuelle Veränderungen oder

• unerwartete visuelle Veränderungen bei Bedienung der Anwendung.

Beispiele für automatische visuelle Veränderungen:

• Laufschrift,

• automatisch gestartetes Video,

• automatisch scrollende Inhalte,

• blinkende oder blitzende Inhalte,

• Inhalte, die automatisch nach einer bestimmten Zeit aktualisiert werden.

Beispiele für unerwartete visuelle Veränderungen bei Bedienung der Anwendung sind:

• beim Scrollen der Maske werden Inhalte zusätzlich animiert,

• beim Scrollen der Maske werden die Inhalte mit unterschiedlicher Geschwindigkeit gescrollt,

• manuell gestartetes Video enthält blitzenden Inhalte,

• blinkende Fehlermeldung, die nach Absenden eines Formulars eingeblendet wird,

• beim Einblenden von Inhalten werden diese nicht unmittelbar angezeigt, sondern animiert eingeblendet (z. B. skaliert, verschoben, gedreht oder in ihrer Transparenz verändert).

Darstellung

Programmierung/Schnittstellen

Navigationsreihenfolge

Online betrachten

Synonyme: Tab-Reihenfolge, Focus order

Siehe auch: Tastaturbedienung, Kontextänderungen, Zeitbegrenzungen

Die Navigationsreihenfolge bestimmt, in welcher Reihenfolge mit der Tastatur fokussierbare Elemente und Bereiche den Fokus erhalten. Typischerweise betrifft dies die folgenden Navigationsmethoden:

• Navigation zwischen den Elementen mit der Tabulatortaste,

• Navigation innerhalb der Elemente mit den Pfeiltasten,

• Navigation zwischen den Bereichen (z. B. mit der F6-Taste),

• Schnellnavigation (z. B. mit BILD AB, ENDE).

Bedienung

Praxistipp Navigationsreihenfolge in Web-Anwendungen

HTML

Die korrekte Navigationsreihenfolge sollte über die Reihenfolge der Elemente im Quellcode gesteuert werden. Das Attribut tabindex sollte nicht verwendet werden. Das Attribut autofocus sollte nur mit Bedacht verwendet werden, weil dadurch ggf. für sehbeeinträchtigte und blinde Menschen die Inhalte vor dem automatisch fokussierten Element schwer wahrnehmbar sind. Es gibt jedoch Anwendungsfälle, bei denen autofocus sinnvoll eingesetzt werden kann, z. B. auf einer Login-Seite, um das erste Eingabefeld zu fokussieren. Weitere Informationen: 6.6.3 The tabindex attribute - HTML Standard (whatwg.org), 6.6.7 The autofocus attribute - HTML Standard (whatwg.org)

ARIA

Die korrekte Navigationsreihenfolge sollte über die Reihenfolge der Elemente im Quellcode gesteuert werden. Das Attribut tabindex=0 muss für Bedienelemente verwendet werden, die andernfalls nicht den Tastaturfokus erhalten würden. Elemente, die per JavaScript fokussierbar sein sollen, sich jedoch nicht automatisch im TAB-Kreislauf befinden, werden mit tabindex=-1 ausgezeichnet. Dies gilt z. B. für Schalter in Werkzeugleisten, Einträge in Auswahllisten oder Radiobuttons innerhalb einer Radiobuttongruppe. In diesen Fällen wird lediglich jeweils ein Schalter, ein Listeneintrag bzw. ein Radiobutton mit tabindex=0 ausgezeichnet und alle anderen mit tabindex=-1. Weitere Informationen: Developing a Keyboard Interface | APG | WAI | W3C

Praxistipp Effiziente Navigation in Anwendungen

Enthält das aktuelle Fenster der Anwendung viele fokussierbare Elemente, können Nutzende, die auf Tastaturbenutzung angewiesen sind, nicht effizient durch das Fenster navigieren, da sie mit der TAB-Taste diese Elemente durchlaufen müssen. Um eine effiziente Navigation mit der Tastatur zu ermöglichen, wird empfohlen, eine oder mehrere der folgenden Methoden zu implementieren und in der Hilfe zu dokumentieren:

• Bereichsnavigation (z. B. mit F6),

• Sprunglinks am Anfang des Fensters bzw. vor Bereichen mit vielen Navigationsschritten,

• Tastaturkürzel für häufig benötigte Funktionen bzw. Bedienelemente,

• Bereiche mit vielen Navigationsschritten ein- und ausblendbar gestalten (z. B. Menü mit Untermenü, Registerkarten, Akkordeon),

• Auslagern von Inhalten mit vielen Navigationsschritten auf sekundäre Masken (z. B. in Dialogfenster, die separat aufgerufen werden können),

• Verwenden von gruppierenden Elementen, innerhalb derer mit den Pfeiltasten anstelle der TAB-Taste navigiert wird (z. B. Werkzeugleiste, Menü),

• bei Anwendungen, die den virtuellen Cursor nicht unterstützen: Modus bei dem nur Bedienelemente den Fokus erhalten.

Kontextänderungen

Online betrachten

Synonyme: Aktualisierungen, change of context

Siehe auch: Animationen, Zeitbegrenzungen, Navigationsreihenfolge, Modaler Dialog

Kontextänderungen sind:

• Wechsel zu einem anderen Programm,

• Änderung des Viewports (z. B. Wechsel zu einem anderen Anwendungsfenster),

• Änderungen des Tastaturfokus,

• Änderung des Inhalts, der die Bedeutung der Seite ändert.

Bei Bedienung erwartete und erforderliche Kontextänderungen sind z. B.:

• Aktivierung eines Links: Öffnen einer neuen Maske,

• Aktivierung eines Hilfe-Links: Öffnen der Hilfe, ggf. in einer anderen Anwendung (z. B. im Browser oder PDF-Reader),

• Aktivierung eines seiteninternen Links: Scrollen zur verlinkten Position und Änderung des Tastaturfokus,

• Aktivierung eines Absenden-Schalters: Öffnen einer neuen Maske,

• Aktivierung eines Löschen-Schalters: Entfernen des zu löschenden Elements, ggf. Änderung des Tastaturfokus (weil der Löschen-Schalter deaktiviert oder entfernt wurde),

• Aktivierung des Logout-Schalters: Logout aus der Anwendung,

• Aktivierung eines Menü-Schalters: Öffnen des Menüs und Fokussierung des ersten Menüeintrags,

• Aktivierung eines Schalters zum Öffnen eines modalen Dialogs: Öffnen des Dialogs und Fokussierung des ersten Elements im Dialog,

• Scrollen der Seite: Änderung des sichtbaren Bereichs,

• Navigation mit der Tastatur (z. B. mit der Tabulatortaste): Änderung des Tastaturfokus, ggf. Änderung des sichtbaren Bereichs (sofern sich das fokussierte Element nicht im sichtbaren Bereich befindet),

• Navigation durch eine Radiobuttongruppe, bei der sich hinter jedem Radiobutton zugehörige Formularfelder befinden, die nur in Abhängigkeit vom Radiobutton sinnvoll bedient werden können: Die Formularelemente beim ausgewählten Radiobutton werden aktiviert, die jeweils anderen Formularelemente werden deaktiviert.

• Navigation durch eine Gruppe von Karteireitern: Die zugehörige Registerkarte wird eingeblendet (alternativ erst nach Aktivierung des Karteireiters).

Beispiele für unerwartete Kontextänderungen, die vermieden oder angekündigt werden müssen:

• Aktivierung einer Checkbox innerhalb eines Formulars: Einblenden von weiteren Formularfeldern, die sich visuell und in der Navigationsreihenfolge vor der Checkbox befinden,

• Texteingabe in ein Eingabefeld: Löschen von bereits getätigten Eingaben in anderen Feldern, weil sich die Eingaben in diesem Feld und den anderen Feldern gegenseitig ausschließen,

• Texteingabe in ein Eingabefeld: Nach Erreichen der maximalen Zeichenzahl wird der Fokus ins folgende Eingabefeld gesetzt,

Beispiele für unerwartete Kontextänderung, die vermieden oder angekündigt werden sollen:

• Aktivierung eines Links: Öffnen einer neuen Maske in einer anderen Anwendung,

• Aktivierung eines Karteireiters: Die eingeblendete Registerkarte oder ein Element in dieser erhält den Fokus.

Beispiele für unerwartete Kontextänderungen, die vermieden werden müssen:

• Navigation durch eine Radiobuttongruppe: Öffnen einer neuen Maske,

• Navigation durch eine Tabelle: Öffnen eines modalen Dialogs,

• Vollständig ausgefülltes Formular: Absenden des Formulars,

• Fokussieren eines Absenden-Schalters: Absenden des Formulars,

• Fokussieren des Löschen-Schalters: Entfernen des zu löschenden Elements.

Bedienung

Programmierung/Schnittstellen

Zeitbegrenzungen

Online betrachten

Synonyme: Timeout, Time limit

Siehe auch: Animationen, Kontextänderungen, Authentifizierung, Karussell

Zeitbegrenzungen sind zeitliche Vorgaben, um Inhalte wahrzunehmen, Elemente zu bedienen oder Aufgaben abzuschließen. Zeitbegrenzungen können z. B. auftreten, wenn

• nach einer bestimmten Zeit der Inaktivität ein automatisches Logout erfolgt,

• ein für die Authentifizierung notwendiger PIN nur eine bestimmte Zeit gültig ist,

• Meldungen nach einer bestimmten Zeit ausgeblendet werden,

• Inhalte automatisch aktualisiert werden (z. B. in einem Karussell),

• Laufschrift angezeigt wird.

Darstellung und Bedienung

Elementübergreifende Anforderungen

Online betrachten

Inhaltsverzeichnis

• Elementstatus

• Status bzgl. der Bedienbarkeit

• Konsistenz

• Tastaturkürzel und Schnelltasten

• Zeigeinstrumentbedienung

• Tastaturbedienung

• Nutzungspräferenzen

• Farben und Kontraste

• Schrift

• Fokusindikator

• Textcursor

• Pflichtfeldkennzeichnung

Elementstatus

Online betrachten

Siehe auch: Status bzgl. der Bedienbarkeit, Fokusindikator

Viele Bedienelemente können einen Status besitzen, z. B.

• markiert oder nicht markiert,

• gewählt oder nicht gewählt,

• geöffnet oder geschlossen,

• gedrückt oder nicht gedrückt,

• korrekt oder fehlerhaft (siehe auch Fehlervermeidung und -korrektur),

• fokussiert oder nicht fokussiert (siehe auch Fokusindikator),

• bedienbar oder deaktiviert (siehe auch Status bzgl. der Bedienbarkeit).

Hinweis: Welcher Status bei welchem Bedienelement möglich ist, gibt die verwendete Programmiersprache vor.

Hinweis: Konkrete Empfehlungen zu spezifischen Statusänderungen bei einzelnen Elementen werden beim jeweiligen Element beschrieben.

Bedienung

Programmierung/Schnittstellen

Status bzgl. der Bedienbarkeit

Online betrachten

Synonyme: deaktiviert, inaktiv, nur lesend, nur Anzeige, Anzeigemodus, schreibgeschützt, disabled, read-only, display-only

Siehe auch: Elementstatus

Bedienelemente können bedienbar (Standard) oder deaktiviert sein. Formularfelder können darüber hinaus schreibgeschützt sein oder sich im Anzeigemodus befinden.

Hinweis: Welcher Status bei welchem Bedienelement möglich ist, gibt die verwendete Programmiersprache vor.

Darstellung

Bedienung

Programmierung/Schnittstellen

Konsistenz

Online betrachten

Synonyme: Erwartungskonformität, consistency

Konsistente Gestaltung und Bedienung hilft den Benutzenden, die Anwendung zu verstehen und effizient zu bedienen. Konsistenz soll angestrebt werden:

• innerhalb der Anwendung und

• mit anderen Anwendungen.

Darstellung

Programmierung/Schnittstellen

Tastaturkürzel und Schnelltasten

Online betrachten

Synonyme für Tastaturkürzel: Tastenkombination, Tastaturkombination, Tastaturbefehl, Tastaturäquivalente, Tastensequenz, Accesskey, Hotkey, Shortcut

Synonyme für Schnelltasten: Merkhilfe, Beschleunigungstaste, Abkürztasten, Mnemonic, Menu accelerator

Tastaturkürzel sind Tasten oder Tastenkombinationen, mit denen aus der Anwendung heraus effizient Funktionen aufgerufen oder Elemente fokussiert werden können. Die Tastaturkürzel können unabhängig von der aktuellen Fokusposition aufgerufen werden. Tastaturkürzel bestehen häufig aus einer Kombination eines druckbaren Zeichens (Buchstabe, Zahl, Sonderzeichen) mit einer oder mehrerer Modifikationstaste(n) (z. B. STRG oder ALT). Tastaturkürzel müssen eindeutig sein.

Schnelltasten sind Tasten, die nur innerhalb eines Elements zur effizienten Navigation genutzt werden können. Sie kommen meist in Menüs zum Einsatz. Als Schnelltaste wird in der Regel der erste Buchstabe des entsprechenden Elements (z. B. Menüeintrages) verwendet. Schnelltasten müssen nicht eindeutig sein: Besitzen z. B. innerhalb eines Menüs verschiedene Einträge die gleiche Schnelltaste, so können die Einträge durch Drücken der Taste nacheinander fokussiert werden. Schnelltasten werden ohne Modifikationstasten verwendet.

Darstellung

Bedienung

Programmierung/Schnittstellen

Praxistipp Tastaturkürzel und Schnelltasten

Plattformspezifische Tastaturkürzel

Die Tastaturkürzel der Plattform (z. B. des Betriebssystems Windows) sollten in der Anwendung nicht überschrieben oder deaktiviert werden. d. h. die Tastaturkürzel der Plattform sollten auch in der jeweiligen Anwendung funktionieren (z. B. STRG+X und STRG+V zum Ausschneiden und Einfügen von Text).

Tastaturkürzel der Assistenztechnologien

Die Assistenztechnologien verwenden viele Tastaturkürzel. Diese Tastaturkürzel sollten nicht in der Anwendung genutzt werden, weil andernfalls die Assistenztechnologie oder die Anwendung nicht mit diesen Tastaturkürzeln bedient werden kann.

So verwenden die Screenreader die EINF-Taste als Modifikationstaste für viele ihrer Tastaturkürzel. Die EINF-Taste sollte somit nicht als Modifikationstaste für die Tastaturkürzel der Anwendung genutzt werden.

Weil Assistenztechnologien darüber hinaus weitere Modifikationstasten und Tastaturkürzel ohne Modifikationstasten verwenden, sollte es möglich sein, die anwendungsspezifischen Tastaturkürzel neu zu definieren oder zu deaktivieren.

Konfiguration von Tastaturkürzeln

Unabhängig von den verwendeten Assistenztechnologien sind Tastaturkürzel wichtig für Menschen, die auf die Tastaturbedienung angewiesen sind. Deswegen sollte die Anwendung es ermöglichen, für alle Funktionen eigene Tastaturkürzel zu definieren, selbst wenn standardmäßig für diese keine Tastaturkürzel vorgesehen sind. Sofern eine solche Möglichkeit besteht, sollte in der Hilfe darauf hingewiesen werden.

Dokumentation der Tastaturkürzel und Schnelltasten

Die Tastaturkürzel sollten in der Anwendung explizit dokumentiert werden, d. h. in Textform beim jeweiligen Element (dauerhaft sichtbar oder in einem Tooltip), z. B. „Drucken (STRG+D)“.

Die Schnelltasten sollten in der Anwendung implizit dokumentiert werden, z. B. durch Unterstreichen des jeweiligen Buchstabens, z. B. „Drucken“.

Die Schnelltasten innerhalb von Auswahllisten und Ausklapplisten werden in der Regel nicht dokumentiert – dort fungiert der Anfangsbuchstabe des jeweiligen Listeneintrages als Schnelltaste.

In der Hilfe sollten die Tastaturkürzel wie folgt dokumentiert werden:

• Dokumentation der jeweiligen Tastaturkürzel innerhalb der themenspezifischen Kapitel (Beschreibung einer Maske, Funktion, Elements etc.) sowie

• Dokumentation aller Tastaturkürzel auf einer separaten Seite mit Hinweisen zur Tastaturbedienung.

Zeigeinstrumentbedienung

Online betrachten

Synonyme: Mausbedienung, Touchbedienung, Stiftbedienung, Pointing device operation, Pointer operation,

Siehe auch: Tastaturbedienung

Die Zeigeinstrumentbedienung umfasst alle Bedienmodalitäten mit einem Zeigeinstrument, z. B.

• Maus,

• Grafiktablett,

• Touchpad,

• Touchdisplay,

• Trackpoint,

• Trackball,

• Joystick,

• Stift.

Darstellung

Bedienung

Aus Sicht der Barrierefreiheit existiert keine zwingende Anforderung, dass eine Anwendung mit einem Zeigeinstrument bedienbar sein muss. Erforderlich ist lediglich die Bedienung mit der Tastatur. Sofern jedoch eine Anwendung mit Zeigeinstrument bedient werden kann, sind bestimmte Anforderungen einzuhalten.

Tastaturbedienung

Online betrachten

Synonyme: keyboard operation, keyboard interface

Siehe auch: Zeigeinstrumentbedienung, Fokusindikator, Navigationsreihenfolge

Alle Funktionen, die z. B. mit einem Zeigeinstrument, per Bewegungssteuerung oder per Spracheingabe aufrufbar sind, müssen auch mit der Tastatur aufrufbar sein, weil beeinträchtigte Benutzende ggf. kein Zeigeinstrument nutzen bzw. den Zeiger nicht sehen, die Bewegung nicht ausführen oder nicht sprechen können. Beeinträchtigte Benutzende können ggf. auch keine Tastatur nutzen, aber deren Assistenztechnologie simuliert die Tastatur und interagiert mit der Tastaturschnittstelle des Betriebssystems bzw. der Accessibility API.

Die Simulation eines Zeigeinstruments über die Tastatur (z. B. Tastaturmaus über den Ziffernblock) gilt in diesem Zusammenhang nicht als zulässige Bedienalternative zur Zeigeinstrumentbedienung.

Darstellung

Bedienung

Tastaturbedienung (allgemeine Anforderungen)

Hinweis: Die Bedienung einzelner Elemente wird beim jeweiligen Element beschrieben.

Hinweis: Die Tastaturbedienung muss in der Regel nicht separat implementiert werden, weil die Plattformsoftware oder das verwendete Framework diese bereits zur Verfügung stellt. Es soll jedoch darauf geachtet werden, die Tastaturkürzel nicht für eigene Funktionen zu überschreiben.

Programmierung/Schnittstellen

Praxistipp Tastaturbedienung in Web- und Desktop-Anwendungen

Benutzerdefinierte Elemente

Die Standardelemente der Auszeichnungs- bzw. Programmiersprache oder des verwendeten Frameworks sind in der Regel vollständig tastaturbedienbar. Diese sollen somit bevorzugt verwendet werden.

Werden benutzerdefinierte Elemente verwendet, so soll bezüglich der Tastaturbedienbarkeit insbesondere auf Folgendes geachtet werden:

• Erreichbarkeit mit der Tastatur (z. B. mittels tabindex),

• Bedienbarkeit mit der Tastatur (Eventhandler für die Tastatur bzw. geräteunabhängige Eventhandler),

• Bedienbarkeit ist erwartungskonform oder dokumentiert (erwartungskonform hinsichtlich der visuellen Darstellung und der Rolle, die an die Accessibility API übermittelt wird).

• Fokusindikator,

• Fokushandling (z. B. kein Fokusverlust bei Bedienung; Navigationsreihenfolge),

• ggf. definierte Tastaturkürzel sind konsistent mit denen der Plattformsoftware bzw. überschreiben die der Plattformsoftware nicht.

Wird ein benutzerdefiniertes Element implementiert, empfiehlt es sich häufig, ein verwandtes Standardelement zu verwenden und entsprechend anzupassen, weil dann die Grundfunktionalität des Standardelements genutzt werden kann.

Drag & Drop

Das Ziehen und Ablegen von Elementen (Drag & Drop) kann nur mit einem Zeigegerät ausgeführt werden. Es wird empfohlen, die Bedienalternative mit der Tastatur so zu gestalten, dass sie effizient und erwartungskonform genutzt werden kann. Mögliche Varianten sind u. a.

• Kontextmenü (z. B. zum Verschieben von Elementen in andere Bereiche),

• mehrere Schalter, gruppiert in einer Werkzeugleiste (z. B. zur Änderung der Reihenfolge von Elementen innerhalb eines Bereichs),

• ein Schalter (z. B. zum Datei-Upload),

• eigene Tastaturkürzel (z. B. Anpassung der Größe von Elementen),

• Tastaturkürzel der Plattform (z. B. Ausschneiden und Einfügen von Elementen mit STRG+X und STRG+V),

• Pfeiltastenbedienung (z. B. bei einem Schieberegler),

• Start und Ende mit der EINGABE-Taste, Bewegung mit den Pfeiltasten (z. B. Zeichnen einer Freihandmaske).

Häufig ist eine Kombination der Varianten sinnvoll (z. B. Schalter und Tastaturkürzel).

Da die Bedienalternative mit der Tastatur in der Regel nicht ersichtlich ist, sollte sie in der Anwendung und Hilfe beschrieben werden.

Nicht dauerhaft sichtbare Bedienelemente

Bedienelemente, die bei der Bedienung der Anwendung ein- und ausgeblendet werden, z. B.

• weil sie sich in Tooltips befinden oder

• weil sie nur angezeigt werden, wenn sich der Tastaturfokus an einer bestimmten Position befindet,

sind mit der Tastatur in der Regel nicht zu bedienen.

Es wird empfohlen, Bedienelemente dauerhaft anzuzeigen und z. B. Bedienelemente in Tooltips zu vermeiden.

Alternativ muss eine Bedienalternative mit der Tastatur implementiert und in der Hilfe und Anwendung beschrieben werden. Darüber hinaus muss die Anwendung so gestaltet werden, dass mit Assistenztechnologie wahrnehmbar ist, wann nicht dauerhaft sichtbare Elemente eingeblendet werden. So müssen z. B. blinde Nutzende mit dem Screenreader erkennen können, dass ein Tooltip Bedienelemente enthält, damit sie die dokumentierte Bedienalternative mit der Tastatur nutzen können.

Nutzungspräferenzen

Online betrachten

Synonyme: Benutzereinstellungen, Individualisierung, individuelle Anpassung, Anpassung an Präferenzen, User preferences

Siehe auch: Farben und Kontraste, Schrift, Fokusindikator

Darstellung

Praxistipp Kontrastanpassung für Desktop-Anwendungen

Unter Windows können Benutzende die Darstellung der Farben an ihre Bedürfnisse anpassen (Einstellungen > Erleichterte Bedienung > Hoher Kontrast). Im Gegensatz zu anderen Betriebssystemen, die lediglich bestimmte Farbänderungen erlauben (wie Einfärben, Abdunkeln oder Invertieren der Farben), kann unter Windows die Vorder- und Hintergrundfarbe frei gewählt werden. Darüber hinaus können für verschiedene Elementtypen bzw. deren Status eigene Farben definiert werden.

Mit der Windows-Kontrastanpassung können die Farben für folgende Elemente und Zustände angepasst werden:

• Text (SystemColorWindowTextColor)

• Hintergrund (SystemColorWindowColor)

• Links (SystemColorHotlightColor)

• Markierter Text, gewähltes Element (SystemColorHighlightTextColor)

• Hintergrund von markiertem Text oder gewählten Elementen (SystemColorHighlightColor)

• Text von Bedienelementen (außer Links) (SystemColorButtonTextColor)

• Hintergrund von Bedienelementen (außer Links) (SystemColorButtonFaceColor)

• Deaktivierte Elemente (SystemColorGrayTextColor)

Damit die Windows-Kontrastanpassung in einer Anwendung korrekt funktioniert, muss Folgendes beachtet werden:

• Die Definition von Vorder- und Hintergrundfarben muss so erfolgen, dass sie durch die Windows-Kontrastanpassung überschrieben werden kann. Davon ausgenommen sind Grafiken und Videos.

• Inhalte, deren Vordergrundfarbe angepasst wird, darf keinen Hintergrund besitzen, dessen Farbe nicht angepasst wird. Dies gilt z. B. für Text, dessen Hintergrund eine Grafik ist, die nicht angepasst wird. Dies gilt nicht, wenn die Schrift eine Kontur in der Hintergrundfarbe besitzt, weil dann über die Kontur die Sichtbarkeit gewährleistet wird.

• Grafiken mit transparentem Hintergrund müssen vermieden werden. Dies gilt nicht, wenn entweder die Vordergrundfarbe der Grafik angepasst werden kann (z. B. durch Verwendung von SystemColorWindowTextColor) oder die grafischen Inhalte eine Kontur besitzen.

• Für die Elementtypen Text, Links und Formularelemente sowie die Zustände deaktiviert, markiert und gewählt müssen die entsprechenden Informationen an die Accessibility API bezüglich Rolle und Status übermittelt werden. Alternativ müssen die entsprechenden Farben für die Elemente und Zustände verwendet werden (z. B. SystemColorGrayTextColor für deaktivierte Elemente).

• Schriftgrafiken müssen vermieden werden. Alternativ muss sich die Vorder- und Hintergrundfarbe der Schriftgrafiken gemäß den Windows-Einstellungen anpassen lassen.

• Ausschließlich farbkodierte Inhalte müssen vermieden werden, unabhängig vom Kontrast zwischen den Farben.

• Seitenbereiche, Tooltips, Pop-ups sowie Bedienelemente, die durch unterschiedliche Hintergrundfarben gekennzeichnet sind, sollen einen Rahmen erhalten, damit sie sich auch bei der Windows-Kontrastanpassung vom Hintergrund abheben.

• Unterstützt die Anwendung nicht die Windows-Kontrastanpassung, so muss die Anwendung eine eigene Möglichkeit zur Anpassung der Farben mit analogem Funktionsumfang anbieten. Diese Option muss in der Anwendung und Hilfe beschrieben werden.

• Wenn die Windows-Kontrastanpassung durch die Anwendung nur bei einer bestimmten Konfiguration unterstützt wird (z. B. Auswahl eines bestimmten Farbschemas), so muss dies in der Anwendung und Hilfe beschrieben werden.

Beispiel 1: In den zwei folgenden Abbildungen sind in zwei Zeilen je zwei Textinhalte, zwei Schalter und zwei Links dargestellt – einmal in der Standarddarstellung (linke Abbildung) und einmal bei Verwendung der Windows-Kontrastanpassung (Kontrast Nr. 1).

• In der linken Abbildung sind Text, Schalter und Link in beiden Zeilen aufgrund der verwendeten Farben zu erkennen:

  • Text: schwarze Schrift auf weißem Hintergrund,

  • Schalter: schwarze Schrift auf grauem Hintergrund,

  • Link: blaue Schrift auf weißem Hintergrund.

• In der rechten Abbildung sind Text, Schalter und Link nur in der oberen Zeile korrekt zu erkennen, weil sie programmatisch als Text, Schalter und Link ausgezeichnet wurden:

  • Text: gelbe Schrift auf schwarzem Hintergrund,

  • Schalter: weiße Schrift auf schwarzem Hintergrund,

  • Link: blaue Schrift auf schwarzem Hintergrund.

• In der rechten Abbildung sind Text, Schalter und Link in der unteren Zeile nicht voneinander zu unterscheiden, da sie alle in der Textfarbe angezeigt werden (gelbe Schrift auf schwarzem Hintergrund). Ursache für die Fehldarstellung ist, dass Schalter und Link nicht programmatisch als solche ausgezeichnet wurden.

Beispiel 2: In den zwei folgenden Abbildungen sind ein bedienbarer Schalter („Absenden“) und zwei deaktivierte Schalter („Prüfen“ und „Löschen“) dargestellt – einmal in der Standarddarstellung (linke Abbildung) und einmal bei Verwendung der Windows-Kontrastanpassung (Kontrast Nr. 1).

• In der Standarddarstellung sind die beiden deaktivierten Schalter aufgrund der ausgegrauten Farben als deaktiviert zu erkennen.

• Bei der Windows-Kontrastanpassung ist lediglich der „Prüfen“-Schalter korrekt als deaktiviert zu erkennen (grüne Schrift auf schwarzem Hintergrund).

• Der „Löschen“-Schalter ist bei der Windows-Kontrastanpassung nicht als deaktiviert zu erkennen, sondern wird als bedienbar angezeigt (weiße Schrift auf schwarzem Hintergrund). Die Ursache für die Fehldarstellung ist, dass er nicht programmatisch als deaktiviert ausgezeichnet wurde.

Beispiel 3: In den zwei folgenden Abbildungen sind vier Schalter dargestellt, die mit einem schwarzen Icon beschriftet sind – einmal in der Standarddarstellung (linke Abbildung) und einmal bei Verwendung der Windows-Kontrastanpassung (Kontrast Nr. 1).

• In der Standarddarstellung sehen alle vier Schalter gleich aus (schwarzes Icon auf weißem Hintergrund).

• Bei der Windows-Kontrastanpassung sehen die vier Schalter aufgrund der unterschiedlichen Technologie zur Darstellung des Icons unterschiedlich aus:

  • Das erste Icon wird korrekt angezeigt, weil ein Font-Icon verwendet wurde, bei dem Vorder- und Hintergrundfarbe angepasst werden (weißes Icon auf schwarzem Hintergrund). Diese Variante ist zu bevorzugen.

  • Das zweite Icon wird nicht angepasst (schwarzes Icon auf weißem Hintergrund), weil es sich um eine Grafik ohne transparenten Hintergrund handelt. Diese Variante ist akzeptabel.

  • Das dritte Icon ist nicht so gut zu erkennen, weil es sich um eine Grafik mit transparentem Hintergrund handelt (schwarzes Icon auf schwarzem Hintergrund). Das Icon ist jedoch aufgrund seiner weißen Kontur wahrnehmbar. Diese Variante ist akzeptabel.

  • Das vierte Icon ist nicht zu erkennen, weil es sich um eine Grafik mit transparentem Hintergrund handelt (schwarzes Icon auf schwarzem Hintergrund). Diese Variante sollte nicht verwendet werden.

Farben und Kontraste

Online betrachten

Synonyme: Farbkodierung, colour, contrast

Siehe auch: Text, Schrift, Grafiken, Kontrastanpassung

Farben sind ein wichtiges visuelles Gestaltungsmittel. Sehbeeinträchtigte Menschen können jedoch Farben oder Farbunterschiede (Kontraste) möglicherweise nicht wahrnehmen.

Darstellung

Programmierung/Schnittstellen

Praxistipp Farbkodierung

Um EN 301 549: 9.1.4.1 bzw. 11.1.4.1 zu erfüllen, muss zwischen zwei verschiedenen Formen von Farbkodierung unterschieden werden:

• der Farbunterschied vermittelt eine Information,

• die Farbe selbst vermittelt eine Information.

Farbunterschied vermittelt eine Information

Beispiele:

• Der aktive Menüpunkt besitzt eine graue Hintergrundfarbe, alle anderen Menüpunkte besitzen eine weiße Hintergrundfarbe.

• Die Textfarbe ist Schwarz und die Linkfarbe Blau.

Sofern die Farben an sich keine Bedeutung besitzen, sondern nur der Unterschied zwischen den Farben, ist ein Kontrastverhältnis von mindestens 3:1 zwischen den Farben ausreichend.

Allerdings ist es empfehlenswert, ein weiteres visuelles Mittel (z. B. Icon, Schriftschnitt, Größe, Lage, Form, Rahmen, Unterstreichung, Text) zu verwenden, um die per Farbunterschied vermittelte Information abzubilden, z. B.

• Der aktive Menüpunkt besitzt einen fetten Schriftschnitt, alle anderen Menüpunkte einen normalen Schriftschnitt.

• Der Text besitzt keine Unterstreichungen, alle Links sind unterstrichen.

Hinweis: EN 301 549: 9.1.4.1 und 11.1.4.1 formuliert Anforderungen für sehbeeinträchtigte Menschen, welche die Anwendung ohne Assistenztechnologie verwenden. Zusätzliche Anforderungen gelten gemäß EN 301 549: 9.1.3.1 und 11.1.3.1.1 für Nutzende von Assistenztechnologie hinsichtlich von Farbkodierungen, z. B.

• Damit blinde Menschen die per Farbunterschied vermittelten Informationen wahrnehmen können, müssen diese Informationen programmatisch oder in Textform an die Accessibility API übermittelt werden.

• Damit Nutzende der Windows-Kontrastanpassung die per Farbunterschied vermittelten Informationen wahrnehmen können, müssen diese Informationen programmatisch (siehe Praxistipp Kontrastanpassung), über ein weiteres visuelles Mittel (siehe oben) oder in Textform vermittelt werden.

Farbe vermittelt eine Information

Beispiele:

• Fehlerhaft ausgefüllte Formularfelder besitzen einen roten Rahmen, korrekt ausgefüllte Formularfelder besitzen einen grünen Rahmen.

• Für Meldungen werden unterschiedliche Hintergrundfarben verwendet: Rot für Warnmeldungen, Grün für Erfolgsmeldungen und Gelb für Hinweise.

• In einer Finanzübersicht werden Verluste mit roter Textfarbe und Gewinne mit schwarzer Textfarbe dargestellt.

In diesen Fällen vermittelt die Farbe an sich eine Information und nicht nur der Unterschied zwischen den Farben. Deswegen ist hier ein Kontrastverhältnis von mindestens 3:1 zwischen den Farben nicht ausreichend. In jedem Fall muss ein weiteres visuelles Mittel verwendet werden, um die Information zu vermitteln, z. B.

• Die fehlerhaft ausgefüllten Formularfelder besitzen ein Fehler-Icon (z. B. ein Ausrufezeichen in einem roten Kreis) und die korrekt ausgefüllten Formularfelder besitzen ein Erfolgs-Icons (z. B. ein Häkchen in einem grünen Kreis). Darüber hinaus wird eine aussagekräftige Fehlermeldung in Textform angezeigt, um EN 301 549, 9.3.3.1 bzw. 11.3.3.1 zu erfüllen.

• Die Meldungen besitzen jeweils eine Überschrift, die den Status vermittelt (z. B. „Warnung“, „Erfolg“ und „Hinweis“).

• In der Finanzübersicht werden die Verluste mit einem Minuszeichen vor der Zahl gekennzeichnet.

Hinweis: EN 301 549: 11.1.4.1 formuliert Anforderungen für sehbeeinträchtigte Menschen, welche die Anwendung ohne Assistenztechnologie verwenden. Zusätzliche Anforderungen gelten gemäß EN 301 549: 11.1.3.1.1 für Nutzende von Assistenztechnologie hinsichtlich von Farbkodierungen (siehe oben).

Praxistipp Kantenglättung

Die WCAG geht bei den Kontrastanforderungen davon aus, dass die Kantenglättung deaktiviert wurde. Dies ist jedoch nicht realistisch, da die meisten Benutzenden mit aktiver Kantenglättung arbeiten. Durch die Kantenglättung können bei dünnen Strichstärken die tatsächlichen Kontraste deutlich unter den aus den Farbwerten errechneten Kontrasten liegen. Deswegen sollen entweder die Strichstärke oder die Farben so angepasst werden, dass das Kontrastverhältnis (von mindestens 4,5:1 für Text und 3:1 für grafische Inhalte) auch bei aktivierter Kantenglättung eingehalten werden kann. Da die Kantenglättung unterschiedlich konfiguriert sein kann, ist es nicht möglich, exakte Werte anzugeben. Folgende Richtwerte werden jedoch in den meisten Fällen dazu beitragen, dass die Kontrastverhältnisse eingehalten werden können:

• Mindeststrichstärke von 2 px oder

• doppeltes Kontrastverhältnis bei geringeren Strichstärken (z. B. mindestens 9:1 statt 4,5:1).

Dabei soll beachtet werden, dass eine Strichstärke von 2 px bei Buchstaben erst ab einer bestimmten Schriftgröße erreicht wird, bei Arial z. B. ab 25 px und bei Times New Roman ab 75 px.

Beispiel: In den folgenden beiden Abbildungen sind drei Mal jeweils der Buchstabe „x“ und ein Schrägstrich („/“) dargestellt, jeweils in der Schriftart „Times New Roman“ und mit der Schriftgröße 16px. Der Kontrast der im CSS definierten grauen bzw. schwarzen Textfarbe zum weißen Hintergrund beträgt rein rechnerisch:

• Links: 4,5:1,

• Mitte: 7:1,

• Rechts: 21:1.

Damit werden für den gesamten Text die erforderlichen Mindestkontraste eingehalten. In der stark vergrößerten Darstellung ist jedoch zu erkennen, dass die errechneten Kontraste beim „x“ aufgrund der Kantenglättung nur teilweise beim dickeren Abstrich (diagonaler Strich von links oben nach rechts unten) und den horizontalen Serifen erreicht werden. Für den dünneren Aufstrich (diagonaler Strich von links unten nach rechts oben) liegt der Kontrast deutlich darunter, z. B. im unteren Bereich maximal bei:

• Links: 2,9:1,

• Mitte: 2,9:1,

• Rechts: 5,2:1.

Für den Schrägstrich werden die errechneten Kontraste an keiner Stelle erreicht.

• Links: maximal 2,4:1, Mittelwert ca. 2,0:1,

• Mitte: maximal 2,5:1, Mittelwert ca. 2,1:1,

• Rechts: maximal 3,5:1, Mittelwert ca. 2,3:1.

Schrift

Online betrachten

Synonyme: Buchstaben, Zeichen, Zahlen, font

Siehe auch: Text, Kontrast, Beschriftung, Überschrift

Schrift dient der Darstellung von Textinformationen.

Darstellung

Programmierung/Schnittstellen

Praxistipp Sonderzeichen

Bei der Verwendung von Sonderzeichen sind hinsichtlich der Übermittlung der Zeichen an die Accessibility API verschiedene Anwendungsfälle zu unterscheiden:

Dekorative Sonderzeichen

Rein dekorative Sonderzeichen sind so auszeichnen, dass sie nicht an die Accessibility API übermittelt werden. Für sie gelten die gleichen Regeln wie für Layoutgrafiken.

Beispiele:

• Schalter mit der Beschriftung „Weiter »“: Die beiden Größerzeichen sind rein dekorativ. Der Schalter sollte den Accessible Name „Weiter“ besitzen.

• Formularfeldbeschriftung „- - Ort - -“: Die Bindestriche sind rein dekorativ. Das Formularfeld sollte den Accessible Name „Ort“ besitzen.

Zweckentfremdete inhaltstragende Sonderzeichen

Sonderzeichen, die nicht ihrer Bedeutung entsprechend verwendet werden, sind mit einem aussagekräftigen Alternativtext zu versehen. Für sie gelten die gleichen Regeln wie für Grafiken.

Beispiele:

• Schalter mit der Beschriftung »: Die beiden Größerzeichen vermitteln visuell die Information „Weiter“. Der Schalter sollte den Accessible Name „Weiter“ besitzen.

• Schalter mit der Beschriftung x: Das Multiplikationszeichen vermittelt visuell die Information „Schließen“. Der Schalter sollte den Accessible Name „Schließen“ besitzen (ggf. mit einem Hinweis, was geschlossen wird, z. B. „Fenster schließen“).

Hinweis: Der Stern („*“) gilt bei Verwendung als Pflichtfeldkennzeichnung nicht als zweckentfremdet.

Zweckbezogene inhaltstragende Sonderzeichen

Sonderzeichen, die entsprechend ihrer Bedeutung verwendet werden, können verwendet werden, sofern das Zeichen durch Assistenztechnologie korrekt ausgegeben wird. Andernfalls soll es mit einem aussagekräftigen Alternativtext versehen werden.

Beispiele:

• Mathematische Formel „3+5 > 5-3“: Die beiden Rechenzeichen sowie das Größerzeichen werden von der Assistenztechnologie korrekt ausgegeben und können somit verwendet werden.

• Text mit den Ordinalzeichen „ª“ und „º“: Die beiden Zeichen werden von der Assistenztechnologie nicht bzw. nicht korrekt ausgegeben und benötigen somit einen Alternativtext.

• Das Wort „Gast“ mit einer Ligatur von s und t. Die meisten Screenreader kennen die Ligatur nicht und geben statt „Gast“ nur „Ga“ und ein Leerzeichen aus.

Die zweckbezogenen Sonderzeichen sollten sparsam verwendet werden. Es wird empfohlen, ein Zeichen zu verwenden, welches von der Assistenztechnologie knapp ausgegeben wird.

Beispiele:

• Ein Zitat kann mit verschiedenen Anführungszeichen versehen werden. Das Zeichen “ wird von der Assistenztechnologie z. B. als „Typographisches Anführungszeichen oben“ oder als „Typographisches Anführungszeichen rechts“ ausgegeben. Das Zeichen " wird hingegen als „Anführungsstriche“ oder „Anführungszeichen“ ausgegeben und ist somit zu bevorzugen.

• Der Satz „Das Zeichen »❖« gefällt mir besser als „➢““ (siehe folgende Abbildung) wird vom Screenreader z. B. als „Das Zeichen doppelt gewinkelte Klammer zu schwarze Raute mit weißem X doppelt gewinkelte Klammer auf gefällt mir besser als typografisches Anführungszeichen unten 3D schmaler rechtsweisender Pfeilkopf Anführungsstriche“ ausgegeben.

Praxistipp Schriftart und Textformatierung

Damit Texte gut lesbar sind, soll eine gut lesbare Schriftart und Textformatierung gewählt werden. Dabei soll Folgendes beachtet werden:

• Am besten sind Schriften aus der Familie der humanistischen Serifenlosen zu lesen.

• Ligaturen sollen vermieden werden.

• Die Mindestschriftgröße für Textblöcke soll 22px betragen.

• Die Mindestschriftgröße für nebensächlichen Text (z. B. Fußnoten) soll 17px betragen.

• Schmale und breite Schriftweiten sollen vermieden werden.

• Kleine und große Zeichenabstände sollen vermieden werden.

• Dünne und dicke Schriftschnitte sollen vermieden werden.

• Der Zeilenabstand soll mindestens 120 % der Schriftgröße betragen.

• Die Groß- und Kleinschreibung soll gemäß der Rechtschreibregeln verwendet werden. Die ausschließliche Verwendung von Groß- oder Kleinschreibung soll vermieden werden.

• Die Groß- und Kleinschreibung soll gemäß der Rechtschreibregeln verwendet werden. Die ausschließliche Verwendung von Groß- oder Kleinschreibung soll vermieden werden.

• Kapitälchen sollen vermieden werden.

• Hervorhebungen sollen sparsam verwendet werden. Für Hervorhebungen soll ein fetter Schriftschnitt verwendet werden.

• Kursive Schriftschnitte oder Unterstreichungen sollen vermieden werden. Hinweis: Links sollen unterstrichen werden.

• Die Textausrichtung soll linksbündig sein. Blocksatz soll vermieden werden.

Weitere Informationen finden Sie unter: https://www.leserlich.info (Externer Link).

Fokusindikator

Online betrachten

Synonyme: Fokus, Fokusrahmen, Focus Indicator, Focus Appearance

Siehe auch: Tastaturbedienung, Textcursor

Der Fokusindikator zeigt an, welches Element derzeit den Tastaturfokus besitzt (siehe DIN EN ISO 9241-161: 8.37).

Der Fokusindikator wird üblicherweise durch einen Rahmen um das fokussierte Element angezeigt. Andere Fokusindikatoren wären ebenfalls zulässig, sofern sie die Anforderungen erfüllen, z. B.

• Invertieren von Vorder- und Hintergrundfarbe,

• Veränderte Hintergrundfarbe,

• Änderung der Größe des Elements,

• Einblenden eines grafischen Elements, wie z. B. eines seitlichen Balkens.

In bestimmten Fällen können mehrere Fokusindikatoren angezeigt werden:

• Beispiel 1: Wenn eine Auswahlliste den Fokus erhält, kann ein Fokusindikator um die gesamte Liste angezeigt werden. Darüber hinaus muss ein Fokusindikator beim aktuellen Listeneintrag angezeigt werden.

• Beispiel 2: Bei einem kombinierten Eingabefeld kann sich der Fokus sowohl im Eingabefeld als auch in der Auswahlliste befinden.

• Beispiel 3: Wenn ein interaktives Element innerhalb eines Seitenbereichs den Fokus erhält, dann kann auch der Seitenbereich als fokussiert gekennzeichnet werden.

• Beispiel 4: Die Titelzeilen aller Anwendungsfenster, die nicht den Fokus besitzen, werden ausgegraut dargestellt.

In einigen Fällen kann der Fokusindikator mit der Selektionsmarke (d. h. der Kennzeichnung der ausgewählten Option, siehe Elementstatus) identisch sein, wenn das fokussierte Element mit dem ausgewählten Element identisch ist:

• Beispiel 1: Eine Auswahlliste ohne Mehrfachauswahl besitzt einen Fokusindikator beim fokussierten Listeneintrag. Dieser Indikator kann gleichzeitig als Selektionsmarke dienen, weil der fokussierte Listeneintrag mit dem gewählten Listeneintrag identisch ist. Wenn diese Auswahlliste nicht zusätzlich einen Fokusindikator für die gesamte Liste besitzt, ist jedoch darauf zu achten, dass die Selektionsmarke im fokussierten Status der Auswahlliste sich deutlich von der Selektionsmarke im nicht-fokussierten Status der Auswahlliste unterscheidet (z. B. Kontrastverhältnis mindestens 3:1), um erkennen zu können, ob die Auswahlliste fokussiert ist.

• Beispiel 2: Eine Auswahlliste ohne Mehrfachauswahl besitzt einen Fokusindikator beim fokussierten Listeneintrag, z. B. einen Rahmen. Dieser Fokusindikator wird nicht gleichzeitig als Selektionsmarke verwendet. Als Selektionsmarke wird z. B. eine abweichende Hintergrundfarbe genutzt. Bei der Navigation durch die Listeneinträge wird sowohl der Fokusindikator als auch die Selektionsmarke verschoben. Ein zusätzlicher Fokusindikator für die gesamte Liste bzw. eine Unterscheidung der Selektionsmarke im fokussierten und nicht fokussierten Zustand ist in diesem Fall nicht notwendig, da Fokussierung und Selektion unabhängig voneinander zu erkennen sind.

• Beispiel 3: Eine Mehrfach-Auswahlliste besitzt einen Fokusindikator um die gesamte Liste. Da jedoch bei der Mehrfach-Auswahlliste der fokussierte Listeneintrag nicht mit den gewählten Listeneinträgen übereinstimmt, muss Fokusindikator und Selektionsmarke bei den Listeneinträgen separat gekennzeichnet werden (z. B. wie in Beispiel 2 mit einem Rahmen und einer abweichenden Hintergrundfarbe).

Darstellung

Bedienung

Tastaturbedienung Fokusindikator

Die Änderung des Fokusindikators zwischen den Elementen wird in den Abschnitten Tastaturbedienung und Navigationsreihenfolge beschrieben. Standardmäßig erfolgt die Navigation mit der TAB-Taste.

Die Änderung des Fokusindikators innerhalb eines Elements wird bei den jeweiligen Elementen beschrieben. Häufig erfolgt die Navigation innerhalb von Elementen mit den Pfeiltasten.

Zeigeinstrumentbedienung Fokusindikator

Programmierung/Schnittstellen

Praxistipp Fokusindikator

Der Fokusindikator muss ausreichende Kontraste aufweisen und sollte gleichzeitig konsistent gestaltet werden. Bei Anwendungen mit unterschiedlichen Hintergrundfarben ist dies zu erreichen, indem ein zweifarbiger Rahmen (z. B. schwarz und weiß) verwendet wird, der vor jedem Hintergrund ausreichende Kontraste besitzt. Ein zweifarbiger Fokusindikator empfiehlt sich auch bei Bedienelementen auf Farbverläufen oder Grafiken.

Beispiel: Zwei Schalter auf einem Farbverlauf von weiß nach schwarz. Der obere Schalter ist aktuell fokussiert. Der Fokusindikator besteht aus einem schwarzen Rahmen (innen) und einen weißen Rahmen (außen) und ist somit unabhängig von der Hintergrundfarbe immer gut zu erkennen. Es handelt sich dabei um den Standard-Fokusrahmen von Google Chrome.

Textcursor

Online betrachten

Synonyme: Cursor

Siehe auch: Tastaturbedienung, Fokusindikator

Der Textcursor zeigt die Position in einem Eingabefeld an (siehe DIN EN ISO 9241-161: 8.8). Der Textcursor wird üblicherweise durch einen senkrechten Strich an der Stelle, an der Text eingegeben, bearbeitet oder gelöscht wird, angezeigt.

Darstellung

Bedienung

Tastaturbedienung Textcursor

Die Änderung des Fokusindikators zwischen den Elementen wird bei den Elementen Eingabefeld und Mehrzeiliges Eingabefeld beschrieben. Standardmäßig erfolgt die Navigation innerhalb von Eingabefeldern mit den Pfeiltasten.

Zeigeinstrumentbedienung Textcursor

Programmierung/Schnittstellen

Pflichtfeldkennzeichnung

Online betrachten

Synonyme: Erforderliche Formularfelder, Pflichteingabe, Required

Siehe auch: Fehlermeldung, Beschriftung, Elementstatus

Eine Pflichtfeldkennzeichnung ist ein visueller Indikator für Formularfelder, die ausgefüllt werden müssen. So kann z. B. mit einem Stern (*) beim Formularfeld darauf hingewiesen werden, dass ein Feld ausgefüllt werden muss.

Darstellung

Programmierung/Schnittstellen

Praxistipp Pflichtfeldkennzeichnung

Pflichtfelder können mit einem entsprechenden textlichen Zusatz, wie z. B. „Pflichtfeld“ oder „erforderlich“ gekennzeichnet werden. Wenn die Mehrzahl der Felder Pflichtfelder sind, können alternativ auch die Felder, die nicht ausgefüllt werden müssen, gekennzeichnet werden, z. B. mit „optional“.

Die Pflichtfelder können auch mit einem Symbol gekennzeichnet werden. Etabliert hat sich dafür der Stern („*“), bei dem zumindest bei Fachanwendungen davon ausgegangen werden kann, dass er allen Nutzenden bekannt ist. Wird ein anderes Zeichen verwendet, so sollte dessen Bedeutung am Formularbeginn erläutert werden.

Praxistipp programmatische Kennzeichnung von Pflichtfeldern in Web-Anwendungen

Screenreader-Ausgabe

• JAWS: erforderlich ungültiger Eintrag | erforderlich [nach der Rolle und vor dem Wert]

• NVDA: erforderlich ungültiger Eintrag | erforderlich [nach der Rolle und vor dem Wert]

• Windows Sprachausgabe: erforderlich ungültig | erforderlich [nach dem Wert]

Hinweis: Ein nicht-ausgefülltes Pflichtfeld, welches mit required ausgezeichnet wurde, befindet sich aufgrund der HTML-Spezifikation im Status fehlerhaft und wird deshalb von den Screenreadern als „ungültiger Eintrag“ bzw. „ungültig“ ausgegeben. Das Problem tritt bei Verwendung von aria-required nicht auf.

HTML

Pflichtfelder können mit dem required-Attribut ausgezeichnet werden.

• Formularfelder, die mit required ausgezeichnet wurden, werden automatisch durch den Browser validiert und befinden sich im fehlerhaften Zustand, wenn sie nicht ausgefüllt wurden.

• Formularfelder, die mit required ausgezeichnet wurden, sind visuell nicht automatisch als Pflichtfelder erkennbar. Sie besitzen allerdings einen Tooltip (z. B. „Bitte füllen Sie dieses Feld aus“), der jedoch für Tastaturnutzende und mit dem Screenreader nicht wahrnehmbar ist, da er nur beim Mouseover eingeblendet wird.

• Ein Formular mit nicht ausgefüllten Pflichtfeldern kann standardmäßig nicht abgesendet werden. Stattdessen wird der Fokus in das erste fehlerhafte Feld gesetzt und der Tooltip als Fehlermeldung eingeblendet und vom Screenreader als Warnmeldung ausgegeben (analog zu role=alert). Diese Fehlermeldungen sind aus folgenden Gründen nicht barrierefrei:

  • Beim Verlassen des Feldes wird die Fehlermeldung automatisch ausgeblendet und kann nicht erneut eingeblendet werden.

  • Bei vielen Browsern werden die Fehlermeldungen nach wenigen Sekunden automatisch ausgeblendet, selbst wenn der Fokus im Feld verbleibt (z. B. bei Chrome und Edge).

  • Die Fehlermeldung wird nur beim ersten fehlerhaften Feld angezeigt. Weitere nicht ausgefüllte Pflichtfelder sind nicht als fehlerhaft zu erkennen.

Deshalb sollte bei Verwendung von required Folgendes beachtet werden:

• Die Pflichtfelder müssen auch visuell als solche gekennzeichnet werden.

• Die visuelle Pflichtfeldkennzeichnung sollte so ausgezeichnet werden, dass sie nicht vom Screenreader ausgegeben wird, um die redundante Ausgabe zu vermeiden.

• Die Anwendung sollte eigene Fehlermeldungen bei allen nicht ausgefüllten Pflichtfeldern dauerhaft anzeigen.

Hinweis: Im Praxistipp zu Radiobuttons und Checkboxen sind Besonderheiten bezüglich deren Auszeichnung als Pflichtfelder erläutert.

Weitere Informationen 4.10.5.3.4 The required attribute - HTML Standard (whatwg.org)

ARIA

Pflichtfelder können mit dem Attribut aria-required=true ausgezeichnet werden.

• Formularfelder, die mit aria-required=true ausgezeichnet wurden, werden nicht automatisch durch den Browser validiert und befinden sich nicht im fehlerhaften Zustand, wenn sie nicht ausgefüllt wurden. Der fehlerhafte Zustand kann mit aria-invalid=true übermittelt werden.

• Formularfelder, die mit aria-required=true ausgezeichnet wurden, sind visuell nicht automatisch als Pflichtfelder erkennbar.

Weitere Informationen: aria-required property - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link)

Textelemente

Online betrachten

Inhaltsverzeichnis

• Überschrift

• Beschriftung

• Beschreibung

• Text

Überschrift

Online betrachten

Synonyme: Abschnittsüberschrift, Hauptüberschrift, Heading

Siehe auch: Schrift, Text, Beschriftung, Titel, Gruppe

Überschriften dienen der Gliederung von Textabschnitten. Sie beschreiben den Inhalt des jeweiligen Textabschnitts.

Darstellung

Bedienung

Tastaturbedienung Überschrift (in einer Anwendung ohne virtuellen Cursor)

Programmierung/Schnittstellen

Praxistipp Überschriften in Web-Anwendungen

Screenreader-Ausgabe

• JAWS: Überschrift Ebene [Zahl] [Beschriftung]

• NVDA: Überschrift Ebene [Zahl] [Beschriftung]

• Windows Sprachausgabe: Überschriftenebene [Zahl] [Beschriftung]

HTML

Überschriften werden mit den HTML-Elementen <h1>, <h2>, <h3>, <h4>, <h5> und <h6> ausgezeichnet. Dabei sollte Folgendes beachtet werden:

• Überschriften sollten knapp, eindeutig und aussagekräftig sein, weil sie die primäre Methode zur Navigation und dem Wahrnehmen der Seitenstruktur für Screenreader-Nutzende darstellen.

• Die Überschriften sollten hierarchisch korrekt verschachtelt werden, d. h. auf eine <h1> sollten <h2>-Überschriften folgen, deren Abschnitte wiederum <h3>-Überschriften enthalten können. Gemäß HTML-Spezifikation dürfen keine Überschriften-Ebenen übersprungen werden, so darf z. B. auf eine <h2> keine <h4>, <h5> oder <h6> folgen.

• Die Hauptüberschrift (<h1>) sollte den Zweck der jeweiligen Seite beschreiben (und z. B. nicht lediglich den Anwendungsnamen enthalten).

Überschriften können innerhalb des <hgroup>-Elements zusammen mit Absätzen (<p>-Element) gruppiert werden, um z. B. einen Untertitel oder eine alternative Überschrift anzugeben. Mit keinem der Screenreader für Windows ist diese Gruppierung wahrnehmbar, d. h. der Inhalt des <p>-Elements wird als normaler Text ausgegeben, weil das <hgroup>-Element gemäß den „HTML Accessibility API Mappings“ keine Semantik besitzt.

Weitere Informationen: 4.3.6 The h1, h2, h3, h4, h5, and h6 elements - HTML Standard (whatwg.org) , 4.3.11 Headings and outlines - HTML Standard (whatwg.org) (Externer Link), Headings | Web Accessibility Initiative (WAI) | W3C

ARIA

Wird die Überschrift nicht mit den HTML-Elementen umgesetzt, sollte u. a. Folgendes beachtet werden:

• Die Rolle wird mit role=heading übermittelt.

• Die Überschriften-Ebene wird mit aria-level übermittelt. Dabei sollten nur die Zahlen von 1 bis 6 verwendet werden.

  • Bei Zahlen größer als 6 gibt JAWS die Überschrift mit der Ebene 2 aus.

  • Bei Zahlen größer als 9 geben NVDA und Windows Sprachausgabe die Überschrift mit der Ebene 2 aus.

• Die Beschriftung sollte per Textinhalt erfolgen.

Weitere Informationen: heading role - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link)

Beschriftung

Online betrachten

Synonyme: Bezeichnung, Formularfeldbeschriftung, Label, Name, Accessible Name

Siehe auch: Schrift, Text, Grafik, Formular, Gruppe, Beschreibung, Fehlermeldung, Pflichtfeldkennzeichnung

Beschriftungen dienen der Identifikation von Bedienelementen (siehe DIN EN ISO 9241-161: 8.21).

Eine Beschriftung besteht aus einem kurzen, beschreibenden Text oder einer aussagekräftigen Grafik bzw. aus einer Kombination von Text und Grafik. Die Beschriftung kann sich innerhalb des Elements oder neben dem Element befinden, welches beschriftet wird.

Darstellung

Zeigeinstrumentbedienung Beschriftung

Programmierung/Schnittstellen

Praxistipp Beschriftung in Web-Anwendungen

Screenreader-Ausgabe

• JAWS: [Beschriftung] [Rolle] [Pflichtfeldhinweis] [Validierungshinweis] [Wert] [Beschreibung] [Fehlermeldung] [Bedienhinweis des Screenreaders] [Hinweis auf Tastaturkürzel]

• NVDA: [Beschriftung] [Rolle] [Pflichtfeldhinweis] [Validierungshinweis] [Beschreibung] [Hinweis auf Tastaturkürzel] [Wert]

• Windows Sprachausgabe: [Beschriftung] [Rolle] [Wert] [Pflichtfeldhinweis] [Validierungshinweis] [Hinweis auf Tastaturkürzel]

Hinweise:

• Die Beschriftung wird von den Screenreadern an erster Stelle, unmittelbar vor der Rolle, ausgegeben.

• Vor der Beschriftung wird lediglich eine Gruppenbeschriftung ausgegeben, sofern vorhanden.

• Beim Lesen mit dem virtuellen Cursor wird die Beschriftung je nach Bedienelement beim Element selbst ausgegeben oder an der Stelle, an der sie sich im Quellcode befindet. Damit auch beim Lesen mit dem virtuellen Cursor die Beschriftungen korrekt den Bedienelementen zugeordnet werden können, sollte sich die Beschriftung im Quellcode im Element (z. B. bei Links und Schaltern), direkt vor dem Element (bei Formularfeldern außer Radiobuttons und Checkboxen) oder direkt nach dem Element (bei Radiobuttons und Checkboxen) befinden.

HTML

In HTML hängt die Beschriftungsmethode vom Elementtyp ab:

• Links, Schalter (die mit dem <button>-Element ausgezeichnet sind), werden über ihren Textinhalt oder den Alternativtext der Grafik beschriftet,

• Schalter (die mit dem <input>-Element ausgezeichnet sind), werden über das value-Attribut beschriftet.

• Formularelemente werden mit dem <label>-Element beschriftet.

• Formularfeldgruppen (<fieldset>) werden mit dem <legend>-Element beschriftet.

• Grafiken (<img>) werden mit dem alt-Attribut beschriftet.

• Abbildungen (<figure>) werden mit dem <figcaption>-Element beschriftet.

• Tabellen werden mit dem <caption>-Element beschriftet.

• iFrames und Regionen (z. B. <nav> und <section>) werden mit dem title-Attribut beschriftet. Einige Elemente dürfen nicht beschriftet werden (z. B. <div> oder <span>).

Weitere Informationen: 4.10.4 The label element - HTML Standard (whatwg.org), Providing Accessible Names and Descriptions | APG | WAI | W3C, Labeling Controls | Web Accessibility Initiative (WAI) | W3C, 4. Accessible Name and Description Computation - HTML Accessibility API Mappings 1.0 (w3.org)

ARIA

In ARIA können Beschriftungen mit den Attributen aria-labelledby und aria-label übermittelt werden.

• Per aria-labelledby kann auf die IDs von sichtbaren oder unsichtbaren Beschriftungen verwiesen werden.

• Mit aria-label kann die Beschriftung direkt in Textform angegeben werden.

• Einige Elemente, die mit ARIA-Rollen ausgezeichnet sind, können außerdem über ihren Textinhalt beschriftet werden. Dies gilt u. a. für die Rollen button, link, checkbox, radio, option und tab. In der ARIA-Spezifikation sind diese Elemente mit „Name From: content“ gekennzeichnet.

• Einige Elemente, die mit ARIA-Rollen ausgezeichnet sind, müssen explizit (d. h. in der Regel mit aria-label oder aria-labelledby) beschriftet werden. Eine Beschriftung über den Textinhalt ist nicht möglich. Dies gilt u. a. für die Rollen: listbox, combobox, dialog, form, application, grid. In der ARIA-Spezifikation sind Elemente, die beschriftet werden müssen, mit „Accessible Name Required: True“ gekennzeichnet. Ob ein Element explizit beschriftet werden kann, ist in der ARIA-Spezifikation am „Name From: author“ ersichtlich.

• Darüber hinaus kann eine Beschriftung mit role=caption ausgezeichnet werden und dient dann als Beschriftung von Tabellen (role=grid, role=table, role=treegrid) und Abbildungen (role=figure), sofern die Beschriftung das erste (oder bei role=figure auch letzte) Kindelement des zu beschriftenden Elements ist. Unabhängig von der Auszeichnung mit role=caption soll per aria-labelledby auf die Beschriftung verwiesen werden.

• Einige ARIA-Rollen dürfen nicht beschriftet werden, z. B. generic, paragraph, presentation, code, insertion, deletion, emphasis, strong, subscript und superscript. In der ARIA-Spezifikation sind diese Elemente mit „Name From: prohibited“ gekennzeichnet. Elemente mit diesen Rollen dürfen allerdings Text enthalten.

• Es ist zulässig, per aria-labelledby auf ausgeblendete Elemente, die z. B. mit display:none oder hidden ausgezeichnet wurden, zu verweisen. Die Inhalte der ausgeblendeten Elemente dienen als Beschriftung des Elements mit aria-labelledby. Es empfiehlt sich in solchen Fällen jedoch, aria-label zu verwenden.

Weitere Informationen: aria-label property - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link), aria-labelledby property - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link), caption role - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link)

Allgemeine Hinweise

• Jedes Bedienelement muss eine Beschriftung besitzen, die als Accessible Name an die Accessibility API übermittelt wird. Dies gilt auch, wenn das Element keine visuell sichtbare Beschriftung besitzt.

• Die Beschriftung sollte knapp und aussagekräftig sein.

• Der Accessible Name sollte keinen Sprachwechsel und keine strukturierten Inhalte enthalten, weil dies mit der Assistenztechnologie nicht wahrnehmbar ist.

• Für jedes Element kann nur mit einer Methode eine Beschriftung an die Accessibility API übermittelt werden. Werden mehrere Methoden verwendet, wird lediglich die Beschriftung als Accessible Name verwendet, deren Methode die höchste Priorität besitzt. Die Priorität der Methoden ist wie folgt definiert:

  1. aria-labelledby,

  2. aria-label,

  3. HTML-Beschriftungsmethoden (wie <label>, <caption>, value, alt, sofern für das Element zutreffend),

  4. Textinhalt (sofern für das Element zulässig),

  5. title,

  6. placeholder (nur bei Eingabefeldern).

• Elemente sollten nicht per title- oder placeholder-Attribut beschriftet werden, weil diese beiden Attribute, die eigentlich für die Übermittlung einer Beschreibung bzw. eines Eingabehinweises gedacht sind, nur als Beschriftung verwendet werden, wenn es keine richtige Beschriftung gibt. Es handelt sich dabei um einen Reparaturmechanismus, der sicherstellen soll, dass ein Element nicht ohne Beschriftung ausgegeben wird.

• Wenn die Beschriftung eines Bedienelements explizit über ein Attribut erfolgt (z. B. aria-label, aria-labelledby, id, auf die per <label for> verwiesen wird), dann muss sich das Attribut an dem Element befinden, welches den Tastaturfokus erhält und die Rolle des zu beschriftenden Elements besitzt. Das Bedienelement kann nicht per Attribut beschriftet werden, wenn sich das Attribut an einem übergeordneten oder untergeordneten Element befindet.

• Textinhalte, die über die CSS-Selektoren before oder after als Pseudoelemente dargestellt werden, werden bei der Ermittlung der Beschriftung berücksichtigt. Soll dies vermieden werden, sollten sie mit aria-hidden=true ausgezeichnet werden.

• Wird per aria-labelledby auf ein Formularfeld verwiesen, so wird der Wert des Formularfeldes (nicht jedoch dessen Beschriftung) bei der Ermittlung der Beschriftung des Elements mit aria-labelledby berücksichtigt.

• ARIA-Elemente müssen in der Regel mit einer ARIA-Methode (z. B. aria-label oder aria-labelledby) oder über ihren Textinhalt (sofern für die entsprechende Rolle zulässig) beschriftet werden. So kann z. B. eine ARIA-Checkbox nicht mit dem <label>-Element und eine ARIA-Grafik nicht mit dem alt-Attribut beschriftet werden. Eine Ausnahme stellen ARIA-Elemente dar, deren zugrundeliegenden HTML-Elemente die entsprechende HTML-Beschriftungsmethode erlauben. So kann ein kombiniertes Eingabefeld (<input role=combobox>) mit dem <label>-Element beschriftet werden, weil das HTML-Element <input> mit dem <label>-Element beschriftet werden kann.

• Die sichtbare Beschriftung sollte nicht mit aria-hidden=true ausgezeichnet werden, selbst wenn ein Accessible Name vorhanden ist, damit die Sprachausgabe auch bei Mausbedienung funktioniert.

• Die sichtbare Beschriftung sollte als Accessible Name verwendet werden, um eine mehrfache Ausgabe der Beschriftung mit der Sprachausgabe zu vermeiden.

• Bei Formularfeldern sollte sich der Accessible Name im Quellcode unmittelbar vor dem Element befinden, außer bei Radiobuttons und Checkboxen, bei denen sich der Accessible Name im Quellcode unmittelbar dahinter befinden sollte. Das ist wichtig, damit auch beim Lesen mit dem virtuellen Cursor des Screenreaders die Beschriftung korrekt den Formularfeldern zugeordnet werden kann.

• Je nach Elementtyp ist der Textinhalt von Elementen auch mit dem virtuellen Cursor des Screenreaders nicht wahrnehmbar, wenn diese explizit beschriftet sind (z. B. mit aria-label oder aria-labelledby).

  • Bei Bedienelementen (wie z. B. Links und Schalter) sollte der Textinhalt als Beschriftung verwendet werden. Andernfalls muss sichergestellt sein, dass alle Informationen, die im Textinhalt stehen, auch im Accessible Name vorhanden sind.

  • Bei gruppierenden Elementen (wie Formularfeldgruppen, Regionen, Listen oder Tabellen) ist deren Inhalt mit dem virtuellen Cursor wahrnehmbar, selbst wenn diese explizit beschriftet sind. Diese Elemente sollten somit explizit beschriftet werden, damit deren Zweck erkennbar ist.

Beschreibung

Online betrachten

Synonyme: Hinweis, Hilfe, Bedienhinweis, Eingabehinweis, Instruktion, Description, Accessible Description

Siehe auch: Schrift, Text, Beschriftung, Fehlermeldung, Pflichtfeldkennzeichnung, Tooltip, Hilfe und Support

Eine Beschreibung enthält zusätzliche Informationen zur Bedienung der Anwendung (siehe DIN EN ISO 9241-161: 8.19).

Beschreibungen können sich auf ein Bedienelement, einen Bereich, eine Maske oder die gesamte Anwendung beziehen. Eine Beschreibung besteht aus einem erläuternden Text, einer Grafik oder aus einer Kombination von Text und Grafik.

Beschreibungen können

• dauerhaft sichtbar sein,

• bei der Bedienung dynamisch ein- und ausgeblendet werden (z. B. beim Hovern mit einem Zeigeinstrument oder bei Fokuserhalt mit der Tastatur bzw. nach Aktivierung eines Bedienelements).

Darstellung

Bedienung

Programmierung/Schnittstellen

Praxistipp Beschreibungen in Web-Anwendungen

Screenreader-Ausgabe

• JAWS: [Beschriftung] [Rolle] [Pflichtfeldhinweis] [Validierungshinweis] [Wert] [Beschreibung] [Fehlermeldung] [Bedienhinweis des Screenreaders] [Hinweis auf Tastaturkürzel]

• NVDA: [Beschriftung] [Rolle] [Pflichtfeldhinweis] [Validierungshinweis] [Beschreibung] [Hinweis auf Tastaturkürzel] [Wert]

• Windows Sprachausgabe: [Beschriftung] [Rolle] [Wert] [Pflichtfeldhinweis] [Validierungshinweis] [Hinweis auf Tastaturkürzel]

Hinweise:

• Die Beschreibung wird von JAWS und NVDA eher am Ende, in jedem Fall nach der Beschriftung und Rolle ausgegeben.

• Die Beschreibung wird von der Windows Sprachausgabe nicht ausgegeben.

• JAWS und NVDA können so konfiguriert werden, dass keine Ausgabe der Beschreibung erfolgt. Diese Funktion wird von erfahrenen Screenreadernutzenden verwendet, um die Inhalte effizienter wahrnehmen zu können. Deshalb sollten nur zusätzliche Informationen in der Beschreibung enthalten sein.

• Beim Lesen mit dem virtuellen Cursor werden Beschreibungen vom Screenreader in der Regel nicht ausgegeben. Die Ausgabe der Beschreibungen erfolgt nur bei TAB-Navigation. Deshalb sollten nur zusätzliche Informationen in der Beschreibung enthalten sein und die Beschreibung nur bei Bedienelementen, die den Tastaturfokus erhalten können, verwendet werden.

HTML

In HTML können die meisten Bedienelemente nur über das title-Attribut mit einer Beschreibung versehen werden. Das title-Attribut ist jedoch aus folgenden Gründen nicht barrierefrei:

• Bei Verwendung des Browserzooms wird der Tooltip, der durch das title-Attribut angezeigt wird, nicht skaliert.

• Bei Tastaturnavigation wird der Tooltip (außer im Browser Edge) nicht eingeblendet und ist somit für sehende Tastaturnutzende nicht wahrnehmbar.

• Die Tooltips können nicht mit der Maus überfahren werden.

• Die Tooltips können in einigen Browsern (z. B. Firefox) nicht ausgeblendet werden, ohne den Fokus wegzubewegen.

• Auf Mobilgeräten können die Tooltips nicht oder nur schwer angezeigt werden. Aus diesen Gründen sollte das title-Attribut vermieden werden.

In HTML können wenige Elemente zusätzlich zum title-Attribut mit einer weiteren Methode mit einer Beschreibung versehen werden:

• Schalter, die mit dem <input type=button|reset|submit>-Element ausgezeichnet sind, über das value-Attribut, sofern dieses nicht bereits für den Accessible Name verwendet wird,

• Schalter, die mit dem <summary>-Element ausgezeichnet sind, über ihren Textinhalt, sofern dieser nicht bereits für den Accessible Name verwendet wird,

• Tabellen über das <caption>-Element, sofern dieses nicht bereits für den Accessible Name verwendet wird. Damit soll allerdings lediglich sichergestellt werden, dass die sichtbare Beschriftung mit der assistiven Technologie zumindest als Beschreibung wahrnehmbar ist, wenn diese nicht als Beschriftung (Accessible Name) ausgegeben wird. Da jedoch die sichtbare Beschriftung mit dem Accessible Name übereinstimmen oder zumindest in diesem enthalten sein muss (EN 301 549: 9.2.5.3), sollte keine der drei Methoden zur Auszeichnung einer Beschreibung verwendet werden.

Weitere Informationen: 3.2.6.1 The title attribute - HTML Standard (whatwg.org) (Externer Link), Providing Accessible Names and Descriptions | APG | WAI | W3C, 4. Accessible Name and Description Computation - HTML Accessibility API Mappings 1.0 (w3.org)

ARIA

In ARIA können Beschreibungen mit den Attributen aria-describedby und aria-description übermittelt werden.

• Per aria-describedby kann auf die IDs von sichtbaren oder unsichtbaren Beschreibungen verwiesen werden.

• Mit aria-description kann die Beschreibung direkt in Textform angegeben werden. Das Attribut wird erst mit ARIA 1.3 definiert und wird somit von älterer Assistenztechnologie noch nicht unterstützt.

• Es ist zulässig, per aria-describedby auf ausgeblendete Elemente, die z. B. mit display:none oder hidden ausgezeichnet wurden, zu verweisen. Die Inhalte der ausgeblendeten Elemente dienen als Beschreibung des Elements mit aria-describedby. Es empfiehlt sich in solchen Fällen jedoch, aria-description zu verwenden.

Mit weiteren ARIA-Attributen können Informationen an die Accessibility API übermittelt werden, die beschreibenden Charakter haben, aber keine Beschreibung (Accessible Description) darstellen:

• Fehlermeldungen mit aria-errormessage,

• Platzhalter mit aria-placeholder,

• Informationen zu Tastaturkürzel mit aria-keyshortcuts,

• Hinweis auf eine ausführliche Beschreibung mit aria-details.

Achtung: Obwohl das ARIA-Attribut aria-roledescription so bezeichnet ist, als ob mit ihm die Rolle des Elements beschrieben werden könnte, ist dies nicht der Fall. Mit aria-roledescription wird die Rolle des Elements überschrieben, weshalb das Attribut mit Vorsicht zu verwenden ist.

Weitere Informationen: aria-describedby property - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link), aria-description property - Accessible Rich Internet Applications (WAI-ARIA) 1.3 (w3c.github.io) (Externer Link)

Allgemeine Hinweise

• Eine Beschreibung, die programmatisch als Accessible Description übermittelt wird, kann zwar ausführlicher sein als die Beschriftung, sollte jedoch ebenfalls knapp und aussagekräftig sein. Die Beschreibung sollte nicht redundant zur Beschriftung sein.

• Außerdem sollte die Accessible Description keine Sprachwechsel und keine strukturierten Inhalte enthalten, weil dies mit der Assistenztechnologie nicht wahrnehmbar ist.

• Längere Beschreibungen oder Beschreibungen mit Sprachwechsel oder strukturierten Inhalten sollten so umgesetzt werden, dass sie mit dem virtuellen Cursor des Screenreaders gelesen werden können, d. h. in Textform vorhanden sein. Vom jeweiligen Bedienelement kann per aria-details verwiesen oder in einer kurzen Accessible Description auf die ausführliche Beschreibung hingewiesen werden.

• Für jedes Element kann nur mit einer Methode eine Beschreibung an die Accessibility API übermittelt werden. Werden mehrere Methoden verwendet, wird lediglich die Beschreibung als Accessible Description verwendet, deren Methode die höchste Priorität besitzt. Die Priorität der Methoden ist wie folgt definiert:

  1. aria-describedby,

  2. aria-description,

  3. sichtbare Beschriftung bei Schaltern und Tabellen, sofern nicht für den Accessible Name verwendet (siehe oben),

  4. title.

• Wenn die Beschreibung eines Bedienelements explizit über ein Attribut erfolgt (z. B. aria-description, aria-describedby, title), dann muss sich das Attribut an dem Element befinden, welches den Tastaturfokus erhält und die Rolle des zu beschreibenden Elements besitzt. Das Bedienelement kann nicht per Attribut beschrieben werden, wenn sich das Attribut an einem übergeordneten oder untergeordneten Element befindet.

• Textinhalte, die über die CSS-Selektoren before oder after als Pseudoelemente dargestellt werden, werden bei der Ermittlung der Beschreibung berücksichtigt. Soll dies vermieden werden, sollten sie mit aria-hidden=true ausgezeichnet werden.

• Wird per aria-describedby auf ein Formularfeld verwiesen, so wird der Wert des Formularfeldes (nicht jedoch dessen Beschriftung) bei der Ermittlung der Beschreibung des Elements mit aria-describedby berücksichtigt.

• Die sichtbare Beschreibung sollte nicht mit aria-hidden=true ausgezeichnet werden, selbst wenn eine Accessible Description vorhanden ist, damit die Sprachausgabe auch bei Mausbedienung funktioniert.

• Die sichtbare Beschriftung sollte als Accessible Description verwendet werden, um eine mehrfache Ausgabe der Beschreibung mit der Sprachausgabe zu vermeiden.

• Um eine sinnvolle Lesereihenfolge mit dem virtuellen Cursor des Screenreaders zu gewährleisten, sollten sich Beschreibungen im Quellcode beim oder in dem Element befinden, welches beschrieben wird, z. B.

  • Eingabehinweise in einem Formular als Kindelement am Anfang des <form>-Elements,

  • Eingabehinweise eines Formularfelds unmittelbar vor oder nach dem Formularfeld, jedoch in jedem Fall nach der Beschriftung des Feldes.

• Die Attribute title, aria-describedby und aria-description sind globale Attribute. d. h. sie können bei jedem HTML-Element bzw. bei jeder ARIA-Rolle verwendet werden. Es ist jedoch zu beachten, dass die Accessible Description von den meisten Screenreadern nicht beim Lesen mit dem virtuellen Cursor ausgegeben wird, so dass diese drei Attribute nur bei Bedienelementen, die den Tastaturfokus erhalten, verwendet werden sollten. Unproblematisch ist die Verwendung von aria-describedby bei weiteren Elementen, sofern der Beschreibungstext, auf den das Attribut verweist, auch mit dem virtuellen Cursor lesbar ist, d. h. nicht ausgeblendet wurde (z. B. mit hidden oder aria-hidden=true).

Text

Online betrachten

Synonyme: Fließtext

Siehe auch: Schrift, Beschriftung, Beschreibung, Fehlermeldung, Grafik

Text dient der Vermittlung von Informationen in Schriftform. Text kann u. a. Überschriften, Links, Listen und Grafiken enthalten.

Darstellung

Bedienung

Tastaturbedienung Text (in einer Anwendung, die den virtuellen Cursor nicht unterstützt)

Programmierung/Schnittstellen

Praxistipp Text

Anwendung, die den virtuellen Cursor nicht unterstützt

Längere Texte (Richtwert: 80 bis 400 Zeichen) ohne Textstruktur (d. h. nur Fließtext ohne Listen, Tabellen, Überschriften etc.) sollen Anwendungen, die den virtuellen Cursor nicht unterstützen,

• in mehreren TAB-Schritten den Fokus erhalten (je TAB-Schritt rund 80 Zeichen) oder

• so ausgezeichnet werden, dass sie mit dem virtuellen Cursor gelesen werden können, oder

• in einem verlinkten Dokument angeboten werden, welches mit dem virtuellen Cursor gelesen werden kann (z. B. HTML, PDF, RTF).

Lange Texte (ab ca. 400 Zeichen) oder Texte mit Struktur (z. B. Listen, Tabellen, Überschriften) sollen

• so ausgezeichnet werden, dass sie mit dem virtuellen Cursor gelesen werden können, oder

• in einem verlinkten Dokument angeboten werden, welches mit dem virtuellen Cursor gelesen werden kann (z. B. HTML, PDF, RTF).

Anwendungen mit vielen TAB-Schritten auf Texten und sonstigen nicht bedienbaren Elementen sollen einen Modus zum Deaktivieren dieser unnötigen Navigationsschritte für sehende Tastaturnutzende enthalten. Dieser Modus und dessen Aktivierung soll in den Hinweisen zur Barrierefreiheit beschrieben werden.

Anwendung, die den virtuellen Cursor unterstützt

Wenn das Kopieren von einzelnen Textinhalten im Anwendungskontext relevant sein kann, dann soll dies auch mit der Tastatur möglich sein. Folgende Anforderungen sind dann für die Textinhalte zu erfüllen:

• die Textinhalte sind mit der Tastatur fokussierbar,

• innerhalb des Texts ist der Textcursor sichtbar,

• innerhalb des Texts kann mit den Pfeiltasten navigiert werden, um den Startpunkt der Markierung zu bestimmen,

• der Text kann mit UMSCHALT+Pfeiltasten markiert werden,

• der markierte Text kann mit STRG+C kopiert (ggf. auch über das Kontextmenü) und befindet sich nach dem Kopieren in der Windows-Zwischenablage.

Um das zu erreichen, können schreibgeschützte Eingabefelder verwendet werden.

Sofern lediglich der gesamte Inhalt eines Textabschnitts kopierbar sein muss, kann alternativ auch ein Schalter zum Kopieren des Textinhalts implementiert werden. Die Aktivierung des Schalters soll bewirken, dass der zugehörige Text in die Zwischenablage kopiert wird.

Anwendungen mit vielen TAB-Schritten auf kopierbaren Texten sollen einen Modus zum Deaktivieren dieser Navigationsschritte enthalten. Dieser Modus und dessen Aktivierung soll in den Hinweisen zur Barrierefreiheit beschrieben werden.

Grafische Elemente

Online betrachten

Inhaltsverzeichnis

• Grafik

• Layoutgrafik

• Fortschrittsanzeige

Grafik

Online betrachten

Synonyme: Grafisches Element, Icon, Bild, Abbildung, inhaltstragende Grafik, Pixelgrafik, Vektorgrafik, Graphic, Image

Siehe auch: Layoutgrafik

Grafiken dienen der visuellen, nicht-textlichen Vermittlung von Informationen.

Hinweis: Zusätzliche Anforderungen an Grafiken, die den Status, den Wert, die Rolle oder Beschriftung eines Elements übermitteln, werden beim jeweiligen Element bzw. in den entsprechenden Abschnitten (z. B. Elementstatus, Beschriftung) beschrieben.

Darstellung

Bedienung

Tastaturbedienung Grafik

Hinweis: Die folgenden Anforderungen gelten nur, wenn die Grafik mit der Tastatur erreichbar sein muss (siehe oben).

Zeigeinstrumentbedienung Grafik

Programmierung/Schnittstellen

Praxistipp Grafiken in Web-Anwendungen, die Rolle, Status oder Wert übermitteln

HTML

Bei den HTML-Standardelementen muss bezüglich der Grafiken, die Informationen zu Rolle, Status oder Wert übermitteln, nichts beachtet werden, weil die entsprechenden Informationen automatisch vom Browser korrekt an die Accessibility API übermittelt werden.

ARIA

Bei benutzerdefinierten Elementen, die mit ARIA-Rollen und ARIA-Attributen umgesetzt werden, sollten die Grafiken, die Informationen zu Rolle, Status oder Wert übermitteln, als Layoutgrafiken ausgezeichnet werden. Die Informationen sollten stattdessen programmatisch übermittelt werden, z. B. mit folgenden Attributen:

• role für die Rolle,

• aria-valuenow und aria-valuetext für den Wert,

• aria-required für Pflichtfelder,

• aria-invalid für fehlerhafte Formularfelder,

• aria-checked bzw. aria-selected für den Status „ausgewählt“,

• aria-disabled für deaktivierte Bedienelemente,

• aria-pressed für den Status „gedrückt“ bzw. „nicht gedrückt“,

• aria-expanded für den Status „reduziert“/“ausgeblendet“ bzw. „erweitert“/„eingeblendet“

• aria-haspopup für Elemente, bei deren Aktivierung ein Menü, eine Auswahlliste, eine Baumstruktur, eine Tabelle oder ein Dialog eingeblendet wird,

• aria-sort für die Sortierrichtung,

• aria-current für die Kennzeichnung des aktuellen Elements.

Sofern für die entsprechende Information kein ARIA-Attribut existiert, sollte die Information in Textform als Teil der Beschriftung oder Beschreibung des Elements übermittelt werden.

Weitere Informationen: Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link)

Praxistipp Grafiken in Web-Anwendungen

Screenreader-Ausgabe

• JAWS: [Alternativtext] Grafik

• NVDA: Grafik [Alternativtext]

• Windows Sprachausgabe: [Alternativtext] Bild

HTML und ARIA

Die Auszeichnung und Beschriftung der Grafiken hängt von der verwendeten Methode zur Darstellung der Grafik ab:

• Grafiken, die mit dem <img>-Element ausgezeichnet sind, werden mit dem alt-Attribut beschriftet.

• Schalter mit grafischer Beschriftung, die mit dem <input type=image>-Element ausgezeichnet sind, werden ebenfalls mit dem alt-Attribut beschriftet.

• Alle anderen Grafiken sollten mit role=img ausgezeichnet und explizit mit aria-label oder aria-labelledby beschriftet werden. Dies gilt z. B. für die Elemente <svg> und <canvas>., CSS-Hintergrundgrafiken, Font-Icons und Buchstaben, die in einem grafischen Kontext verwendet werden (z. B. „x“ für „gelöscht“).

• Grafiken für Listenzeichen (list-style-image) können weder mit einem Alternativtext versehen noch als Layoutgrafik ausgezeichnet werden und sollten deshalb nicht verwendet werden.

Dabei gelten folgende Ausnahmen:

• Grafiken, die zur Beschriftung von Bedienelementen dienen, können als Layoutgrafik ausgezeichnet werden. Stattdessen wird das Bedienelement aussagekräftig beschriftet (z. B. <button title=Löschen><img src=… alt></button>, <button aria-label=Löschen><img src=…></button>). Sofern das Bedienelement per aria-label oder aria-labelledby beschriftet wird, wird die enthaltene Grafik automatisch zur Layoutgrafik und muss nicht separat als solche ausgezeichnet werden.

• Die Screenreader geben die relevanten Informationen der Elemente (Beschriftung, Rolle, Status, Wert), die sich innerhalb von <svg> und <canvas> befinden, aus, wenn das jeweilige <svg>- bzw. <canvas>-Element nicht als Grafik ausgezeichnet ist. So kann z. B. das <svg>- bzw. <canvas>-Element mit role=group als Gruppe ausgezeichnet und mit aria-label oder aria-labelledby beschriftet werden. Mit dem Screenreader ist dann nicht direkt wahrnehmbar, dass es sich um eine Grafik handelt (diese Information kann jedoch indirekt über die Beschriftung der Gruppe übermittelt werden), aber es besteht die Möglichkeit, ausführliche und strukturierte Textalternativen innerhalb der grafischen Elemente zu übermitteln, z. B. bei Diagrammen.

• Font-Icons oder Grafiken, die über die CSS-Selektoren before oder after als Pseudoelemente dargestellt werden, können zukünftig auch direkt im CSS mit einem Alternativtext versehen werden ( 1.2. Alternative Text for Accessibility - CSS Generated Content Module Level 3 (w3.org) (Externer Link)). Dies wird derzeit aber noch nicht zuverlässig von den Assistenztechnologien unterstützt.

Weitere Informationen: 4.8.3 The img element - HTML Standard (whatwg.org) (Externer Link), Images Tutorial | Web Accessibility Initiative (WAI) | W3C

Layoutgrafik

Online betrachten

Synonyme: Schmuckgrafik, dekorative Grafik, nicht-inhaltstragende Grafik, ggf. auch Hintergrundgrafik, Decorative Graphic

Siehe auch: Grafik

Layoutgrafiken dienen der visuellen Gestaltung der Anwendung, ohne jedoch Informationen zu übermitteln. Layoutgrafiken können z. B. rein dekorativ sein oder parallel zu einer Information in Textform angezeigt werden, ohne jedoch zusätzlich zum Text eine Information zu übermitteln.

Darstellung

Bedienung

Programmierung/Schnittstellen

Praxistipp Layoutgrafiken in Web-Anwendungen

Screenreader-Ausgabe

Keine

HTML und ARIA

Die Auszeichnung der Layoutgrafiken hängt von der verwendeten Methode zur Darstellung der Grafik ab:

• Grafiken, die mit dem <img>-Element ausgezeichnet sind, sollten mit einem leeren Alternativtext als Layoutgrafik ausgezeichnet werden (<img src=… alt="">).

• Grafiken, die mit dem <svg>-Element ausgezeichnet sind, sollten mit aria-hidden als Layoutgrafik ausgezeichnet werden (<svg aria-hidden=true>).

• Grafiken, die mit dem <canvas>-Element ausgezeichnet sind, sollten mit aria-hidden als Layoutgrafik ausgezeichnet werden (<canvas aria-hidden=true>).

• Schriftzeichen, die rein dekorativ verwendet werden, sollten mit aria-hidden als Layoutgrafik ausgezeichnet werden (<span aria-hidden=true>~~~</span>).

• Font-Icons oder Grafiken, die über die CSS-Selektoren before oder after als Pseudoelemente dargestellt werden, sollten mit aria-hidden als Layoutgrafik ausgezeichnet werden (<span class=… aria-hidden=true></span>). Zukünftig können diese Pseudoelemente auch direkt im CSS als Layoutgrafiken ausgezeichnet werden ( 1.2. Alternative Text for Accessibility - CSS Generated Content Module Level 3 (w3.org) (Externer Link)). Dies wird derzeit aber noch nicht zuverlässig von den Assistenztechnologien unterstützt.

• Font-Icons sollten mit aria-hidden als Layoutgrafik ausgezeichnet werden (<span aria-hidden=true>i</span>).

• Grafiken für Listenzeichen (list-style-image) können weder mit einem Alternativtext versehen noch als Layoutgrafik ausgezeichnet werden und sollten deshalb nicht verwendet werden.

• CSS-Hintergrundgrafiken (background-image) sind automatisch Layoutgrafiken.

• Sonstige CSS-Grafiken (die z. B. mit border erstellt werden) sind automatisch Layoutgrafiken.

Layoutgrafiken dürften nicht den Tastaturfokus erhalten, d. h. die Grafik selbst oder deren Nachfahrenelemente dürfen nicht mit tabindex bzw. als Bedienelemente (z. B. <button>) ausgezeichnet sein.

Weitere Informationen: Decorative Images | Web Accessibility Initiative (WAI) | W3C

Fortschrittsanzeige

Online betrachten

Synonyme: Verlaufsanzeige, Fortschrittsbalken, Progressbar

Siehe auch: Schieberegler, Grafik

Eine Fortschrittsanzeige dient der Anzeige, wie weit ein Prozess fortgeschritten ist (siehe DIN EN ISO 9241-161: 8.30). Der Fortschritt kann in Textform, grafisch (z. B. Fortschrittsbalken) oder aus einer Kombination von Grafik und Text angezeigt werden. Die Darstellung der Fortschrittsanzeige ändert sich automatisch, bis der Prozess abgeschlossen ist.

Darstellung

Bedienung

Tastaturbedienung Fortschrittsanzeige

Hinweis: Die folgende Tabelle gilt nur, wenn die Fortschrittsanzeige mit der Tastatur erreichbar sein muss (siehe oben).

Programmierung/Schnittstellen

Praxistipp Fortschrittsanzeige in Web-Anwendungen

Screenreader-Ausgabe

Fortschrittsanzeige mit Wert:

• JAWS: [Beschriftung] Fortschrittsanzeige [Wert] Prozent

• NVDA: [Beschriftung] Fortschrittsbalken [Wert]

• Windows Sprachausgabe: [Beschriftung] [Wert in %] Prozent Statusleiste Aktueller Wert [Wert] Mindestwert [minimaler Wert] Höchstwert [maximaler Wert]

Fortschrittsanzeige ohne Wert:

• JAWS: [Beschriftung] Fortschrittsanzeige 0 Prozent

• NVDA: [Beschriftung] Beschäftigt-Status

• Windows Sprachausgabe: [Beschriftung] 0 Prozent Statusleiste Aktueller Wert 0 Mindestwert [minimaler Wert] Höchstwert [maximaler Wert]

Hinweise:

• JAWS gibt den Wert irreführend mit dem Zusatz „Prozent“ aus, ohne diesen in einen Prozentwert umzurechnen.

• Die Aktualisierung der Fortschrittsanzeige ist mit JAWS und der Windows Sprachausgabe nicht automatisch wahrnehmbar.

• NVDA gibt die Aktualisierung der Fortschrittsanzeige unabhängig von der Fokusposition automatisch mit kurzen Pieptönen aus, deren Tonhöhe die Höhe des Werts repräsentiert.

HTML

Die Fortschrittsanzeige sollte mit dem HTML-Element <progress> umgesetzt werden.

Der aktuelle Wert wird mit dem value-Attribut gesetzt. Wird kein value-Attribut angegeben, handelt es sich um eine unbestimmte Fortschrittsanzeige, die lediglich anzeigt, dass ein Fortschritt passiert, ohne angeben zu können, wie weit dieser vorangeschritten ist.

Der maximale Wert wird mit dem max-Attribut gesetzt. Es sollte beachtet werden, dass dieser Wert mit vielen Assistenztechnologien nicht wahrnehmbar ist. Der minimale Wert ist immer 0.

Die Beschriftung sollte mit dem Element <label for=ID> mit der Fortschrittsanzeige verknüpft werden.

Das <progress>-Element kann gemäß HTML-Spezifikation unterschiedliche Kindelemente enthalten. Diese sind jedoch weder visuell wahrnehmbar noch werden sie von den Assistenztechnologien ausgegeben.

Weitere Informationen: 4.10.13 The progress element - HTML Standard (whatwg.org)

ARIA

Wird die Fortschrittsanzeige nicht mit dem HTML-Element umgesetzt, sollte u. a. Folgendes beachtet werden:

• Die Rolle wird mit role=progressbar übermittelt.

• Der aktuelle Wert kann mit aria-valuenow angegeben werden. Wird der Wert nicht angegeben, handelt es sich um eine unbestimmte Fortschrittsanzeige.

• Mit aria-valuetext kann zusätzlich ein Wert in Textform angegeben werden, der dann von der Assistenztechnologie anstelle des Werts im aria-valuenow ausgegeben werden soll.

• Der minimale und der maximale Wert können mit aria-valuemin und aria-valuemax angegeben werden.

• Die Beschriftung kann per aria-label oder aria-labelledby erfolgen.

• Die Darstellung der Fortschrittsanzeige sollte im Hochkontrast-Modus von Windows überprüft werden.

Weitere Informationen: progressbar role - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link)

Strukturelle Elemente

Online betrachten

Inhaltsverzeichnis

• Desktop: Fenster

• Tooltip

• Formular

• Werkzeugleiste

• Gruppe

• Liste

• Tabelle

• Hierarchische Tabelle

• Titelzeile

• Statuszeile

• Modaler Dialog

Desktop: Fenster

Online betrachten

Synonyme: Anwendungsfenster, Window

Siehe auch: Titelzeile, Statuszeile, Modaler Dialog

Ein Fenster enthält alle aktuell sichtbaren Elemente der Anwendung (siehe DIN EN ISO 9241-161: 8.51). Ein Fenster kann folgende Elemente enthalten:

• Titel

• Arbeitsbereich (ggf. mit Menü),

• Statuszeile.

Hinweis: Alle Anforderungen an Fenster beziehen sich ausschließlich auf Desktop-Anwendungen. Bei Web-Anwendungen stellt der Browser das Fenster dar. Die Web-Anwendung selbst enthält keine Fenster.

Beispiele:

Darstellung

Im Folgenden werden nur die Anforderungen beschrieben, die sich direkt auf das Fenster beziehen. Anforderungen an die Elemente innerhalb des Fensters sind beim jeweiligen Element beschrieben.

Bedienung

Tastaturbedienung Fenster

Zeigeinstrumentbedienung Fenster

Programmierung/Schnittstellen

Tooltip

Online betrachten

Synonyme: Quickinfo, Infotip, Mouse over

Siehe auch: Beschreibung, Tooltip, modaler Dialog

Ein Tooltip dient der dynamischen Anzeige einer zusätzlichen Information, z. B. der Beschriftung (insbesondere bei grafischen Bedienelementen), einer Beschreibung, einem Tastaturkürzel, einer kontextspezifischen Hilfe. (siehe DIN EN ISO 9241-161: 8.50). Tooltips werden bei Fokussierung des zugehörigen UI-Elements eingeblendet. Tooltips enthalten keine interaktiven Elemente.

Darstellung

Bedienung

Tastaturbedienung Tooltip

Zeigeinstrumentbedienung Tooltip

Programmierung/Schnittstellen

Formular

Online betrachten

Synonyme: Formularbereich, Form

Siehe auch: Gruppe, Fehlervermeidung und -korrektur, Pflichtfeldkennzeichnung, Authentifizierung, Bedienelemente

Formulare dienen der Eingabe von Daten. Ein Formular enthält ein oder mehrere Formularelemente.

Darstellung

Im Folgenden werden nur die Anforderungen beschrieben, die sich direkt auf das Formular beziehen. Anforderungen an die interaktiven Elemente innerhalb des Formulars sind beim jeweiligen Element beschrieben.

Bedienung

Tastaturbedienung Formular

Programmierung/Schnittstellen

Werkzeugleiste

Online betrachten

Synonyme: Symbolleiste, Toolbar, Toolbox, Command Bar Tab

Siehe auch: Menü, Gruppe, Menü-Schalter

Werkzeugleisten dienen der Gruppierung von interaktiven Elementen zur Bearbeitung von Inhalten oder Daten (siehe DIN EN ISO 9241-161: 8.49).

Eine Werkzeugleiste enthält interaktive Elemente (meist Schalter oder Umschalter), die visuell gruppiert sind, z. B. mit einem Rahmen. Die Inhalte der Werkzeugleiste sind meist horizontal oberhalb oder unterhalb des Bereichs, dessen Inhalt mit den Elementen der Werkzeugleiste bearbeitet wird, angeordnet. Die Elemente der Werkzeugleiste können mehrzeilig angeordnet sein. Bei Werkzeugleisten mit vielen Schaltern werden aus Platzgründen häufig Icons als Beschriftung der Schalter verwendet.

Darstellung

Im Folgenden werden nur die Anforderungen beschrieben, die sich direkt auf die Werkzeugleiste beziehen. Anforderungen an die interaktiven Elemente innerhalb der Werkzeugleiste sind beim jeweiligen Element beschrieben.

Bedienung

Tastaturbedienung Werkzeugleiste

Programmierung/Schnittstellen

Praxistipp Werkzeugleiste in Web-Anwendungen

Screenreader-Ausgabe

Bei TAB-Navigation:

• JAWS: [Beschriftung] Symbolleiste

• NVDA: [Beschriftung] Werkzeugleiste

• Windows Sprachausgabe: [Beschriftung] Symbolleiste

Mit dem virtuellen Cursor:

• JAWS: Werkzeugleiste mit [Anzahl] Schaltern … Werkzeugleiste Ende

• NVDA: Werkzeugleiste … außerhalb von Werkzeugleiste

• Windows Sprachausgabe: -

HTML

In HTML existiert kein Element für Werkzeugleisten. Stattdessen können Schalter und weitere Bedienelemente in einer Liste (<menu> und <li>), beschrifteten Region (z. B. <section>) oder einer Formularfeldgruppe (<fieldset>, beschriftet mit <legend>) gruppiert werden. Die Navigation zwischen den Elementen erfolgt dann allerdings mit der TAB-Taste und nicht mit den Pfeiltasten. Um die effiziente Tastaturnavigation zu unterstützen, sollte die Region bzw. Formularfeldgruppe übersprungen werden können (siehe Praxistipp Effiziente Navigation).

Weitere Informationen: 4.4.7 The menu element - HTML Standard (whatwg.org) (Externer Link), 4.3.3 The section element - HTML Standard (whatwg.org) (Externer Link) 4.10.15 The fieldset element - HTML Standard (whatwg.org)

ARIA

Bei der Umsetzung von Werkzeugleisten sollte Folgendes beachtet werden:

• Die Rolle wird mit role=toolbar übermittelt.

• Die Werkzeugleiste sollte mit aria-label oder aria-labelledby beschriftet werden.

• Eine vom Standard abweichende vertikale Ausrichtung der Werkzeugleiste kann mit aria-orientation=vertical angegeben werden. Die Ausrichtung wird von Assistenztechnologie häufig nicht ausgegeben, so dass bei einer vertikal ausgerichteten Werkzeugleiste die Bedienung mit allen Pfeiltasten möglich sein sollte.

• Die Werkzeugleiste sollte auch visuell als solche erkennbar sein, damit sehende Tastaturnutzende die Bedienung mit den Pfeiltasten erkennen können.

• Die Werkzeugleiste sollte mindestens drei Bedienelemente enthalten.

• Die sichtbaren Elemente innerhalb der Werkzeugleiste und das programmatisch fokussierte Element sollten die gleiche Position und Größe besitzen.

Weitere Informationen: toolbar role - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link), Toolbar Pattern | APG | WAI | W3C

Gruppe

Online betrachten

Synonyme: Formularfeldgruppe, Gruppenfeld, Gruppierung, Groupbox

Siehe auch: Überschriften, Formular, Werkzeugleiste

Gruppen dienen der Zusammenfassung von inhaltlich zusammengehörigen Elementen (siehe DIN EN ISO 9241-161: 8.15). Die Gruppe besitzt eine Beschriftung, die als Gruppenbeschriftung für die enthaltenen Elemente dient.

Darstellung

Programmierung/Schnittstellen

Praxistipp Formularfeldgruppen in Web-Anwendungen

Screenreader-Ausgabe

• JAWS: [Beschriftung] Gruppe … Gruppe Ende

• NVDA: [Beschriftung] Gruppierung … außerhalb von Gruppierung

• Windows Sprachausgabe: -

Hinweise:

• Formularfeldgruppen werden von der Windows Sprachausgabe nicht ausgegeben.

• Bei JAWS und NVDA ist das Ende der Formularfeldgruppe nur beim Lesen mit dem virtuellen Cursor wahrnehmbar. Bei der TAB-Navigation wird die Rolle „Gruppe“ bzw. „Gruppierung“ lediglich beim ersten (bzw. bei UMSCHALT+TAB beim letzten) Formularelement in der Gruppe, d. h. beim Betreten der Gruppe ausgegeben. Das Verlassen der Gruppe ist bei TAB-Navigation nicht wahrnehmbar. In den Elementübersichten der Screenreader wird die Beschriftung der Formularfeldgruppe bei jedem Formularelement innerhalb der Gruppe angezeigt.

• Damit JAWS und NVDA die Formularfeldgruppen erkennen können, müssen sie beschriftet werden, unabhängig davon, ob sie mit dem HTML-Element <fieldset> oder mit den ARIA-Rollen group bzw. radiogroup ausgezeichnet sind.

• Befindet sich innerhalb des <fieldset>- und außerhalb des <legend>-Elements eine Überschrift, wird von JAWS die Gruppenbeschriftung nicht korrekt ausgegeben. Somit sollten Überschriften im <fieldset> vermieden werden.

HTML

Formularfeldgruppen werden mit dem <fieldset>-Element ausgezeichnet und dienen der Gruppierung von zusammengehörenden Formularfeldern, insbesondere bei Radiobuttons. Die Formularelemente, die zur Gruppe gehören, sind im Quellcode innerhalb des <fieldsets> verschachtelt. Die Beschriftung der Formularfeldgruppe erfolgt mit dem <legend>-Element, welches sich als erstes Kindelement im <fieldset> befinden sollte. Weil die Beschriftung der Gruppe vor der Beschriftung der enthaltenen Formularelemente ausgegeben wird, sollte Folgendes beachtet werden:

• Die Beschriftung der Gruppe sollte möglichst knapp sein, ohne dabei an Aussagekraft zu verlieren.

• Formularfeldgruppen sollten nicht ineinander verschachtelt werden.

Gemäß HTML-Spezifikation kann das <legend>-Element Bedienelemente enthalten. Dies wird jedoch von den Assistenztechnologien teilweise nicht unterstützt, so dass empfohlen wird, im <legend>-Element lediglich die Beschriftung der Formularfeldgruppe in Textform aufzunehmen. Das <fieldset>-Element kann mit disabled als deaktiviert ausgezeichnet werden. Dies bewirkt, dass alle enthaltenen Formularelemente deaktiviert sind (mit Ausnahme von Formularelementen, die sich im <legend>-Element befinden).

Weitere Informationen: 4.10.15 The fieldset element - HTML Standard (whatwg.org), [4].10.16 The legend element - HTML Standard (whatwg.org)](https://html.spec.whatwg.org/multipage/form-elements.html#the-legend-element)

ARIA

Wird die Formularfeldgruppe nicht mit dem HTML-Element umgesetzt, sollte zusätzlich Folgendes beachtet werden:

• Die Rolle der Liste wird mit role=group bzw. role=radiogroup (nur bei Radiobuttons) übermittelt. Bei der Ausgabe durch die Screenreader erfolgt keine Unterscheidung zwischen group und radiogroup.

• Die Beschriftung der Gruppe kann per aria-label oder aria-labelledby erfolgen.

• Die ARIA-Rolle radiogroup kann (im Gegensatz zur Rolle group) mit den Attributen aria-readonly als schreibgeschützt, aria-required als Pflichtfeld und aria-invalid als fehlerhaft ausgezeichnet werden. Darüber hinaus kann mit aria-errormessage der ARIA-Radiobuttongruppe eine Fehlermeldung zugewiesen werden.

• Sowohl die ARIA-Rolle radiogroup als auch die ARIA-Rolle group können mit aria-disabled als deaktiviert ausgezeichnet werden. Dies bewirkt, dass alle enthaltenen Formularelemente von der Assistenztechnologie als deaktiviert ausgegeben werden (d. h. sie sollten auch tatsächlich deaktiviert sein).

Weitere Informationen: group role - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link), radiogroup role - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link)

Liste

Online betrachten

Synonyme: List

Siehe auch: Auswahlliste, Baumstruktur, Tabelle

Eine Liste dient der strukturierten Anzeige von Daten. Eine Liste enthält mehrere Listeneinträge. Listen können sortiert oder unsortiert sein. Listen können ineinander verschachtelt sein. Häufig besitzen Listen einen visuellen Indikator am Beginn jedes Listeneintrags, ein sogenanntes Aufzählungszeichen, z. B.

• einen Anstrich oder ein Icon für eine unsortierte Liste

• einen Buchstaben oder eine Zahl für eine sortierte Liste.

Listeneinträge können Bedienelemente enthalten.

Darstellung

Bedienung

Tastaturbedienung Liste (in einer Anwendung, die den virtuellen Cursor unterstützt)

Bei Anwendungen, die den virtuellen Cursor unterstützen, erhalten die Liste und deren Listeneinträge nicht den Tastaturfokus. Lediglich interaktive Elemente innerhalb der Listeneinträge sollen mit der Tastatur erreicht und bedient werden können.

Tastaturbedienung Liste (in einer Anwendung, die den virtuellen Cursor nicht unterstützt)

Bei Anwendungen, die den virtuellen Cursor nicht unterstützen, muss jeder Listeneintrag den Fokus erhalten können, damit deren Inhalte mit Assistenztechnologie (z. B. Screenreader) wahrnehmbar sind.

Hinweis: In den Programmiersprachen für Software gibt es häufig kein Element für Listen. Stattdessen werden für unverschachtelte Listen Auswahllisten und für verschachtelte Listen Baumstrukturen verwendet. In diesem Fall soll die Auswahlliste bzw. Baumstruktur in der Beschriftung oder Beschreibung einen Hinweis enthalten, dass sie nur der Darstellung von Inhalten und nicht der Auswahl dient.

Zeigeinstrumentbedienung Liste

Programmierung/Schnittstellen

Praxistipp Listen in Web-Anwendungen

Screenreader-Ausgabe von sortierten und unsortierten Listen

Mit dem virtuellen Cursor:

• JAWS:

  • Liste mit [Anzahl] Einträgen (Verschachtelung [Ebene])

  • [Aufzählungszeichen] [Listeneintrag]

  • Listenende (Verschachtelung [Ebene])

• NVDA:

  • Liste mit [Anzahl] Einträgen

  • [Aufzählungszeichen] [Listeneintrag]

  • außerhalb von Liste

• Windows Sprachausgabe:

  • Liste öffnen

  • [Position] von [Anzahl] Ebene [Ebene] [Aufzählungszeichen] [Listeneintrag]

  • Liste schließen

Hinweis: Die Windows-Sprachausgabe gibt aufgrund des impliziten bzw. expliziten aria-level bei jedem Listeneintrag fälschlicherweise „Überschriftenebene [Zahl]“ aus.

HTML

Unsortierte Listen werden mit <ul> und <li> ausgezeichnet. Für Bedienelemente, die sich in einer Liste befinden, kann anstelle von<ul> auch <menu> verwendet werden. Das <menu>-Element wird mit der Semantik des <ul>-Elements an die Accessibility API übermittelt.

Sortierte Listen werden mit <ol> und <li> ausgezeichnet. Bei sortierten Listen kann der Startwert mit start angegeben, die Richtung mit reversed geändert und der Typ des Aufzählungszeichens mit type festgelegt werden.
Verschachtelte Listen werden umgesetzt, indem eine Liste (<ol> oder <ul>) sich innerhalb eines <li>-Elements der übergeordneten Liste befindet.

Der Unterschied zwischen einer sortierten und unsortierten Liste, d. h. zwischen <ol> und <ul>, ist visuell und mit Assistenztechnologie nur anhand der Aufzählungszeichen zu erkennen. Somit sollten die Aufzählungszeichen mit dem Listentyp übereinstimmen.

Es sollten einfache Aufzählungszeichen wie disc für unsortierte Listen oder decimal bzw. lower-latin für sortierte Listen gewählt werden, um die korrekte Ausgabe zu gewährleisten und nicht unnötig zu verlängern. Die folgenden beispielhaften Werte der CSS-Eigenschaft list-style-type werden von den Screenreadern JAWS (erster Eintrag), NVDA (zweiter Eintrag, sofern abweichend) und der Windows Sprachausgabe (dritter Eintrag, sofern abweichend) wie folgt ausgegeben:

• none: [keine Ausgabe]

• disc: Aufzählungszeichen

• circle: rundes hohles Aufzählungszeichen / weißes Aufzählungszeichen / leeres Aufzählungszeichen

• square: schwarzes Quadrat / großes gefülltes schwarzes Quadrat / [keine Ausgabe]

• disclosure-open: schwarzes nach unten zeigendes kleines Dreieck / schwarzes nach unten weisendes kleines Dreieck / [keine Ausgabe]

• disclosure-closed: gefülltes kleines Dreieck nach rechts / schwarzes nach rechts weisendes kleines Dreieck / [keine Ausgabe]

• decimal: [Zahl]

• lower-roman: [Zahl; bei Zahlen, die aus einem Buchstaben bestehen, nur der Buchstabe; bei Zahlen, die aus vielen Buchstaben bestehen, die Buchstaben einzeln oder als Wort] / [Zahl; bei Zahlen, die aus vielen Buchstaben bestehen, die einzelnen Buchstaben] / [Zahl; bei Zahlen, die aus vielen Buchstaben bestehen, die Buchstaben als Wort]

• lower-latin: [Buchstabe]

• lower-greek: [Buchstabe mit Zusatz „griechischer Kleinbuchstabe“] / [keine Ausgabe] / [keine Ausgabe]

• georgian: [keine Ausgabe]

Listenzeichen mit list-style-image werden von JAWS und NVDA nicht und von der Windows Sprachausgabe als „Bild“ (ohne Alternativtext) ausgegeben.

Weitere Informationen: 4.4.5 The ol element - HTML Standard (whatwg.org) (Externer Link), 4.4.6 The ul element - HTML Standard (whatwg.org) (Externer Link), 4.4.7 The menu element - HTML Standard (whatwg.org) (Externer Link), 4.4.8 The li element - HTML Standard (whatwg.org) (Externer Link)

ARIA

Wird die Liste nicht mit dem HTML-Element umgesetzt, sollte u. a. Folgendes beachtet werden:

• Die Rolle der Liste wird mit role=list übermittelt.

• Die Rolle der Listeneinträge wird mit role=listitem übermittelt.

• Verschachtelte Listen können gemäß ARIA-Spezifikation mit aria-level umgesetzt werden. Dies wird allerdings nur von der Windows Sprachausgabe korrekt ausgegeben. Damit die Ausgabe von verschachtelten Listen auch durch JAWS und NVDA korrekt erfolgen kann, sollten verschachtelte Listen im Quellcode korrekt verschachtelt werden (Beispiel: <div role=list><div role=listitem>Eintrag 1<div role=list><div role=listitem>Eintrag 1.1 …).

Weitere Informationen: list role - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org) (Externer Link)

Tabelle

Online betrachten

Synonyme: Table

Siehe auch: Liste, Hierarchische Tabelle

Eine Tabelle dient der strukturierten Anzeige von Daten (siehe DIN EN ISO 9241-161: 8.44).

Eine Tabelle besteht aus Zellen, die in Spalten und Zeilen angeordnet sind. Meist befinden sich in der ersten Zeile die Spaltenüberschriften und häufig in der ersten Spalte die Zeilenüberschriften. Darüber hinaus können Tabellen verschiedene Funktionalitäten enthalten, z. B.

• Sortieren und Filtern der Zellinhalte (z. B. über die Spaltenüberschriften),

• Skalieren der Spalten- und Zeilengröße,

• Ein- und Ausblenden von Spalten bzw. Änderung der Reihenfolge der Spalten,

• Ein- und Ausblenden untergeordneter Tabellenzeilen (siehe: Hierarchische Tabelle),

• Anzeige von Summenzeilen am Tabellenende,

• Inline-Bearbeiten der Zellinhalte (im Folgenden als Bearbeitungsmodus bezeichnet),

• externes Bearbeiten der Zellinhalte, z. B. über eine Werkzeugleiste oberhalb der Tabelle oder Schalter innerhalb der Tabellenzellen,

• Auswählen von Tabellenzeilen, z. B. per Checkboxen (Mehrfach-Auswahl) oder Radiobutton (Einfach-Auswahl),

• Auswählen von Tabellenzellen, z. B. per Markieren mit der Maus oder Tastatur,

• Blättern oder Scrollen durch die Datensätze, ggf. mit einer Paginierung.

Die Anforderungen an die einzelnen Bedienelemente innerhalb der Tabelle werden beim jeweiligen Bedienelement beschrieben. Hier werden nur zusätzliche Anforderungen für das gesamte Element beschrieben.

Darstellung

Bedienung

Tastaturbedienung Tabelle (in einer Anwendung, die den virtuellen Cursor unterstützt)

Bei Anwendungen, die den virtuellen Cursor unterstützen, erhalten die Tabellen und deren Zellen nicht den Tastaturfokus. Lediglich interaktive Elemente innerhalb der Tabellenzellen sollen mit der Tastatur erreicht und bedient werden können. Dies gilt nur, sofern die Tabelle nicht mit role=grid ausgezeichnet ist. Tabellen mit role=grid werden wie Tabellen in Anwendungen ohne virtuellen Cursor bedient (siehe folgenden Abschnitt).

Tastaturbedienung Tabelle (in einer Anwendung, die den virtuellen Cursor nicht unterstützt)

Bei Anwendungen, die den virtuellen Cursor nicht unterstützen, sowie bei Tabellen, die mit role=grid ausgezeichnet wurden, muss jede Tabellenzelle den Fokus erhalten können, damit deren Inhalte mit Assistenztechnologie (z. B. Screenreader) wahrnehmbar sind. Es ist nicht ausreichend, wenn z. B. nur zeilenweise durch die Tabelle navigiert werden kann. Bei Tabellen in Anwendungen, die den virtuellen Cursor nicht unterstützen, wird zwischen dem Navigations- und Bearbeitungsmodus unterschieden:

• In Navigationsmodus kann mit den Pfeiltasten zwischen den Zellen navigiert werden.

• Im Bearbeitungsmodus können die interaktiven Elemente innerhalb einer Zelle bedient werden. Sofern die Zelle mehrere interaktiven Elemente enthält, so kann im Bearbeitungsmodus zwischen den Elementen navigiert werden.

Tabelle 1: Zeigeinstrumentbedienung Tabelle

Programmierung/Schnittstellen