Eine vollständige Anleitung zu zugänglichen Front-End-Komponenten

Inhaltsverzeichnis

Nachfolgend finden Sie eine alphabetische Liste aller zugänglichen Komponenten. Überspringen Sie das Inhaltsverzeichnis oder scrollen Sie einfach nach unten, um sie einzeln zu erkunden.

• : Fokusstile
• Autovervollständigung
• Tasten
• Karten
• Karussells
• "Schließen"-Schaltflächen
• Inhalts-Schieberegler
• Kontrollkästchen
• Farbsysteme
• Farbpaletten
• Comics
• Komponentenbibliotheken
• Cookie-Zustimmungsaufforderungen
• aktuelle Seitennavigation
• dunkler Modus
• Datendiagramme
• Datenvisualisierungen
• Datumsauswahl
• deaktivierte Tasten
• Teiler
• Stile bilden
• Fußnoten
• Inhalte verstecken
• Icon-Links
• Eingänge
• Tastaturnavigation
• Verknüpfungen
• Medienscroller
• Modale
• Navigationsmenü
• Passwortfelder
• bevorzugt-reduziert-*
• Radio Knöpfe
• Skelette
• Links „überspringen“.
• SVGs
• Registerkarten
• Tische
• testen
• Zugriff auf Komponenten von Drittanbietern
• Kippschalter
• Werkzeuge
• Kurzinfos
• Video-/Audioplayer

Zugänglich :focus Styles

Jeder Browser hat Standard-Fokusstile, die jedoch standardmäßig nicht sehr zugänglich sind. Das Ziel von :focus ist es, dem Benutzer eine Orientierung zu geben, wo genau er sich im Dokument befindet, und ihm zu helfen, sich darin zurechtzufinden. Um dies zu erreichen, müssen wir einen zu subtilen oder gar nicht sichtbaren Fokus vermeiden. Tatsächlich ist das Entfernen von Umrissen eine schlechte Idee, da es alle sichtbaren Hinweise auf den Fokus für Tastaturbenutzer entfernt. Je offensichtlicher der Fokus ist, desto besser.

Es gibt Möglichkeiten, bessere :focus -Stile zu entwerfen. In ihrem Artikel Tipps für Fokusstile hebt Nic Chan einige hilfreiche Tipps hervor, wie man Fokusstile mit einem besseren Angebot und ein wenig Polsterung, Versatz und richtigen Umrissen verbessern kann. Brauchst du mehr Spaß mit :focus Styles? Lari Maza steht auch hinter dir.

Wir können auch :focus-within verwenden, um das übergeordnete Element eines fokussierten Elements zu formatieren, und :focus-visible , um bei der Interaktion mit einer Maus/einem Zeiger keine Fokusstile anzuzeigen, wenn dies Probleme in Ihrem Design verursacht.

Es ist wichtig, die Zugänglichkeitsbedenken rund um :focus-visible zu berücksichtigen: Wie Hidde de Vries angemerkt hat, verwenden nicht alle Leute, die sich auf Fokusstile verlassen, eine Tastatur, und Fokusstile nur auf die Tastatur zu setzen, nimmt auch Mausbenutzern ein erschwingliches Angebot, da Fokus auch zeigt an, dass etwas interaktiv ist (danke an Jason Webb für den Tipp!) .

Abschließend ist anzumerken, dass Chrome, Edge und andere Chromium-basierte Browser in letzter Zeit aufgehört haben, eine Fokusanzeige ( Fokusring ) anzuzeigen, wenn der Benutzer auf eine Schaltfläche klickt oder tippt (danke an Kim Johannesen für den Tipp!) .

Zugängliche Autovervollständigung

Jedes Mal, wenn Sie sich mit einem größeren Datensatz befassen müssen, sei es eine Karte, eine Datenvisualisierung oder nur eine Länderauswahl beim Checkout, kann die automatische Vervollständigung die Eingaben der Kunden massiv steigern. Aber genauso wie es bei der Eingabe hilft, muss es auch bei der Ankündigung der Optionen und der Auswahl für die Screenreader-Benutzer helfen.

Gov.uk, das Team hinter dem Government Digital Service im Vereinigten Königreich, hat (neben vielen anderen Dingen) eine Open-Source-Accessible-Autocomplete, eine JavaScript-Komponente, die den Best Practices von WAI-ARIA folgt. Sie können wählen, wann Vorschläge angezeigt werden sollen, und das Menü als absolut positioniertes Overlay anzeigen oder standardmäßig den ersten Vorschlag auswählen. Das Team stellt auch eine Demoseite mit einem Dutzend barrierefreier Beispiele und Implementierungen für die automatische Vervollständigung bereit.

Zugängliche Schaltflächen und Symbollinks

Es ist nicht ungewöhnlich, dass ein Link oder eine Schaltfläche visuell keinen Text enthält, sondern nur aus einem Symbol besteht – beispielsweise einer kompakten Navigationsleiste oder sozialen Symbolen. Aber wie stellen Sie sicher, dass diese Art von Symbollinks vollständig zugänglich sind? Wie sich herausstellt, ist es nicht so einfach, wie man meinen könnte.

Um zu zeigen, wie wir es besser machen können, hat Kitty Giraudel dem Thema einen Artikel „Barrierefreie Icon-Links“ gewidmet. Sie verwenden einen Icon-Link, bestehend aus einem SVG mit dem ikonischen Twitter-Vogel, um den Punkt zu veranschaulichen und zeigen Schritt für Schritt, wie man ihn barrierefrei macht: mit einem beschreibenden Text, der visuell versteckt wird, und dann das SVG-Markup aus dem Accessibility-Baum mit aria-hidden entfernen aria-hidden und schließlich die Korrektur der Tatsache, dass svg -Elemente im Internet Explorer fokussiert werden können, indem das Attribut focusable wird. Am Ende des Artikels zeigt Kitty auch, wie man das alles in eine kleine React-Komponente umwandelt .

Ein kleines Detail, das für viele Benutzer einen großen Unterschied machen wird.

In „Creating Accessible Icon Buttons and Inclusively Hidden“ gehen Sara Soueidan und Scott O'Hara auf all die Feinheiten und Details von Symbolschaltflächen ein und erforschen eine Reihe von Techniken, damit sie funktionieren. Sara und Scott untersuchen eine Reihe von Techniken und schlagen vor, eine geeignete Technik für zugänglichen visuell verborgenen Text zu verwenden – den Text, der visuell verborgen, aber für Bildschirmlesegeräte zugänglich ist. Dies könnte mit einer .sr-only -Hilfsklasse oder mit hidden und aria-labelledby oder nur mit aria-label erfolgen. Sara würde nicht empfehlen, das SVG-Symbol selbst zu verwenden, um eine Beschriftung für die Schaltfläche bereitzustellen, wenn ich eine direkt auf der Schaltfläche selbst bereitstellen kann.

Im Allgemeinen gibt es jedoch immer noch einige Verwirrung darüber, welches Element für die Benutzerinteraktion verwendet werden soll: Wann verwenden wir Links und wann Schaltflächen? Marcy Sutton hat einen ausführlichen Artikel über Links vs. Buttons in Modern Applications geschrieben. Mit einem Link navigiert der Besucher zu einer neuen Ressource und reißt ihn aus dem aktuellen Kontext heraus. Aber eine Schaltfläche fordert eine Änderung in der Schnittstelle auf.

Marcy skizziert Anwendungsfälle sowohl für Links als auch Schaltflächen in Single-Page-Anwendungen und zeigt, dass eine Schaltfläche ein perfektes Element zum Öffnen eines modalen Fensters, zum Auslösen eines Popups, zum Umschalten einer Schnittstelle oder zum Abspielen von Medieninhalten ist. Sie können auch Vadim Makeevs Artikel „Wann ist ein Knopf kein Knopf?“ lesen.

Zugängliche deaktivierte Tasten

Bei langen Webformularen ist es mittlerweile üblich, den „Weiter“-Button deaktiviert zu lassen, bis der Kunde alle Daten korrekt eingegeben hat. Dieses Verhalten weist darauf hin, dass etwas mit dem Formular nicht stimmt und es nicht abgeschlossen werden kann, ohne die Eingabe zu überprüfen. Dies funktioniert, wenn die Inline-Validierung für jedes Eingabefeld gut funktioniert, und es funktioniert überhaupt nicht, wenn es fehlerhaft oder fehlerhaft ist.

In „Disabled Buttons Suck“ hebt Hampus Sethfors die Nachteile deaktivierter Tasten hervor. Wenn sie vorhanden sind, kommunizieren wir zwar, dass etwas nicht stimmt, aber wir erklären nicht wirklich, was falsch ist oder wie es behoben werden kann. Wenn der Kunde also eine Fehlermeldung übersehen hat – sei es in längerer Form auf dem Desktop oder sogar in kurzer Form auf dem Handy, ist er verloren. In vielerlei Hinsicht ist es effizienter, Schaltflächen aktiv zu halten und Fehler zu kommunizieren.

Und wenn dies nicht möglich ist, bieten Sie zumindest einen Ausweg mit einer Schaltfläche „Ich kann das Formular nicht ausfüllen, bitte helfen Sie“, damit der Kundendienst den Kunden kontaktieren kann, falls er in Schwierigkeiten gerät. Wenn Sie eine detailliertere Auffrischung zu Webformularen benötigen, wird Sie „Formulardesign von Eins bis Null“ auf Trab halten.

Sandrina Pereira geht in ihrem Artikel zu CSS-Tricks der Problematik nach, dass die gängige Art der Verwendung von <button disabled> nicht nur den Klick, sondern auch den Fokus verhindert. Auch wenn dies harmlos erscheinen mag, führt es bei Screenreader-Benutzern zu Verwirrung. Ihr Vorschlag: Das Austauschen von „ disabled “ mit „ aria-disabled “ macht das Erlebnis angenehmer, da die Schaltfläche immer noch per Fokus zugänglich ist und auch einen Tooltip auslösen kann – obwohl sie als „disabled“ gekennzeichnet ist.

Zugängliche Karten

Karten bieten viele Vorteile. Sie funktionieren gut auf Mobilgeräten, bieten große Klickbereiche und die Tatsache, dass sie sowohl horizontal als auch vertikal gestapelt werden können, erleichtert viele Layoutentscheidungen. Es gibt jedoch keinen zu befolgenden Barrierefreiheitsstandard, kein <card> -Element oder ein ARIA-Entwurfsmuster. Stattdessen hängen die potenziellen Zugänglichkeitsbarrieren, auf die Sie möglicherweise stoßen, vom Zweck und Inhalt der Karte ab. In seiner Sammlung inklusiver Komponenten untersucht Heydon Pickering einige Permutationen einer einfachen Kartenkomponente und wie man die Balance zwischen solider HTML-Struktur und ergonomischer Interaktion hält.

Adrian Roselli hat auch einen großartigen Artikel geschrieben, der sich mit einem Aspekt von Karten befasst, der leicht zu ihrer größten Zugänglichkeitsfalle werden kann: große Klickbereiche. Sie können zu extrem ausführlichen Steuerelementen führen, wenn ein Benutzer einen Bildschirmleser verwendet, um durch sie zu navigieren. Für Voice-Benutzer kann es verwirrend sein, was sie sagen sollen, um den Call-to-Action auszuwählen. Adrian demonstriert, wie ein wenig Planung dieses Problem lösen kann.

Ein weiterer tiefer Einblick in barrierefreie Kartenkomponenten kommt vom Team von Nomensa: In ihrem Blogbeitrag werfen sie einen Blick auf häufige Probleme im Zusammenhang mit Karten und Blockierungslinks und geben wertvolle Tipps, wie Sie Ihre Karten barrierefreier machen können – indem Sie Inhalte neu anordnen, um sie zu verbessern Semantik zum Beispiel.

Zugängliche Karussells und Content-Slider

Ein zugängliches Karussell klingt ein bisschen wie ein Oxymoron – obwohl es viele Skripte gibt, die die Funktionalität bereitstellen, sind nur wenige von ihnen zugänglich. Jetzt gibt es natürlich zugängliche Bereichsschieberegler, aber Karussells sind eine etwas andere Komponente. Wie Alison Walden in ihrem Artikel „Wenn Sie ein Karussell benutzen müssen, machen Sie es barrierefrei“ feststellt, wird die sehende Person nicht gezwungen, das Karussell überhaupt zu benutzen, sondern Tastaturbenutzer werden gezwungen, durch das Karussell in seiner Gesamtheit zu navigieren. Zumindest könnte ein versteckter „Überspringen“-Link beim Tastaturfokus erscheinen. Außerdem sollte sich der Fokus auf das nächste interaktive Element bewegen, das auf das Karussell folgt, sobald die Person durch alle Panel-Sets geblättert hat.

Heydon Pickering schlägt vor, Listen-Markup zu verwenden, um die Folien zu gruppieren, Schaltflächen „Zurück“ und „Nächste“ einzuschließen, Punkte zu fixieren und unsichtbare verknüpfte Elemente zu verwenden, die aus dem Fokus entfernt wurden. Der Artikel enthält auch ein Codebeispiel, das IntersectionObserver verwendet, sodass Sie möglicherweise eine Polyfüllung dafür benötigen.

Zugängliche Schließen-Schaltflächen

„Schließen“-Schaltflächen sind überall – in Mods, Anzeigen, Bestätigungsmeldungen, Cookie-Eingabeaufforderungen und allen Overlays, die in Ihrer Benutzeroberfläche erscheinen. Leider ist die Funktionalität oft auf Mausbenutzer beschränkt, sodass Benutzer von Bildschirmlesegeräten und Tastaturbenutzern außen vor bleiben. Wir können es reparieren.

In „Accessible Close Buttons“ geht Manuel Matuzovic tief ins Detail und hebt 11 Beispiele und Muster von unzugänglichen Close-Buttons sowie 5 Beispiele von Close-Buttons hervor, die ziemlich gut funktionieren. Der einfachste Weg, das Problem zu lösen, besteht darin, eine Schaltfläche mit sichtbarem Text und einem nur visuell zugänglichen Symbol bereitzustellen und sicherzustellen, dass die Beschreibung durch Screenreader nicht durch die Beschreibung des Symbols verunreinigt wird. Manuel bietet auch Codebeispiele für 5 Schaltflächen zum Schließen, die Sie sofort auf Ihre Arbeit anwenden können.

Zugängliche Kontrollkästchen und Optionsfelder

Das gute alte Problem: Wie gestalten wir Kontrollkästchen und Optionsfelder, um sicherzustellen, dass sie in den meisten Browsern zumindest ähnlich aussehen – und gleichzeitig sicherstellen, dass sie zugänglich bleiben? In ihrem Artikel behandelt Sara Soueidan einige Techniken, die Sie beachten sollten, um das gewünschte Ergebnis zu erzielen.

Sara behandelt die verschiedenen Techniken zum Ausblenden von Elementen, wie sich jede von ihnen auf die Zugänglichkeit des Inhalts auswirkt und wie sie visuell ausgeblendet werden, damit sie durch eine besser gestaltbare Alternative ersetzt werden können: das SVG.

Wenn wir ein interaktives Element ausblenden, müssen wir sicherstellen, dass wir eine Ausblendtechnik wählen, die es für den Screenreader zugänglich hält, es über dem platzieren, was es visuell ersetzt, damit ein Benutzer, der per Berührung navigiert, es dort finden kann, wo er es erwartet, und dann transparent machen. Sara bietet auch Live-Demos, die wir sofort verwenden können, zusammen mit nützlichen Verweisen auf Artikel zum Weiterlesen.

Zugängliche Farbsysteme

Der richtige Farbkontrast ist ein wesentlicher Bestandteil, um sicherzustellen, dass nicht nur Menschen mit Sehbehinderungen Ihr Produkt problemlos verwenden können, sondern auch alle anderen, wenn sie sich in Umgebungen mit wenig Licht befinden oder ältere Bildschirme verwenden. Wenn Sie jedoch schon einmal versucht haben, selbst ein zugängliches Farbsystem zu erstellen, wissen Sie wahrscheinlich, dass dies eine ziemliche Herausforderung sein kann.

Das Team von Stripe hat kürzlich beschlossen, sich der Herausforderung zu stellen und sein bestehendes Farbsystem neu zu gestalten. Die Vorteile, die es sofort bieten sollte: Barrierefreiheitsrichtlinien erfüllen, klare und lebendige Farbtöne verwenden, die Benutzer leicht voneinander unterscheiden können, und eine konsistente visuelle Gewichtung haben, ohne dass eine Farbe Vorrang vor einer anderen zu haben scheint. Wenn Sie neugierig sind, mehr über ihren Ansatz zu erfahren, wird Ihnen ihr Blogbeitrag zu barrierefreien Farbsystemen wertvolle Einblicke geben.

Zugängliche Farbpaletten

Das Finden der perfekten Tönung oder Nuance einer Farbe ist nicht nur eine Frage des Geschmacks, sondern auch der Zugänglichkeit. Denn bei fehlendem Farbkontrast kann ein Produkt im schlimmsten Fall sogar für Menschen mit Sehbehinderung unbrauchbar werden. WCAG 2.0 Level AA erfordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text.) und 3:1 für großen Text, und WCAG 2.1 erfordert ein Kontrastverhältnis von mindestens 3:1 für Grafiken und UI-Komponenten (wie Formulareingaben). Grenzen). AAA erfordert ein Kontrastverhältnis von mindestens 7:1 für normalen Text und 4,5:1 für großen Text. Ein sehr detaillierter Kontrastprüfer, der Ihnen hilft, potenzielle Fallstricke im Voraus zu erkennen, stammt von Gianluca Gini: Geenes.

Mit dem Tool können Sie an Farbtonbereichen und Sättigung basteln und die Farbpaletten auf eines von drei auswählbaren UI-Modellen anwenden. Nach dem Auftragen können Sie verschiedene Arten von Sehstörungen auslösen, um zu sehen, wie betroffene Personen die Farben sehen, und schließlich eine fundierte Entscheidung über die besten Töne für Ihre Palette treffen. Um die Farben sofort zu verwenden, kopieren Sie einfach ihren Code und fügen Sie ihn ein oder exportieren Sie ihn nach Sketch. Sie können auch Sehschwächen in DevTools emulieren.

Sehbehinderungen verstehen

Sie haben wahrscheinlich schon einmal von Protanopie, Deuteranopie oder Glaukom gehört. Aber wie sehen Menschen mit solchen Sehbehinderungen eigentlich Ihre Farbkombinationen? Corey Ginnivans Tool Who Can Use simuliert es für Sie.

Geben Sie eine Hintergrund- und eine Textfarbe ein und das Tool berechnet für Sie das Kontrastverhältnis sowie die WCAG-Einstufung. Um diese ziemlich abstrakten Zahlen zu vermenschlichen, zeigt Who Can Use auch eine Liste verschiedener Sehtypen, wie viele Menschen davon betroffen sind, und natürlich die Simulation Ihrer Farbkombination für jeden Typ. Ein toller kleiner Helfer, um die Wirkung von Farbe besser zu verstehen.

Zugängliche Comics

Wenn wir etwas komplexere Formen und Layouts im Web verwenden, scheint es manchmal so viel einfacher zu sein, es einfach als Vorder- oder Hintergrundbild zu speichern und verschiedene Bilder auf kleinen und großen Bildschirmen bereitzustellen. Das gilt für komplizierte Diagramme und Grafiken ebenso wie für gute alte Comics mit sprechenden Sprechblasen, aber was wäre, wenn wir uns das Erlebnis komplett neu vorstellen könnten?

Comica11y ist ein Experiment von Paul Spencer, das darauf abzielt, ein allumfassendes Online-Comic-Leseerlebnis zu erreichen. Was wäre, wenn wir verschiedene Lesemodi für den Comic haben könnten, z. B. mit Untertiteln, richtigem Fokusmanagement zum Navigieren zwischen Panels, Hochkontrastmodus, SVG-Farbblindheitsfiltern, programmatischen Blasen, auswählbarem und übersetzbarem Text, LTR- und RTL-Unterstützung und sogar anpassbare Schriftgrößen? Eine wunderbare Initiative, die zeigt, wie weit wir UI-Herausforderungen annehmen und das Web nutzen können, um das Erlebnis erheblich zu verbessern.

Zugängliche Komponentenbibliotheken

Während viele der von uns erstellten Komponentenbibliotheken versuchen, alle üblichen Verdächtigen abzudecken (die Akkordeons, die Tische, die Karussells, die Dropdown-Menüs zusammen mit Typografie, Farben und Schatten), konzentriert sich No Style Design System von Adam Silver darauf hauptsächlich rund um Barrierefreiheit und Webformulare.

Als ein System, das für sein Buch über Form Design Patterns erstellt und in diesem verwendet wird, bietet Adams Bibliothek eine Reihe zugänglicher Komponenten für alles, von Autocomplete, Checkboxes und Password Reveal bis hin zu Radios, Select Boxes und Steppern. Die meisten von ihnen haben ein minimales CSS-Design mit sauberem, zugänglichem Markup.

Und wenn Sie etwas fortgeschrittenere Komponenten benötigen, stehen Ihnen die Inclusive Components von Heydon Pickering – wir haben oben einige Beispiele erwähnt – zur Seite: mit umfassenden Tutorials zu zugänglichen Karten, Datentabellen, Benachrichtigungen, Schiebereglern, Schnittstellen mit Registerkarten, QuickInfos, Menüs und Umschaltern.

Zugängliche Cookie-Zustimmungsaufforderungen

Overlays und Popups sind immer problematisch. Aber besonders für Screenreader-Benutzer sind diese Eingabeaufforderungen manchmal unglaublich schwierig, um Einstellungen vorzunehmen oder sogar die Verwendung von Cookies auf der Website zu bestätigen. In ihrem 15-minütigen Vortrag „Screenreader und Cookie-Einwilligungen“ geht Leonie Watson detailliert auf die schlechten Erfahrungen ein, die Compliance-Pop-ups mit Barrierefreiheit gemacht haben. In einigen Fällen gleiten Benutzer an Einwilligungsaufforderungen vorbei, ohne sich dessen bewusst zu sein, in anderen Fällen kann die Aufforderung nicht akzeptiert werden, was dazu führt, dass die Website überhaupt nicht genutzt werden kann.

Wie können wir sie also besser machen? In Cookie-Banner und Zugänglichkeit hebt Sheri Byrne-Haber häufige Probleme hervor, die Cookie-Eingabeaufforderungen normalerweise haben: von ihrem visuellen Erscheinungsbild bis hin zu Fokusfallen, dem Erscheinungsbild in der Tab-Reihenfolge, der Art der Annahme und alternativen Formaten der Offenlegung der Einwilligung. Quentin Bellanger stellt ein grundlegendes Codebeispiel für ein Cookie-Zustimmungsmodal und ein dazugehöriges Tutorial bereit. Es gibt auch kostenlose Open-Source-Lösungen: Osano Cookie Consent und cookie-consent-box, aber sie erfordern möglicherweise einige Arbeiten zur Barrierefreiheit.

Zugängliche aktuelle Seitennavigationszustände

Farbe ist ein effektiver Weg, um Bedeutung zu vermitteln, aber es ist immer eine gute Idee, auch für Menschen mit Sehbehinderung oder Farbsehschwäche einen zweiten visuellen Indikator zu haben. Ein Symbol zum Beispiel. Callum Hart verlässt sich auf eine Kombination aus Farbe und Symbol, um anzuzeigen, auf welcher Seite sich ein Benutzer gerade befindet. In seinem Blogbeitrag „An Accessible Current Page Navigation State“ gibt er wertvolle Einblicke in die Überlegungen hinter dieser Designentscheidung.

Vom Einbetten des SVG-Symbols in den HTML-Code und der Verwendung von aria-hidden , um es vor Hilfstechnologien zu verbergen, bis hin zur Verwendung von ems anstelle von Pixeln und der Vermittlung von zusätzlichem Kontext für Screenreader-Benutzer mit dem aria-current Attribut bietet der Beitrag einen detaillierten Einblick in die Vorgehensweise Sorgen Sie für einen wirklich barrierefreien Navigationszustand.

Eine vollständige Anleitung zum Dark Mode im Web

Der Dunkelmodus wird schnell zu einer Benutzerpräferenz, da Apple, Windows und Google ihn in ihre Betriebssysteme implementiert haben. Aber was ist mit dem Dark Mode im Web? Adhuham hat einen umfassenden Leitfaden zum Dark Mode geschrieben, der sich mit verschiedenen Optionen und Ansätzen zur Implementierung eines Dark Mode-Designs im Web befasst.

Zu Beginn befasst sich der Leitfaden mit den technischen Überlegungen, die die Implementierung eines Dunkelmodus mit sich bringt, und behandelt verschiedene Ansätze zum Umschalten der Themen und zum Speichern der Benutzereinstellungen, damit sie auf der gesamten Website und bei späteren Besuchen konsistent angewendet werden. Tipps zum Umgang mit Benutzeragentenstilen mit dem color-scheme Meta-Tag helfen, potenzielle FOIT-Situationen zu vermeiden.

Natürlich werden auch Designüberlegungen mit wertvollen Tipps behandelt, um Bilder, Schatten, Typografie, Symbole und Farben für den Dunkelmodus vorzubereiten. Apropos: Um sicherzustellen, dass wir den hohen Kontrast im Modus nicht versehentlich unterbrechen, werfen Sie einen Blick auf Styling für den Windows-Modus mit hohem Kontrast ( danke für den Tipp, Courtney Heitman! ).

Zugängliche Datendiagramme

Datenvisualisierungen sind eine großartige Möglichkeit, Informationen hervorzuheben. Sie bringen jedoch auch ihre eigenen Barrierefreiheitsprobleme mit sich. Als Sara Soueidan sich mit SuperFriendly zusammengetan hat, um eine barrierefreie Microsite für den Jahresbericht der Khan Academy zu erstellen, wollte sie sicherstellen, dass die Art und Weise, wie die Daten präsentiert und implementiert werden, so barrierefrei wie möglich ist, unabhängig davon, wie ein Besucher die Site erkundet. Ihre Lösung: SVG.

In einer Fallstudie zu barrierefreien Datendiagrammen hat Sara alles zusammengefasst, was Sie beachten müssen, wenn Sie Ihre SVG-Diagramme und Visualisierungen barrierefrei machen möchten – beginnend mit dem wichtigsten Schritt, der Auswahl einer geeigneten Einbettungstechnik. Es wird auch behandelt, warum Sie es vermeiden sollten, ein SVG-Diagramm mithilfe von ARIA-Rollen zugänglich zu machen, und warum Sara <figure> nicht zum Einbetten ausgewählt hat. Ein fantastisches Nachschlagewerk. Plus: Besonders bei Diagrammen könnten wir auch besser zugängliche Textlabels verwenden, und Sara behandelt sie auch in einem separaten Artikel.

Zugängliche Datenvisualisierungen

Datenvisualisierungen enthalten oft wichtige Informationen, auf die Benutzer reagieren müssen. Während wir manchmal stattdessen große Zahlen mit kurzen Sätzen verwenden können, können Visualisierungen helfen, Entwicklungen und große Mengen an Informationen schneller zu verstehen. Das bedeutet aber, dass die Informationen leicht verständlich sein müssen, und das bezieht sich insbesondere auf die Farbauswahl, die Informationsdarstellung, Beschriftungen, Legenden sowie Muster und Formen. In ihrer Artikelserie zur Barrierefreiheit in Datenvisualisierungen hebt Sarah L. Fossheim nützliche Richtlinien und Ressourcen rund um das Thema hervor, zusammen mit Beispielen, Geboten und Verboten, die beim Entwerfen barrierefreier Datenvisualisierungen zu beachten sind.

Sarah schlägt vor, sich nicht auf Farben zu verlassen, um die Daten zu erklären, und generell helle und kontrastarme Farben zu vermeiden. Die Verwendung von Mustern und Formen zusätzlich zu Farbe ist nützlich, und eine klare Sprache, Beschriftungen und Legenden können helfen, die Datenvisualisierung klar zu erklären. Jeder Artikel ist vollgepackt mit zahlreichen Beispielen und Ressourcen zum Weiterlesen. Ebenfalls einen Blick wert: Sarahs Rezension von Datenvisualisierungen zu US-Präsidentschaftswahlen ( danke an Stephanie Eckles für den Tipp! ).

Zugängliche Datumsauswahl

Es gibt Dutzende von Datumsauswahlbibliotheken, aber es ist immer großartig, zuverlässige Arbeitspferde zu haben, die einfach browserübergreifend funktionieren, keine starken Abhängigkeiten haben, einigermaßen gut geschrieben sind und alle wichtigen Anforderungen an die Barrierefreiheit erfüllen.

Duet Date Picker ist einfach so. Es ist eine zugängliche, WCAG 2.1-konforme Datumsauswahl, die in jedem JavaScript-Framework oder überhaupt keinem Framework implementiert und verwendet werden kann. Es verfügt über integrierte Funktionen, mit denen Sie ein minimal und maximal zulässiges Datum festlegen können, und wiegt etwa 10 KB, verkleinert und gezippt (dies umfasst alle Stile und Symbole).

Wenn Sie eine Alternative benötigen, sehen Sie sich React Dates an, eine von Airbnb veröffentlichte Bibliothek, die für die Internationalisierung optimiert und gleichzeitig zugänglich und mobilfreundlich ist.

Horizontale Trennwände gestalten

<hr> -Elemente sind normalerweise ziemlich langweilig. Schlichte, horizontale Linien, die für eine optische Unterbrechung sorgen und Inhalte unterteilen. Aber wussten Sie, dass sie mit CSS und SVG gestaltet werden können, um Ihren Inhalten und Designs eine nette persönliche Note zu verleihen?

Sara Soueidan hat genau das getan: Die <hr> s auf ihrer persönlichen Seite werden nicht als langweilige Linien angezeigt, sondern Sie sehen Vögel, die auf einem Draht sitzen. Um Ihnen dabei zu helfen, Ihre <hr> s schöner zu gestalten, hat Sara zusammengefasst, wie sie horizontale Linien mit Hilfe von CSS- und SVG-Magie gestaltet hat. Sie sucht auch nach Möglichkeiten, sie weiter zu verbessern, damit sie sich an verschiedene Kontexte anpassen und gleichzeitig semantisch und zugänglich bleiben. Ein nettes kleines Detail.

Zugängliche Cross-Browser-Formularstile

Haben Sie sich jemals mit dem Ausblenden und Gestalten von benutzerdefinierten Kontrollkästchen und Optionsfeldern herumgeschlagen? Was ist mit benutzerdefinierten Auswahlstilen? Oder vielleicht ein zugängliches Dropdown-Navigationsmenü? Wir neigen dazu, ständig die gleichen Komponenten zu bauen und umzubauen, also lassen Sie uns sie ein für alle Mal richtig machen.

Sarah Higleys „<select> your gift“ ist ein umfassender zweiteiliger tiefer Einblick in alle Herausforderungen und Feinheiten des Stylings des <select> -Elements, mit bearbeitbaren und mehrfach wählbaren Varianten, ihrer vergleichenden Verwendbarkeit (mit Daten!) und praktischen Empfehlungen wie man es richtig macht.

Stephanie Eckles' Moderne CSS-Lösungen für alte CSS-Probleme hebt viele nützliche moderne Techniken hervor, um viele Herausforderungen zu lösen, aber einige Artikel aus ihrer Serie sind Formularen gewidmet: benutzerdefinierte CSS-Kontrollkästchen, gestaltete Optionsfelder, ausgewählte Stile, Eingaben und Textbereiche.

In ihrem Blog erklärt Sara Soueidan detailliert, wie man Checkboxen und Radiobuttons ausblenden und stylen kann. Bonus: Die Codebeispiele von Adrian Roselli bieten zusätzliche Einblicke in unzureichend entwickelte Umschalter. Fantastische Ressourcen, die Sie sofort verwenden und Formulare barrierefrei gestalten können.

Inhalte verantwortungsbewusst verbergen

Wie versteckt man Inhalte verantwortungsbewusst, um sie unsichtbar, aber dennoch für Screenreader zugänglich zu machen? Kitty Giraudel fasste verschiedene Möglichkeiten zusammen, etwas zu verbergen, sei es mit HTML oder CSS, und wann man welche verwendet.

Wie Kitty vorschlägt, möchten Sie möglicherweise vermeiden, dass zu viele Diskrepanzen zwischen dem visuellen Inhalt und dem zugrunde liegenden Inhalt vorhanden sind, der der Barrierefreiheitsebene ausgesetzt ist. Je mehr sie synchron sind, desto besser. Kitty definiert drei verschiedene Szenarien, um Ihnen bei der Beurteilung zu helfen, wann Sie welche Technik verwenden sollten: Wenn Sie etwas sowohl visuell als auch vor der Barrierefreiheitsstruktur verbergen müssen (z. B. Widgets ein-/ausblenden, Offscreen-Navigation oder einen geschlossenen Dialog), verwenden Sie display: none oder das hidden HTML-Attribut. Wenn Sie etwas aus dem Barrierefreiheitsbaum verstecken, aber sichtbar halten müssen, verwenden Sie aria-hidden="true" (gültige Fälle sind visuelle Inhalte ohne Bedeutung, Symbole). Und last but not least, wenn Sie etwas verbergen, aber zugänglich halten möchten, verwenden Sie die visuell verborgene CSS-Deklarationsgruppe (z. B. für ergänzende Inhalte, die mehr Kontext bieten, z. B. für Symbolschaltflächen oder Links). Eine tolle Übersicht.

Zugängliche Fußnoten und Randnoten

Im Wesentlichen sind Fußnoten nicht viel mehr als Jump-Links – Links zur Beschreibung einer Quelle, die entweder am Ende des Dokuments oder in der Seitenleiste platziert werden oder inline erscheinen, ein kleines Akkordeon. Da es sich bei Fußnoten jedoch um Sprunglinks handelt, müssen wir sicherstellen, dass Screenreader-Benutzer verstehen, wenn Links auf Fußnoten verweisen – und wir können dies mit dem Attribut aria-describedby tun. Der Zähler für jeden Link würde über einen CSS-Zähler implementiert. Mit :target heben wir dann die Zeile hervor, zu der der Leser gesprungen ist, und liefern einen Backlink zurück zur eigentlichen Fußnotenstelle im Inhalt.

Kitty Giraudel erklärt ausführlich, wie man barrierefreie Fußnoten erstellt, und Sie können auch nachlesen, wie Sie barrierefreie Fußnoten mit React erstellen, und sie mithilfe von „react-a11y-footnotes“ in React with Eleventy erstellen (danke an Kitty Giraudel für den Tipp!) .

Zugängliche Eingänge

2019 analysierte WebAIM die Zugänglichkeit der Top-1-Million-Websites, mit einem erschreckenden Ergebnis: Der Prozentsatz fehlerfreier Seiten wurde auf unter ein Prozent geschätzt. Um unsere Websites für Menschen, die auf Hilfstechnologien angewiesen sind, integrativ und nutzbar zu machen, müssen wir die Grundlagen von semantischem HTML richtig beherrschen. Mit seinem Credo, klein anzufangen, zu teilen und zusammenzuarbeiten, ist Oscar Braunerts Artikel über inklusive Inputs ein guter Ausgangspunkt dafür.

Beginnend mit den Grundlagen von WAI, ARIA und WCAG untersucht der Artikel, wie Eingaben zugänglicher gemacht werden können. Die Tipps lassen sich ohne Veränderung der Benutzeroberfläche umsetzen und, wie es Oscar ausdrückt: „Im Zweifelsfall einfach machen. Niemand wird es merken. Außer einigen Ihrer Benutzer. Und sie werden es dir danken.“

Die perfekte Verbindung

Ein Link ist ein Link ist ein Link, oder? Nun, ein Link ist mehr als nur ein anklickbares Wort oder Bild. In ihrem Artikel „Der perfekte Link“ untersucht Rian Rietveld, wie man einen Link schreibt, gestaltet und codiert, der für jeden auf jedem Gerät funktioniert.

Rian behandelt die Frage, ob ein Link in einem neuen Fenster oder einem neuen Tab geöffnet werden soll, wie man Linktexte verständlich macht, wie man mit Links zu einer E-Mail-Adresse, Telefonnummer oder Datei umgeht, was man beim Einbetten eines Bildes in eine Link, wann es zu unterstreichen ist und wie man mit Hover- und Focus-Stilen umgeht, sowie semantische Fragen und interne Links. Ein 360-Grad-Blick auf das Thema.

Zugängliche App-weite Tastaturnavigation

Ein durchdachtes Konzept für die Tastaturnavigation kommt allen zugute: Es ermöglicht Menschen, die nicht bequem mit der Maus umgehen können, unterstützt Screenreader-Benutzer bei der Interaktion mit einer Anwendung und bietet Power-Usern mehr Shortcuts, um so effizient wie möglich zu arbeiten. Normalerweise ist die Tastaturunterstützung auf bestimmte Tastenkombinationen beschränkt, aber das Team von Discord hat beschlossen, mit ihrer Anwendung noch einen Schritt weiter zu gehen und die Tastaturunterstützung auf alles auszudehnen.

Die Fallstudie „How Discord Implemented App-Wide Keyboard Navigation“ gibt wertvolle Einblicke, wie sie die Aufgabe angegangen sind – und natürlich die Herausforderungen, denen sie dabei gegenüberstanden. Eines stellte sich als besonders schwierig heraus: Wie kann man konsequent angeben, wo der Fokus auf der Seite liegt? Da bestehende Lösungen für Focus Rings nicht funktionierten, musste das Team eine eigene Lösung von Grund auf neu entwickeln und den Code als Open Source verwenden. Wenn Sie vor einer ähnlichen Herausforderung stehen, ist diese für Sie.

Zugängliches Tap/Click-Menü

Ist es immer noch eine gute Idee, Mega-Dropdowns zu entwerfen, die sich beim Hover öffnen? Wahrscheinlich nicht. Hover-Menüs haben viele Probleme mit der Benutzerfreundlichkeit und Zugänglichkeit, da sie inkonsistent und verwirrend sind und natürlich eine alternative Lösung für mobile Geräte benötigen. Tatsächlich schlägt Mark Root-Wiley vor, dass es an der Zeit ist, Hover-Menüs zugunsten von eindeutigen und zugänglichen Klickmenüs fallen zu lassen.

In seinem Artikel geht Mark detailliert darauf ein, wie man ein barrierefreies Klickmenü erstellt, zusammen mit nützlichen Hinweisen und Referenzen aus seiner Forschung. Die Idee ist, das Menü als reines CSS-Hover-Menü zu erstellen, das li:hover > ul und li:focus-within > ul verwendet, um die Untermenüs anzuzeigen. Dann verwenden wir JavaScript, um die <button> -Elemente zu erstellen, die aria -Attribute festzulegen und die Event-Handler hinzuzufügen. Das Endergebnis ist als Codebeispiel auf CodePen und als GitHub-Repo verfügbar. Dies sollte auch ein guter Ausgangspunkt für Ihr Menü sein.

Zugängliche Medien-Scroller-Komponenten

Wie würden Sie vorgehen, um eine responsive Media-Scroller-Komponente zu erstellen, die auf Fernsehern, Telefonen und Desktops gleichermaßen funktioniert? Adam Argyle führt Sie Schritt für Schritt durch den Prozess.

Die Scroller-Komponente wurde zum Hosten von Miniaturansichten von Medien oder Produkten entwickelt und basiert auf einem <ul> mit zugänglichem Markup. CSS verwandelt die bescheidene Liste in ein reibungsloses Scroll-Erlebnis, das die Bilder präsentiert und sie an einem Raster ausrichtet. Um etwas Finesse hinzuzufügen, erleichtert JavaScript Roving-Index-Interaktionen und hilft Tastaturbenutzern dabei, das Durchlaufen einer großen Anzahl von Elementen zu überspringen, und nicht zuletzt verwandelt die experimentelle prefers-reduced-data Medienabfrage den Medien-Scroller bei Bedarf in eine leichtgewichtige Erfahrung . Klug!

Zugängliche Modale

Möglicherweise haben Sie ein einfaches Modal oder Overlay auf der Seite, vielleicht um die Eingabe des Kunden zu bestätigen oder um ein paar Fotos in einer Galerie anzuzeigen oder einfach um die Präferenzen des Benutzers zu bestätigen. In all diesen Fällen wird der Aufbau eines zugänglichen Modals zu einem ziemlichen Abenteuer, das auch als Fokusfalle bekannt ist.

Wie Eric Bailey ausführlich erklärt, müssen Sie die Grenzen des eingeschlossenen Inhalts identifizieren, einschließlich des ersten und letzten fokussierbaren Elements, dann alles entfernen, was nicht darin enthalten ist, den Fokus auf den eingeschlossenen Inhalt verschieben und auf Ereignisse achten, die entkommen die Grenze, stellen Sie den vorherigen Zustand wieder her und verschieben Sie den Fokus zurück auf das interaktive Element, das den eingeschlossenen Inhalt ausgelöst hat.

Idealerweise würden wir etwas so Einfaches wie das dialog in HTML verwenden, aber leider hat es massive Zugänglichkeitsprobleme. Mit dem Shadow DOM ist es auch nicht einfach, den Fokus zu verwalten. Wir können das inert Attribut verwenden, um die Fähigkeit interaktiver Elemente, entdeckt und fokussiert zu werden, zu entfernen und dann wiederherzustellen. Für ältere Browser können wir inert Polyfills von Google Chrome und von WICG verwenden.

• Scott O'Haras barrierefreies modales Fenster ist ein zuverlässiges, vollständig zugängliches Skript, das verwendet werden kann.
• Kitty Giraudel wird in Kürze a11y-dialog Next veröffentlichen, ein leichtgewichtiges (1,6 KB) Skript, das den Fokus einfängt und wiederherstellt, aria–* Attribute umschaltet und den Dialog bei Overlay-Klick und Escape schließt. Es ist wichtig , diese Version nicht mit der vorherigen Version (6.1.0) zu verwechseln, da sie sich auf den <dialog> stützt, dem es immer noch an Implementierungsunterstützung mangelt, und der weiterhin Probleme mit der Barrierefreiheit hat.
• Sie könnten sich Parvus ansehen, eine einfache, zugängliche Open-Source-Bild-Lightbox ohne Abhängigkeiten. In einem typischen Szenario haben wir ein Bild, das mit einer größeren Version des Bildes verknüpft ist. Bei Parvus reicht es aus, dem Link, der ein Bild umschließt, eine Klasse .lightbox hinzuzufügen, und das Skript erledigt alles andere automatisch für Sie.

Zugängliche Passwortfelder

„Passwort anzeigen“ und Passworthinweise machen Formularfelder benutzerfreundlicher. Sie helfen Benutzern herauszufinden, ob sie ihr Passwort falsch eingegeben haben und welches Muster akzeptabel ist, wenn sie ein neues erstellen. Wie sich jedoch herausstellt, mangelt es bei diesen Dingen oft an Zugänglichkeit.

Um Ihnen dabei zu helfen, die Situation zu verbessern, wirft Nicolas Steenhout einen genaueren Blick auf die Zugänglichkeit zum Anzeigen/Ausblenden von Passwörtern und wie Sie sicherstellen können, dass Passworthinweise für alle hilfreich sind. Von der Verbesserung der Schaltflächen zum Ein-/Ausblenden mit einer Funktion zum switch und aria-live und aria-pressed bis hin zur Unterstützung der automatischen Vervollständigung hat Nicolas alles zusammengefasst, was Sie wissen müssen, um das Web in dieser Hinsicht etwas zugänglicher zu machen.

Unterstützen Sie Benutzereinstellungen mit prefers-reduced-*

Nicht jeder Benutzer ist gleich, und während einige Benutzer Animationen lieben, haben andere möglicherweise medizinische Probleme in Bezug auf Bewegung. Mit prefers-reduced-motion “ können Sie Animationen ein- und ausschalten, aber es gibt noch mehr Lösungen, um Animationen je nach Vorliebe eines Benutzers zu verwalten. In seinem Blogbeitrag spricht Elijah Manor verschiedene Techniken wie @media, matchMedia und einen benutzerdefinierten React-Hook an, um CSS-, SVG-SMIL- und JavaScript-Animationen zu adressieren.

Wenn es darum geht, Ihre Inhalte für jedermann zugänglich zu machen, gibt es eine weitere prefers-reduced-* , über die Sie Bescheid wissen sollten – auch wenn sie noch nicht von Browsern unterstützt wird (aber Sie können sie in Polypane- und Chromium-Browsern emulieren): prefers-reduced-data . Es zeigt an, wann ein Benutzer so wenig Daten wie möglich verwenden möchte – zum Beispiel, wenn seine Verbindung langsam ist oder wenn Daten begrenzt sind.

• Tatiana Mac hat einen sehr gründlichen Artikel zum Thema „Ansatz ohne Bewegung zuerst bei Animationen“ geschrieben, in dem sie vorschlägt, alle animationsspezifischen Stile in einem animationsspezifischen Stylesheet zu platzieren und dieses nur anzuzeigen, wenn der Besucher nicht „Bewegung reduzieren“ angegeben hat.
• Kitty Giraudel stellt Richtlinien zum Implementieren eines Modus mit reduzierter Bewegung in einem Beispiel einer Banking-Benutzeroberfläche und auch ein Codebeispiel bereit.
• Das Polypane-Team hat zusammengefasst, was Sie über die Medienabfrage wissen müssen, um Ihre Seite schon heute zukunftssicher zu machen.

Zugängliche Skelette

Skelettmuster neigen dazu, sich Screenreadern nicht sinnvoll zu präsentieren. Sie verwenden oft aria-busy="true" wenn ein Widget geladen wird, aber nur wenige Screenreader berücksichtigen das Attribut tatsächlich. Wie also besser machen?

Wie Adrian Roselli vorschlägt, könnten Sie CSS verwenden, um jeden Knoten mit aria-busy="true" zu finden und ihn auf display: none setzen, um den gleichen Effekt für Screenreader- und Nicht-Screenreader-Benutzer zu erzielen. In seinem Artikel „Mehr zugängliche Skelette“ führt er Sie Schritt für Schritt durch den Prozess. Die Demo funktioniert browserübergreifend mit aktuellen Versionen von JAWS, NVDA, VoiceOver und TalkBack.

Zugängliche „Überspringen“-Links

Besonders auf Seiten mit viel Navigation kann das Wechseln zwischen Abschnitten oder auf der Seite frustrierend und nervig sein. Hier können „Überspringen“-Links sehr hilfreich sein. Leider ist es nicht ungewöhnlich, dass „Skip“-Links implementiert, aber mit display: none “ ausgeblendet werden und daher für niemanden verfügbar sind (einschließlich Screenreader- und Tastaturbenutzern).

In So erstellen Sie einen Link zum Überspringen von Inhalten bietet Paul Ryan eine Schritt-für-Schritt-Anleitung zum Implementieren eines barrierefreien Links zum Überspringen von Inhalten. Grundsätzlich verwenden wir die CSS-Transformation, um den Skip-Link vom Bildschirm zu verschieben, ihn aber auf :focus wieder auf den Bildschirm zu bringen. In den Kommentaren zu dem Artikel bemerkte Eric Bailey auch, dass wir Skip-Links vor Inhaltsabschnitten bereitstellen könnten, die viele interaktive Elemente enthalten, oder Elemente, durch die die Navigation schwierig sein kann (z. B. Inhaltsverzeichnisse und iframe ).

Zugängliche SVGs

Apropos SVG: Was wir heute mit SVG machen können, geht weit über die Grundformen von damals hinaus. Wir können SVG-Icons nicht nur beschreiben, sondern auch stylen und animieren. Wenn wahre Inklusivität jenseits von Mustern liegt – welche anderen Faktoren sollten wir beim Entwerfen und Entwickeln barrierefreier SVGs berücksichtigen?

Genau diese Frage beantwortet Carie Fisher in ihrem Beitrag Accessible SVGs: Inclusiveness Beyond Patterns. In dem Artikel wirft Carie einen genaueren Blick auf SVG-Farbe und -Kontrast, Hell- und Dunkel-Modi, SVG-Animation, reduzierte Bewegung und viele Tools rund um Barrierefreiheit. In den Artikeln finden Sie außerdem Demos und Codebeispiele sowie detaillierte Erklärungen und Hinweise zum Weiterlesen.

Und wenn Sie tiefer in die komplexe Welt der barrierefreien Komponenten eintauchen möchten – nicht nur im Zusammenhang mit SVGs – haben wir gerade Caries Artikel über barrierefreie Codemuster veröffentlicht.

Zugängliche Registerkarten

Ihre Benutzeroberfläche verwendet möglicherweise Registerkarten, aber um den Inhalt dieser Registerkarten für Tastaturbenutzer und Benutzer von Bildschirmlesegeräten zugänglich zu halten, benötigen wir eine sehr sorgfältige und bewusste Darstellung des visuellen Designs und der ARIA-Semantik. In Tabbed Interfaces geht Heydon Pickering ins Detail und versucht, genau die richtige Lösung zu finden, um das Tastaturverhalten und die Fokusverwaltung zu berücksichtigen. Er schlägt vor, Abschnitte schrittweise zu Tab-Panels zu erweitern (Codebeispiel) (Danke an Daniela Kubesch für den Tipp!).

Wie Adam Silver anmerkt, wissen weniger versierte Screenreader-Benutzer möglicherweise nicht, wie man die Pfeiltasten zum Wechseln der Registerkarten verwendet. Es gibt ein Argument dafür, alle Tabs in der normalen Tab-Reihenfolge mit wenig Eingriff von Entwicklern fokussierbar zu machen, um die Funktionsweise von Tabs über die Tastatur zu ändern.

Alternativ ist TabPanelWidget eine reaktionsschnelle und barrierefreie Lösung für Registerkarten. Es stützt sich auf einfaches altes semantisches HTML und verwandelt sich in ein Akkordeon, wenn die Tabs nicht vollständig passen (dank ResizeObserver , aber es gibt eine Polyfill für Browser, die es noch nicht unterstützen).

Das Skript ist nicht nur eine semantische und zugängliche Lösung, sondern auch eine reaktionsschnelle und vielseitige Lösung, mit der Sie Tabpanel- und Akkordeon-Widgets für das Web erstellen können. Es ist tastaturfreundlich und als Vanilla-JS-Bibliothek (oder als Widget für Vue, React und Angular) verfügbar.

Zugängliche Tische

Es gibt viele Barrierefreiheitsprobleme im Zusammenhang mit Tabellen, aber die größte Herausforderung besteht darin, eine visuelle Darstellung in eine lineare Serie umzuwandeln, die von einem Screenreader sinnvoll vorgelesen wird, ohne dass wichtige Informationen ausgelassen werden. Glücklicherweise hat Adrian Roselli viel Zeit damit verbracht, die Herausforderungen und Lösungen barrierefreier Tabellen zu erforschen.

In seinem Beitrag zu barrierefreien Tabellen schlägt Adrian vor, die Tabelle in ein <div> mit role="region" , aria-labelledby und tabindex="0" , um sicherzustellen, dass ein Nur-Tastatur-Benutzer mit der Tabulatortaste zum Container wechseln kann, der die table erhält den Fokus und <caption> innerhalb der table, um sicherzustellen, dass sie Screenreadern richtig angekündigt wird. Adrian stellt auch ein Codebeispiel für eine responsive Tabelle sowie Tabellen mit erweiterbaren Zeilen, sortierbaren Tabellen und festen Tabellenüberschriften bereit.

Wie Screenreader durch Datentabellen navigieren

Haben Sie schon einmal versucht, mit einem Screenreader durch eine Tabelle zu navigieren? Wenn nicht, sollten Sie sich den Artikel von Leonie Watson darüber ansehen, wie Screenreader in Datentabellen navigieren. Es teilt wertvolle Erkenntnisse und zeigt, worauf es ankommt, um frustrationsfreie Tabellen zu erstellen, die von jedem verwendet werden können.

In dem Beitrag verwendet Leonie NVDA, um zu einer Tabelle zu wechseln, durch deren Inhalt zu navigieren und bestimmte Informationen zu finden. Die entsprechenden HTML-Elemente (oder ARIA-Rollen) informieren sie über die Eigenschaften der Tabelle und geben ihr Zugriff auf Tastaturbefehle speziell zum Navigieren durch den Inhalt der Tabelle.

Eine interessante Erkenntnis: Tastaturfokus und Screenreader-Fokus sind nicht dasselbe. Im Gegensatz zu dem, was Sie vielleicht gehört haben, müssen Sie nicht jede Zelle einer Tabelle mit einer Tastatur fokussierbar machen, um die Navigation zu erleichtern. Wenn der Inhalt in der Zelle nicht interaktiv ist, müssen sich Tastaturbenutzer wahrscheinlich viel mehr anstrengen, um in der Tabelle zu navigieren, als Sie beabsichtigt haben. Sie können sich auch ein Smashing TV-Video mit Leonie über How A Screen Reader User Accesss The Web (73 Min.) ansehen.

Zugängliche Kippschalter

Wann immer unsere Formulare unseren Kunden eine binäre Auswahl bieten – Ein/Aus, Dunkel-/Hell-Modus usw. – könnten wir einen Kippschalter verwenden. Der Schalter muss mehreren Zwecken dienen: Er muss die aktuelle Auswahl klar erklären (und das ist gar nicht so oft klar!), Er muss erklären, dass es zwei Optionen gibt, und er muss für Kunden offensichtlich genug sein verstehen, wie man zwischen ihnen wechselt. Als Sara Soueidan sich mit dem Bau eines Kippschalters befasste, verbrachte sie natürlich viel Zeit damit, sich damit zu beschäftigen, wie man einen barrierefreien Kippschalter baut.

Die Lösung von Sara verwendet zwei Optionsfelder, jedes mit seiner eigenen Bezeichnung, die den Hilfstechnologien als ein paar separate Optionen angekündigt werden, auf die über die Tastatur zugegriffen werden kann, und hat keine zusätzlichen ARIA- oder JS-Anforderungen, um zu funktionieren. Das Ergebnis ist ein Codebeispiel zum Wechseln des Themas, und Sie können sich auch das Codebeispiel von Scott O'Hara ansehen.

Es ist wichtig zu beachten, dass Saras Radio-Button-Kippschalter aufgrund seiner zwei Beschriftungen zugänglich ist. Wenn also ein Kippschalter keine zwei Beschriftungen hat, wäre dies kein zu verwendendes Muster. Markup-Muster für Kippschalter finden Sie in Scotts Repo. ( Danke an Scott O'Hara für den Tipp! ).

Kitty Giraudel teilt auch ein Tutorial für eine kleine reine HTML- und CSS-Implementierung eines barrierefreien Umschalters, den Sie nach Belieben optimieren können. Die Basis für den barrierefreien Schalter ist ein ordnungsgemäß beschriftetes Kontrollkästchen. Es vermittelt seinen Status sowohl mit Ikonografie als auch mit Farbe und hinterlässt keine Artefakte, wenn CSS nicht aktiviert ist. Der Umschalter verfügt über native Fokusstile, die angepasst werden können, einen deaktivierten Zustand und unterstützt bei Bedarf auch die Ausrichtung von rechts nach links.

Zugängliche Tooltips und Toggletips

Eine Komponente, die eng mit Symbolschaltflächen verwandt ist, ist ein Tooltip. Wörtlich „Tipps für Tools“, sind sie kleine Informationen, die den Zweck eines Steuerelements oder eines visuellen Elements erklären, das andernfalls missverstanden werden könnte. Jedes Mal, wenn wir erklären möchten, warum wir eine bestimmte persönliche Information in einem Checkout benötigen, verwenden wir wahrscheinlich einen guten alten Tooltip. Also, wie machen wir sie richtig?

Heydon Pickerings Inclusive Tooltips and Toggletips bietet einen sehr gründlichen Überblick über so ziemlich alles, was zum Erstellen eines barrierefreien Tooltips benötigt wird. Das bedeutet, zu entscheiden, ob der Inhalt des Tipps als Bezeichnung oder Beschreibung bereitgestellt werden soll, und ARIA-Eigenschaften entsprechend auszuwählen, sich nicht auf title zu verlassen und interaktive Inhalte wie Schaltflächen zum Schließen und Bestätigen oder Links in QuickInfos zu vermeiden.

• Sara Soueidan geht natürlich auch auf die Feinheiten beim Erstellen eines vollständig zugänglichen Hilfe-Tooltips ein und kommt zu dem Schluss, dass JavaScript unerlässlich ist, um vollständig zugängliche interaktive Komponenten zu erstellen.
• Sarah Higley erklärt auch die Komplexität von Tooltips und veröffentlichte ein Codebeispiel, das ein zuverlässiges Muster in Aktion zeigt.
• Scott O'Hara hat ein GitHub-Repo für Tooltips,
• Adrian Roselli stellt auch viele Codebeispiele für Toggles zur Verfügung, einschließlich Demos mit deaktivierten Tooltips und RTL-Richtung.

Zugängliche Video-/Audioplayer

Es ist nicht ungewöhnlich, dass Zuschauer heutzutage häufig Untertitel verwenden, wenn sie sich einen kurzen Clip oder einen langen Film ansehen. Vielleicht konsumieren wir das Video in einer lauten Umgebung, vielleicht können wir Schriftsprache besser verstehen, oder vielleicht sind wir gerade mit etwas anderem beschäftigt und müssen schnell etwas nachschlagen, ohne auf Kopfhörer zurückgreifen zu müssen. Wie oft verwenden wir darüber hinaus die <space> der Tastatur, um eine Pause einzuleiten, oder die Tastenpfeile, um uns vor und zurück zu bewegen? Dennoch bieten viele Videoplayer und benutzerdefinierte Lösungen diese Funktionalität nicht standardmäßig.

Barrierefreie HTML5-Mediaplayer bietet eine Übersicht über barrierefreie Audio- und Videoplayer. Es gibt viele großartige Open-Source-Optionen, z. B. scheint AblePlayer eine der zuverlässigen zu sein. Es enthält einen vollständigen Satz von Player-Steuerelementen, die über die Tastatur zugänglich sind, für Benutzer von Bildschirmlesegeräten ordnungsgemäß gekennzeichnet und von Spracherkennungsbenutzern steuerbar sind, einen hohen Kontrast aufweisen, Untertitel und Untertitel, Kapitel, textbasierte Audiobeschreibungen und eine interaktive Transkriptionsfunktion unterstützen und automatische Texthervorhebung. Es unterstützt YouTube- und Vimeo-Videos. Wie auch immer, es hängt von jQuery ab.

Alternativ könnten Sie sich auch Vime.js ansehen: vollständig Open Source, leichtgewichtig, vollständig anpassbar und ohne Abhängigkeiten von Drittanbietern . Andere großartige Optionen wie Plyr und Accessible HTML5 Video Player von PayPal sind ähnlich. Letzteres ist für Nur-Tastatur-Benutzer und Screenreader-Benutzer vollständig zugänglich, in Vanille-JavaScript geschrieben, wird zusätzlich als React-Komponente bereitgestellt und greift auf die nativen Steuerelemente des Browsers zurück, wenn JavaScript nicht verfügbar ist ( Danke für den Tipp, @jamsandwich ! ).

Website-Funktionen, die Screenreader-Benutzer stören

Eine fehlende alternative Bildunterschrift, ein automatisch abspielendes Video, unbeschriftete Schaltflächen, schlechte Verwendung von Überschriften, unzugängliche Webformulare – was für sehende Benutzer wie ein kleines Problem erscheinen mag, kann den Unterschied ausmachen, ob eine Website unabhängig oder nicht für Blinde und Blinde verwendet werden kann sehbehinderte Menschen. Das weiß Holly Tuke aus eigener Erfahrung.

Um das Bewusstsein für häufige Barrierefreiheitsprobleme zu schärfen, hat Holly fünf lästige Website-Funktionen zusammengefasst, mit denen sie als Screenreader-Benutzerin jeden Tag konfrontiert ist, und natürlich, wie man sie behebt. Chris Ashton hat auch einen Artikel veröffentlicht, in dem häufige Probleme von Benutzern von Bildschirmleseprogrammen erläutert werden, die in Gesprächen, die sich allein auf Semantik und Tastaturzugänglichkeit konzentrieren, oft vernachlässigt werden. Kleine Details, die einen großen Unterschied machen ( Danke an Alex Chudesnov für den Tipp! ).

Aber zuerst, Barrierefreiheitsunterstützung

Es gibt viele verschiedene Möglichkeiten, wie Hilfstechnologien mit Browsern und Code interagieren. Da es immer noch nicht möglich ist, Screenreader und Sprachsteuerungssoftware vollständig zu automatisieren, müssen wir manuelle Tests durchführen. Und hier kommt a11ysupport.io ins Spiel.

Diese von der Community betriebene Website wurde ursprünglich von Michael Fairchild erstellt und soll dabei helfen, Entwickler darüber zu informieren, welche Barrierefreiheit unterstützt wird. Es ist ein aktives Projekt und Beiträge sind immer willkommen, also fangen Sie an zu testen. Außerdem lohnt es sich immer, die WAI-ARIA-Autorenpraktiken zu überprüfen, die grundlegende Semantik, Rollen und ARIA beschreiben, die für gemeinsame Komponenten und Muster erforderlich sind (danke an Stephanie Eckles für den Tipp!) .

Ressourcen und Checklisten für Barrierefreiheit

Barrierefreiheit ist unglaublich wichtig, wird aber leider oft übersehen. Das von der Community betriebene A11Y-Projekt versucht, die digitale Zugänglichkeit zu vereinfachen, indem es Designern und Entwicklern das Know-how zur Verfügung stellt, das sie benötigen, um schöne, zugängliche und integrative Erfahrungen zu erstellen.

Von den Grundprinzipien hinter barrierefreiem Design über die Durchführung eines Barrierefreiheitsaudits bis hin zur Kultivierung der Community – das A11Y-Projekt betrachtet das Thema aus einer 360-Grad-Sicht. Sie finden Artikel wie schnelle Tipps, Tipps zu lesenden Büchern, Newsletter zum Folgen sowie praktische Tools, Gruppen, die sich für Barrierefreiheit einsetzen, und vieles mehr.

Repository von Accessibility-Tools

Haben Sie jemals das juckende Gefühl, etwas zu vergessen, bevor Sie ein Projekt abliefern? Checklisten sind bekanntlich der Schlüssel, um den Überblick über Dinge zu behalten, die vor dem finalen Showdown erledigt und erledigt werden müssen. Wenn es um Barrierefreiheit geht, gibt es eine wachsende Liste von Tools und Ressourcen, die Ihnen dabei helfen werden, die Dinge im Auge zu behalten: A11y-Ressourcen.

Diese von Hannah Milan kuratierte Liste wurde ursprünglich erstellt, um mehr als 200 handkuratierte Plugins, Tools, Artikel, Fallstudien, Designmuster, Designressourcen, Barrierefreiheitsstandards und sogar Checklisten für Barrierefreiheit zu verfolgen. Natürlich können Sie jederzeit ein Werkzeug einreichen, wenn Sie feststellen, dass etwas fehlt.

Zugriff auf Komponenten von Drittanbietern

Wiederverwendbare Komponenten wie benutzerdefinierte Auswahlen, automatische Vervollständigungen oder Datumsauswahl sind leistungsstarke Helfer. Viele Komponenten von Drittanbietern, die angeblich zugänglich sind, erweisen sich jedoch als nur teilweise zugänglich, wenn Sie etwas tiefer graben. Wie Hidde de Vries betont, können selbst Komponenten, die den ARIA Authoring Practices Guide 1:1 implementiert haben, kritisch sein, da der Leitfaden keine Behauptungen über die Zugänglichkeit von Screenreadern oder die Benutzererfahrung aufstellt. Wie finden Sie also die Komponenten, die wirklich zugänglich sind?

Hidde hat eine Checkliste mit Fragen veröffentlicht, die Sie stellen können, um etwas mehr Gewissheit über die Zugänglichkeit einer Komponente zu erhalten: Wie wurde getestet? Mit wem haben sie getestet? Sind sie offen über die Vor- und Nachteile ihres Ansatzes? Und wer hat die Komponente erstellt? Er gibt auch einige wertvolle Tipps aus der Community, die Ihnen helfen zu beurteilen, ob eine Komponente, die behauptet, barrierefrei zu sein, hält, was sie verspricht.

Einpacken

Es gibt definitiv Dutzende und Hunderte wichtiger Richtlinien von unglaublichen Leuten in der Barrierefreiheits-Community, wie Steve Faulkner mit einer riesigen Artikelserie über Semantik und Barrierefreiheit und Leonie Watson mit einer riesigen Artikelserie über Barrierefreiheit im Allgemeinen. Es ist unmöglich, alle aufzulisten, aber wir sind für jeden Beitrag aufrichtig dankbar.

Wir haben wahrscheinlich einige wichtige und wertvolle Techniken und Ressourcen übersehen! Hinterlassen Sie also bitte einen Kommentar und verweisen Sie auf sie – wir würden diesen Beitrag gerne aktualisieren und auf dem neuesten Stand halten, damit wir alle darauf zurückkommen und schneller zuverlässige, zugängliche Komponenten erstellen können.

Wir hoffen aufrichtig, dass sich diese Tools und Techniken bei Ihrer täglichen Arbeit als nützlich erweisen – und Ihnen vor allem dabei helfen, einige zeitraubende Routineaufgaben zu vermeiden.

Bleiben Sie erreichbar!

Danke! ️

Ein großes Dankeschön an @jamsandwich, Courtney Heitman, Stephanie Eckles, Adam Silver, Daniela Kubesch, Tanisha Sabherwal, Manuel Matuzovic, Vadim Makeev, Kitty Giraudel, Ian James, Juha Lehtonen, Heydon Pickering, Shivani Gupta, Jason Webb, Alex Kallinikos, Scott O'Hara, Sara Soueidan, Sasha Chudesnov, Adam Liptrot, Holger Bartel, Kim Johannesen und alle anderen, die leidenschaftlich rund um Barrierefreiheit gearbeitet haben, für die Beiträge zu diesem Artikel. Gemeinschaftsangelegenheiten.

Mehr zur Barrierefreiheit

• CSS-Audit-Tools
• CSS-Generatoren
• Die komplexe Welt der zugänglichen Muster entwirren
• Entwerfen mit reduzierter Bewegung für Bewegungsempfindlichkeiten
• Ich habe das Internet einen Tag lang mit einem Screenreader benutzt
• Barrierefreiheit in Chrome DevTools
• Dinge, die Sie heute mit CSS machen können
• Abonnieren Sie auch unseren Newsletter, um die nächsten nicht zu verpassen.