Der Prüfschritt ist immer anwendbar.

Wie wird geprüft

In diesem Prüfschritt geht es darum, dass Benutzeroberflächen-Elemente, die eine bestimmte Charakteristik haben, diese auch auf einer semantischen Ebene besitzen, so dass Hilfsmitteltechnologien wie z.B. Screenreader sie auch erkennen können. Was optisch voneinander unterscheidbar ist, Sollte auch für Hilfsmittel voneinander unterscheidbar sein. Das betrifft die folgenden Element-Typen und Bereiche:

  • Überschriften
  • Listen
  • Absätze und Zeilenumbrüche
  • einfache Tabellen
  • zusammenhängende Gruppen von Formularelementen
  • optisch voneinander unterscheidbare Bereiche der Benutzeroberfläche
  • Hervorhebungen in Texten
  • Komplexe Tabellen
  • die Beziehung zwischen Beschriftungen (Labels) und den dazu gehörenden Formularfeldern

Bei webbasierten Anwendungen kann dies z.B. durch geeignete Browser-Erweiterungen oder Bookmarklets (z.B. die JavaScript Bookmarklets for Accessibility Testing von Paul J. Adam) geprüft werden. Bei Anwendungssoftware kann hierfür mit dem Screenreader geprüft werden. Im Zweifel können auch Tools wie z.B. inspect.exe oder Accessibility Insights for Windows verwendet werden.

  • Als Überschriften erkennbare Elemente sollten entsprechend ausgezeichnet sein (HTML: H1, H2, H3, …). Sofern dies in Anwendungssoftware nicht möglich ist, sollten sie für die Accessibility API als übergeordnetes Element, z.B. als Titel eines Bereichs erkennbar sein. Dies kann z.B. mit inspect.exe oder mit Accessibility Insights getestet werden, indem man den entsprechenden Bereich mit der Maus auswählt und dann die Property-Werten überprüft, ob „Name“ die richtige Bezeichnung hat. Alternativ kann man den Bereich im Accessibility Tree suchen (linke Seite von Accessibility Insights, der gerade ausgewählte Bereich wird in der Anwendung deutlich markiert) und prüfen, ob der Property Wert für „Name“ korrekt ist. Zusätzlich kann auch mit dem Screenreader geprüft werden, ob Überschriften oder Bereichsnamen (sofern sie wie Überschriften aussehen) korrekt ausgegeben werden.
  • Die Prüfung von Listen in webbasierten Anwendungen kann mit dem entsprechenden Bookmarklet erfolgen. In Anwendungssoftware ist die häufigste Erscheinungsform von Listen ein Strukturbaum. Dieser sollte bezüglich Bezeichnungen, Typ (Rolle) und Hierarchieebene im Accessibility Tree identifiziert werden können. Zusätzlich kann auch geprüft werden, ob Screenreader alle notwendigen Informationen korrekt ausgeben.
  • Bei Absätzen ist darauf zu achten, ob es leere Absätze gibt. Das sollte vermieden werden. Da Absätze in der Regel nur in webbasierten Anwendungen zu finden sind, kann hier z.B. mit dem Bookmarklet „Inhalte gegliedert“ des Projekts BIK gearbeitet werden (https://testen.bitv-test.de/bookmarklets.html#gegliedert).
  • Bei einfachen Tabellen ist in webbasierten Anwendungen darauf zu achten, dass Überschriften-Zellen mit TH und Daten-Zellen mit TD ausgezeichnet sind. Dabei ist es gleichgültig, ob es sich um Zeilen- oder Spalten-Überschriften handelt. In Anwendungen werden Tabellen oft mit „Data Grid“ angekündigt. Am leichtesten lassen sich Tabellen mit Screenreadern unter Windows testen. Bei webbasierten Anwendungen nutzt man die Tastenkombination STRG+ALT+Pfeiltasten, um zu einzelnen Zellen zu navigieren. Für alle Anwendungen gilt dabei grundsätzlich: es muss immer möglich sein, zu erfahren, wo genau man sich in einer Tabelle befindet und wie die dazu gehörende Spalten- oder Zeilen-Überschrift lautet. Die Navigationsmechanismen können dabei von einfacher Navigation mit den Pfeiltasten bis hin zu anwendungsspezifischen Tastenkombinationen reichen.
  • Bei komplexen Tabellen, also z.B. Tabellen mit mehreren Überschriften-Zeilen, wobei die oberste Überschriften-Zeile jeweils zwei oder mehr Spalten breit ist, muss es möglich sein, dass von jeder Daten-Zelle ein Bezug hergestellt werden kann zu der untergeordneten und der übergeordneten Überschrift (also Zeile zwei und Zeile eins). Bei Webanwendungen kann dies mit den Attributen „HEADERS“ für die Datenzellen und „ID“ für die Überschriften-Zellen realisiert werden, wobei das HEADERS-Attribut alle Werte der IDs der zugeordneten Überschriften enthält. Außerdem kann mit dem Attribut SCOPE gearbeitet werden. Für Tabellen in Anwendungssoftware bräuchte es einen vergleichbaren Mechanismus, damit die Bezüge zwischen Daten- und Überschriften-Zellen eindeutig hergestellt sind und z.B. von Hilfsmitteln auch entsprechend ausgegeben werden. Empfehlenswert ist es aber nicht, mit solchen Konstrukten zu arbeiten. Vielmehr sollte der Fokus auf Übersichtlichkeit und Klarheit gelegt werden. Die Prüfung kann entweder mit dem Screenreader oder mit Tools wie Accessibility Insights oder inspect.exe erfolgen, wobei hier darauf zu achten ist, dass die Position in der Tabelle sowie der Bezug zur Überschrift meist der Wert der Property „Name“ ist, während der Inhalt der Zelle in der Property „Value“ steht.
  • Gruppen von Formularfeldern besitzen in der Regel eine Überschrift. Diese muss so in die Anwendung eingebaut sein, dass sie programmatisch nachvollzogen werden kann, also aus den Property-Werten jedes einzelnen Formularfelds herausgelesen werden kann. Bei Webanwendungen empfiehlt sich dafür die Verwendung von FIELDSET.
  • Bereiche oder Blöcke einer Anwendung, die optisch klar voneinander unterscheidbar sind, benötigen ebenfalls eine semantische Entsprechung. Das kann webbasiert mittels Überschriften oder Document Landmarks geschehen oder in Anwendungen zum Beispiel über einen geeigneten Aufbau des Accessibilty Trees, der es dann erlaubt, das Anspringen der entsprechenden Knotenpunkte mit geeigneten Tastaturkommandos zu versehen.
  • Wenn Wörter oder Abschnitte hervorgehoben darstellt werden, benötigt dies ebenfalls eine z.B. mit dem Screenreader nachvollziehbare Entsprechung. Dies geschieht im Web z.B. mit STRONG oder EM, während die als abgekündigt geltenden Tags I für kursiv, B für fett und U für unterstrichen schon lange nicht mehr verwendet werden sollen, weil dies dem Anspruch der Trennung von Inhalt und Layout widerspräche. In Anwendungen kommt dies in der Regel eher in Rich Text Editoren oder in Dokumenten-Betrachtern zum Tragen.
  • Formular-Elemente besitzen in der Regel eine Beschriftung. Zwischen der Beschriftung und dem Formularfeld muss ein eindeutiger Bezug bestehen, so dass die entsprechenden Informationen an die Accessibility API weiter gereicht werden können und von assistiven Technologien erkannt werden kann. Wird also z.B. vom Screenreader bei Fokussierung eines Formularfelds nicht das Label oder ein falsches Label ausgegeben, so kann davon ausgegangen werden, dass hier eine Barriere vorliegt. Bei der Prüfung ohne Screenreader ist hier auf die Properties „Name“ (Beschriftung, Label), „Value“ (Wert, Inhalt des Formularfelds) und z.B. „ControlType“ oder „LocalizedControlType“ (Rolle) zu achten. Ein Eingabefeld besitzt z.B. in der Regel den LocalizedControlType „Bearbeiten“, was korrekt ist, da es sich hier um ein reines Textfeld handelt. Checkboxen heißen z.B. CheckBoxControlType oder in lokalisierter Form „Kontrollkästchen“. Hier ist der Status wichtig, der z.B. über die Property „ToggleState“ (kann den Wert On oder Off annehmen) an augelesen werden kann.
    Praxistipp: Sofern bei Klick auf die Beschriftung der Fokus in das dazu gehörende Formularfeld versetzt wird, kann von einer programmatisch nachvollziehbaren Beziehung zwischen Beschriftung und Formularfeld ausgegangen werden. Die Korrektheit dieser Vermutung sollte aber immer auch mit dem Screenreader überprüft werden.

Beispiele

  • Überschriften sind semantisch und hierarchisch korrekt ausgezeichnet, was daran erkannt werden kann, dass Screenreader „Überschrift“ und Grad (z.B. Überschrift Ebene 2) ausgeben. Bei Anwendungssoftware sind es eher die Bereiche, die mit Überschriften versehen sind. Hier geben Screenreader in der Regel nicht „Überschrift“ aus.
  • Überschriften sollten nicht missbräuchlich eingesetzt werden, zum Beispiel um unterschiedliche Schriftgrößen darzustellen.
  • Eine Tabelle für den Busfahrplan wird so verwendet, dass der Header für jede Zelle programmatisch ermittelbar ist: Bushaltestelle in der ersten Spalte vertikal, Busse in der ersten Zeile horizontal, die Zellen enthalten die Zeit. Somit werden Haltestellen und Busse als Überschriften vorgelesen. Assistive Systeme können so ermitteln, welcher Bus und welche Bushaltestelle zu der entsprechenden Zeit zugeordnet sind.
  • Absätze werden korrekt verwendet, es werden keine „einfachen Zeilenumbrüche“ <br /> (line) breaks oder SHIFT + ENTER bzw. STRG + ENTER in Anwendungen für Absätze bzw. doppelte Zeilenumbrüche zur Unterteilung genutzt.
  • Listen sind semantisch korrekt ausgezeichnet.
    In Nicht-Web-Anwendungen identifiziert der Screenreader dann den Control-Typ ListItem, der über unterschiedliche Property-Werte näher spezifiziert werden muss (klickbar, Verschachtelungstiefe, etc.). Zum besseren Verständnis können hier auch Beispiele aus Webanwendungen betrachtet werden:
    • Ungeordnete Liste von Elementen, zum Beispiel <ul><li>: Eine ungeordnete Liste zählt verschiedene, nicht sortierbare Dinge auf, wie eine Einkaufsliste.
    • Geordnete Liste von Elementen, zum Beispiel <ul><ol> wird dann genutzt, um die Einkaufsliste alphabetisch zu sortieren.
    • Definitionsliste, zum Beispiel <dl><dt>: Eine Definitionsliste wird verwendet, um eine Definition von Begriffspaaren zu gruppieren, wie Kontaktdaten.
    • Ungeordnete Listen <ul><li> um Links in Menüs zu gruppieren.
  • Zur Abstandsgenerierung werden keine leeren Absätze verwendet.
  • Listen werden bspw. auch für Suchergebnisse verwendet: Der Nutzer mit einem assistiven System kann besser durch die Ergebnisse navigieren (u.a. durch Position, Anzahl der Elemente/Ergebnisse).
  • In einem Formular sind die Beschriftungen alle programmatisch korrekt mit den Eingabefeldern verknüpft. Die Beschriftung wird bei Erreichen des Eingabefeldes vom Screenreader ausgegeben. Bei Klick auf die Beschriftung wird der Fokus meistens auf das Formularelement versetzt.

Anforderung (Beschreibung)

Software webbasiert oder Software mit offener Funktionalität

Strukturen und Beziehungen der Inhalte einer Anwendung werden über geeignete Elemente visualisiert. Diese sind programmatisch verfügbar, wichtige Informationen sind im Kontext für alle Benutzer wahrnehmbar. Absätze werden über eine Leerzeile getrennt, nicht über doppelte (line) breaks. Überschriften unterstützen den Benutzer bei der Identifizierung von Zugehörigkeiten, helfen beim Navigieren und Orientieren und vielem mehr durch die Anwendung.

Anmerkung: In Software wird die programmatische Bestimmbarkeit durch „Accessibility Schnittstellen“ zur Verfügung gestellt. Diese Schnittstellen werden von der Plattformsoftware bereitgestellt, um die Interoperabilität zwischen Software und unterstützenden Technologien zu ermöglichen.

Nicht-Web-Software mit geschlossener Funktionalität

Stellt eine Nicht-Web-Sofware Informationen auf einer Benutzeroberfläche zur Verfügung, die nicht für assistive Systeme wie Screenreader zugänglich ist, sollen auditive Informationen bereitgestellt werden. Sie ermöglichen dem Benutzer eine Zuordnung der Informationen per Audioausgabe.

Viele Menschen, die offiziell als blind gelten, verfügen noch über ein gewisses Maß an Sehkraft und nutzen einige Aspekte der visuellen Anzeige. Eine Audioalternative, die sowohl vollständig als auch ergänzend ist, umfasst alle visuellen Informationen wie Fokus oder Hervorhebung. Die Audioausgabe soll jederzeit den sichtbaren Informationen auf dem Bildschirm zugeordnet werden können. Sie schließt zudem Aussagen über die Struktur und Beziehungen ein, die durch die visuelle Darstellung übermittelt werden.

Warum wird das geprüft

Benutzeroberflächen-Elemente, die eine bestimmte Charakteristik haben, sollten diese auch auf einer semantischen Ebene besitzen. Hilfsmitteltechnologien können dadurch all das, was optisch voneinander unterscheidbar ist, auch über die Accessibility API der jeweiligen Plattform als unterscheidbar ausgeben. Dies ist notwendig, damit auch Benutzerinnen und Benutzer von z.B. Screenreadern den Aufbau der Anwendung und die Darstellung der Inhalte wahrnehmen können.

Verweise (Referenzen)

  • EN 301549 v3.1.1 Kap. 11.1.3.1 Info and relationships
  • WCAG v2.1 Kap. 1.3.1 Info and relationships