Gut, besser, am besten: Die komplexe Welt der zugänglichen Muster entwirren

Veröffentlicht: 2022-03-10
Kurze Zusammenfassung ↬ Woher wissen wir, welche Muster gut, besser, am besten sind, wenn es um Zugänglichkeit geht? Ist es besser, ein etabliertes Muster/eine Bibliothek zu verwenden oder neue zu erstellen? Angesichts der unzähligen verfügbaren Auswahlmöglichkeiten können wir uns bei diesem Thema schnell in einem Netz der Verwirrung verfangen.

Marc Benioff hat denkwürdigerweise gesagt, dass die einzige Konstante in der Technologiebranche der Wandel ist. Da ich über 15 Jahre in der Technik gearbeitet habe, kann ich das bestätigen. Andere Tech-Dinosaurier können bezeugen, dass die Art und Weise, wie das Internet in den frühen Tagen funktionierte, drastisch anders war, als viele von uns es sich jemals hätten vorstellen können.

Während dieser ständige Wandel in der Technologiebranche zu Innovationen und Fortschritten geführt hat, die wir heute sehen, hat er auch das Konzept der Wahlfreiheit eingeführt. Auch wenn die Auswahl – oberflächlich betrachtet – wie eine von Natur aus positive Sache erscheinen mag, ist sie nicht immer gleichbedeutend mit Regenbogen und Rosen. Der Zustrom des technologischen Wandels bringt auch das Aufsplittern von Programmiersprachen und die nie endenden Geschmacksrichtungen der Programmier-„Schärfe“ mit sich. Manchmal verwandelt sich diese Fülle an Auswahlmöglichkeiten in eine Überauswahl – eine gut untersuchte kognitive Beeinträchtigung, bei der Menschen Schwierigkeiten haben, eine Entscheidung zu treffen, weil sie zu viele Optionen haben.

In diesem Artikel werden wir versuchen, die komplexe Welt der zugänglichen Muster zu entwirren – Schritt für Schritt. Wir werden die Dinge beginnen, indem wir aktuelle barrierefreie Muster und Bibliotheken überprüfen, dann werden wir unsere allgemeinen Musteranforderungen und potenziellen Einschränkungen betrachten, und schließlich werden wir eine Reihe von kritischen Denkübungen durchlaufen, um zu lernen, wie Muster besser auf Barrierefreiheit bewertet werden können.

Was für ein verworrenes Netz wir weben

Overchoice hat sich in alle Aspekte der Technologie eingeschlichen, einschließlich der Muster und Bibliotheken, die wir zum Erstellen unserer digitalen Kreationen verwenden – vom einfachen Kontrollkästchen bis zum komplexen dynamischen Modal und allem dazwischen. Aber woher wissen wir, welches Muster oder welche Bibliothek das richtige ist, wenn es so viele Möglichkeiten gibt? Ist es besser, etablierte Muster/Bibliotheken zu verwenden, denen Benutzer täglich begegnen? Oder ist es besser, brandneue Muster für ein angenehmeres Benutzererlebnis zu erstellen?

Angesichts der unzähligen verfügbaren Optionen können wir schnell von der Überfülle an Auswahlmöglichkeiten gelähmt werden. Aber wenn wir einen Schritt zurücktreten und überlegen, warum wir unsere digitalen Produkte überhaupt bauen (dh der Endbenutzer), ist es nicht sinnvoll, das Muster oder die Bibliothek zu wählen, die den größten Mehrwert für die größte Anzahl von Menschen bietet ?

Wenn Sie dachten, dass die Auswahl eines Musters oder einer Bibliothek bereits ein entmutigender Prozess ist, ist dies möglicherweise der Punkt, an dem Sie anfangen, sich Sorgen zu machen. Aber kein Grund zur Sorge – die Auswahl eines barrierefreien Musters/einer barrierefreien Bibliothek ist kein Hexenwerk. Wie alles andere in der Technologie beginnt diese Reise mit ein wenig Wissen, einer Menge Trial-and-Error und dem Verständnis, dass es nicht nur ein perfektes Muster / eine perfekte Bibliothek gibt, die zu jedem Benutzer, jeder Situation oder jedem Framework passt.

Woher weiß ich das? Nun, ich habe die letzten fünf Jahre damit verbracht, verschiedene Arten von barrierefreien Mustern zu erforschen, zu erstellen und zu testen, während ich am A11y Style Guide, der ARIA-Musterbibliothek von Deque und der Bewertung beliebter SVG-Muster gearbeitet habe. Aber ich habe auch viele Client-Patterns und Bibliotheken auf jedem erdenklichen Framework/Plattform überprüft. Zum jetzigen Zeitpunkt kann ich ohne Bedenken sagen, dass es eine angeborene Hierarchie für die Zugänglichkeit von Mustern gibt, die sich zu entwickeln beginnt, wenn man lange genug hinschaut. Und obwohl es gelegentlich Muster gibt, die um jeden Preis vermieden werden müssen, ist es nicht immer so eindeutig. Wenn es um Zugänglichkeit geht, würde ich argumentieren, dass die meisten Muster in Gradienten von gut, besser, am besten fallen. Der schwierige Teil ist zu wissen, welches Muster in welche Kategorie gehört.

Mehr nach dem Sprung! Lesen Sie unten weiter ↓

Kritisches Denken über Muster

Woher wissen wir also, welche Muster gut, besser, am besten sind, wenn es um Zugänglichkeit geht? Es hängt davon ab, ob. Dieser oft zitierte Satz aus der Community für digitale Zugänglichkeit ist keine Ausrede, sondern eine Abkürzung für „Wir brauchen mehr Kontext, um Ihnen die beste Antwort geben zu können“. Der Kontext ist jedoch nicht immer klar, daher stelle ich beim Erstellen und Bewerten der Zugänglichkeit eines Musters einige grundlegende Fragen:

  • Gibt es bereits ein etabliertes barrierefreies Muster, das wir verwenden können?
  • Welche Browser und Geräte mit assistiver Technologie (AT) unterstützen wir?
  • Gibt es Framework-Einschränkungen oder andere Integrationen/Faktoren, die berücksichtigt werden müssen?

Natürlich können Ihre spezifischen Fragen von meinen abweichen, aber der Punkt ist, dass Sie anfangen müssen, Ihre kritischen Denkfähigkeiten einzusetzen, wenn Sie Muster bewerten. Sie können dies tun, indem Sie zuerst jedes Muster für die Zugänglichkeit beobachten, analysieren und dann einordnen, bevor Sie eine endgültige Entscheidung treffen. Aber bevor wir dazu kommen, lassen Sie uns zunächst etwas mehr auf die anfänglichen Fragen eingehen.

Gibt es bereits ein etabliertes barrierefreies Muster?

Warum scheint es, dass wir mit jedem neuen Framework eine ganze Reihe neuer Muster erhalten? Diese ständige Neuerfindung des Rades mit neuen Musteroptionen kann Entwickler verwirren und frustrieren, zumal dies normalerweise nicht erforderlich ist.

Glauben Sie mir nicht? Stellen Sie sich das so vor: Wenn wir uns dem Atomic Design System anschließen, verstehen wir, dass mehrere kleine Code-„Atome“ zusammenkommen, um ein größeres digitales Produkt zu erstellen. Aber in der wissenschaftlichen Welt sind Atome nicht die kleinste Komponente des Lebens. Jedes Atom besteht aus vielen subatomaren Teilchen wie Protonen, Neutronen und Elektronen.

Dieselbe Logik lässt sich auf unsere Muster anwenden. Wenn wir uns alle Muster genauer ansehen, die in den verschiedenen bestehenden Frameworks verfügbar sind, ist die subatomare Kernstruktur im Wesentlichen dieselbe, unabhängig von der tatsächlich verwendeten Programmiersprache. Aus diesem Grund schätze ich optimierte Codierungsbibliotheken mit zugänglichen Mustern, auf denen wir basierend auf technologischen und gestalterischen Anforderungen aufbauen können.

Hinweis : Einige großartige seriöse Quellen sind Inclusive Components, Accessible Components und das Gov.UK Design System, zusätzlich zu der Liste der zugänglichen Muster, die das Smashing Magazine kürzlich veröffentlicht hat (plus eine detailliertere Liste von Mustern und Bibliotheken am Ende des Artikels). .

Welche Browser und Assistive Technology (AT)-Geräte unterstützen wir?

Nachdem wir einige grundlegende Muster recherchiert haben, die funktionieren könnten, können wir uns der Frage der Unterstützung von Browsern und assistiven Technologien (AT) zuwenden. Browserunterstützung allein ist kein Scherz. Wenn Sie der Mischung AT-Geräte und ARIA-Spezifikationen hinzufügen, werden die Dinge schwierig … nicht unmöglich, nur viel mehr Zeit, Mühe und Denkprozess, um alles herauszufinden.

Aber es sind nicht nur schlechte Nachrichten. Es gibt einige fabelhafte Ressourcen wie HTML5 Accessibility und Accessibility Support, die uns helfen, ein besseres Verständnis für die aktuelle Unterstützung von Browsern und AT-Geräten zu erlangen. Diese Websites beschreiben die verschiedenen verfügbaren HTML- und ARIA-Muster-Unterelemente, enthalten Open-Source-Community-Tests und stellen einige Musterbeispiele bereit – sowohl für Desktop- als auch für mobile Browser/AT-Geräte.

Gibt es Framework-Einschränkungen oder andere zu berücksichtigende Integrationen/Faktoren?

Nachdem wir einige zugängliche Basismuster ausgewählt und die Browser-/AT-Geräteunterstützung berücksichtigt haben, können wir zu detaillierteren kontextbezogenen Fragen rund um das Muster und seine Umgebung übergehen. Wenn wir beispielsweise ein Muster in einem Content-Management-System (CMS) verwenden oder Legacy-Code berücksichtigen, gibt es bestimmte Mustereinschränkungen. In diesem Fall kann eine Handvoll Musteroptionen schnell auf ein oder zwei reduziert werden. Auf der anderen Seite sind einige Frameworks nachsichtiger und offener dafür, jedes Muster zu akzeptieren, sodass wir uns weniger Gedanken über Framework-Einschränkungen machen müssen und uns mehr darauf konzentrieren können, die zugänglichste Musterauswahl zu treffen, die wir treffen können.

Neben allem, was wir bisher besprochen haben, müssen bei der Auswahl eines Musters viele zusätzliche Überlegungen berücksichtigt werden, z. B. Leistung, Sicherheit, Suchmaschinenoptimierung, Sprachübersetzung, Integration von Drittanbietern und mehr. Diese Faktoren spielen zweifellos bei der Auswahl zugänglicher Muster eine Rolle, aber Sie sollten auch an die Personen denken, die die Inhalte erstellen. Das von Ihnen gewählte barrierefreie Muster muss robust genug sein, um potenzielle Einschränkungen in Bezug auf vom Editor und/oder Benutzer generierte Inhalte zu bewältigen.

Bewertung von Mustern für Barrierefreiheit

Code sagt oft mehr als Worte, aber bevor wir uns auf all das einlassen, eine kurze Anmerkung, dass die folgenden Musterbeispiele nicht die einzigen Muster sind, die für jede Situation verfügbar sind, noch ist dasjenige, das in der Gruppe als „beste“ erachtet wird, die beste Option in der Gruppe ganze Welt zugänglicher Muster.

Für die Musterdemos unten sollten wir uns eine hypothetische Situation vorstellen, in der wir jede Gruppe von Mustern mit sich selbst vergleichen. Obwohl dies keine realistische Situation ist, sollten Sie durch diese Übungen zum kritischen Denken und die Bewertung der Muster für die Zugänglichkeit besser vorbereitet sein, wenn Sie in der realen Welt auf die Musterauswahl stoßen.

Zugängliche Schaltflächenmuster

Die erste Gruppe von Mustern, die wir auf Zugänglichkeit überprüfen werden, ist auf fast jeder Website oder App allgegenwärtig: Schaltflächen. Das erste Schaltflächenmuster verwendet die ARIA-Schaltflächenrolle, um eine Schaltfläche nachzuahmen, während das zweite und dritte Schaltflächenmuster das HTML- <button> -Element verwenden. Das dritte Muster fügt auch aria-describedby und CSS hinzu, um Dinge visuell zu verbergen.

Siehe den Stift [Zugängliche Tastenmuster](https://codepen.io/smashingmag/pen/KKNEjKR) von Carie Fisher.

Sehen Sie sich die Muster für stiftzugängliche Schaltflächen von Carie Fisher an.

Gut: role="button"

 <a role="button" href="[link]">Sign up</a>

Besser: <button>

 <button type="button">Sign up</button>

Am besten: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

Während die ersten Muster auf den ersten Blick einfach erscheinen, werfen sie einige Fragen zur Barrierefreiheit auf. Beim ersten Schaltflächenmuster sehen wir beispielsweise, dass ARIA role="button" anstelle eines HTML- <button> -Elements beim "guten" Muster verwendet wird. Da wir wissen, dass das HTML- <button> -Element in HTML4 eingeführt wurde, können wir vernünftigerweise spekulieren, dass es von den neuesten Versionen aller wichtigen Browser vollständig unterstützt wird und mit den meisten AT-Geräten gut funktioniert. Aber wenn wir tiefer graben und uns die Barrierefreiheitsunterstützung für ARIA role="button" ansehen, sehen wir einen leichten Vorteil aus der Sicht der Hilfstechnologie, während dem HTML- <button> -Element einige Bereiche der Browser- und AT-Abdeckung fehlen, insbesondere wenn wir dies berücksichtigen Unterstützung der Sprachsteuerung.

Warum ist das ARIA-Muster dann nicht in der Kategorie „besser“? Macht ARIA es nicht zugänglicher? Nö. Tatsächlich rezitieren Fachleute für Barrierefreiheit in solchen Fällen oft die erste Regel von ARIA – verwenden Sie ARIA nicht. Dies ist eine augenzwinkernde Art zu sagen, wann immer möglich HTML-Elemente zu verwenden. ARIA ist in der Tat mächtig, aber in den falschen Händen kann es mehr schaden als nützen. Tatsächlich heißt es im WebAIM Million-Bericht, dass „Seiten mit ARIA-Präsentation durchschnittlich 60 % mehr Fehler aufwiesen als solche ohne“. Daher müssen Sie wissen, was Sie tun, wenn Sie ARIA verwenden.

Ein weiterer Kritikpunkt gegen die Verwendung von ARIA in dieser Situation ist, dass die von uns benötigte Schaltflächenfunktionalität für das Muster role="button" erstellt werden müsste, während diese Funktionalität bereits im Element <button> vorgebacken ist. Wenn man bedenkt, dass das <button> -Element auch 100 % Browserunterstützung hat und ein einfach zu implementierendes Muster ist, liegt es in der Hierarchie leicht vorne, wenn man die ersten beiden Muster auswertet. Hoffentlich hilft dieser Vergleich dabei, mit dem Mythos aufzuräumen, dass das Hinzufügen von ARIA ein Muster zugänglicher macht – oft ist das Gegenteil der Fall.

Das dritte Schaltflächenmuster zeigt das HTML- <button> -Element, gekoppelt mit aria-describedby , verknüpft mit einem ID-Element, das mit CSS visuell verborgen ist. Obwohl dieses Muster etwas komplexer ist, fügt es viel Kontext hinzu, indem es eine Beziehung zwischen der Schaltfläche und dem Zweck herstellt. Im Zweifel ist es immer besser, wenn wir der Situation mehr Kontext hinzufügen können, sodass wir davon ausgehen können, dass es bei korrekter Codierung das beste Muster ist, wenn wir nur diese spezifischen Schaltflächenmuster vergleichen.

Zugängliche kontextbezogene Linkmuster

Die zweite Gruppe von Mustern, die wir betrachten werden, sind kontextbezogene Links. Diese Muster tragen dazu bei, AT-Benutzern mehr Informationen zu geben, als auf dem Bildschirm sichtbar sind. Das erste Verknüpfungsmuster verwendet CSS, um die zusätzlichen Kontextinformationen visuell zu verbergen. Während das zweite und dritte Verknüpfungsmuster dem Mix ARIA-Attribute hinzufügen: aria-labelledby bzw. aria-label .

Siehe den Pen [Accessible Link Patterns](https://codepen.io/smashingmag/pen/VwmRJYv) von Carie Fisher.

Siehe die Pen Accessible Link Patterns von Carie Fisher.

Gut: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Besser: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

Am besten: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

Während alle drei kontextbezogenen Verknüpfungsmuster gleich aussehen, gibt es einige offensichtliche Unterschiede, wenn wir den Code untersuchen oder sie mit AT-Geräten testen. Das erste Muster verwendet eine CSS-Technik, um den Inhalt für sehende Benutzer visuell zu verbergen, rendert den verborgenen Inhalt jedoch weiterhin für nicht sehende AT-Benutzer. Und obwohl diese Technik in den meisten Fällen funktionieren sollte , wird zwischen dem Link und den zusätzlichen Informationen keine wirkliche Beziehung hergestellt, sodass die Verbindung bestenfalls vorläufig ist. Daher ist das erste Verknüpfungsmuster eine gute Wahl, aber nicht das robusteste Verknüpfungsmuster der drei.

Die nächsten beiden Verknüpfungsmuster sind etwas schwieriger auszuwerten. Gemäß den ARIA-Spezifikationen des W3C „ist der Zweck von aria-label derselbe wie der von aria-labelledby . Es bietet dem Benutzer einen erkennbaren Namen des Objekts.“ Theoretisch sollten also beide Attribute die gleiche grundlegende Funktionalität haben.

Die Spezifikationen weisen jedoch auch darauf hin, dass Benutzeragenten aria-labelledby gegenüber aria-label Vorrang einräumen, wenn sie entscheiden, welcher zugängliche Name dem Benutzer übermittelt werden soll. Die Forschung hat auch Probleme im Zusammenhang mit automatischer Übersetzung und Arienbezeichnungsattributen aufgezeigt. Das heißt also, wir sollten aria-labelledby , richtig?

Nun, nicht so schnell. Dieselben ARIA-Spezifikationen sagen weiter: „Wenn die Schnittstelle so ist, dass es nicht möglich ist, ein sichtbares Label auf dem Bildschirm zu haben (oder wenn ein sichtbares Label nicht die gewünschte Benutzererfahrung ist), sollten Autoren aria-label verwenden und sollten es nicht benutze aria-labelledby .“ Apropos verwirrend – also welches Muster sollen wir wählen?

Wenn wir einen großen Übersetzungsbedarf hätten, könnten wir uns entscheiden, den visuellen Aspekt zu ändern und die Links mit dem vollständigen angezeigten Kontext zu schreiben (z. B. „ Lesen Sie mehr über dieses tolle Ding “) oder uns entscheiden, aria-labelledby zu verwenden. Nehmen wir jedoch an, wir hätten keine umfangreichen Übersetzungsanforderungen oder könnten diese Anforderungen auf vernünftige/zugängliche Weise erfüllen, und wir wollten das Erscheinungsbild nicht ändern – was dann?

Basierend auf den aktuellen ARIA 1.1-Empfehlungen (mit dem Versprechen der Übersetzung von aria-label in ARIA 1.2) und der Tatsache, dass aria-label für Entwickler etwas einfacher zu implementieren ist als aria-labelledby , könnten wir uns entscheiden, aria-label höher zu gewichten aria-labelledby in unserer Musterauswertung. Dies ist ein klares Beispiel dafür, wann der Kontext bei der Wahl unserer barrierefreien Muster eine große Rolle spielt.

Zugängliche <svg> -Muster

Lassen Sie uns zu guter Letzt eine Gruppe von SVG-Bildmustern auf Barrierefreiheit untersuchen. SVGs sind eine visuelle Darstellung von Code, aber nichtsdestotrotz Code. Dies bedeutet, dass ein AT-Gerät möglicherweise ein nicht dekoratives SVG-Bild überspringt, es sei denn, das role="img" wird dem Muster hinzugefügt.

Unter der Annahme, dass die folgenden SVG-Muster informativer Natur sind, wurde in jedes ein role="img" . Das erste SVG-Muster verwendet <title> und <text> in Verbindung mit CSS, um Inhalte visuell vor sehenden Benutzern zu verbergen. Die nächsten beiden SVG-Muster beinhalten die <title> - und <desc> -Elemente, aber mit einem aria-labelledby Attribut, das dem letzten Muster hinzugefügt wurde.

Siehe den Stift [Zugängliche SVG-Muster](https://codepen.io/smashingmag/pen/poNYXvK) von Carie Fisher.

Sehen Sie sich die stiftzugänglichen SVG-Muster von Carie Fisher an.

Gut: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

Besser: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

Am besten: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

Schauen wir uns zuerst das erste Muster mit <title> und <text> und visuell verstecktem CSS an. Im Gegensatz zu zuvor sichtbar verborgenem Text in Mustern besteht eine inhärente Beziehung zwischen den <title> - und <text> -Elementen, da sie unter demselben SVG-Elementdach gruppiert sind. Diese Beziehung ist jedoch nicht sehr stark. Wenn Sie sich meine Forschungen zu SVG-Mustern ansehen, sehen wir tatsächlich, dass nur 3 von 8 Browser/AT-Kombinationen die vollständige Nachricht gehört haben. (Hinweis: Das Schweinemuster Nr. 1 entspricht dem Glühbirnenmuster Nr. 7.)

Dies trifft zu, obwohl die funktionierenden W3C-SVG-Spezifikationen das <text> -Element als „ein Grafikelement, das aus Text besteht … die zu zeichnenden Zeichen als Zeichendaten ausgedrückt werden, definieren. Dadurch sind Textdaten in SVG-Inhalten für Sehbehinderte leicht zugänglich.“ Dieses erste Muster ist in Ordnung, aber wir können es besser machen.

Das zweite Muster entfernt das <text> -Element und ersetzt es durch ein <desc> -Element. In den W3C-SVG-Spezifikationen heißt es:

„Das untergeordnete Element <title> stellt eine kurze Textalternative für das Element dar … und das Element <desc> stellt detailliertere Textinformationen für das Element dar, z. B. eine Beschreibung.“

Das bedeutet, dass die <title> - und <desc> -Elemente in SVGs ähnlich wie Bildalternativtext und lange Beschreibungsoptionen verwendet werden können, die traditionell in <img> -Elementen zu finden sind. Nach dem Hinzufügen des <desc> -Elements zum zweiten SVG sehen wir eine ähnliche Browser/AT-Unterstützung, wobei 3 von 8 Kombinationen die vollständige Nachricht hören. (Hinweis: Das Schweinemuster Nr. 2 entspricht dem Glühbirnenmuster Nr. 10.) Während diese Testergebnisse das erste Muster widerzuspiegeln scheinen, wird dieses Muster aus dem Grund in die Kategorie „besser“ eingestuft, weil es etwas einfacher ist, Code zu implementieren. klug und betrifft mehr AT-Benutzer, da es auf JAWS, VoiceOver Desktop und VoiceOver Mobile funktionierte, während das erste Muster weniger beliebte Browser/AT-Kombinationen unterstützte.

Das dritte Muster verwendet wieder die Elemente <title> und <desc> , hat aber jetzt eine aria-labelledby plus ID, die dem Mix hinzugefügt wurde. Laut denselben SVG-Tests bedeutet das Hinzufügen dieses zusätzlichen Codes, dass wir 7 von 8 Browser/AT-Kombinationen vollständig unterstützen können. (Hinweis: Das Schweinemuster Nr. 3 entspricht dem Glühbirnenmuster Nr. 11.) Von den drei SVG-Mustern ist dieses dritte das „beste“, da es die meisten AT-Geräte unterstützt. Aber dieses Muster hat einen Nachteil bei der Verwendung einiger Browser/AT-Kombinationen; Sie hören doppelte Bildtitel/Beschreibungsinhalte für dieses Muster. Obwohl es für die Benutzer möglicherweise nervig ist, würde ich argumentieren, dass es im Allgemeinen besser ist, duplizierte Inhalte zu hören als gar keine.

Abschließende Gedanken

Während wir alle die Wahlmöglichkeiten in der Technologie sicherlich schätzen, frage ich mich, ob wir an einem Punkt angelangt sind, an dem uns die Überfülle an Optionen gelähmt und verwirrt hat, was wir als nächstes tun sollen? In Bezug auf die Auswahl zugänglicher Muster können wir einfache Fragen zu Muster-/Bibliotheksoptionen, Browser-/AT-Geräteunterstützung, Framework-Einschränkungen und mehr stellen.

Mit den richtigen Daten sind diese Fragen leicht zu beantworten. Es wird jedoch etwas komplizierter, wenn wir über Muster hinausgehen und wirklich die Menschen berücksichtigen, die sie verwenden. Dann erkennen wir die Auswirkungen unserer Entscheidungen auf die Fähigkeit unserer Benutzer, erfolgreich zu sein. Wie Prof. George Dei eloquent feststellt:

„Inklusion bringt Menschen nicht in das, was bereits existiert – es schafft einen neuen Raum, einen besseren Raum für alle.“

Indem wir uns etwas mehr Zeit nehmen, Muster kritisch zu hinterfragen und die am besten zugänglichen auszuwählen, werden wir zweifellos einen integrativeren Raum schaffen, um mehr Benutzer zu erreichen – zu ihren Bedingungen.

Ähnliche Resourcen

Werkzeuge

  • Unterstützung für Barrierefreiheit, Michael Fairchild, a11ysupport.io
  • HTML5-Barrierefreiheit, Steve Faulkner

Musterbibliotheken

  • Barrierefreiheitsprojekt
  • Styleguide für Barrierefreiheit
  • Zugängliche Komponenten, Scott O'Hara
  • Zugängliches drag-and-drop Plug-In für die Neuordnung von Listen, Harris Schneiderman
  • Deques ARIA-Musterbibliothek
  • Deques barrierefreie Reaktionsbibliothek
  • GOV.UK-Designsystem
  • Inklusive Komponenten, Heydon Pickering
  • US-Webdesignsystem (USWDS)
  • Tutorials zur Barrierefreiheit im Web