Im Rahmen der Anpassung des Testverfahrens an die Web Content Accessibility Guidelines (WCAG) 2.1, sowie die geänderte EN 301 549 und Barrierefreie-Informationstechnik-Verordnung (BITV) haben sich die folgenden Änderungen ergeben. Neben den dargestellten Änderungen der Prüfschritte wurde auch die Werkzeugliste überarbeitet.
Überarbeitung von Prüfschritten im Jahr 2019
Prüfschritt, der komplett entfällt
Der Prüfschritt "2.4.8a Position im Webauftritt klar" ist komplett entfallen, da er in den WCAG 2.1 auf Konformitätsstufe AAA steht (2.4.8 Location).
Neue Prüfschritte
1.3.4a Keine Beschränkung der Bildschirmausrichtung
Webinhalte sollten sich an die nutzergewählte Ausrichtung von Ausgabegeräten anpassen. Sie sollten sowohl im Hochformat als auch im Querformat dargestellt werden und nutzbar sein, es sei denn, eine bestimmte Ausrichtung des Inhalts ist unerlässlich.
Für Menschen mit Behinderung ist es oft besonders wichtig, ein Ausgabegerät (z.B. ein Smartphone) in einer bestimmten Ausrichtung nutzen können. Wenn beispielsweise Text stark vergrößert wird, bietet die Verwendung des Querformats oft ein besseres Leseerlebnis, da mehr Wörter in eine Zeile passen.
Außerdem haben einige Benutzer ihre Geräte in einer festen Ausrichtung montiert (z.B. am Arm eines Elektrorollstuhls). Daher sollten Websites und Anwendungen die Darstellung von Inhalten nicht auf eine Ausrichtung einschränken.
1.3.5a Eingabefelder zu Nutzerdaten vermitteln den Zweck
Eingabefelder, die sich auf den Nutzer selbst beziehen, sollten eine semantisch eindeutige, sprachunabhängige Bestimmung ihres Zweckes ermöglichen. Geeignet dafür ist derzeit das HTML autocomplete-Attribut, mit dem sich der Eingabezweck für Felder wie etwa Name, E-Mail oder Telefonnummer ebenso wie für Adress-Daten oder Kreditkarten-Daten definieren lässt.
Es wird erwartet, dass andere Taxonomien zur Festlegung des Zwecks von Interface-Komponenten entwickelt werden, welche die Verwendung von autocomplete ersetzen können.
Die Festlegung des Eingabezwecks erlaubt es neuartigen Hilfsmitteln, bei Formularfeldern, welche sich auf Daten des Nutzers beziehen, zusätzliche Informationen anzuzeigen, und zwar unabhängig vom der jeweils gewählten Beschriftung des Feldes und unabhängig von der natürlichen Sprache des Angebots.
Zusätzliche Informationen können etwa Bilder bzw. Icons sein, die über ein Browser-Plugin oder eine externe assistive Technologie bereitgestellt werden und über bzw. vor dem jeweiligen Eingabefeld angezeigt werden, etwa wenn Nutzer eine bestimmte Tastenkombination drücken. Für Menschen, die Schwierigkeiten mit dem Lesen haben oder bevorzugt über Bilder kommunizieren, erleichtert dies eine Identifizierung von nutzerbezogenen Feldern in Formularen.
Darüber hinaus bietet autocomplete Eingabevorschläge für das Feld, welche Nutzer einfach übernehmen können. Das erleichtert die Texteingabe.
1.4.10a Inhalte brechen um
Seiten-Inhalte sollen bei einer Browserfensterbreite von 320 CSS-Pixeln (bzw. bei einer Browserfensterbreite von 1280 CSS-Pixeln und 400% Zoomvergrößerung) so umbrechen, dass alle Informationen und Funktionen verfügbar sind, ohne dass Nutzer horizontal scrollen müssen. (Ausnahmen gelten für Inhalte, für deren Nutzung ein zweidimensionales Layout erforderlich ist, z.B. Bilder, Landkarten, Diagramme, Videos, Spiele, Präsentationen, Datentabellen und Anwendungs-Schnittstellen, in denen die Bearbeitung von Inhalten die permanente Verfügbarkeit von Werkzeugleisten erfordert.)
Sehbehinderte Nutzer vergrößern häufig Seiten-Inhalte über die Zoomfunktion des Browsers. Über eine responsive Gestaltung mittels CSS media queries sollen Web-Seiten die Nutzung mit starkem Zoom durch eine dynamische Anpassung des Seiten-Umbruchs daher unterstützen.
Der Vorteil: Nutzer müssen beim Lesen nur in eine Richtung scrollen. Wenn Zeilen bei Zoomvergrößerung nicht umgebrochen werden, sind Nutzer dagegen gezwungen, beim Lesen jeder Zeile horizontal hin- und her zu scrollen, was die Aufnahme der Inhalte sehr stark beeinträchtigt und verlangsamt.
1.4.11a Kontraste von Grafiken und Bedienelementen ausreichend
Grafische Interface-Elemente und deren Zustände sowie informationstragenden Grafiken sollten einen Kontrast zu angrenzenden Farben von 3:1 oder besser haben.
Viele Menschen mit Sehbehinderungen brauchen gute Kontraste, um Interface-Elemente bzw. deren Zustände oder Elemente in informationstragenden Grafiken, z.B. statistischen Diagrammen oder Schaubildern, wahrnehmen zu können. Die Forderung nach einem Minimalkontrast für informationstragende Grafiken hilft diesen Menschen.
1.4.12a Textabstände anpassbar
Zeilen- Absatz- Wort- und Buchstaben-Abstände sollten sich von Nutzern auf folgende Werte einstellen lassen, ohne dass Inhalte oder Funktionalitäten nicht mehr verfügbar sind:
- Zeilen: 1,5-fache Textgröße
- Abstände nach Absätzen: 2-fache Textgröße
- Buchstabenabstände: 0,12-fache Textgröße
- Wortabstände: 0,16-fache Textgröße.
Ein Verlust an Inhalten oder Funktionalitäten könnte sich zum Beispiel dadurch zeigen, dass Inhalte in Elementen, deren Größe sich bei Einstellung größerer Textabstände und dadurch erfolgender Textspreizungen oder Umbrüche nicht dynamisch anpasst, abgeschnitten werden.
Die Anforderung verlangt nicht von Autoren, die genannten Werte bei Ihren Inhalten umzusetzen, sondern lediglich, dass von Nutzern vorgenommene Anpassungen nicht zum Abschneiden von Text oder Verlust von Funktionalitäten führt.
Menschen mit Sehbehinderungen können die Lesbarkeit von Texten verbessern, wenn sie über Werkzeuge wie Bookmarklets oder über eigene Stylesheets die Abstände zwische Zeilen, Absätzen, Zeichen und Worten anpassen können. Solche Anpassungen führen dazu, das Texte ggf. mehr Platz brauchen und Container dementsprechend dynamisch angelegt sein müssen, um den längeren Text ohne Verlust zu zeigen.
1.4.13a Eingeblendete Inhalte bedienbar
Zusätzliche Inhalte, die angezeigt werden, wenn Elemente den Zeiger- oder Tastaturfokus erhalten, z.B. benutzerdefinierte Tooltips oder Ausklapp-Menüs, sollten drei Anforderungen erfüllen:
- Wenn zusätzliche Inhalte durch Darüberfahren mit dem Zeiger erscheinen, können Benutzer den Zeiger über diesen Inhalt bewegen, ohne dass er verschwindet.
- Es gibt die Möglichkeit, einen eingeblendeten Inhalt zu schließen, ohne den Fokus zu verschieben (z.B. durch Drücken der Escape-Taste oder durch Aktivieren des Elements, dessen Fokussierung den Inhalt einblendet).
- Der Inhalt schließt nicht selbsttätig nach einer gewissen Zeitspanne.
Hinweis: Die Anforderung gilt nicht für eingeblendete Inhalte, deren Verhalten durch den Nutzer-Agenten bestimmt wird (etwa native title-Attribute).
Für sehbehinderte Nutzer, die mit starker Zoomvergrößerung arbeiten, sind zusätzliche Inhalte, die bei Zeiger- oder Tastatur-Fokussierung eingeblendet werden, aus mehreren Gründen problematisch: Die eingeblendeten Inhalte sind wegen des starken Zoomfaktors oft nur teilweise sichtbar. Nutzer müssen in der Lage sein, den Zeiger von dem auslösenden Element über den eingeblendeten Inhalt zu bewegen (was meist den sichtbaren Ausschnitt verschiebt), ohne dass der eingeblendete Inhalt schließt. Außerdem verdecken die eingeblendeten Inhalte häufig andere Inhalte. Es sollte daher auch möglich sein, den eingeblendeten Inhalt wieder zu schließen, ohne den Fokus zu bewegen. Sehbehinderte Nutzer brauchen ggf. mehr Zeit, Inhalte zu lesen. Erst wenn sie vom Nutzer geschlossen werden, beispielsweise mit der Tastatur oder durch Weiter-Tabben, sollten sie nicht mehr zur Verfügung stehen.
2.1.4a Tastatur-Kurzbefehle abschaltbar oder anpassbar
Wenn Webseiten Tastaturkurzbefehle über Einzeltasten (Buchstaben, Zahlen, Satzzeichen oder Symbole) implementieren, sollten diese entweder abgeschaltet oder auf eine Tastenkombination mit Modifikator-Tasten umgestellt werden können, oder sie sind nur aktiv, wenn bestimmte Interface-Elemente den Fokus haben.
Tastaturkurzbefehle sind für Menschen, die am Computer oder einem mobilen Gerät die Spracheingabe benutzen, häufig problematisch. Spracheingaben können unerwartet Befehle für Funktionen auslösen, der Nutzungskontext geht dadurch verloren.
2.5.1a Alternativen für komplexe Zeiger-Gesten
Wenn Webinhalte Funktionen implementieren, die über pfadbasierte Zeiger-Gesten (z. B. Streich- und Ziehgesten) oder über Mehrpunktgesten bedient werden können, sollte es Alternativen für die Aktivierung mittels einer einfachen Zeigereingabe geben. 'Zeiger' schließt dabei indirekte Eingaben mittels Mauszeiger ebenso wie direkte Eingaben ein, etwa mit dem Finger auf dem Touchscreen oder mit dem Stift auf einem Grafiktablett. Ausgenommen sind Fälle, in denen die pfadbasierte oder Mehrpunkt-Eingabe essenziell wichtig ist - etwa bei der Handschrifterkennung.
Für Menschen mit Bewegungseinschränkungen ist es oft schwierig und teilweise unmöglich, komplexe Zeiger-Gesten erfolgreich auszuführen. Deshalb sollen solche Gesten, wenn Sie von Web-Inhalten implementiert werden, nicht der einzige Weg sein, eine Funktion auszuführen. Beispiele für komplexe Gesten sind Streichgesten vom Rand her, um Menüs einzublenden, Wischgesten zum Bewegen von Karussell-Inhalten, Zieh-Gesten zum Verstellen von Schiebereglern, oder Mehrpunktgesten wie die Spreizgeste zum Vergrößern eines Kartenausschnitts.
2.5.2a Zeigergesten können abgebrochen oder widerrufen werden
Funktionen von Interface-Komponenten sollen nicht bereits durch den Down-Event eines Zeigers (z.B. Mauszeiger, Trackpad-Zeiger, Finger oder Eingabestift) über einem Bedienelement ausgeführt werden; falls doch, muss es eine Möglichkeit geben, die ausgelöste Funktion entweder abzubrechen oder rückgängig zu machen.
Eine Ausnahme für diese Anforderung besteht, wenn das Auslösen der Funktion durch das Down-Ereignis essenziell ist (etwa beim Zeichnen mittels Maus, Eingabestift oder Finger auf einem Touchscreen oder Grafiktablett, oder beim Interagieren mit einer virtuellen Tastatur).
Menschen mit motorischen Beeinträchtigungen haben häufig Schwierigkeiten, Zeiger-Gesten auf Schnittstellen-Elementen zielgerichtet auszuführen. Die Ausführung beim Up-Event (etwa wenn die Maustaste losgelassen wird oder der Finger vom Touchscreen abgehoben wird) gibt diesen Menschen die Möglichkeit, Fehleingaben zu vermeiden, da es sie befähigt, vor Auslösen des Up-Events den Zeiger vom Interface-Element wegzubewegen. Wenn Down-Events bereits Funktionen auslösen, besteht diese Korrekturmöglichkeit nicht.
In Fällen, wo eine Zeiger-Eingabe mehrstufig ist, etwa bei Drag-and-Drop Aktionen, ist es wichtig, dass es einen Weg gibt, versehentlich ausgeführte Eingaben rückgängig zu machen. Dies kann auf verschiedene Weise geschehen, etwa über einen Bestätigungsdialog, durch das Loslassen des Elements über dem Ausgangsort, oder durch das Loslassen des Elements über einem Ort, der nicht als Drop Target definiert ist und das Element zum Ausgangspunkt zurückspringen lässt.
2.5.3a Sichtbare Beschriftung Teil des zugänglichen Namens
Sichtbare Beschriftungen von Bedienelementen sollen im zugänglichen Name des Bedienelements (also dem Text, der programmatisch als Beschriftung ermittelt wird) vorkommen. Dies betrifft zum Beispiel Links, Beschriftungen von Textfeldern, Buttons, oder Checkboxen.
Spracheingabenutzer können Bedienelemente wie Links, Tasten oder Eingabefelder aktivieren, indem sie den sichtbaren Namen sagen, auch in der Verbindung mit Befehlen (z.B. Klick "Abschicken"). Wenn die sichtbare Beschriftung nicht in dem hinterlegten zugänglichen Namen des Bedienelements (also dem Text, der programmatisch als Beschriftung ermittelt wird) vorkommt, lässt sich das Bedienelement gegebenenfalls nicht oder nur über Umwege mittels Spracheingabe aktivieren.
Bedienelemente haben manchmal einen zugänglichen Namen, der von der sichtbaren Beschriftung abweicht, weil er über nicht sichtbare Attribute wie aria-label oder über nur bei Mausnutzung eingeblendete Attribute wie title festgelegt wird. So könnte etwa die sichtbare Beschriftung "AGB akzeptieren" durch den hinterlegten zugänglichen Namen "Allgemeine Geschäftsbedingungen annehmen" ersetzt werden. Wenn Spracheingabenutzer nun Klicke "AGB akzeptieren" diktieren, kommt dieser Text so nicht im zugänglichen Namen vor, die Eingabe schlägt deshalb fehl.
Manchmal wird versteckter Text benutzt, um sichtbare Beschriftungen zu erweitern, oft auch in der Absicht, Hilfsmittelnutzern zu helfen. Das ist dann in Ordnung, wenn die sichtbare Beschriftung durchgehend in dem zugänglichen Namen enthalten ist, am besten zu Beginn.
2.5.4a Alternativen für Bewegungsaktivierung
Wenn Webinhalte auf die Bewegung eines mobilen Gerätes reagieren oder wenn Bewegungen des Benutzers von Gerätesensoren oder der Kamera erfasst werden, um Funktionen auszulösen, sollten hierfür alternative Eingabemöglichkeiten vorhanden sein, und die Bewegungseingabe soll vom Nutzer abgeschaltet werden können (außer wenn die Bewegung Teil einer Hilfsmitteleingabe oder für die Funktion unerlässlich ist).
Menschen mit motorischen Einschränkungen können Bewegungseingaben oft nicht, oder nicht gezielt, ausführen. In manchen Fällen sind Geräte fest montiert, zum Beispiel an einem Rollstuhl, was Bewegungseingaben unmöglich macht. Deshalb ist es wichtig, dass es auch andere Möglichkeiten der Eingabe über Bedienelemente des Webinhaltes gibt.
Bei anderen motorischen Einschränkungen kann es durch unwillkürliche Bewegungen zu ungewollten Eingaben kommen. Deshalb ist es wichtig, dass sich von Webinhalten bereitgestellte motorische Eingaben deaktivieren lassen.
4.1.3a Statusmeldungen programmatisch verfügbar
Wenn Webanwendungen Statusmeldungen erzeugen, etwa wenn ein Produkt in einen digitalen Warenkorb gelegt wurde, ein Formular beim Abschicken eine Fehlermeldung oder eine Bestätigungsmeldung erzeugt, sollen visuell eingeblendete Statusmeldungen über geeignete Rollen oder Eigenschaften ausgezeichnet werden und damit programmatisch, also auch für nicht-visuelle Nutzer, ermittelbar sein.