Verbesserung der Barrierefreiheit von 24 Ways

Ich habe in letzter Zeit über die Natur meiner Arbeit nachgedacht und welche Aspekte davon mir am meisten Spaß machen. In einer Rolle, die oft die Bereiche Design und Entwicklung umfasst, sei es die Bearbeitung von Texten, die Bewertung des Designs einer Benutzeroberfläche oder das Refactoring von Code, habe ich festgestellt, dass meine Interessen im Bereich der Überprüfung und Verfeinerung liegen.

Meine Arbeit an 24 Ways ist ein gutes Beispiel dafür. Seitdem Drew McLellan mich 2013 bat, die Seite neu zu gestalten, bin ich Teil des Teams und helfe bei der Überprüfung, Bearbeitung und Formatierung von Artikeln. Aber ich konnte auch den Wunsch erfüllen, den ich bei der Einführung des Redesigns geäußert habe.

Ich glaube fest an Iteration und daran, eine Website niemals als abgeschlossen zu betrachten. Ich hoffe, dass das, was dieses Jahr veröffentlicht wurde, als Grundlage dienen kann und dass sich das Design in den kommenden Jahren weiterentwickeln wird.

In den dazwischen liegenden Jahren, als sich die Werkzeuge verbessert und die Best Practices weiterentwickelt haben, habe ich das Design angepasst und den Code refaktorisiert und dabei eine Komponentenbibliothek entwickelt.

Fokus auf Barrierefreiheit

Dieses Jahr habe ich Leuten wie Laura Kalbag über Barrierefreiheit im Sinne von Universal Design zugehört und Blogs wie Heydon Pickerings Inclusive Components verfolgt, die sich mit dem Design und der Implementierung gängiger Interaktionsmuster mit einem inklusiven Ansatz befassen. Plötzlich fühlte sich das schwierige Thema Barrierefreiheit zugänglicher und weniger dogmatisch an.

Nachdem ich all dieses Wissen verdaut hatte, war ich begierig darauf zu sehen, wie sich 24 Ways unter dem Mikroskop schlagen würde. In diesem Artikel werde ich fünf Bereiche abdecken, in denen ich Verbesserungen vornehmen konnte.

• Seitenstruktur
• Beschriftung von Elementen
• Tastaturnavigation
• Aurales Erlebnis
• Allgemeine Benutzerfreundlichkeit

Bevor ich beginne, ein Dankeschön. Nachdem ich eine erste Reihe von Änderungen vorgenommen hatte, bat ich meinen Freund und Barrierefreiheitsexperten Francis Storr, meine Arbeit zu überprüfen. Er deckte eine Reihe zusätzlicher Probleme auf, teilweise aufgrund seiner Erfahrung in diesem Bereich, aber auch durch das Testen der Website mit einer Reihe verschiedener Hilfstechnologien.

Neubewertung der Seitenstruktur

Das ursprüngliche Design hatte einen Mobile-First-Ansatz verfolgt. Die Navigation wurde zurückgestellt und am Ende der Seite platziert. Um sicherzustellen, dass sie in Nicht-JavaScript-Szenarien von oben auf der Seite zugänglich war, fügte ich einen Link zum **Überspringen der Navigation** hinzu. Wenn JavaScript verfügbar war, wurde dieser Link umfunktioniert, um eine Navigationsschublade zu enthüllen, die je nach Breite des Viewports von oben oder rechts hereinrutschte. Dies führte zur folgenden Seitenstruktur.

<header class="c-banner">…</header>
<a class="c-menu" href="#menu">Jump to menu</a>
<main class="c-main">…</main>
<nav class="c-navigation" id="menu">
  <div class="c-traverse-nav">…</div>
  <div class="c-navigation__drawer"/>…</div>
</nav>
<footer class="c-contentinfo">…</footer>

Rückblickend war dies aus mehreren Gründen problematisch.

• Der Menüknopf (.c-menu) befand sich nicht neben dem Element, das er steuerte (c-navigation-drawer). Das Verschieben des Fokus auf diese Weise kann verwirrend sein, insbesondere wenn es nicht richtig verwaltet wird.
• Die gesamte Navigation auf der Website wurde zusammengefasst, obwohl jede Linkgruppe einen anderen Zweck erfüllte.

• Das Schubladenverhalten beruhte darauf, dass ein Link wie ein Button funktionierte. Jedoch besagt die erste Regel von ARIA:

  Wenn Sie ein natives HTML-Element oder -Attribut verwenden *können*, das die von Ihnen benötigten Semantik und das von Ihnen benötigte Verhalten **bereits integriert** hat, anstatt ein Element umzufunktionieren und eine ARIA-Rolle, einen Zustand oder eine Eigenschaft hinzuzufügen, um es zugänglich zu machen, **dann tun Sie es**.

  Letztes Jahr habe ich das JavaScript aktualisiert, so dass dieser Link durch einen button ersetzt wurde, aber diese Komplexität war ein Hinweis darauf, dass meine ursprüngliche Lösung suboptimal war.

Hier ist die Struktur, zu der ich heute gekommen bin.

<header class="c-banner">
  …
  <a class="c-banner__skip" href="#main">Skip to content</a>
</header>
<div class="c-menu">
  <button class="c-menu__button">…</button>
  <div class="c-menu__drawer">…</div>
</div>
<main class="c-main" id="main">…</main>
<nav class="c-traverse-nav">…</nav>
<footer class="c-contentinfo">…</footer>

Durch die Verlagerung der Navigation nach oben auf der Seite waren der Button und die Schublade nun nebeneinander platziert. Der Menüknopf ist nicht mehr zweigesichtig; er ist und bleibt ein Button.

Ein Nachteil dieses Ansatzes ist, dass die Navigation jedes Mal gehört werden kann, wenn Sie eine neue Seite besuchen. Auch hier können wir einen Skip-Link verwenden, diesmal jedoch einen, der auf den Inhaltsblock (#main) verweist. Anstatt dieses fokussierbare Element vor bestimmten Benutzern zu verstecken, wird es bei Fokus sichtbar.

Diese Struktur ist vielleicht weniger ideologisch rein, aber weitaus pragmatischer. Dies wurde zu einem wiederkehrenden Thema. Da ich jegliche Hoffnung auf die Unterstützung des HTML5-Outline-Algorithmus durch Browser aufgegeben hatte, hörte ich auf, h1 für Abschnittsüberschriften zu verwenden, und folgte der Empfehlung, dass Überschriftenränge verwendet werden sollten, um die Dokumentenstruktur zu vermitteln.

Verbesserung der Tastaturnavigation

Als interaktivste Komponente der Website war das Menü der überraschende Fokus meiner Überprüfung. Das Design sieht vor, dass die Navigationsschublade wie ein Dialog funktioniert, ein Benutzeroberflächenmuster, das eine Reihe von Annahmen mit sich bringt. Diese sind detailliert in eBay's MIND-Pattern beschrieben, aber im Wesentlichen zieht ein Dialog den Fokus von anderen Elementen auf der Seite ab und ist modal; nur Elemente darin können bedient werden, während er geöffnet ist.

Ich hatte zuvor verschiedene JavaScript-Schnipsel zusammengeschustert, um den Fokus zu verwalten (Schustern, das zu verschiedenen Zeiten seltsame Fehler hervorbrachte, wie z. B. das Nicht-Fokussieren des ersten Elements im Dialog), aber versäumt, die Rolle des Menüs anzugeben. Nachdem diese Probleme behoben waren (role='dialog' beim Öffnen des Menüs hinzugefügt), wies Francis darauf hin, dass Screenreader weiterhin auf Links außerhalb des Dialogs zugreifen konnten, wenn dieser geöffnet war. In macOS VoiceOver würde beispielsweise das Drücken von STRG + OPT + CMD + L zur Navigation durch Links innerhalb des Menüs tatsächlich jeden Link auf der Seite ankündigen.

Die Lösung bestand darin, alles außerhalb des Dialogs als "inert" zu markieren. Rob Dodson beschreibt dies in seinem Video Accessible Modal Dialogs näher. Die Implementierung kann etwas knifflig sein, aber ein Vorschlag zur Einführung eines inert-Attributs würde die Verwaltung erleichtern. In der Zwischenzeit bietet der Vorschlag ein Polyfill, sodass Sie diese Funktion bereits heute nutzen können.

Ich habe festgestellt, dass das Denken über eine Benutzeroberfläche in Bezug auf gängige Interaktionsmuster und deren Funktionsweise, um weit verbreitet verstanden zu werden, mir geholfen hat, Komplexität zu vermeiden und robusteren Code zu schreiben. Tatsächlich hat das Eintauchen in die Welt der Barrierefreiheit eine Fülle nützlicher Ressourcen aufgedeckt, mit gut geschriebenen JavaScript-Beispielen in Hülle und Fülle. Angesichts meiner schwierigen Beziehung zur Programmiersprache des Webs waren diese von unschätzbarem Wert.

Elemente korrekt beschriften

Ein erheblicher Teil der Barrierefreiheit besteht darin, Dinge zu beschriften, die allein auf visuelle Erscheinung angewiesen sind, um Bedeutung zu vermitteln. Ähnlich wie das alt-Attribut uns erlaubt, Bilder zu beschreiben, erweitern aria-label (und seine Verwandten) diese Fähigkeit auf andere Elemente.

Hier ist der Markup, den ich im Navigationselement verwendet habe, das es Benutzern ermöglicht, durch vorherige und nächste Artikel in einer Reihe zu navigieren.

<div class="c-traverse-nav">
  <a rel="prev" href="/2016/we-need-to-talk-about-technical-debt/"
    data-sequence-title="We Need to Talk About Technical Debt">
    <svg width="20" height="20" viewBox="0 0 200 200" role="img">
      <path d="M50 100l85 85 7-7-78-78 78-78-7-7"/>
    </svg>
    <span class="u-hidden">Previous article</span>
  </a>

  <a rel="next" href="/2016/what-the-heck-is-inclusive-design/"
    data-sequence-title="What the Heck Is Inclusive Design?">
    <span class="u-hidden">Next article</span>
    <svg width="20" height="20" viewBox="0 0 200 200" role="img">
      <path d="M150 100l-85 85-7-7 78-78-78-78 7-7"/>
    </svg>
  </a>
</div>

Obwohl ich Textinhalte für diese Links bereitgestellt hatte, hatte diese Komponente immer noch eine Reihe von Problemen.

• Es gab keine Angabe über die Rolle, die diese Links spielen, und ihre Beziehung zueinander.
• Die Verwendung von role='img' für die SVG-Icons, ohne zugängliche Namen bereitzustellen, war vergleichbar mit der Einbindung von Bildern ohne alt-Attribute.
• Nützliche Informationen, in diesem Fall der Titel des vorherigen und nächsten Artikels, waren in einem data--Attribut versteckt. Dieses Attribut wurde in der Stylesheet verwendet, um Inhalte hinzuzufügen, die in animierten "Klappen" angezeigt werden, die beim Hovern erscheinen.

 .c-traverse-nav a[rel=prev]:hover::after {
  content: 'Previous: \A' attr(data-sequence-title);
}

.c-traverse-nav a[rel=next]:hover::after {
  content: 'Next: \A' attr(data-sequence-title);
}

Bedeutungsvolle Inhalte in CSS? Das hätte ein Warnsignal sein sollen. Ich habe diese Komponente wie folgt überarbeitet.

<nav class="c-traverse-nav" aria-label="Articles">
  <a rel="prev" href="/2016/what-the-heck-is-inclusive-design/"
    aria-label="Previous: We Need to Talk About Technical Debt">
    <svg width="20" height="20" viewBox="0 0 200 200" focusable="false" aria-hidden="true">
      <path d="M50 100l85 85 7-7-78-78 78-78-7-7"/>
    </svg>
  </a>

  <a rel="next" href="/2016/what-the-heck-is-inclusive-design/"
    aria-label="Next: What the Heck Is Inclusive Design?">
    <svg width="20" height="20" viewBox="0 0 200 200" focusable="false" aria-hidden="true">
      <path d="M150 100l-85 85-7-7 78-78-78-78 7-7"/>
    </svg>
  </a>
</nav>

Das Erste, was ich tat, war, dieser Linkgruppe eine Beschriftung zu geben. Ursprünglich wählte ich Articles navigation. Beim Testen mit VoiceOver wurde jedoch angekündigt: navigation, Articles navigation. Da das nav-Element bereits die Rolle beschreibt, müssen wir nur zusätzliche Informationen über die Art dieser Navigation bereitstellen.

Zweitens, auf Anraten von Francis, fügte ich focusable='false' zu allen Inline-SVG-Markups hinzu. Dies liegt an einem Fehler in IE11, bei dem SVGs standardmäßig per Tastatur fokussierbar sind.

Bezüglich der Beschriftung der SVG-Icons hatte ich zwei Möglichkeiten. Ich konnte entweder den versteckten Textinhalt mit aria-label auf diese Icons übertragen oder sie mit aria-hidden aus dem Accessibility-Baum entfernen. Bei der Betrachtung der zweiten Option erkannte ich, dass ich den versteckten Text mit dem im data--Attribut zusammenführen und diese kombinierten Informationen in einem aria-label-Attribut verwenden konnte. Plötzlich wurde mein CSS viel einfacher.

.c-traverse-nav a:hover::after {
  content: attr(aria-label);
}

Zugänglicher Markup ist nützlicher Markup.

Berücksichtigung des auralen Erlebnisses

Die Navigation auf der Website mit einem Screenreader führte dazu, dass ich auch einige andere kleine Änderungen vorgenommen habe. Zum Beispiel enthalten einige Links auf der Website einen Pfeil nach rechts, eine visuelle Ausgestaltung, die mit der folgenden CSS erstellt wurde.

.c-continue::after {
  content: ' \203A'; /* Single Right-Pointing Angle Quotation Mark */
}

Screenreader kündigen generierte Inhalte jedoch typischerweise an. Wenn diese Links vorgelesen wurden, hörte man Unsinn wie diesen.

link, weitere Artikel von drew single right-pointing angle quotation mark.

Das Hinzufügen von speak: none hatte keine Auswirkung (CSS-aural-Eigenschaften haben wenig Unterstützung). Ich konnte jedoch einen ähnlichen Pfeil mit CSS-Rändern erstellen.

.c-continue::after {
  display: inline-block;
  vertical-align: middle;
  height: 0.375em;
  width: 0.375em;
  border: 0.1875em solid;
  border-color: currentColor currentColor transparent transparent;
  transform: rotate(45deg);
  content: '';
}

Ich habe auch die Gestaltung von Autorennamen in Artikelzusammenfassungen verbessert. Ursprünglich wurden diese vom Rest des Auszugs durch die Darstellung als Großbuchstaben unterschieden. Francis wies darauf hin, dass einige Screenreader Großbuchstaben buchstabieren (unabhängig davon, ob sie im HTML erscheinen oder durch CSS verändert wurden), wenn sie kein bekanntes Wort buchstabieren. VoiceOver und NVDA haben beispielsweise Schwierigkeiten mit dem Nachnamen von Chris Coyier, sodass sein Name als Chris C-O-Y-I-E-R vorgelesen würde. Die einfache Lösung war, Namen stattdessen durch fettgedruckten Text zu kennzeichnen.

Wenn ich ehrlich bin, war ich in der Vergangenheit eher arrogant und dachte, dass ich durch die Verwendung von semantischem Markup und progressivem Enhancement nicht zu viel über Barrierefreiheit nachdenken müsste. Während die Verwendung der richtigen Elemente und die Betrachtung einer Benutzeroberfläche nicht nur in visueller Hinsicht wichtig ist, ist dies das absolute Minimum. Ein Verständnis verschiedener Hilfstechnologien und die Bereitschaft, mit ihnen zu testen, ist ebenso wichtig.

Überprüfung der allgemeinen Benutzerfreundlichkeit

Das Nachdenken über Barrierefreiheit hat mich dazu veranlasst, auch die allgemeine Benutzerfreundlichkeit zu verbessern.

Für die diesjährigen Artikel verlinken wir nicht mehr von den Artikel-Exzerpten zu den Websites der Autoren. Dieser historische Überbleibsel war schlecht gelöst; wenn man zufällig auf den Namen des Autors klickte, gelangte man zu dessen Website und nicht, wie erwartet, zum Artikel. Wir haben auch Kommentaranzahlen eingebunden, die mit dem Kommentarbereich auf der Artikelseite verlinkt waren (der selbst zu einer separaten Kommentarseite verlinkte). Wahnsinn!

Jetzt hat jeder Artikel einen Link; zum Artikel. Eine Startseite, die früher durch 24×3 Links getabt werden musste, ist jetzt weniger unübersichtlich und für alle leichter zu navigieren.

Weitere Verfeinerungen umfassten die Sicherstellung, dass die Website sowohl in Bezug auf die Höhe als auch auf die Breite responsiv ist, dass das Navigationsmenü geschlossen werden kann, wenn man außerhalb klickt, und eine Überprüfung der Gesamtleistung. Diese werden vielleicht nicht als Verbesserungen der Barrierefreiheit betrachtet, aber ich bin mir da nicht so sicher. Dies anzunehmen, würde bedeuten, Barrierefreiheit als eine völlig separate Angelegenheit zu betrachten. Tatsächlich werden Änderungen, die einer Nutzergruppe zugutekommen, typischerweise allen zugutekommen.

---

Etwas Neues zu schaffen wird immer Aufmerksamkeit und Bewunderung erregen, aber es gibt eine unterbewertete Adelung darin, das Bestehende zu verbessern. Obwohl nicht alle Änderungen visuell sind, können sie genauso viel Wirkung haben. Ich weiß, dass viele dieser Verbesserungen nicht vorgenommen worden wären, wenn wir uns entschieden hätten, die Website dieses Jahr neu zu gestalten. Hoffentlich ermutigt Sie dieser Überblick, Ihre eigenen Projekte zu betrachten und über ähnliche Änderungen nachzudenken, die Sie vornehmen könnten.

Ein wachsendes Bewusstsein für die Probleme und die Erweiterung Ihres Wissens über die verfügbaren Werkzeuge ist eine wesentliche Voraussetzung für die Arbeit im Web. Behalten Sie dieses Wissen jedoch nicht für die Zukunft zurück; wenn Sie können, gehen Sie zurück und beheben Sie auch Ihre älteren Projekte.