Prüfschritt | Warum wird das geprüft? |
---|
5.2 Aktivierung von Barrierefreiheitsfunktionen | Barrierefreiheitsfunktionen, die von der zu testenden Webseite (also nicht vom Betriebssystem oder dem Browser) bereitgestellt werden, sollen von ihrer potentiellen Nutzerschaft selbstständig aktivierbar sein. Wenn die Webseite beispielsweise eine Funktion zur Verfügung stellt, mit derer die Kontrastverhältnisse innerhalb der Seite verbessert werden, müssen sämtliche Bedienelemente, die zur Aktivierung der Funktion bedient werden müssen, auch in der Standardansicht ein ausreichendes Kontrastverhältnis aufweisen. Damit wird sichergestellt, dass auch Nutzer, die mit kontrastarmen Inhalten und Bedienelementen Schwierigkeiten haben (also zur Zielgruppe der Barrierefreiheitsfunktion gehören), die Funktion zur Kontrasterhöhung selbstständig aktivieren können. |
7.3 Bedienelemente für Untertitel und Audiodeskription | Videoplayer bieten den Menschen eine Vielzahl von Interaktionsmöglichkeiten. Am wichtigsten sind dabei die Bedienelemente zur Wiedergabekontrolle. Sie sind daher prominent auf der obersten Interaktionsebene des Players positioniert. Bedienelemente für das Ein- und Ausblenden der Untertitel bzw. das Starten und Beenden der Audiodeskription sind für Menschen, die diese Funktion benötigen, ebenfalls wichtige Steuerelemente. Sie sollen leicht gefunden werden und müssen daher ebenfalls auf der obersten Interaktionsebene positioniert sein. |
9.1.1.1d Alternativen für CAPTCHAs | In bildbasierten CAPTCHAs werden Bilder von Zeichenfolgen eingesetzt, welche Nutzer als Text eingeben müssen, um bestimmte Bereiche von Webangeboten zu erreichen. Für blinde und sehbehinderte Nutzer sind solche CAPTCHAs nicht zugänglich. Audio-Captchas sind für höreingeschränkte Nutzer nicht zugänglich. Deshalb soll in beiden Fällen mindestens eine CAPTCHA-Alternative angeboten werden. Bei bildbasierten CAPCHAs soll der Alternativtext den Zweck des CAPTCHAs beschreiben und angeben, wie CAPTCHA-Alternativen zu finden sind. |
9.4.1.3 Statusmeldungen programmatisch verfügbar | In vielen Nutzungskontexten erhalten sehende Benutzer von Webanwendungen Statusmeldungen (einige von ihnen vorübergehend), die Rückmeldungen über das Ergebnis von Interaktionen (z. B. die Zahl der beim Filtern einer Suchergebnisliste zurückgegebenen Einträge) oder den Erfolg oder Misserfolg von Transaktionen geben. Diese Meldungen sind ebenso wichtig für nicht-visuelle Nutzer und sollten für assistive Technologien verfügbar sein, damit die Nutzer auf sie aufmerksam werden, ohne ihren aktuellen Fokus oder Standpunkt ändern zu müssen. |
11.7 Benutzerdefinierte Einstellungen | Wenn Menschen eigene Einstellungen im System oder im Browser vornehmen, zum Beispiel weil sie größere Schrift oder eigene angepasste Farbeinstellungen brauchen, sollen diese vom Webangebot wo immer möglich respektiert und übernommen werden. |
11.8.3 Erhaltung von Barrierefreiheitsinformationen bei Transformation | Menschen mit Behinderung benötigen semantische Auszeichnungen (zum Beispiel durch Überschriften oder richtig aufgebaute Datentabellen), um Inhalte effektiv zu nutzen. Werden diese Auszeichnungen in Transformationen entfernt oder korrumpiert, leidet die Benutzbarkeit der Dokumente. |
11.8.4 Reparaturassistenz |
|
12.2.2 Technischer Support | Hinweise zu Barrierefreiheits-Funktionen sind nicht immer verständlich genug. Hinweise zur Hilfsmittel-Kompatibilität können schnell veraltet sein. Es ist wichtig, dass der technische Support auf Kunden-Fragen eingehen und Hilfe bereitstellen kann. |
12.2.4 Vom Support bereitgestellte Dokumentation | Die technische Dokumentation ist ein wichtiger Bestandteil vieler Angebote, besonders bei komplexeren Web-Anwendungen. Damit auch Menschen mit Behinderungen sie gut nutzen können, sollte sie alle Anforderungen der Barrierefreiheit erfüllen. |