Inhaltsbereich Navigation Navigation Fußzeile

Barrierefreiheits-Tests

Die Barrierefreiheits- und Ergonomie-Tests konzentrieren sich auf die Prüfung von Aufgaben und Workflows der Nutzenden. Hierbei wird gegen die Vorgaben des Design Systems auf Basis der Kriterien aus den Normen und Richtlinien geprüft.

Die meisten dieser Kriterien werden bereits vor der Implementierung durch ihre Beachtung im Design System erfüllt. Aufgrund der Natur menschlicher Behinderungen beziehen sich Teile der Kriterien auf das visuelle Design, andere Kriterien sind hingegen rein technischer Natur. Daher werden sowohl maschinelle und manuelle Testverfahren als auch Kombinationen aus beidem eingesetzt.

Die vollständige oder auch nur teilweise Automatisierung von Barrierefreiheitsprüfungen ist nur bedingt möglich. Die Automatisierung hat natürliche Grenzen, da Barrierefreiheit stark vom Verstehen der Inhalte und Funktionen abhängig ist und somit eine menschliche Evaluation benötigt. Manuelle technische Tests sollten immer erst dann durchgeführt werden, wenn alle maschinellen Tests erfolgreich waren. Gestalterische und inhaltliche Kriterien können und sollen aber anhand von Prototypen bereits vor der eigentlichen Umsetzung durchgeführt werden.

Das Testen der Barrierefreiheit integriert sich als Erweiterung in vorhandene Teststrukturen. Zusätzlich überprüfen Experten Neuentwicklungen und unterstützen bei Bedarf zu jedem Zeitpunkt im Prozess der Frontend-Entwicklung.

Die Überprüfung der Konformität einer Anforderung gegen die Vorgaben der WCAG bzw. BITV muss in jeder Konzept-, Design- und Entwicklungsphase erfolgen. Idealerweise sollen die Barrierefreiheits- und Ergonomie-Anforderungen als nicht-funktionale Anforderungen in Jira o.ä. hinterlegt und verknüpft sein.

Testdurchführung Barrierefreiheit

Die wesentlichen technischen Anforderungen der WCAG können mit geeigneten Werkzeugen bereits im Document Object Model bzw. Accessibility Object Model moderner Browser getestet werden. Für weitere Anforderungen z. B. zur visuellen Darstellung ist es angezeigt, weitere Werkzeuge zur Konformitätsprüfung einzusetzen, wohingegen Prüfungen inhaltlicher Kriterien manuell im Browser vorgenommen werden müssen. Kein Testwerkzeug alleine kann feststellen, ob eine Web-Anwendung sämtliche Richtlinien für Barrierefreiheit erfüllt. Daher werden Prüfwerkzeuge nach Bedarf durch Experten und Tester ausgewählt und in den nicht-funktionalen Anforderungen (zum Beispiel über den Issue-Typ NFA in Jira) aufgelistet.

Praxistests Barrierefreiheit

Idealerweise testen Nutzende assistiver Technologien mit ihren eigenen Hilfsmitteln wie Screenreadern, Braillezeilen oder auch alternativen Eingabemethoden. Diese Kompatibilitäts-Prüfungen ergänzen die BITV-Tests, da auch Hilfsmittel nicht frei von Fehlern sind und Standards teils nur unvollständig unterstützen.

Insbesondere bei der Verwendung von WAI-ARIA-Attributen empfehlen wir dringend, dem ARIA Authoring Practices Guide (APG) des W3C zu folgen. Bitte beachten Sie aber auch hier, dass nicht alle Möglichkeiten von ARIA von allen Screenreadern in allen Versionen verlässlich unterstützt werden. Gerade bei dynamischen Inhalten kann es hier zu vermeintlichen Fehlern kommen, die aber nicht durch weiteren oder geänderten Code behebbar sind.

Unterschiede in verschiedenen Screenreadern

Je nach Betriebssystem- / Browser- und Hilfsmittelkombination werden Standard-Elemente unterschiedlich, teils aber auch gar nicht vorgelesen. Um das Testen zu vereinfachen haben wir hier einige der auffälligsten Unterschiede dokumentiert:

HTML-ElementJAWS 2022NVDA 22.3.2VoiceOver
buttonSchalter
input type=textEingabefeld
input type=radioAuswahlschalter
input type=checkboxKontrollfeld
(Achtung: bei Tri-State-Checkboxen gibt JAWS in Kombination mit Firefox nicht den unbestimmten Zustand aus)		Kontrollfeld
(Tri-State funktioniert mit allen Kombinationen)		Kontrollfeld
comboboxKombiniertes EingabefeldKombinationsfeldKombinationsfeld
textareaMehrzeiliges EingabefeldEingabefeld mehrzeiligMehrzeiliges Eingabefeld
fieldsetGruppeGruppierungGruppe
legendInhalt der Legend wird zum Namen der Gruppe
headerBannerBanner Sprungmarke–
mainHauptregion bzw. am Schluß-Tag Hauptregion EndeHaupt-Sprungmarke, auch am Ende Haupt-Sprungmarke–
footerInhaltsangabeInhaltsangabe RegionInhaltsangabe
navNavigation Region, beim schließenden Tag wird Navigation Region Ende vorgelesenNavigation Sprungmarke, der schließende Tag und damit das Ende der Navigation wird nicht vorgelesen–
asideBeim direkten Anspringen Ergänzung, sonst nichtsErgänzung Sprungmarke–
sectionWird nicht vorgelesen, wenn kein aria-label zur Beschreibung der Section vergeben wurde.
articleArtikel bzw. am Schluß-Tag Artikel EndeWird nicht vorgelesen, wenn kein aria-label zur Beschreibung des Article vergeben wurde

Weitere Informationen finden Sie unter HTML5 sectioning elements and screen readers.

Testwerkzeuge für Barrierefreiheit

Nur eine kleine Teilmenge der Anforderungen zur Barrierefreiheit ist zu 100% und verlässlich maschinell und automatisiert prüfbar. Die überwiegende Anzahl benötigt die sachkundige Einschätzung durch einen menschlichen Tester, gegebenenfalls unterstützt durch eine Software, die verdächtige Stellen zur weiteren manuellen Überprüfung identifiziert.

Eine Sammlung von Prüf-Tools finden Sie in der Werkzeugliste des BITV-Test.

Gängige assistive Hilfsmittel

Linting / Test-Automatisierung

Browserbasierte Werkzeuge

Bookmarklets

MacOS

Windows

iOS

Es wird vorausgesetzt, dass Apple Xcode verwendet wird.

Android

Es wird vorausgesetzt, dass Android Studio verwendet wird.

E-Mail

  • accessible-email.org – Eingabehilfen für E-Mail-Entwickler (kostenloses Online-Tool, möglicherweise nicht konform mit Datensicherheitsbeschränkungen)

Richtlinien und Werkzeuge für die Erstellung & Prüfung von PDF-Dokumenten