94% positive Resonanz auf die Buchungsstrecke

Barrierefreiheit

Ziel und Umfang

Ich überprüfte den Ist-Zustand der gesamten Buchungs- und Check-out-Strecke hinsichtlich ihrer Barrierefreiheit. Ein besonderer Schwerpunkt lag auf der Terminauswahl über den interaktiven Kalender auf der Startseite, da dieser als komplexe, dynamisch erzeugte Komponente besondere Anforderungen an Tastaturbedienung und Screenreader-Nutzung stellte.

Neben der manuellen Prüfung setzte ich automatisierte Prüfungen ein und arbeitete mit einem externen Dienstleister zusammen, der spezialisierte Werkzeuge zur Erkennung und Einordnung von Accessibility-Problemen bereitstellte.

Die Prüfungen richtete ich mindestens auf WCAG Level AA aus. Wo die eingesetzten Werkzeuge dies unterstützten, ergänzte ich die Prüfungen um zusätzliche Accessibility Best Practices.

ATAG war für den betrachteten Anwendungsfall nicht Bestandteil des Testumfangs, da die Anwendung keine entsprechende Authoring-Umgebung zur Erstellung von Webinhalten bereitstellte.
Unabhängig davon stellte ich sicher, dass dynamisch erzeugte Seitentitel korrekt gesetzt wurden. Dazu verwendete ich Helmet für React und überprüfte die resultierenden Seitentitel manuell.

 

Automatisierte Accessibility-Tests

Bereits während der Entwicklung setzte ich automatisierte Prüfungen ein, um Accessibility-Probleme möglichst früh im Entwicklungsprozess zu erkennen. In der React-Entwicklung verwendete ich unter anderem eslint-plugin-jsx-a11y, um beispielsweise fehlende oder problematische Attribute wie alt-Texte direkt im Code erkennen zu können.

Zusätzlich setzte ich im Visual-Studio-Code-Umfeld den Axe Accessibility Linter ein, um die entstehende HTML-Struktur bereits während der Entwicklung auf mögliche Accessibility-Probleme zu prüfen.

Für die fertige Buchungsstrecke verwendete ich unter anderem axe-core und WAVE, um die einzelnen Seiten separat zu überprüfen. Dabei wurden unter anderem fehlerhafte Landmarks, problematische Überschriftenhierarchien und fehlende bzw. ungeeignete Alternativtexte identifiziert.

In Zusammenarbeit mit einem externen Dienstleister richtete ich außerdem spezialisierte automatisierte Testabläufe ein. Dadurch konnten auch Bereiche überprüft werden, die erst durch Benutzerinteraktionen erreichbar waren, beispielsweise der Login-Bereich und der Check-out-Prozess einschließlich der Bezahlung.

Die automatisierten Prüfungen verwendete ich dabei nicht als alleinige Qualitätskontrolle. Die gefundenen Probleme überprüfte ich anschließend manuell, insbesondere hinsichtlich Tastaturbedienung und Screenreader-Ausgabe.

 

Manuelles Accessibility-Testing

Das manuelle Testen war ein wesentlicher Bestandteil der Prüfung und wurde sowohl während der Entwicklung als auch nach der Behebung einzelner Probleme wiederholt durchgeführt.

Ich testete den kompletten User Flow der Buchungsstrecke mit der Tastatur und überprüfte dabei insbesondere die Reihenfolge der Interaktionen und die Erreichbarkeit der einzelnen Bedienelemente. Zusätzlich verwendete ich VoiceOver auf macOS, um die einzelnen Seiten mit einem Screenreader durchzugehen und gleichzeitig die Tastaturbedienung und die ausgegebenen Informationen zu überprüfen.

Dabei überprüfte ich beispielsweise nicht nur, ob ein alt-Attribut vorhanden war, sondern auch, ob dessen Inhalt für Screenreader-Nutzer tatsächlich sinnvoll war. Bei dekorativen Bildern und Icons untersuchte ich dagegen, ob eine Ausgabe durch den Screenreader überhaupt erforderlich war.

Auch dynamisch generierte Inhalte und Button-Labels wurden manuell überprüft. Gerade beim Kalender war es wichtig, dass die einzelnen Bedienelemente für Screenreader verständlich benannt und Zustandsänderungen nachvollziehbar ausgegeben wurden.

 

Identifizierte Probleme und technische Remediation

Auf Basis der automatisierten und manuellen Prüfungen nahm ich verschiedene technische und visuelle Anpassungen vor.

• Tastaturbedienung und Fokus
  Ich ergänzte bei interaktiven Elementen wie Buttons und Eingabefeldern einen deutlich sichtbaren und kontrastreichen Fokus-Ring. Dadurch konnte die aktuell fokussierte Position auch bei ausschließlicher Tastaturbedienung eindeutig erkannt werden. (WCAG 2.4.7)
   

• Semantisches HTML und Struktur
  Nicht-semantisches HTML sowie fehlerhafte Verschachtelungen von Labels wurden korrigiert. Bei den Überschriften traten durch die dynamische React-Struktur inkonsistente Hierarchien auf. (WCAG 1.3.1)

  Ich passte die Generierung entsprechend an, sodass die Überschriften in der vorgesehenen Reihenfolge ohne unnötige Sprünge ausgegeben wurden. (WCAG 4.1.2)

• Accessible Names und ARIA
  Insbesondere beim Kalender überarbeitete ich die Bezeichnungen der interaktiven Elemente, damit deren Funktion für Screenreader-Nutzer verständlich ausgegeben wurde. Dazu ergänzte bzw. korrigierte ich ARIA-Attribute und verwendete bei dynamisch erzeugten Inhalten geeignete Beschriftungen.

  Bei Akkordeon-Komponenten stellte ich außerdem sicher, dass zugehörige Inhalte erst durch die entsprechende Interaktion sichtbar bzw. für den Screenreader zugänglich wurden.

• Bilder und Icons
  Ich überprüfte Bilder und Icons einzeln darauf, ob sie eine informative Funktion besitzen oder ausschließlich dekorativ sind. Dekorative Icons wurden mit aria-hidden="true" aus der Ausgabe für Screenreader entfernt.

  Bei Buttons, die ausschließlich aus einem Icon bestanden, war dagegen eine verständliche Beschriftung erforderlich. Hier ergänzte ich entsprechende Texte, die für Screenreader verfügbar waren, ohne die visuelle Darstellung der Komponente zu verändern. (WCAG 4.1.2)

• Kontrast und Typografie

  An verschiedenen Stellen überarbeitete ich den Kontrast zwischen Text und Hintergrund. Insbesondere graue Texte auf hellgrauen Hintergründen wurden angepasst. Teilweise wurde zusätzlich der Schriftschnitt auf eine besser wahrnehmbare Medium-Variante geändert. (WCAG 1.4.3)

  Hinweistexte, die für die Bedienung oder das Verständnis des Prozesses relevant waren, wurden von 14px (0.875rem) auf 16px (1rem) vergrößert.

  Zudem nutzte ich die integrierten Zoom- und Vergrößerungsfunktionen der Browser, um die Anwendung bei vergrößerter Darstellung zu überprüfen. Zusätzlich simulierte ich mit Browser-Entwicklertools verschiedene Formen von Farbfehlsichtigkeit, um zu überprüfen, ob Informationen und Bedienelemente auch ohne die alleinige Wahrnehmung von Farben verständlich und nutzbar bleiben.

• Dynamische Inhalte und Live Regions

  Bei dynamisch aktualisierten Datums- und Zeitangaben setzte ich Live Regions ein und setzte sie auf aria-live="polite", bei Anzahl-Countern im Kalenderbereich hingegen, wo Änderungen sofort vorgelesen werden sollten, stellte ich dieses Aria-Attribut auf “assertive”. Dadurch konnten Änderungen für Screenreader-Nutzer nachvollziehbar angekündigt werden. (WCAG 4.1.3)

  Häufig war es auch sinnvoll, dass der gesamte Text vorgelesen werden sollte und nicht nur der geänderte Wert, dadurch erschließt sich leichter der Kontext, das erreichte ich, indem ich die live-region auf durch aria-atomic="true" setzte.

  Fehlermeldungen

• Ich überprüfte jede Komponente (z.B. Input-Felder), die Eingaben von Usern verarbeitet darauf, dass eine verständliche und kontraststarke Fehlermeldung ausgegeben wird, auch auf eine lesbare von mind. 1rem (16px) habe ich eingerichtet.

   

Validierung der Änderungen

Nach der technischen Umsetzung überprüfte ich die Änderungen erneut mit automatisierten Tools sowie durch manuelle Tastatur- und Screenreader-Tests.

Dabei durchlief ich die Buchungsstrecke erneut Schritt für Schritt und überprüfte insbesondere die zuvor problematischen Bereiche. Die automatisierten Prüfungen dienten dabei als zusätzliche Kontrolle, während die manuelle Prüfung sicherstellte, dass die korrigierten Komponenten auch tatsächlich sinnvoll mit Tastatur und Screenreader bedienbar und verständlich waren.

Die Ergebnisse der Prüfungen und die daraus entstandenen Korrekturen wurden dokumentiert. Nach Abschluss der vorgesehenen Remediation wurde die Barrierefreiheitserklärung entsprechend aktualisiert bzw. veröffentlicht.