Umgang mit häufigen Problemen der Barrierefreiheit

Wenn wir im Zusammenhang mit Web-Technologie von Barrierefreiheit sprechen, denken die meisten Menschen sofort daran, sicherzustellen, dass Websites/Apps für Menschen mit Behinderungen nutzbar sind, zum Beispiel:

• Sehbehinderte Menschen, die Bildschirmleser oder Vergrößerungen/Zooms verwenden, um auf Texte zuzugreifen.
• Menschen mit motorischen Beeinträchtigungen, die Tastaturen (oder andere nicht-mausbasierten Funktionen) nutzen, um die Funktionalität von Websites zu aktivieren.
• Menschen mit Hörbehinderungen, die auf Untertitel oder andere Textalternativen für Audio-/Videoinhalte angewiesen sind.

Es ist jedoch ein Irrtum zu sagen, dass Barrierefreiheit nur für Behinderungen gedacht ist. Das eigentliche Ziel der Barrierefreiheit ist es, Websites/Apps für so viele Menschen in möglichst vielen Kontexten wie möglich nutzbar zu machen, nicht nur für Benutzer von leistungsstarken Desktop-Computern. Einige Beispiele könnten sein:

• Benutzer auf mobilen Geräten.
• Benutzer auf alternativen Browser-Geräten wie Fernsehern, Uhren usw.
• Benutzer älterer Geräte, die möglicherweise nicht über die neuesten Browser verfügen.
• Benutzer von Geräten mit geringerer Spezifikation, die möglicherweise langsame Prozessoren haben.

In gewisser Weise dreht sich dieses ganze Modul um Barrierefreiheit — das Browser-übergreifende Testen stellt sicher, dass Ihre Sites von möglichst vielen Menschen genutzt werden können. Was ist Barrierefreiheit? definiert Barrierefreiheit vollständiger und gründlicher als dieser Artikel es tut.

Das gesagt, wird dieser Artikel Browser-übergreifende und Testprobleme im Zusammenhang mit Menschen mit Behinderungen behandeln und wie sie das Internet nutzen. Wir haben bereits über andere Bereiche wie Responsive Design und Leistung an anderen Stellen des Moduls gesprochen.

In diesem Abschnitt werden wir einige der Hauptprobleme umreißen, die im Zusammenhang mit der Barrierefreiheit im Web auftreten, in Verbindung mit spezifischen Technologien, zusammen mit Best Practices, die zu befolgen sind, und einigen einfachen Tests, die Sie durchführen können, um festzustellen, ob Ihre Sites auf dem richtigen Weg sind.

Semantisches HTML (bei dem die Elemente für ihren korrekten Zweck verwendet werden) ist von Haus aus zugänglich — solche Inhalte sind für sehende Zuschauer lesbar (sofern Sie nicht etwas Unüberlegtes tun, wie den Text zu klein zu machen oder ihn mit CSS zu verstecken), sind aber auch für unterstützende Technologien wie Bildschirmleser (Apps, die eine Webseite buchstäblich für ihren Benutzer vorlesen) nutzbar und bieten auch weitere Vorteile.

Semantische Struktur

Der wichtigste schnelle Gewinn im semantischen HTML besteht darin, eine Struktur von Überschriften und Absätzen für Ihren Inhalt zu verwenden; dies liegt daran, dass Bildschirmleser-Benutzer dazu neigen, die Überschriften eines Dokuments als Wegweiser zu verwenden, um schneller den benötigten Inhalt zu finden. Wenn Ihr Inhalt keine Überschriften hat, erhalten sie nur eine riesige Textwand ohne Wegweiser, um etwas zu finden. Beispiele für schlechtes und gutes HTML:

<font size="7">My heading</font>
<br /><br />
This is the first section of my document.
<br /><br />
I'll add another paragraph here too.
<br /><br />
<font size="5">My subheading</font>
<br /><br />
This is the first subsection of my document. I'd love people to be able to find
this content!
<br /><br />
<font size="5">My 2nd subheading</font>
<br /><br />
This is the second subsection of my content. I think it is more interesting than
the last one.

<h1>My heading</h1>

<p>This is the first section of my document.</p>

<p>I'll add another paragraph here too.</p>

<h2>My subheading</h2>

<p>
  This is the first subsection of my document. I'd love people to be able to
  find this content!
</p>

<h2>My 2nd subheading</h2>

<p>
  This is the second subsection of my content. I think it is more interesting
  than the last one.
</p>

Darüber hinaus sollte Ihr Inhalt in der Quellreihenfolge logisch Sinn ergeben — Sie können ihn später immer noch mit CSS beliebig platzieren, aber Sie sollten die Quellreihenfolge von Anfang an richtig wählen.

Als Test können Sie das CSS einer Site deaktivieren und prüfen, wie verständlich sie ohne CSS ist. Sie könnten dies manuell tun, indem Sie das CSS einfach aus Ihrem Code entfernen, aber der einfachste Weg ist die Verwendung von Browser-Funktionen, zum Beispiel:

• Firefox: Wählen Sie Ansicht > Seitenstil > Kein Stil aus dem Hauptmenü.
• Safari: Wählen Sie Entwickeln > Stile deaktivieren aus dem Hauptmenü (um das Menü Entwickeln zu aktivieren, wählen Sie Safari > Einstellungen > Erweitert > Menü Entwickeln in der Menüleiste anzeigen).
• Chrome: Installieren Sie die Webentwickler-Toolbar-Erweiterung, starten Sie dann den Browser neu. Klicken Sie auf das erscheinende Zahnradsymbol und wählen Sie CSS > Alle Stile deaktivieren.
• Edge: Wählen Sie Ansicht > Stil > Kein Stil aus dem Hauptmenü.

Nutzung nativer Tastaturzugänglichkeit

Bestimmte HTML-Features können nur über die Tastatur ausgewählt werden — dies ist das Standardverhalten, das es seit den Anfängen des Internets gibt. Die Elemente, die diese Fähigkeit haben, sind die gängigen, die es Benutzern ermöglichen, mit Webseiten zu interagieren, nämlich Links, <button>s und Formularelemente wie <input>.

Sie können dies mit unserem native-keyboard-accessibility.html Beispiel ausprobieren (siehe den Quellcode) — öffnen Sie dies in einem neuen Tab und versuchen Sie, die Tab-Taste zu drücken; nach ein paar Mal drücken, sollten Sie sehen, dass der Tabulatorfokus beginnt, durch die verschiedenen fokussierbaren Elemente zu wechseln; die fokussierten Elemente erhalten einen hervorgehobenen Standardstil in jedem Browser (er unterscheidet sich leicht zwischen den verschiedenen Browsern), damit Sie erkennen können, welches Element fokussiert ist.

Sie können dann Enter/Return drücken, um einem fokussierten Link zu folgen oder eine Schaltfläche zu drücken (wir haben etwas JavaScript hinzugefügt, damit die Schaltflächen eine Nachricht ausgeben), oder beginnen, in ein Texteingabefeld zu tippen (andere Formularelemente haben unterschiedliche Steuerungen, z. B. können beim <select>-Element die Optionen mit den Pfeiltasten nach oben und unten angezeigt und durchgegangen werden).

Beachten Sie, dass verschiedene Browser unterschiedliche Tastatursteuerungsoptionen verfügbar haben können. Die meisten modernen Browser folgen dem oben beschriebenen Tab-Muster (Sie können auch Shift + Tab verwenden, um rückwärts durch die fokussierbaren Elemente zu wechseln), aber einige Browser haben ihre eigenen Besonderheiten:

• Safari auf dem Mac erlaubt Ihnen standardmäßig nicht, durch Links zu tabben; um dies zu aktivieren, öffnen Sie die Systemeinstellungen, scrollen Sie herunter zu Tastatur und aktivieren Sie Tastaturnavigation. Wenn Sie eine ältere Version von macOS verwenden, lesen Sie Verwenden Ihrer Tastatur wie eine Maus auf dem Mac im macOS-Benutzerhandbuch von Apple.

Dieses Beispiel zeigt die Bedeutung der Verwendung des richtigen semantischen Elements für den richtigen Job auf. Es ist möglich, jedes Element mit CSS so zu gestalten, dass es aussieht wie ein Link oder eine Schaltfläche, und es mit JavaScript wie ein Link oder eine Schaltfläche zu verhalten, aber es sind keine echten Links oder Schaltflächen, und Sie verlieren eine Menge der Barrierefreiheit, die Ihnen diese Elemente von vornherein bieten. Also tun Sie es nicht, wenn Sie es vermeiden können.

Ein weiterer Tipp — wie in unserem Beispiel gezeigt, können Sie steuern, wie Ihre fokussierbaren Elemente aussehen, wenn sie fokussiert sind, indem Sie die :focus Pseudoklasse verwenden. Es ist eine gute Idee, Fokus- und Hover-Stile zu kombinieren, damit Ihre Benutzer, unabhängig davon, ob sie Maus oder Tastatur verwenden, den visuell Hinweis erhalten, dass eine Steuerung beim Aktivieren etwas tut:

a:hover,
input:hover,
button:hover,
select:hover,
a:focus,
input:focus,
button:focus,
select:focus {
  font-weight: bold;
}

Einbauen von Tastaturzugänglichkeit

Manchmal ist es nicht möglich, die Tastaturzugänglichkeit beizubehalten. Sie könnten eine Site übernommen haben, bei der die Semantik nicht sehr gut ist (vielleicht arbeiten Sie mit einem schrecklichen CMS, das Schaltflächen mit <div>s erstellt), oder Sie verwenden eine komplexe Steuerung, die keine eingebaute Tastaturzugänglichkeit hat, wie das HTML-<video>-Element (erstaunlicherweise, Opera ist der einzige Browser, der das Durchlaufen der <video>-Element-Standardbrowsersteuerungen per Tabulator erlaubt). Sie haben hier ein paar Optionen:

1. Erstellen Sie benutzerdefinierte Steuerungen mit <button>-Elementen (die wir standardmäßig per Tabulator erreichen können!) und JavaScript, um deren Funktionalität zu verknüpfen. Siehe Ein plattformübergreifender Videoplayer für einige gute Beispiele dafür.

2. Erstellen Sie Tastenkombinationen mit JavaScript, sodass Funktionen aktiviert werden, wenn bestimmte Tasten auf der Tastatur gedrückt werden. Siehe Maus- und Tastatur-Steuerungen für Desktop für einige spielbezogene Beispiele, die für jeden Zweck angepasst werden können.

3. Verwenden Sie einige interessante Taktiken, um Schaltflächenverhalten zu simulieren. Nehmen Sie zum Beispiel unser fake-div-buttons.html-Beispiel (siehe Quellcode). Hier haben wir unseren gefälschten <div>-Schaltflächen die Möglichkeit gegeben, fokussiert zu werden (auch per Tabulator), indem wir jedem das Attribut tabindex="0" gegeben haben (siehe WebAIMs tabindex-Artikel für weitere wirklich nützliche Details). Dadurch können wir zu den Schaltflächen tabben, aber nicht, um sie über die Enter/Return-Taste zu aktivieren. Dazu mussten wir den folgenden Trick mit JavaScript hinzufügen:

   js

   document.onkeydown = (e) => {
     if (e.code === "Enter") {
       // The Enter/Return key
       document.activeElement.onclick(e);
     }
   };
   

   Hier fügen wir dem document-Objekt einen Listener hinzu, um zu erkennen, wann eine Schaltfläche auf der Tastatur gedrückt wurde. Wir überprüfen, welche Schaltfläche gedrückt wurde, über die code-Eigenschaft des Event-Objekts; wenn es dem Code entspricht, der Return/Enter entspricht, führen wir die Funktion aus, die im onclick-Handler der Schaltfläche gespeichert ist, indem wir document.activeElement.onclick() verwenden. activeElement gibt uns das Element, das derzeit auf der Seite fokussiert ist.

Textalternativen

Textalternativen sind für Barrierefreiheit äußerst wichtig — wenn eine Person eine Seh- oder Hörbehinderung hat, die sie daran hindert, bestimmte Inhalte zu sehen oder zu hören, dann ist das ein Problem. Die einfachste verfügbare Textalternative ist das schlichte alt-Attribut, das wir in allen Bildern, die relevante Inhalte enthalten, einschließen sollten. Dies sollte eine Beschreibung des Bildes enthalten, die seine Bedeutung und seinen Inhalt auf der Seite erfolgreich vermittelt, damit es von einem Bildschirmleser aufgenommen und dem Benutzer vorgelesen werden kann.

Fehlender Alt-Text kann auf verschiedene Weise getestet werden, zum Beispiel mit Barrierefreiheits-Prüftools.

Alt-Text ist für Video- und Audioinhalte etwas komplexer. Es gibt eine Möglichkeit, Textspuren (z. B. Untertitel) zu definieren und sie beim Abspielen von Videos anzuzeigen, in Form des <track>-Elements und des WebVTT-Formats (siehe Hinzufügen von Untertiteln zu HTML-Videos für ein ausführliches Tutorial). Die Kompatibilität mit Browsern für diese Funktionen ist ziemlich gut, aber wenn Sie Textalternativen für Audio bereitstellen oder ältere Browser unterstützen möchten, könnte ein einfacher Texttranscript, der irgendwo auf der Seite oder auf einer separaten Seite präsentiert wird, eine gute Idee sein.

Elementbeziehungen und Kontext

Es gibt bestimmte Features und Best Practices in HTML, die dazu entwickelt wurden, Kontext und Beziehungen zwischen Elementen bereitzustellen, wo sonst keine existieren. Die drei häufigsten Beispiele sind Links, Formularbeschriftungen und Datentabellen.

Der Schlüssel zu zugänglichem Link-Text besteht darin, dass Benutzer von Bildschirmlesern häufig eine gemeinsame Funktion verwenden, bei der sie eine Liste aller Links auf der Seite aufrufen. In diesem Fall muss der Link-Text aus dem Kontext Sinn ergeben. Zum Beispiel ist eine Liste von Links mit der Bezeichnung "klicken Sie hier", "klicken Sie mich" usw. wirklich schlecht für die Barrierefreiheit. Es ist besser, wenn der Link-Text im Kontext und außerhalb des Kontexts Sinn ergibt.

Als nächstes auf unserer Liste ist das Formular-<label>-Element eines der zentralen Features, das es uns ermöglicht, Formulare zugänglich zu machen. Das Problem mit Formularen ist, dass Sie Beschriftungen benötigen, die angeben, welche Daten in jedes Formulareingabe eingegeben werden sollten. Jede Beschriftung muss in einem <label> enthalten sein, um sie eindeutig mit ihrem Partner-Formularelement zu verknüpfen (der for-Attributwert jeder <label> muss mit dem id-Wert des Formularelements übereinstimmen), und es wird auch dann Sinn ergeben, wenn die Quellordnung nicht völlig logisch ist (was zugegeben der Fall sein sollte).

Zuletzt ein kurzes Wort zu Datentabellen. Eine einfache Datentabelle kann mit sehr einfachem Markup geschrieben werden (siehe bad-table.html live, und Quellcode), aber dies hat Probleme — es gibt keine Möglichkeit für einen Bildschirmleser-Benutzer, Zeilen oder Spalten als Daten-Gruppierungen miteinander in Verbindung zu bringen — um dies zu tun, müssen Sie wissen, was die Kopfzeilenzeilen sind und ob sie Zeilen, Spalten usw. anführen. Dies kann nur visuell für eine solche Tabelle erfolgen.

Wenn Sie sich stattdessen unser punk-bands-complete.html-Beispiel (live, Quellcode) ansehen, können Sie einige Hilfen zur Barrierefreiheit bei der Arbeit sehen, wie Tabellenköpfe (<th>- und scope-Attribute), <caption>-Element usw.

CSS bietet in der Regel weit weniger grundlegende Barrierefreiheitsfeatures als HTML, kann aber trotzdem genauso viel Schaden für die Barrierefreiheit anrichten, wenn es falsch verwendet wird. Wir haben bereits ein paar Barrierefreiheits-Tipps zu CSS erwähnt:

• Verwenden Sie die korrekten semantischen Elemente, um unterschiedliche Inhalte in HTML zu kennzeichnen; wenn Sie einen anderen visuellen Effekt erzielen möchten, verwenden Sie CSS — missbrauchen Sie keine HTML-Elemente, um das gewünschte Aussehen zu erzielen. Wenn Sie zum Beispiel größeren Text wünschen, verwenden Sie font-size, kein h1-Element.
• Stellen Sie sicher, dass Ihre Quellreihenfolge ohne CSS Sinn ergibt; Sie können die Seite anschließend beliebig mit CSS gestalten.
• Sie sollten sicherstellen, dass interaktive Elemente wie Schaltflächen und Links geeignete Fokus-/Hover-/Aktivzustände haben, um dem Benutzer visuelle Hinweise auf ihre Funktion zu geben. Wenn Sie die Standardwerte aus stilistischen Gründen entfernen, stellen Sie sicher, dass Sie Ersatzstile hinzufügen.

Es gibt einige andere Überlegungen, die Sie berücksichtigen sollten.

Farbe und Farbkontrast

Bei der Auswahl eines Farbschemas für Ihre Website sollten Sie sicherstellen, dass die Textfarbe (Vordergrund) gut mit der Hintergrundfarbe kontrastiert. Ihr Design mag cool aussehen, aber es bringt nichts, wenn Menschen mit Sehbehinderungen wie Farbenblindheit Ihre Inhalte nicht lesen können. Verwenden Sie ein Werkzeug wie WebAIMs Farbkontrast-Prüfer, um zu überprüfen, ob Ihr Schema genügend Kontrast aufweist.

Ein weiterer Tipp ist, nicht nur auf die Farbe für Wegweiser/Informationen zu vertrauen, da dies für diejenigen, die die Farbe nicht sehen können, nicht geeignet ist. Anstatt z. B. erforderliche Formularfelder in Rot zu markieren, markieren Sie sie mit einem Sternchen und in Rot.

Ausblenden von Inhalten

Es gibt viele Instanzen, in denen ein visuelles Design erfordert, dass nicht alle Inhalte gleichzeitig angezeigt werden. In unserem Tabbed info box example (siehe Quellcode) haben wir zum Beispiel drei Informationspanels, aber wir positionieren sie übereinander und bieten Registerkarten, die angeklickt werden können, um jedes einzublenden (es ist auch über die Tastatur zugänglich — Sie können alternativ Tab und Enter/Return verwenden, um sie auszuwählen).

Benutzer von Bildschirmlesern kümmern sich nicht um all das — sie sind mit dem Inhalt zufrieden, solange die Quellreihenfolge Sinn ergibt und sie darauf zugreifen können. Absolute Positionierung (wie in diesem Beispiel verwendet) wird im Allgemeinen als eine der besten Mechanismen zum Ausblenden von Inhalten für visuelle Effekte angesehen, da sie Bildschirmleser nicht daran hindert, Zugang zu erhalten.

Andererseits sollten Sie visibility: hidden oder display: none nicht verwenden, weil sie Inhalte vor Bildschirmlesern verbergen. Sofern es natürlich keinen guten Grund gibt, warum Sie möchten, dass dieser Inhalt vor Bildschirmlesern verborgen ist.

JavaScript hat dieselben Probleme wie CSS in Bezug auf Barrierefreiheit — es kann für Barrierefreiheit katastrophal sein, wenn es schlecht oder übermäßig verwendet wird. Wir haben bereits auf einige Barrierefreiheitsprobleme im Zusammenhang mit JavaScript hingewiesen, hauptsächlich im Bereich semantischen HTMLs — Sie sollten immer das geeignete semantische HTML verwenden, um Funktionalität zu implementieren, wo immer es verfügbar ist, z. B. verwenden Sie Links und Schaltflächen entsprechend. Verwenden Sie keine <div>-Elemente mit JavaScript-Code, um Funktionalität zu simulieren, wenn es überhaupt möglich ist — es ist fehleranfällig und mehr Arbeit als die kostenlose Funktionalität, die Ihnen HTML bietet.

Einfache Funktionalität

Im Allgemeinen sollte einfache Funktionalität nur mit dem vorhandenen HTML funktionieren — JavaScript sollte nur verwendet werden, um die Funktionalität zu verbessern, nicht sie vollständig einzubauen. Gute Verwendungen von JavaScript umfassen:

• Bereitstellung von clientseitiger Formularvalidierung, die Benutzer schnell auf Probleme mit ihren Formulareinträgen aufmerksam macht, ohne auf die Überprüfung der Daten durch den Server warten zu müssen. Wenn es nicht verfügbar ist, funktioniert das Formular dennoch, aber die Validierung kann langsamer sein.
• Bereitstellung benutzerdefinierter Steuerungen für HTML-<video>s, die für Benutzer, die nur die Tastatur verwenden, zugänglich sind (wie bereits erwähnt, sind die Standard-Browser-Steuerungen in den meisten Browsern nicht über die Tastatur zugänglich).

Komplexere JavaScript-Implementierungen können Probleme mit der Barrierefreiheit verursachen — Sie müssen tun, was Sie können. Zum Beispiel wäre es unvernünftig, von Ihnen zu erwarten, dass Sie ein komplexes 3D-Spiel, das mithilfe von WebGL geschrieben wurde, 100% zugänglich für eine blinde Person machen, aber Sie könnten Tastatursteuerungen implementieren, damit es von Nicht-Maus-Benutzern genutzt werden kann, und das Farbschema kontrastreich genug machen, um es für Menschen mit Farbbehinderungen nutzbar zu machen.

Komplexe Funktionalität

Eines der Hauptprobleme für Barrierefreiheit sind komplexe Apps, die komplizierte Formularsteuerungen (wie Datumsauswähler) und dynamische Inhalte umfassen, die häufig und inkrementell aktualisiert werden.

Nicht-native komplizierte Formularsteuerungen sind problematisch, weil sie oft viele verschachtelte <div>s beinhalten und der Browser standardmäßig nicht weiß, was damit zu tun ist. Wenn Sie sie selbst erfinden, müssen Sie sicherstellen, dass sie für die Tastatur zugänglich sind; wenn Sie ein Drittanbieter-Framework verwenden, überprüfen Sie sorgfältig die verfügbaren Optionen, um zu sehen, wie zugänglich sie sind, bevor Sie es verwenden. Bootstrap scheint für Barrierefreiheit ziemlich gut zu sein, obwohl Bootstrap ein wenig zugänglicher machen von Rhiana Heath einige seiner Probleme (hauptsächlich im Zusammenhang mit Farbkontrast) erkundet und einige Lösungen anspricht.

Regelmäßig aktualisierte dynamische Inhalte können problematisch sein, weil Bildschirmleser-Benutzer sie möglicherweise verpassen, insbesondere wenn sie unerwartet aktualisiert werden. Wenn Sie eine Single-Page-App mit einem Hauptinhaltspanel haben, das regelmäßig mit XMLHttpRequest oder Fetch aktualisiert wird, könnte ein Benutzer des Bildschirmlesers diese Aktualisierungen verpassen.

WAI-ARIA

Benötigen Sie solche komplexen Funktionen oder reicht einfaches semantisches HTML aus? Wenn Sie Komplexität benötigen, sollten Sie die Verwendung von WAI-ARIA (Accessible Rich Internet Applications), einer Spezifikation, die Semantik (in Form von neuen HTML-Attributen) für Elemente wie komplexe Formularsteuerungen und aktualisierende Panels bietet, in Betracht ziehen, die von den meisten Browsern und Bildschirmlesern verstanden werden kann.

Um mit komplexen Formular-Widgets umzugehen, müssen Sie ARIA-Attribute wie roles verwenden, um anzugeben, welche Rolle verschiedene Elemente in einem Widget haben (zum Beispiel sind sie ein Tab oder ein Tab-Panel?), aria-disabled, um zu sagen, ob eine Steuerung deaktiviert ist oder nicht usw.

Um mit regelmäßig aktualisierten Inhaltsbereichen umzugehen, können Sie das aria-live-Attribut verwenden, das einen aktualisierenden Bereich identifiziert. Sein Wert gibt an, wie dringend der Bildschirmleser ihn vorlesen soll:

• off: Der Standard. Updates sollten nicht angekündigt werden.
• polite: Updates sollten nur angekündigt werden, wenn der Benutzer untätig ist.
• assertive: Updates sollten dem Benutzer so schnell wie möglich angekündigt werden.

Hier ist ein Beispiel:

<p><span id="LiveRegion1" aria-live="polite" aria-atomic="false"></span></p>

Sie können ein Beispiel in Aktion auf Freedom Scientific's ARIA (Accessible Rich Internet Applications) Live Regions-Beispiel sehen — der hervorgehobene Absatz sollte alle 10 Sekunden seinen Inhalt aktualisieren, und ein Bildschirmleser sollte dies dem Benutzer vorlesen. ARIA Live Regions - Atomic bietet ein weiteres nützliches Beispiel.

Wir haben nicht den Raum, um WAI-ARIA hier im Detail zu behandeln, Sie können viel mehr darüber lernen bei WAI-ARIA-Grundlagen.

Da wir nun die Überlegungen zur Barrierefreiheit für verschiedene Web-Technologien behandelt haben, einschließlich einiger Testtechniken (wie Tastaturnavigation und Farbkontrastprüfer), schauen wir uns einige andere Tools an, die Sie beim Testen auf Barrierefreiheit nutzen können.

Es gibt eine Reihe von Prüftools, die Sie Ihren Webseiten füttern können. Sie werden sie überprüfen und eine Liste von Barrierefreiheitsproblemen auf der Seite zurückgeben. Lassen Sie uns ein Beispiel ansehen, indem wir Wave verwenden, ein Online-Prüftool für Barrierefreiheit, das eine Webadresse akzeptiert und eine annotierte Ansicht dieser Seite mit hervorgehobenen Barrierefreiheitsproblemen zurückgibt.

1. Gehen Sie auf die Wave-Startseite.
2. Geben Sie die URL unseres bad-semantics.html-Beispiels in das Texteingabefeld oben auf der Seite ein. Drücken Sie dann Enter oder klicken/tippen Sie auf den Pfeil an der äußersten rechten Kante des Eingabefelds.
3. Die Seite sollte mit einer Beschreibung der Barrierefreiheitsprobleme antworten. Klicken Sie auf die angezeigten Symbole, um weitere Informationen zu jedem der von Waves Bewertung ermittelten Probleme zu sehen.

Deque's aXe-Tool geht ein Stück weiter als die oben genannten Prüftools. Wie die anderen überprüft es Seiten und gibt Barrierefreiheitserrors zurück. Seine nützlichste Form ist wahrscheinlich die Browser-Erweiterungen:

• aXe für Chrome
• aXe für Firefox

Diese fügen den Browser-Entwicklertools einen Barrierefreiheitstab hinzu. Zum Beispiel haben wir die Firefox-Version installiert und damit unser bad-table.html-Beispiel überprüft. Wir erhielten die folgenden Ergebnisse:

aXe ist auch mit npm installierbar und kann in Aufgabenverwalter wie Grunt und Gulp, Automatisierungs-Frameworks wie Selenium und Cucumber, Unit-Testing-Frameworks wie Jasmine und mehr integriert werden (siehe erneut die Haupt-aXe-Seite für Details).

Es lohnt sich auf jeden Fall, mit einem Bildschirmleser zu testen, um sich daran zu gewöhnen, wie stark sehbehinderte Menschen das Internet nutzen. Es gibt eine Reihe von Bildschirmlesern:

• Einige sind kostenpflichtige kommerzielle Produkte, wie JAWS (Windows).
• Einige sind kostenfreie Produkte, wie NVDA (Windows), ChromeVox (Chrome, Windows und macOS) und Orca (Linux).
• Einige sind in das Betriebssystem integriert, wie VoiceOver (macOS und iOS), ChromeVox (auf Chromebooks) und TalkBack (Android).

Im Allgemeinen sind Bildschirmleser separate Apps, die auf dem Host-Betriebssystem ausgeführt werden und nicht nur Webseiten, sondern auch Text in anderen Apps lesen können. Das ist nicht immer der Fall (ChromeVox ist eine Browser-Erweiterung), aber normalerweise neigen Bildschirmleser dazu, auf leicht unterschiedliche Weise zu handeln und haben unterschiedliche Steuerungen, daher müssen Sie die Dokumentation für Ihren gewählten Bildschirmleser konsultieren, um alle Details zu erhalten - gesagt, dass sie alle im Grunde auf dieselbe Weise arbeiten.

Lassen Sie uns einige Tests mit ein paar verschiedenen Bildschirmlesern durchgehen, um Ihnen eine allgemeine Vorstellung zu geben, wie sie funktionieren und wie man mit ihnen testet.

VoiceOver

VoiceOver (VO) ist kostenlos mit Ihrem Mac/iPhone/iPad enthalten, sodass es nützlich ist, auf dem Desktop/Mobilgerät zu testen, wenn Sie Apple-Produkte verwenden. Wir werden es auf macOS auf einem MacBook Pro testen.

Um es einzuschalten, drücken Sie Cmd + F5. Wenn Sie VO noch nie verwendet haben, wird Ihnen ein Willkommensbildschirm angezeigt, auf dem Sie wählen können, ob Sie VO starten und ein wirklich nützliches Tutorial durchlaufen möchten, um zu lernen, wie Sie es verwenden. Um es wieder auszuschalten, drücken Sie erneut Cmd + F5.

Wenn VO eingeschaltet ist, sieht die Anzeige größtenteils gleich aus, aber Sie sehen ein schwarzes Kästchen unten links auf dem Bildschirm, das Informationen darüber enthält, was VO derzeit ausgewählt hat. Zudem wird die aktuelle Auswahl hervorgehoben, mit einem schwarzen Rahmen — diese Hervorhebung wird als VO-Cursor bezeichnet.

Um VO zu verwenden, werden Sie häufig den "VO-Modifizierer" verwenden — dies ist eine Taste oder Tastenkombination, die Sie zusätzlich zu den tatsächlichen VO-Tastaturkürzeln drücken müssen, um sie funktionieren zu lassen. Die Verwendung eines Modifizierers wie diesem ist bei Bildschirmlesern üblich, um zu verhindern, dass ihre Befehle mit anderen Befehlen kollidieren. Im Fall von VO kann der Modifizierer entweder CapsLock oder Ctrl + Option sein.

VO hat viele Tastaturbefehle, und wir werden nicht alle hier auflisten. Die grundlegendsten, die Sie für das Testen von Webseiten benötigen, sind in der folgenden Tabelle aufgeführt. In den Tastaturkürzeln bedeutet "VO" "der VoiceOver-Modifizierer".

Dies scheint eine Menge an Befehlen zu sein, aber es ist nicht so schlimm, wenn man sich daran gewöhnt, und VO gibt Ihnen regelmäßig Erinnerungen, welche Befehle in bestimmten Situationen zu verwenden sind. Spielen Sie jetzt mit VO herum; Sie können dann einige unserer Beispiele im Abschnitt Bildschirmleser-Tests ausprobieren.

NVDA

NVDA ist nur für Windows und Sie müssen es installieren.

1. Laden Sie es von nvaccess.org herunter. Sie können wählen, ob sie eine Spende leisten oder es kostenlos herunterladen möchten; Sie müssen zudem Ihre E-Mail-Adresse angeben, bevor Sie es herunterladen können.
2. Sobald es heruntergeladen ist, installieren Sie es — doppelklicken Sie auf das Installationsprogramm, akzeptieren Sie die Lizenz und folgen Sie den Aufforderungen.
3. Um NVDA zu starten, doppelklicken Sie auf die Programmdatei/Verknüpfung oder verwenden Sie das Tastenkürzel Strg + Alt + N. Bei Start sehen Sie den NVDA-Willkommensdialog. Hier können Sie aus ein paar Optionen wählen und dann die OK-Taste drücken, um zu beginnen.

NVDA ist jetzt auf Ihrem Computer aktiv.

Um NVDA zu verwenden, werden Sie den "NVDA Modifizierer" häufig verwenden — dies ist eine Taste, die Sie zusätzlich zu den tatsächlichen NVDA-Tastaturkürzeln drücken müssen, um sie funktioneren zu lassen. Die Verwendung eines Modifizierers wie diesem ist bei Bildschirmlesern üblich, um zu verhindern, dass ihre Befehle mit anderen Befehlen kollidieren. Im Fall von NVDA kann der Modifizierer entweder Einfügen (standardmäßig) oder CapsLock sein (kann durch Aktivieren des ersten Kontrollkästchens im NVDA-Willkommensdialog gewählt werden, bevor Sie OK drücken).

NVDA hat viele Tastaturbefehle, und wir werden nicht alle hier auflisten. Die grundlegendsten, die Sie für das Testen von Webseiten benötigen, sind in der folgenden Tabelle aufgeführt. In den Tastaturkürzeln bedeutet "NVDA" "der NVDA-Modifizierer".

Bildschirmleser-Tests

Jetzt, da Sie sich daran gewöhnt haben, einen Bildschirmleser zu verwenden, möchten wir, dass Sie ihn verwenden, um einige schnelle Barrierefreiheitstests durchzuführen, um eine Vorstellung davon zu bekommen, wie Bildschirmleser mit guten und schlechten Webseitenfeatures umgehen:

• Schauen Sie sich good-semantics.html an und beachten Sie, wie die Überschriften vom Bildschirmleser gefunden werden und für die Navigation verfügbar sind. Schauen Sie sich nun bad-semantics.html an und beachten Sie, wie der Bildschirmleser keine dieser Informationen erhält. Stellen Sie sich vor, wie ärgerlich das wäre, wenn Sie versuchen, eine wirklich lange Textseite zu navigieren.
• Schauen Sie sich good-links.html an und bemerken Sie, wie sie im Kontext Sinn ergeben. Dies ist nicht der Fall bei bad-links.html — sie sind alle nur "hier klicken".
• Schauen Sie sich good-form.html an und bemerken Sie, wie die Formulareingaben durch ihre Beschriftungen beschrieben werden, weil wir <label>-Elemente richtig verwendet haben. Bei bad-form.html erhalten sie eine unhilfreiche Bezeichnung wie "leer".
• Sehen Sie sich unser punk-bands-complete.html-Beispiel an und sehen Sie, wie der Bildschirmleser in der Lage ist, Spalten und Zeilen von Inhalten zu verknüpfen und sie zusammen vorzulesen, weil wir Kopfzeilen richtig definiert haben. In bad-table.html können keine Zellen assoziiert werden. Beachten Sie, dass NVDA sich leicht merkwürdig verhält, wenn Sie haben nur eine einzelne Tabelle auf einer Seite; Sie könnten die Tabelle-Testseite von WebAIM stattdessen ausprobieren.
• Werfen Sie einen Blick auf das WAI-ARIA Live Regions Beispiel, das wir zuvor gesehen haben, und bemerken Sie, wie der Bildschirmleser den ständig aktualisierten Abschnitt vorliest, während er aktualisiert wird.

Wie bereits erwähnt, können Sie sich nicht allein auf automatisierte Tools verlassen, um Barrierefreiheitsprobleme auf Ihrer Seite zu bestimmen. Es wird empfohlen, dass, wenn Sie Ihren Testplan erstellen, Sie – soweit möglich – einige Barrierefreiheits-Benutzergruppen einbeziehen (siehe unseren Benutzer-Test Abschnitt im vorherigen Kurs für mehr Kontext). Versuchen Sie, einige Benutzer von Bildschirmlesern, einige Benutzer, die nur die Tastatur verwenden, einige nicht hörende Benutzer und vielleicht andere Gruppen einzubeziehen, die Ihrer Anforderungen entsprechen.

Die folgende Liste bietet Ihnen eine Checkliste, der Sie folgen sollten, um sicherzustellen, dass Sie die empfohlenen Barrierefreiheitstests für Ihr Projekt durchgeführt haben:

1. Stellen Sie sicher, dass Ihr HTML so semantisch korrekt wie möglich ist. Validierung ist ein guter Anfang, ebenso wie die Verwendung eines Prüftools.
2. Überprüfen Sie, ob Ihr Inhalt Sinn ergibt, wenn das CSS ausgeschaltet ist.
3. Stellen Sie sicher, dass Ihre Funktionalität tastaturzugänglich ist. Testen Sie mit Tab, Return/Enter usw.
4. Stellen Sie sicher, dass Ihr nicht-Text-Inhalt über Textalternativen verfügt. Ein Prüftool ist gut, um solche Probleme zu erkennen.
5. Stellen Sie sicher, dass der Farbkontrast Ihrer Website akzeptabel ist, indem Sie ein geeignetes Prüfwerkzeug verwenden.
6. Stellen Sie sicher, dass der versteckte Inhalt von Bildschirmlesern sichtbar ist.
7. Stellen Sie sicher, dass die Funktionalität ohne JavaScript verwendbar ist, wo immer möglich.
8. Verwenden Sie ARIA, um die Barrierefreiheit gegebenenfalls zu verbessern.
9. Führen Sie Ihre Website mit einem Prüftool.
10. Testen Sie es mit einem Bildschirmleser.
11. Fügen Sie eine Barrierefreiheitspolitik/-erklärung irgendwo auffindbar auf Ihrer Seite ein, um zu sagen, was Sie getan haben.

Es gibt viele andere Probleme, die Sie bei der Barrierefreiheit antreffen werden; das Wichtigste, das Sie wirklich wissen müssen, ist, wie Sie online Antworten finden können. Konsultieren Sie den Abschnitt Hilfe finden des HTML- und CSS-Artikels für einige gute Hinweise.

Hoffentlich hat Ihnen dieser Artikel ein gutes Fundament in den Hauptproblemen der Barrierefreiheit geliefert, die Sie möglicherweise antreffen, und wie man sie testet und überwindet.

Im nächsten Artikel werden wir die Feature-Erkennung näher betrachten.

• Zurück
• Übersicht: Cross-Browser-Testing
• Weiter