Barrierefreiheit

Accessibility APIs

Den Anfang machte Adem Cifcioglu mit einem Vortrag über die Accessibility APIs. Zunächst erläuterte er ausführlich den Accessibility Tree, der sich folgendermaßen aufbaut:

1. Name
2. Roles
3. States
4. Properties
5. Relationship

In einem solchen Baum sind die Inhalte eines Elements, die Attribute und assoziierten Elemente sowie die ARIA-Attribute enthalten. Nicht enthalten sind jedoch Elemente wie button, checkbox, img etc. Zudem können Elemente versteckt werden mit aria-hidden="true".

Semantik

Hidde de Vries erläuterte, dass HTML keine Aussagen über das Aussehen der Seite trifft sondern vielmehr die Bedeutung festlegt. Dabei wird die Semantik in HTML in Elementen, Attributen und Werten festgelegt: <elements attributes="value">. Auch macht HTML keine Aussage darüber, wie bestimmte Elemente verwendet werden sollen. So kann z.B. das Ausfüllen eines Formulars erfolgen, indem der Browser bekannte Felder automatisch ausfüllt oder aber andere unterstützende Technologien wie Spracheingabe etc. genutzt werden. Dabei gibt es jedoch mehrere Möglichkeiten, dieselbe Semantik auszudrücken, z.B. <button> oder <div role="button">. Weitere Informationen, wie ihr HTML-Semantiken nutzen könnt, findet ihr in der Spezifikation. Und einige Beispiele, wie ihr HTML nicht nutzen solltet, sind in HTMHell gesammelt worden.

Zudem können Listen ihre Semantik verlieren, wenn list-style-type: none festgelegt wird; s.a. "Fixing" Lists. Andere CSS-Anweisungen, wie z.B. text-transform: uppercase werden von manchen Screen-Reader wie abbr interpretiert. Weitere CSS-Anweisungen, die Screen-Reader beeinflussen findet ihr in CSS Can Influence Screenreaders.

Hidde de Vries beendet seinen Vortrag mit einem Zitat der Open UI-Organisation:

«We hope to make it unnecessary to reinvent built-in UI controls»

– Open UI

Weitere Ziele von Open UI sind:

• Komponentennamen von Dokumenten, wie sie heute bereits existieren
• Eine gemeinsame Sprache für die Beschreibung von Benutzeroberflächen und Designsystemen
• Browser-Standards für Komponenten von Webanwendungen

ARIA-Standard

Gerard K. Cohen gab eine Einführung in Accessible Rich Internet Applications (ARIA) und zeigte, wie die ARIA-Spezifikation verwendet werden kann um um passgenaue Komponenten zu erstellen. Dabei warnte er zu Beginn seines Vortrags vor den Gefahren, die ARIA mit sich bringen kann. So kam z.B. WebAIM nach der Analyse von einer Millionen Websites im Februar 2021 zum Ergebnis:

»Auf Homepages mit ARIA wurden im Durchschnitt 41% mehr Fehler entdeckt als auf solchen ohne ARIA!«

Der Standard ist jedoch mit 70 ARIA-Rollen und 29 interaktiven (Widget)-Rollen nicht gerade einfach zu überblicken:

WAI-ARIA Taxonomy

Hinzu kommt noch, dass ARIA-Rollen von sich aus keine Interaktionen bieten sondern nur Zustände und Eigenschaften beschreibt, die dann verwendet werden können um selbst Interaktionen zu definieren.

Daher riet er dringend an, die fünf ARIA-Regeln einzuhalten:

1. Verwendet ARIA nicht, wenn ihr stattdessen HTML verwenden könnt.

2. Ändert nicht die ursprüngliche Semantik, also z.B. nicht

   <a href=“#” role=“button”>Menu</a>
   

3. Alle interaktiven ARIA-Rollen müssen mit der Tastatur bedienbar sein.

4. Verwendet nicht role="presentation" oder aria-hidden="true" für sichtbare, fokusierbare Elemente.

5. Alle interaktiven Elemente müssen einen zugänglichen Namen haben.

Schließlich wies er noch auf die Hinweise im Abschnitt Browser and Assistive Technology Support hin:

»Es ist wichtig, die Interoperabilität von Hilfstechnologien zu testen, bevor der Code … in der Produktion verwendet wird.«

Auch verwies er noch auf einen anderes Zitat aus Mobile and Touch Support:

»Derzeit gibt dieser Leitfaden nicht an, welche Beispiele mit mobilen Browsern oder Touch-Interfaces kompatibel sind. Während einige der Beispiele spezifische Funktionen enthalten, die die Unterstützung für mobile und berührungsempfindliche Oberflächen verbessern, werden einige ARIA-Funktionen nicht von allen mobilen Browsern unterstützt. Darüber hinaus gibt es noch keinen standardisierten Ansatz für die Bereitstellung von Touch-Interaktionen, die in allen mobilen Browsern funktionieren.«

Live Regions

Ugi Kutluoglu erläuterte, welche Probleme Live Regions lösen und welche Missverständnisse es auszuräumen gilt. Im Wesentlichen handelt es sich bei ihnen um DOM-Knoten, die für Benachrichtigungen vorgesehen sind und die meist über JavaScript Screen-Reader steuern.

Eine Live Region lässt sich einfach irgendwo im DOM bereitstellen bevor Inhalte hinzugefügt werden:

<div id=”myLiveRegion” class=”visually-hidden”> </div>

<div aria-live=”polite” aria-relevant=”text” aria-atomic=”true” id=”myLiveRegion”>
    <span>Now playing</span>
    <span id=”song”>Van Morrison - Celtic New Year</span>
</div>

Häufige Fehler sind

• der Versuch, eine Sprachschnittstelle zu erstellen
• die Annahme, dass alles bekannt annonciert wird
• die Annahme, dass ganze Sektionen live werden
• konkurrierende Live-Regionen
• Versuche den Status von Live Regions zu übermitteln
• zu viele Updates in zu kurzer Zeit

Um diese Fehler analysieren zu können, stellte er diverse Debugging-Werkzeuge vor:

• Fügt einen Break bei Änderungen des Teilbaums hinzu, um zu sehen, was wann und durch welches Skript hinzugefügt wird

• Mutation Observer

  (()=>{
      const target = document.querySelector('body');
      const observer = new MutationObserver(function(mutations) {
          mutations.forEach((mutation) => {
              console.log(mutation.addedNodes, mutation.removedNodes, mutation.attributeName)
          });
       });
      observer.observe(target, {childList: true,attributes: true,subtree: true});
  })();
  

• NerdeRegion Extension

High contrast mode

Kilian Valkhof stellte gleich zu Beginn klar, dass dieser Modus nicht unmittelbar zu höheren Kontrasten führt sondern vielmehr die Anzahl der Farben reduziert und die Farben von den Betrachtenden ausgewählt werden können. Dies erleichtert Personen mit Sehschwäche, Farbenblindheit und Lichtempfindlichkeit, aber auch bei hellem Sonnenlicht etc., insgesamt ca. 4% derjenigen, die sich eine Website anschauen wollen.

Nach dem Auswählen einer Option zeigt die High contrast-Seite von Windows eine Vorschau an.

element {
  forced-colors-adjust: none;
}

element:focus {
  outline-color: transparent;
  box-shadow: 0 0 0 2px orangered;
}

Farbkontrast und WCAG

Im Vortrag von Todd Libby ging es dann wirklich um Farbkontraste und wie WCAG 2.0 Erfolgskriterien erfüllt werden können. Dies verdeutlichte er an einigen Erfolgskriterien (engl.: Success criteria):

Success Criterion 1.4.6 Contrast (Enhanced) (AAA)

Die visuelle Darstellung von Text und Textbildern hat ein Kontrastverhältnis von mindestens 7:1 mit Ausnahme der folgenden Punkte:

• Großer Text und Bilder von großflächigem Text haben ein Kontrastverhältnis von mindestens 4,5:1
• Beiläufiger Text und Bilder von Text, die Teil einer inaktiven Komponente der Benutzeroberfläche sind oder die reine Dekoration sind oder die für niemanden sichtbar sind oder die Teil eines Bildes sind, das signifikante andere visuelle Inhalte enthält, haben keine Kontrastanforderungen.
• Logotypen, also Text, der Teil eines Logos oder Markennamens ist, muss keinen Kontrast aufweisen.

Success Criterion 1.4.11 Non-text Contrast (AA)

Die visuelle Darstellung der folgenden Komponenten soll ein Kontrastverhältnis von mindestens 3:1 zu benachbarten Farben aufweisen:

Komponenten der Benutzeroberfläche

Visuelle Informationen, die erforderlich sind, um Komponenten und Zustände der Benutzeroberfläche zu identifizieren, außer bei inaktiven Komponenten oder wenn das Aussehen der Komponente vom Benutzeragenten bestimmt und nicht vom Autor geändert wird.

Grafische Objekte

Teile von Grafiken, die zum Verständnis des Inhalts erforderlich sind, es sei denn, eine bestimmte Darstellung von Grafiken ist für die zu vermittelnde Information wesentlich.

Bedauerlicherweise gehören Farbkontraste auch noch 2021 zu den häufigsten Fehlern auf Websites in Bezug auf Zugänglichkeit:

86,4 % der Homepages enthielten kontrastarmen Text, im Durchschnitt 31 Instanzen pro Homepage.

– WebAIM Million – 2021 Update

Dabei gibt es etliche Werkzeuge, mit denen Farbkontraste überprüft werden können:

• contrast ratio
• Who can use
• Contrast Checker
• Colour Contrast Checker
• Randoma11y
• Button Contrast Checker

Es sind auch etliche Browser-Erweiterungen verfügbar:

• WAVE
• axe
• NoCoffee vision simulator
• Lighthouse

Und auch ganze Farbpaletten lassen sich testen:

• Contrast Grid
• Accessible color palette builder
• tanaguru contrast finder
• A11y Color Palette

Zum Schluss gab er noch den Tipp, dass Farbverhältnisse zwar die Mindestkontraste einhalten sollten, gleichzeitig jedoch zu starke Kontraste im Text zu einer verschwommenen Wahrnehmung führen können.

Accessible SVGs

Heather Migliorisi berichtete über skalierbare Vektorgrafiken (SVG), die sich immer mehr zum bevorzugten Grafikformat im Web entwickeln. Dies wirkt sich auch auf die Hilfetechnologien aus. Ihr 2021 aktualisierter Artikel Accessible SVGs beschreibt detailliert die Themen ihres Vortrags, sodass wir ihn hier nicht selbst zusammenfassen müssen. Sie empfahl jedoch ein paar zusätzliche Quellen:

• Carie Fisher: Creating Accessible SVGs
• Sara Soueidan: Accessible Icon Buttons
• An alt Decision Tree
• Sarah Higley: Quick Tips for High Contrast Mode
• Melanie Richards: CurrentColor SVG in forced colors modes
• Val Head: Designing With Reduced Motion For Motion Sensitivities

Bewegung inklusiv gestalten

Val Head hob dabei vor allem auf die Bevorzugung reduzierter Bewegungen ab:

Auch ein Großteil der verwendeten Browser unterstützt die Media Query prefers-reduced-motion:

Implementiert werden kann die Media-Query sowohl in CSS als auch in Javascript:

@media (prefers-reduced-motion: reduce) {
}

const motionQuery = window.matchMedia('(prefers-reduced-motion)');

if (motionQuery.matches) {
    document.documentElement.classList.add('reduced-motion');
}

motionQuery.addListener(handleReduceMotionChanged);
handleReduceMotionChanged();

Anschließend zeigte sie, wie Interface-Animationen entsprechend gestaltet werden können. Unter anderem zeigte sie Animation with reduced-motion von Marcy Sutton.

Weitere Informationen zur Bevorzugung von reduzierten Bewegungen erhaltet ihr in ihrem Buch Designing Interface Animation, im WebKit-Artikel Responsive Design for Motion und in ihrem Artikel Designing With Reduced Motion For Motion Sensitivities.

Meldet euch

In unseren Schulungen geben wir eine praktische Einführung in die passenden Technologien für barrierearme Websites. Und gerne erstellen wir euch auch ein individuelles Angebot für die Entwicklung eures Style Guides oder eures Frontends, in die die wir die neuesten Erkenntnisse integrieren.

Ich rufe euch auch gerne zurück!

Jetzt anfragen