It’s #FrontendFriday – Wie testet man accessibility?

Im Rahmen der JavaScript Konferenz in München konnten wir uns eine Vielzahl von interessanten Vorträgen anhören. Ein für mich, sehr interessanter Vortrag, war der Talk von Anuradha Kumari zu dem Thema Decoding web accessibility through testing (Link auf die öffentliche Präsentation zu dem Thema). In diesem Talk ging es darum, wie wichtig accessibility im Web ist, auf was wir achten müssen und welche Tools es gibt, die uns dabei helfen können.

Was ist accessibility?

Ressourcen und Dienste für alle nutzbar machen, unabhängig von ihren Beeinträchtigungen.

Laut der World Health Organization leben ca. 15% (1 Milliarde) Menschen mit einer Form von Beeinträchtigung. Da wir für unsere Benutzer:innen entwickeln, müssen wir auch diesen Teil der Menschheit mit einbeziehen, damit diese nicht ausgegrenzt werden.

Grundlegend gibt es (unter anderem) folgende Beeinträchtigungsarten:

• Visuell
• Auditiv
• Motorisch
• Kognitiv

Wie testen wir accessibility?

Der WCAG stellt als Basis seiner Richtlinien das sogenannte POUR Prinzip vor.

• Perceivable (Wahrnehmbar)
  Informationen und Bestandteile der Benutzerschnittstelle müssen den Benutzenden so präsentiert werden, dass diese sie wahrnehmen können.
• Operable (Bedienbar)
  Bestandteile der Benutzerschnittstelle und Navigation müssen bedienbar sein.
• Understandable (Verständlich)
  Informationen und Bedienung der Benutzerschnittstelle müssen verständlich sein.
• Robust (Robust)
  Inhalte müssen robust genug sein, damit sie von einer großen Auswahl an Benutzeragenten einschließlich assistierender Techniken interpretiert werden können.

Tastatur

Eine grundlegende Art der accessibility ist das Navigieren nur mit der Tastatur. Hier kann man einfach prüfen, ob alle relevanten Elemente komplett über die Tastatur erreichbar sind.

Wichtige Tasten

• Tab
• Shift + Tab
• Eingabetaste
• Leertaste
• Pfeiltasten
• ESC

Auf was sollen wir dabei achten?

• Sind alle interaktiven Elemente erreichbar und kann man mit diesen interagieren?
• Ist es eindeutig auf welchem interaktiven Element man gerade in der Anwendung ist?
  • outline: none oder dergleichen kann hier zu Problemen führen.
• Prüfen, ob man in eine „focus trap“ fallen kann. Das heißt man ist in einem Teil der Anwendung „gefangen“ und kann nicht mehr mit der Tab-Navigation rauskommen.
• Gibt es ein tab-index > 0? Grundsätzlich braucht man keinen tab-index der größer 0 ist.

Screen Reader

Es gibt eine Vielzahl unterschiedlicher Screen Reader:

• NVDA – Windows (kostenlos)
• Mac voiceover utility – Mac OS (kostenlos)
• JAWS – Kommerzielles Produkt
• ORCA – Linux (kostenlos)
• Und viele mehr…

Was sollen wir mit einem Screen Reader testen?

• Landmarks
  • Geben der Anwendung eine Struktur
  • Screen Reader nutzen Landmarks für die Navigation
  • <header>, <main>, <nav>, <…> Elemente nutzen anstatt <div id=“header“>
  • Nicht zu viele Landmarks nutzen
• Bei Bildern das alt Attribut nutzen
  • alt=““, wenn das Bild nur dekorativ ist und nicht vorgelesen werden muss
  • alt=“Beschreibung hier eingeben“, für informative Bilder
  • Bilder niemals ohne alt Attribute stehen lassen. Der Screen Reader wird dann versuchen dieses Bild zu interpretieren. Bleibt das alt Attribut leer, dann wird dieses Bild automatisch übersprungen
• Formular label nutzen

  <label> E-Mail eingeben:
   <input type="email" id="email" />
  </label> 
  
  oder 
  
  <label for="email">E-Mail eingeben:</label>
  <input type="email" id="email">

  In beiden Fällen wird hier der Text „E-Mail eingeben“ vom Screen Reader vorgetragen

• Werden dynamische Änderungen angekündigt?
  • Durch das Attribut aria-live=“polite“. Siehe: aria-live
• Sind Handlungen nachvollziehbar?

Browser Tools und Erweiterungen

• DevTools
  • In den DevTools kann man auf die Accessibility über dem Reiter Elements -> Accessibility zugreifen. Hier kann man grundlegende Elemente wie den aria-label oder den Value eines Elementes sehen. Weiterhin sieht man auch den accessibility tree der Webseite.
• Lighthouse
  • In den DevTools kann man über den Reiter Lighthouse einen Accessiblity Report generieren lassen. Dieser ist sehr rudimentär und prüft nur die wichtigsten Parameter.
• Axe extension
  • Ein mächtiges Browser Tool welches die Webanwendung im Browser prüfen kann. Es agiert ähnlich zum Lighthouse, ist aber deutlich umfangreicher. Man kann alle Fehler highlighten und Informationen zu den Fehlern aufrufen.

Automatisierte Tools während der Entwicklung

Was können wir testen?

• Seitentitel
• Überschriften und HTML-Struktur
• Aria Validierungen
• Farbkontrast
• Bildtext Alternativen

Welche Tools können wir dafür nutzen?

• Axe-Core
  • Axe ist eine accessibility testing engine für Webanwendungen.
  • Es kann zusammen mit Cypress, Selenium oder der Axe CLI genutzt werden.
• eslint-plugin-jsx-a11y
  • Plugin für eslint und Code während der Entwicklung zu linten.