Ich habe das Internet einen Tag lang nur mit einer Tastatur benutzt

Dieser Artikel ist Teil einer Serie, in der ich versuche, das Internet unter verschiedenen Einschränkungen zu nutzen, die eine bestimmte demografische Gruppe von Benutzern repräsentieren. Ich hoffe, das Profil der Schwierigkeiten zu schärfen, mit denen echte Menschen konfrontiert sind, die vermeidbar sind, wenn wir auf eine Weise entwerfen und entwickeln, die ihren Bedürfnissen gerecht wird. Letztes Mal habe ich das Web einen Tag lang ohne JavaScript genutzt. Heute habe ich mich gezwungen, nur mit meiner Tastatur im Internet zu navigieren.

Wer benutzt die Tastatur zum Navigieren?

Im Großen und Ganzen gibt es drei Arten von Tastaturbenutzern:

• Benutzer mit eingeschränkter Mobilität, die Schwierigkeiten haben, eine Maus zu verwenden,
• Sehbehinderte Benutzer, die anklickbare Elemente auf der Seite nicht sehen können,
• Power-User, die mit der Maus umgehen können, aber mit der Tastatur schneller zurechtkommen.

Von wie vielen Benutzern sprechen wir?

Ich habe das Internet nach Statistiken zur Tastaturnutzung durchforstet und konnte nichts finden. Ernsthaft. Nicht eine Studie.

Die meisten Websites mit Anleitungen zur Barrierefreiheit von Tastaturen gehen einfach davon aus, dass „viele Benutzer“ sich auf Tastaturen verlassen, um sich fortzubewegen. Jeder, der versucht, eine ungefähre Zahl zu erhalten, wird normalerweise predigt mit „Statistiken spielen keine Rolle – Ihre Website sollte zugänglich sein, Punkt.“

Ja, es ist wahr, dass das Ausmaß der Nicht-Maus-Nutzung ein strittiger Punkt ist. Wenn Sie eine Änderung vornehmen können, die auch nur einen Benutzer ermächtigt, ist es eine Änderung, die es wert ist, vorgenommen zu werden. Aber es gibt viele Statistiken zu Dingen wie Farbenblindheit, Browsernutzung, Verbindungsgeschwindigkeiten und so weiter – warum die Zurückhaltung bei Tastaturstatistiken? Wenn die Zahlen so weit verbreitet sind, wie Websites vermuten lassen, würden sie sicherlich einen stärkeren Geschäftsnutzen ermöglichen und die Verteidigung der Tastaturzugänglichkeit für Ihre Stakeholder erleichtern.

Das, was einer Zahl am nächsten kommt, die ich finden kann, ist ein Artikel über PowerMapper, der darauf hindeutet, dass 7 % der Erwachsenen im erwerbsfähigen Alter in den USA, Großbritannien und Kanada „schwere Geschicklichkeitsschwierigkeiten“ haben. Dies würde dazu führen, dass sie „wahrscheinlich keine Maus verwenden und sich stattdessen auf die Tastatur verlassen“.

Benutzer mit schweren Sehbehinderungen verwenden eine Software, die als Screenreader bezeichnet wird, eine Software, die Inhalte auf dem Bildschirm als synthetisierte Sprache vorliest. Wie sehende Benutzer möchten nicht sehende Benutzer in der Lage sein, Seiten nach interessanten Informationen zu durchsuchen, daher verfügt der Bildschirmleser über Tastaturkürzel zum Navigieren durch Überschriften und Links und verlässt sich für die Interaktion auf fokussierbare Elemente der Tastatur.

„Blinde Menschen brauchen vollen Zugriff auf die Tastatur. Zeitraum."

— David Macdonald, Mitherausgeber von Using WAI ARIA in HTML5

Dieselben Benutzer haben auch Screenreader auf ihren Mobilgeräten, bei denen sie Wischgesten anstelle von Tastaturdrücken verwenden, um Inhalte mit der Tabulatortaste zu „umblättern“. Obwohl sie also nicht buchstäblich eine Tastatur verwenden, erfordern sie, dass die Website über die Tastatur zugänglich ist, da die Screenreader-Technologie sich in die gleiche Tab-Reihenfolge und Ereignis-Listener einklinkt, als ob sie eine Tastatur verwenden würden. Es ist erwähnenswert, dass nur etwa zwei Drittel bis drei Viertel der Screenreader-Benutzer blind sind, was bedeutet, dass der Rest eine Kombination aus Screenreader- und Vergrößerungstechniken verwendet.

2,3 % der Amerikaner (jeden Alters) haben eine Sehbehinderung, die nicht unbedingt die Verwendung eines Bildschirmlesegeräts rechtfertigen würde. Im Jahr 2016 schätzte Addy Osmani die tatsächliche Nutzung von Screenreadern auf etwa 1 bis 2 %. Wenn wir diese Benutzer mit unseren mobilitätseingeschränkten Benutzern und unseren Power-Usern einbeziehen, summiert sich die Tastaturnutzung auf einen beträchtlichen Prozentsatz der globalen Zielgruppe. Daher ist es nicht nur moralisch (und rechtlich – viele Länder verlangen gesetzlich vorgeschrieben, dass Websites barrierefrei sein müssen) richtig, sich um die Barrierefreiheit der Tastatur zu kümmern, sondern es ist auch wirtschaftlich sinnvoll.

In Anbetracht all dessen, wie ist der Stand des Internets heute? Zeit, es herauszufinden!

Das Experiment

Was macht jeder, wenn er einen Tag voller einschüchternder Arbeit vor sich hat? Zögern! Ich ging zu youtube.com. Ich hatte ein bestimmtes Video im Sinn und war dankbar, dass ich nicht in das Hauptsuchfeld tippen musste, da es sich standardmäßig auf das Laden der Seite konzentriert.

Das autofocus -Attribut

Ich bin davon ausgegangen, dass dies mit JavaScript beim Laden des Fensters fokussiert wird, aber es wird tatsächlich vom Browser mit einem autofocus -Attribut für das Eingabeelement behandelt.

Als sehender Tastaturbenutzer fand ich dies äußerst nützlich. Als blinder Screenreader-Benutzer bin ich mir nicht sicher, ob ich das möchte oder nicht. Der Konsens scheint zu sein, dass eine vernünftige Verwendung des autofocus in Fällen in Ordnung ist, in denen der einzige Zweck der Seite darin besteht, mit einem Formular zu interagieren (z. B. Google Landing Page oder ein Website-Kontaktformular).

Standard-Fokusstile

Ich suchte nach Wessen Linie ist das überhaupt? Meine Güte, und ich konnte nicht umhin zu bemerken, dass YouTube keine benutzerdefinierten :focus -Stile definiert hatte, sondern sich auf den nativen Stil des Browsers verließ, um visuell anzuzeigen, durch welche Elemente ich mich bewegte.

Ich hatte immer den Eindruck, dass nicht alle Browser ihren eigenen :focus -Zustand definieren, also müssen Sie Ihr eigenes benutzerdefiniertes Styling definieren. Ich beschloss, dies zu testen und zu sehen, welche Browser es versäumen, einen Standardstil zu implementieren, aber zu meiner Überraschung konnte ich keinen finden. Jeder Browser, den ich getestet habe, hatte seine eigene native Implementierung von :focus , obwohl jeder im Stil unterschiedlich war.

Ich bin sogar ziemlich weit in die Vergangenheit gereist:

Wenn Sie mehr sehen möchten, gibt es eine umfassende Screenshot-Sammlung verschiedener Elemente in nativen Browserzuständen.

Das sagt mir, dass Sie vernünftigerweise davon ausgehen können, dass jeder Browser mit einem grundlegenden :focus -Stil ausgestattet ist. Es ist in Ordnung, den Browser die Arbeit machen zu lassen. Was Sie riskieren, ist Inkonsistenz: Alle Browser gestalten Elemente subtil anders, und einige sind so subtil, dass sie visuell nicht besonders zugänglich sind.

Es ist möglich, die standardmäßigen Browser-Fokusstile zu deaktivieren – indem Sie outline: none für Ihr Element festlegen – aber Sie sollten dies nur tun, wenn Sie Ihre eigene Stilalternative implementieren . Heydon Pickering empfiehlt diesen Ansatz und verweist auf die unklaren oder hässlichen Standardeinstellungen, die von einigen Browsern verwendet werden. Wenn Sie sich entscheiden, Ihre eigenen Stile einzuführen, stellen Sie sicher, dass Sie mehr als nur Farbe als Modifikator verwenden: Fügen Sie einen Umriss oder eine Unterstreichung oder einen anderen visuellen Indikator hinzu, um Benutzer mit Farbenblindheit zu unterstützen.

Viele Websites unterdrücken standardmäßige Fokusstile, bieten jedoch keine benutzerdefinierten Stile, was zu unzugänglichen Erfahrungen führt. Wenn Ihre Website den CSS-Reset von Eric Meyer verwendet, könnte sie unzugänglich sein; Diese häufig verwendete Datei setzt die standardmäßigen :focus -Stile zurück, weist den Entwickler jedoch an, eigene zu schreiben, und viele erkennen die Anweisungen nicht.

Einige Leute argumentieren, dass es für den Benutzer verwirrend sein kann, wenn Sie die Browser-Standardeinstellungen deaktivieren, da sie die visuelle Anbiederung des Fokusstatus verlieren, an den sie gewöhnt sind, und stattdessen lernen müssen, wie der Fokusstatus Ihrer Website aussieht. Auf der anderen Seite argumentieren einige, dass die Standardeinstellungen des Browsers hässlich oder sogar verwirrend für den Nicht-Tastaturbenutzer sind.

Warum verwirrend? Schauen Sie sich dieses animierte Karussellformat auf der BBC an. Es gibt zwei Navigationsschaltflächen – Weiter und Zurück – und es ist für den Tastaturbenutzer nützlich, dass der Fokus während der gesamten Erzählung auf ihnen bleibt. Für den Mausbenutzer kann es jedoch ziemlich verwirrend sein, dass die angeklickte Schaltfläche immer noch „fokussiert“ ist, nachdem der Cursor wegbewegt wurde.

Der :focus-visible CSS-Selektor

Wenn Sie das Beste aus beiden Welten wollen, sollten Sie die CSS4-Pseudoklasse :focus-visible erkunden, mit der Sie je nach Kontext unterschiedliche Fokusstile bereitstellen können. :focus-visible Styling zielt nur auf Elemente ab, die mit der Tastatur fokussiert wurden, nicht mit Mausklick. Das ist super cool, obwohl es derzeit nur in Firefox nativ unterstützt wird. Es kann in Chrome aktiviert werden, indem das Flag „Experimental Web Platform Features“ aktiviert wird.

YouTube-Videos und Tastaturzugänglichkeit

YouTube leistet mit seinem Videoplayer hervorragende Arbeit – jeder Teil des Players ist über die Tastatur navigierbar. Mir gefällt, wie die Lautstärkeregler herausgleiten, wenn Sie den Fokus vom Stummschaltsymbol wegschieben, im Gegensatz zum Herausgleiten, wenn Sie den Mauszeiger über das Stummschaltsymbol bewegen.

Was mir nicht gefallen hat, war, dass hilfreiche Beschriftungen, wie der Text „Stumm“, der angezeigt wird, wenn man mit der Maus über das Symbol „Stumm“ fährt, nicht im Fokus angezeigt werden.

Ein weiterer Bereich, der YouTube im Stich lässt, ist, dass es einige Fokusstile unterdrückt. Hier habe ich versucht, mit der Tabulatortaste zur Schaltfläche "Mehr anzeigen" zu gelangen.

Ich bin aus Versehen direkt hinter die Schaltfläche „Mehr anzeigen“ gesprungen, weil ich kein angewendetes :focus -Styling sehen konnte, egal ob benutzerdefiniertes oder natives. Ich fand heraus, dass das native Styling mit outline-width überschrieben wurde:

Barrierefreiheit der GitHub-Tastatur

Okay, Arbeitszeit. Wo lässt es sich besser arbeiten als in der Heimat des Codes, github.com?

An GitHub sind mir drei Dinge aufgefallen: Eines großartig, eines vernünftig und eines schlecht.

Zuerst das Gute.

Link „Zum Inhalt springen“.

GitHub bietet einen Skip to content -Link an, der das Hauptmenü überspringt.

Wenn Sie die EINGABETASTE drücken , während Sie auf den Link „Zum Inhalt springen“ fokussiert sind, überspringen Sie alle Menüelemente oben auf der Seite und können innerhalb des Hauptinhaltsbereichs mit der Tabulatortaste beginnen, was Zeit beim Navigieren spart. Dies ist ein gängiges Barrierefreiheitsmuster, das sowohl für Tastatur- als auch für Screenreader-Benutzer sehr nützlich ist. Etwa 30 % der Screenreader-Benutzer verwenden einen Skip-Link, wenn Sie einen bereitstellen.

Alternativ entscheiden sich einige Websites dafür, den Hauptinhalt in der Lesereihenfolge an erster Stelle über der Navigation zu platzieren. Dieser Ansatz ist aus der Mode gekommen, da er gegen die Richtlinie verstößt, Ihren DOM-Inhalt an die visuelle Reihenfolge anzupassen (es sei denn, Ihre Navigation erscheint visuell unten). Und obwohl dieser Ansatz bedeutet, dass wir überhaupt keinen „Navigation überspringen“-Link benötigen, würden wir an seiner Stelle wahrscheinlich einen „ Zur Navigation überspringen“-Link wünschen.

Registerkarte zum Anzeigen des Inhalts

Eine Funktion, die mir aufgefallen ist, dass sie anders funktioniert als die Version ohne Tastatur, war die Code-Aufschlüsselungsanzeige.

Mit der Maus können Sie auf den farbigen Balken unter jedem Repository klicken, um eine proportionale Aufschlüsselung der verschiedenen Programmiersprachen anzuzeigen, die im Repository verwendet werden. Mit der Tastatur können Sie nicht direkt zu den farbigen Balken navigieren, aber die Sprachen werden automatisch angezeigt, wenn Sie über das Ende der Metainformationen hinaustappen.

Dies scheint nicht wirklich notwendig zu sein – ich würde gerne zum farbigen Balken gehen und dort die EINGABETASTE drücken – aber dieses unterschiedliche Verhalten schadet auch nicht.

Unsichtbare Verknüpfungen

Eine problematische Sache, auf die ich stieß, war, dass es einen „unsichtbaren“ Link gab, nachdem ich oben rechts an meinem Profilbild vorbeigeblättert hatte. Meine Tab-Reihenfolge würde zum Bild, dann zu diesem unsichtbaren Link und dann zur Schaltfläche „Beobachten“ auf dem Repo (siehe GIF unten). Ich hatte keine Ahnung, was der unsichtbare Link bewirkte, und als ich erkannte, dass ich darauf war, drückte ich die EINGABETASTE und wurde sofort abgemeldet!

Bei näherer Betrachtung sieht es so aus, als wäre ich zu einem „Nur-Screenreader“-Formular navigiert ( sr-only ist ein gebräuchlicher Name der Screenreader-Klasse), das über die Funktion „Abmelden“ verfügt.

Dieser Abmeldelink ist zusätzlich zum Abmeldelink in Ihrem Profil-Dropdown-Menü:

Ich bin mir nicht sicher, ob zwei separate HTML-Abmeldelinks erforderlich sind, da ein Screenreader-Benutzer in der Lage sein sollte, das Dropdown-Menü auszulösen und zum Hauptabmeldelink zu navigieren. Und wenn wir den separaten Link beibehalten wollten , würde ich empfehlen, ein :focus -Styling auf den Screenreader-Inhalt anzuwenden, damit sich sehende Benutzer nicht versehentlich selbst abmelden!

So erstellen Sie eine Verknüpfung „Zum Inhalt springen“.

Wie erstellen wir also die Verknüpfung „Zum Inhalt springen“ neu? Es ist ziemlich einfach zu implementieren, aber es kann täuschend schwierig sein, es perfekt zu machen – also hier ist, was ich als den Heiligen Gral der Skip-Links-Lösungen betrachte.

„Link überspringen“ wird alternativ als „Navigation überspringen“, „Hauptnavigation überspringen“, „Navigationslinks überspringen“ oder „Zum Hauptinhalt springen“ bezeichnet. „Zum Hauptinhalt springen“ ist wahrscheinlich am deutlichsten, da es Ihnen sagt, wohin Sie navigieren, und nicht, was Sie überspringen.

Der Shortcut-Link sollte idealerweise direkt nach dem öffnenden <body> -Tag erscheinen. Es könnte später im DOM erscheinen, sogar nach der Fußzeile, vorausgesetzt, Sie haben ein tabindex="1" -Attribut, um zu erzwingen, dass es das erste interaktive Element in der Tab-Reihenfolge wird. Die Verwendung von tabindex mit einer Zahl größer als Null ist jedoch im Allgemeinen eine schlechte Vorgehensweise und führt häufig zu einer Warnung, wenn Validierungstools wie Lighthouse verwendet werden.

Es ist nicht narrensicher, sich auf tabindex zu verlassen, da Sie möglicherweise mehr als einen Link mit tabindex="1" haben. In diesen Fällen erhält der erste Link zuerst den Registerkartenfokus, nicht alle späteren Links. Lesen Sie hier mehr über die Verwendung des tabindex-Attributs, aber denken Sie daran, dass es zur Sicherheit immer besser ist, Ihren Link physisch an den Anfang des DOM zu verschieben.

 <a class="screen-reader-shortcut" href="#main-content"> Skip to main content </a>

Der Link „Zum Hauptinhalt springen“ ist nur für sehende Benutzer geeignet, die die Navigation bereits mit ihren Augen überspringen können. Während also einige Websites den Skip-Link jederzeit sichtbar halten, besteht die Konvention heutzutage darin, den Link verborgen zu halten, bis Sie mit der Tabulatortaste darauf zugreifen, an welchem ​​​​Punkt er im Fokus ist und das vom :focus -Pseudoselektor angewendete Styling erhält.

 .screen-reader-shortcut { position: absolute; top: -1000em; } .screen-reader-shortcut:focus { position: fixed; top: 0; left: 0; z-index: 999; /* ...and now any nice styling you want to apply... */ padding: 1em; background-color: rgb(114, 105, 105); color: white; text-decoration: none; }

Also, zu was überspringen wir eigentlich? Was ist #main-content ? Es kann wirklich alles sein:

1. Inline-Inhalt
   dh die ID Ihres h1 -Tags: <h1 id="main-content"> .
2. Container
   zB die ID des Containers um Ihren Hauptinhalt wie <main id="main-content"> .
3. Geschwisteranker
   Sie können direkt über Ihrem Hauptinhalt auf ein benanntes Tag verlinken, z. B. <a name="main-content"></a> . Dieser Ansatz wird normalerweise in älteren Tutorials beschrieben – ich würde ihn heutzutage nicht mehr empfehlen.

Für maximale Kompatibilität mit allen Screenreadern empfehle ich die Verknüpfung mit dem h1 -Tag. Damit soll sichergestellt werden, dass der Inhalt vorgelesen wird, sobald Sie den Skip-Link verwendet haben. Das Verlinken auf Container kann zu komischem Verhalten führen, zB der Screenreader beginnt damit, den gesamten Inhalt des Containers vorzulesen.

Ihr #main-content sollte auch einen tabindex von -1 haben, um sicherzustellen, dass er programmatisch fokussierbar ist. Einige Screenreader befolgen den Skip-Link ansonsten möglicherweise nicht.

 <h1 tabindex="-1">This is the title of the page</h1>

Eine letzte Überlegung: Unterstützung für ältere Browser. Wenn Sie genügend Benutzer mit IE9 oder niedriger haben, müssen Sie möglicherweise eine kleine JavaScript-Korrektur auf Ihre Skip-Links anwenden, um sicherzustellen, dass sich der Fokus tatsächlich wie erwartet verschiebt und Ihre Benutzer Ihre Navigation erfolgreich überspringen.

Warum erfinden wir das Rad neu?

Es scheint verrückt, dass wir als Webentwickler diesen „Navigation überspringen“-Hack in der Regel auf allen unseren Websites implementieren müssen. Man könnte meinen, wir könnten die Standards die Arbeit machen lassen.

Seit HTML5 haben wir semantische Elemente wie <main> , <nav> und <header> . Davor hatten wir ARIA-Markenzeichen wie role="main" , role="navigation" bzw. role="banner" . In der aktuellen Landschaft des Webs schreibt die Best Practice vor, dass Sie beides benötigen, dh <main role="main"> , was eine schreckliche Verletzung des DRY-Prinzips darstellt, aber los geht's.

Bei all diesem semantischen Reichtum würden Sie hoffen, dass Browser die Navigation über diese markanten Bereiche nativ unterstützen würden, indem sie beispielsweise eine Tastenkombination für Benutzer bereitstellen, um direkt in den Abschnitt <main> einer Webseite zu gelangen. Kein Glück – im Moment gibt es keine native Unterstützung. Am besten verwenden Sie die Erweiterung Landmark Navigation via Keyboard für Chrome, Opera oder Firefox.

Benutzer von Screenreadern können jedoch direkt zu diesen markanten Regionen navigieren. Bei VoiceOver auf dem Mac können Sie beispielsweise STRG + ALT + U drücken, um das Landmarkenmenü aufzurufen und zum „Haupt“-Orientierungspunkt zu gehen, der eine schnelle und konsistente Verknüpfung zum Hauptinhalt darstellt. Dies hängt natürlich davon ab, dass Websites ihre Dokumente korrekt auszeichnen.

Hier ist ein guter Ausgangspunkt für Ihre Website, wenn Sie möchten, dass sie über Landmark-Regionen navigierbar ist:

 <body> <header role="banner"> <!-- Logo and things can go here --> <nav role="navigation"> <!-- Site navigation links go here --> </nav> </header> <main role="main"> <!-- Main content lives here - including our h1 --> </main> <footer role="contentinfo"> <!-- Copyright statement, etc --> </footer> </body>

All dieses Markup ist durstige Arbeit. Zeit für einen Kaffee.

Pakt Kaffee

Ich erinnere mich, einen Flyer für pactcoffee.com gesehen zu haben… lass uns gehen und einen Blick darauf werfen!

Cookie-Banner

Das Banner „Cookie-Richtlinie“ ist eines der ersten Dinge, die Ihnen hier auffallen, und es ist fast ein instinktiver Reflex für den sehenden Mausbenutzer, es zu schließen. Einige Benutzer von Screenreadern interessieren sich vielleicht nicht dafür (wenn Sie blind sind, würden Sie nicht wissen, dass es da ist, bis Sie es erreichen), aber als sehender Benutzer sehen Sie es, Sie möchten es töten, und im Fall von dieser Seite müssen Sie ALLE ANDEREN LINKS mit der Tabulatortaste passieren, bevor Sie sie schließen können.

Ich habe die ChromeLens-Zugänglichkeitserweiterung verwendet, um die Tab-Reihenfolge der Seite zu verfolgen:

Dies kann behoben werden, indem entweder der Hinweis an den Anfang des Dokuments verschoben wird (er kann immer noch mit CSS visuell am unteren Rand verankert werden) oder indem dem OK-Button ein tabindex="1" hinzugefügt wird. Ich würde vorschlagen, diesen Fix auf alle Inhalte anzuwenden, bei denen die Erwartung besteht, dass der Benutzer ihn schließen möchte.

Mehr unsichtbare Links

Wie auf GitHub bin ich mit der Tabulatortaste zu einem Element außerhalb des Bildschirms gesprungen, dessen Zweck nicht klar war. Es stellte sich heraus, dass es sich um einen Schalter „Weniger anzeigen“ handelte, der sich hinter der Karte „Mehr anzeigen“ befand.

Dies liegt daran, dass der „versteckte“ Bereich nicht wirklich verborgen ist, sondern nur um 180 Grad gedreht wird, indem Sie Folgendes verwenden:

 transform: rotateY(180deg);

… was bedeutet, dass die Schaltfläche „Weniger anzeigen …“ immer noch Teil der Tab-Reihenfolge ist. Dies kann behoben werden, indem eine display: none bis die Anwendung bereit ist, die Drehung auszulösen:

Kaffee bestellt. Es ist jetzt an der Zeit, mit meiner Forschung fortzufahren.

IT-Welt

Ich habe für diesen Artikel recherchiert und bin auf ein ähnliches Experiment wie mein eigenes gestoßen; Kevin Purdy surfte sieben Tage lang nur mit seiner Tastatur im Internet. Ich finde es ironisch, dass ich seinen Artikel unter denselben Einschränkungen nicht lesen konnte!

Das Problem war ein ganzseitiges Cookie-Banner, bei dem ich „Datenschutzeinstellungen aktualisieren“ oder die Standard-Cookie-Einstellungen akzeptieren musste. Egal wie oft ich mit der Tabulatortaste klickte, ich konnte mich nicht auf das Cookie-Banner konzentrieren und es schließen.

Ich grub in den Quellcode, um herauszufinden, was los war. Für einen Moment dachte ich, es könnte unser Erzfeind sein, die CSS-Eigenschaft outline .

Wenn ich den Link „Datenschutzeinstellungen aktualisieren“ untersuche, sehe ich eine outline: 0 , wie ich vermutet habe. Vielleicht konzentriere ich mich also auf die Tasten, aber es gibt kein visuelles Feedback, wenn das passiert?

Ich habe versucht, den Status auf :hover zu setzen, um zu sehen, ob ich als Tastaturbenutzer irgendein Styling verpasst habe:

Tatsächlich nahm der Link beim Schweben eine schöne, offensichtliche orange Farbe an – etwas, das ich nie im Fokus gesehen habe:

Hurra! Geknackt! Ich habe den :focus -Zustand nie gesehen, da benutzerdefiniertes Styling nur auf :hover angewendet wurde. Ich muss die Tasten übersprungen haben, ohne es überhaupt zu bemerken, oder?

Falsch. Selbst als ich das CSS lokal hackte, konnte ich kein Fokus-Styling sehen, was bedeutet, dass ich nicht einmal so weit kam, in das Cookie-Modal zu wechseln. Dann wurde mir klar, dass dem Link ein href Attribut fehlte:

Das war der wahre Übeltäter. Die outline: 0 war nicht das Problem – der Browser würde niemals mit der Tabulatortaste zum Link wechseln, weil es kein gültiger Link war!

Aus der HTML 5.2-Spezifikation:

Das Ziel des/der Links wird durch das href-Attribut angegeben, das vorhanden sein und eine gültige, nicht leere URL enthalten muss, die möglicherweise von Leerzeichen umgeben ist. Fehlt das href-Attribut, definiert das Element keinen Link.

Den Links ein href-Attribut zu geben – auch wenn es nur # ist – würde sie zu gültigen Links machen und sie zur Tab-Reihenfolge der Seite hinzufügen.

Lustigerweise wurde mir später an diesem Tag ein Artikel auf PC World zum Lesen geschickt und ich stieß auf genau das gleiche Problem.

Es scheint, dass beide Websites dieselbe Consent Management Platform (CMP) verwendeten. Ich habe ein wenig nachgeforscht und bin zu dem Schluss gekommen, dass eine Reihe von Websites derselben Firma davon betroffen waren, und habe sie seitdem direkt mit einem Lösungsvorschlag kontaktiert.

Kinetico

Mein Küchenhahn ist undicht und ich wollte ihn ersetzen lassen. Ich habe in der Lokalzeitung eine Anzeige für kinetico.co.uk gesehen, also dachte ich, ich schaue mal rein.

Ich konnte nicht zum Abschnitt „Küchenarmaturen“ navigieren, da der Link hinter einem übergeordneten Link „Salt & Cartridges“ versteckt war, der nur seine untergeordneten Links beim Hover anzeigt. Es ist interessant, dass die Seite zukunftsorientiert genug ist, um einen „Zum Inhalt springen“-Link bereitzustellen (kurz im GIF oben zu sehen), aber kein barrierefreies Menü erstellen konnte!

Hier geht das Menü schief – es zeigt nur das Untermenü, wenn der Mauszeiger über das übergeordnete Menüelement bewegt wird:

Das zu reparieren ist leichter gesagt als getan. In den meisten Fällen können Sie Ihren Selektor einfach „verdoppeln“, um ihn auch auf den Fokus anzuwenden:

 li:hover .nav_sub_menu, li:focus .nav_sub_menu { }

Aber das funktioniert in diesem Fall nicht, weil das <li> -Element zwar hoverbar, aber nicht fokussierbar ist. Es ist der Link innerhalb des <li> , der fokussiert werden kann. Aber das Untermenü befindet sich nicht innerhalb des Links, sondern daneben , also müssen wir den Geschwisterselektor anwenden, um das Untermenü anzuzeigen, wenn der Link im Fokus ist.

 li:hover .nav_sub_menu, a:focus + .nav_sub_menu { }

Diese Optimierung bedeutet, dass wir unser Untermenü sehen können, wenn wir auf der Tastatur zum übergeordneten Menüelement navigieren. Aber was passiert, wenn Sie versuchen, in das Untermenü zu gelangen?

Wenn wir mit der Tabulatortaste vom übergeordneten Menüelement ausgehen, verschiebt sich der Fokus erwartungsgemäß auf den ersten Link im untergeordneten Menü. Aber dies verschiebt den Fokus weg vom übergeordneten Menülink, was bedeutet, dass das Untermenü ausgeblendet wird und die untergeordneten Menüelemente wieder aus der Tab-Reihenfolge entfernt werden!

Dies ist ein Problem, das mit :focus-within gelöst werden kann, wodurch Sie Stile auf ein übergeordnetes Element anwenden können, wenn es oder eines seiner untergeordneten Elemente den Fokus hat. In diesem Fall müssen wir also verdreifachen:

 li:hover .nav_sub_menu, /* hover over parent menu item, show child menu */ a:focus + .nav_sub_menu, /* focus onto parent menu item, show child menu */ .nav_sub_menu:focus-within { /* focus onto child menu item, keep showing child menu */ }

Unser Menü ist jetzt über reines CSS vollständig über die Tastatur zugänglich. Ich liebe kreative CSS-Lösungen, aber ein Wort der Warnung hier: Ziemlich viele „CSS-only“-Lösungen in freier Wildbahn versagen, wenn es um die Tastaturnavigation geht. Das Vermeiden von JavaScript macht eine Website nicht unbedingt zugänglicher.

Tatsächlich könnte ein JS-gesteuertes Menü in diesem Fall besser sein, da die Browserunterstützung für diese Lösung immer noch ziemlich schlecht ist. :focus-within kann derzeit nur in Chrome, Firefox und Safari verwendet werden. Sogar in Chrome stellte ich fest, dass es mit dem display: none Logik zum Ein-/Ausblenden des untergeordneten Menüs; Ich musste meine Menüpunkte ausblenden, indem ich stattdessen die opacity: 0 setzte.

OK, ich bin fertig für heute. Jetzt ist es an der Zeit, sich mit ein bisschen Social Media zu entspannen.

Facebook

Facebook leistet hier unglaubliche Arbeit und bietet eine Meisterklasse in Sachen Tastaturzugänglichkeit.

Beim allerersten Drücken von TAB öffnet sich ein verstecktes Menü, das Verknüpfungen zu den beliebtesten Abschnitten der aktuellen Seite und Links zu anderen beliebten Seiten bietet.

Wenn Sie mit den Pfeiltasten durch die Seitenabschnitte blättern, werden diese Abschnitte visuell hervorgehoben, sodass Sie sehen können, wohin Sie mit der Tabulatortaste wechseln würden.

Die nützlichste Funktion ist, dass Facebook eine Tastenkombination OPT + / (oder ALT + / ) bereitstellt, um jederzeit zum Menü zurückzukehren, wobei das Attribut aria-keyshortcuts verwendet wird.

 <div class="a11y-help"> Press opt + / to open this menu </div> <div aria-label="Navigation Assistant" aria-keyshortcuts="Alt+/" role="menubar"> <a class="screen-reader-shortcut" tabindex="1" href="#main-content"> Skip to main content </a> </div>

Anders als der Link „Zum Hauptinhalt springen“, der auf der nativen Verankerungstechnologie basiert und „einfach funktioniert“, erfordert das Attribut aria-keyshortcuts , dass der Autor das gesamte Tastaturverhalten implementiert, also müssen Sie einiges schreiben benutzerdefiniertes JavaScript, wenn Sie dies verwenden möchten.

Hier ist ein JS, das den Menüleistenbereich verbirgt und menubar , was ein nützlicher Ausgangspunkt ist:

 const a11yArea = document.querySelector('*[role="menubar"]'); document.addEventListener('keydown', (e) => { if (e.altKey && e.code === 'Slash') { a11yArea.style.display = a11yArea.style.display === 'block' ? 'none' : 'block'; } });

Zusammenfassung

Dieses Experiment war eine Mischung aus großartigen und schlechten Keyboard-Erfahrungen. Ich habe drei Hauptimbissbuden.

Halten Sie es stilvoll

Das bei weitem häufigste Problem mit der Barrierefreiheit der Tastatur, mit dem ich heute konfrontiert bin, ist ein Mangel an Fokus-Styling für Tab-Elemente. Das Unterdrücken nativer Fokusstile ohne das Definieren benutzerdefinierter Fokusstile macht es extrem schwierig, wenn nicht sogar unmöglich, herauszufinden, wo Sie sich auf der Seite befinden. Das Entfernen des Umrisses ist ein so häufiger Fauxpas, dass es sogar eine eigene Website dafür gibt.

Sicherzustellen, dass natives oder benutzerdefiniertes Fokus-Styling sichtbar ist, ist das wirkungsvollste, was Sie im Bereich der Tastaturzugänglichkeit tun können, und es ist oft eines der einfachsten; ein einfacher Fall, in dem Sie Selektoren in Ihrem vorhandenen :hover -Stil verdoppeln. Wenn Sie nach dem Lesen dieses Artikels nur eine Sache tun, sollten Sie in Ihrem CSS nach outline: 0 und outline: none suchen.

Semantik ist der Schlüssel

Wie oft haben Sie versucht, einen Link in einem neuen Tab zu öffnen, nur damit Ihr aktuelles Fenster umgeleitet wird? Es passiert mir hin und wieder, und so ärgerlich es auch ist, ich habe Glück, dass es eines der wenigen Usability-Probleme ist, mit denen ich tendenziell konfrontiert werde, wenn ich das Internet benutze. Solche Probleme entstehen durch den Missbrauch der Plattform.

Schauen wir uns diesen Code hier an:

 <span>Click here</span>

Ein fähiger, sehender Benutzer könnte auf das <span> klicken und zu Google weitergeleitet werden. Da dies jedoch ein <span> und kein Link oder eine Schaltfläche ist, verfügt es nicht automatisch über eine Fokussierbarkeit, sodass eine Tastatur oder ein Bildschirmleser keine Möglichkeit hätte, damit zu interagieren.

Tastaturbenutzer sind standardabhängige Benutzer, während die fähige, sehende Bevölkerungsgruppe privilegiert genug ist, um mit dem Element trotz seiner Nichtkonformität interagieren zu können.

Nutzen Sie die nativen Funktionen der Plattform. Schreiben Sie gutes, sauberes HTML und verwenden Sie Validatoren wie https://validator.w3.org, um Dinge wie fehlende href Attribute in Ihren Ankern zu finden.

Inhalt ist der Schlüssel

Möglicherweise müssen Sie Cookie-Hinweise, Abonnementformulare, Anzeigen oder Werbeblocker-Hinweise anzeigen.

Tun Sie, was Sie können, um diese Erfahrungen unauffällig zu machen. Wenn Sie sie nicht unauffällig machen können, machen Sie sie zumindest abweisbar.

Benutzer sind da, um Ihre Inhalte zu sehen, nicht Ihre Banner, also platzieren Sie diese verwerfbaren Elemente an erster Stelle in Ihrem DOM, damit sie schnell verworfen werden können, oder greifen Sie auf tabindex="1" zurück, wenn Sie sie nicht verschieben können.

Unterstützen Sie schließlich Ihre Benutzer dabei, so schnell wie möglich zu Ihren Inhalten zu gelangen, indem Sie den Heiligen Gral der Links „Zum Hauptinhalt springen“ implementieren.

Bleiben Sie dran für den nächsten Artikel in der Serie, in dem ich auf einigen dieser Techniken aufbauen werde, wenn ich einen Tag lang einen Bildschirmleser verwende.