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 in die Lage versetzt werden, all das, was optisch voneinander unterscheidbar ist, auch über die Accessibility API der jeweiligen Plattform als unterscheidbar auszugeben. Das betrifft die folgenden Elemtent-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 z.B. das Tool 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 bei den Property-Werten schaut, ob „Name“ die richtige Bezeichnung hat. Man kann aber auch den Bereich im Accessibility Tree suchen (linke Seite von Accessibility Insights, der gerade ausgewählte Bereich wird in der Anwendung deutlich markiert) und dann 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.
  • 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.
  • 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.
  • Formular-Elemente besitzen in der Regel eine Beschriftung. Wenn keine Beschriftung vorhanden ist, ist das meist problematisch. 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, die dann z.B. vom Screenreader in verständliche Informationen für blinde Menschen verarbeitet werden. Wird also 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. entsprechen 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.

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.
  • Ein Formular mit Pflichtfeldern: Die Beschriftungen für die Pflichtfelder werden in rot und am Ende eines jeden Labels ist ein Sternchen *. Die Anweisungen zum Ausfüllen geben an, dass „alle Pflichtfelder rot und mit einem Sternchen * gekennzeichnet sind“, gefolgt von einem Beispiel.
  • Ein Formular mit Pflicht- und optionalen Feldern, das Farbe und Text verwendet, um die erforderlichen Felder anzugeben: In den Anweisungen am Anfang des Formulars wird erläutert, dass die Pflichtfelder mit rotem Text und einem Symbol gekennzeichnet sind, dessen Textalternative aber „Pflichtfeld“ lautet. Sowohl der rote Text als auch das Symbol sind programmatisch ermittelbar und mit den Formularfeldern verknüpft, so dass Benutzerinnen und Benutzer mit assistiven Systemen die Pflicht-Felder ermitteln können.
  • 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.
  • Überschriften sollten nicht missbräuchlich eingesetzt werden, zum Beispiel um unterschiedliche Schriftgrößen darzustellen
  • 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. Beispiel für Webanwendungen:
    • 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 wird nur CSS 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)

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 in der visuellen Darstellung übermittelt werden.

Warum wird das geprüft

Benutzer mit unterschiedlichen Behinderungen können die Darstellung der Inhalte an die eigenen Bedürfnisse anpassen. Benutzer mit einer Sehbeeinträchtigung profitieren davon, wenn z.B. Informationen über sensorische Merkmale auch im Text verfügbar sind.

Verweise (Referenzen)