Für Anfänger kann Barrierefreiheit einschüchternd sein. Bei all den guten Absichten der Welt ist die Lernkurve für die Entwicklung konformer, vollständig zugänglicher Websites und Apps riesig. Es ist auch schwierig, die richtige Beratung zu finden, da es sich um eine sich ständig verändernde und zunehmend überfüllte Landschaft handelt.
Ich habe diesen Beitrag verfasst, um Ihnen einige Tipps zu kleinen Dingen zu geben, die einen großen Unterschied machen können, während sie Ihren Entwicklungsprozess hoffentlich nicht zu sehr beeinträchtigen.
Tauchen wir ein!
Dokumentstruktur und Semantik
Es wird Sie wahrscheinlich nicht überraschen, dass die strukturierte, semantische Organisation Ihres HTML einen großen Unterschied macht. Screenreader verlassen sich auf ein gut strukturiertes Dokument, um einer kohärenten Erzählung folgen zu können. Stellen Sie also sicher, dass Sie die Elemente, die die HTML5-Spezifikation vorsieht, responsiv und effektiv nutzen.
Wenn Sie unsicher sind, wie Sie Ihre Arbeit richtig markieren, schauen Sie sich Ressourcen wie HTML5 Doctor, Code Academy und natürlich CSS-Tricks an. Sie können sich auch Artikel wie „Writing HTML with accessibility in mind“ und „Semantic Structure“ ansehen, um in die richtige Richtung zu gelangen.
Betrachten wir drei spezifische Dinge, die helfen können, ein gut strukturiertes und semantisches Dokument sicherzustellen.
Verwenden Sie ein einziges <main>-Element
Ein gutes Beispiel für den Aufbau einer verantwortungsvollen, semantischen Dokumentenstruktur ist die Verwendung eines einzigen <main>-Elements. Dies sollte als Wegweiser für die wichtigsten Inhalte der Seite für Ihren Benutzer dienen.
Fügen Sie ihm eine ID hinzu und bieten Sie einen Sprunglink in Ihrem Haupt-<header> wie folgt an
<header role="banner">
<h1>Your main page title</h1>
<a href="#main-content">Skip to the main content</a>
</header>
<!-- Further down the document -->
<main id="main-content">
<!-- Put your main body of content in here and other really important stuff -->
</main>
Dieser kleine Trick wird Ihren Screenreader-Nutzern enorm helfen, da sie direkt zu Ihren wichtigen Inhalten springen können und die schicken Teile überspringen. Das ist aus demselben Grund auch großartig für Tastaturnutzer.
Eine weitere nette Geste ist, dem Sprunglink einen :focus-Stil hinzuzufügen, der ihn sichtbar macht. Versuchen Sie, auf GitHub.com mit der Tabulatortaste zu navigieren. Ziemlich raffiniert, oder?
Verwenden Sie Elemente angemessen
Nun, <button>-Elemente sind eine echte Plage beim Stylen, oder? Das bedeutet aber nicht, dass Sie Ihre JavaScript-Events an ein <div> oder ein <a href="#"> anhängen sollten. Denn wenn Sie einen <button> verwenden, erhalten Sie Tastaturereignisse kostenlos. Sie helfen auch Screenreader-Nutzern, da das Element korrekt angekündigt wird. Schauen Sie sich dieses Beispiel an
document.getElementsByTagName('button')[0].addEventListener('click', evt => {
alert('Oh, hey there!');
});
Wenn ein Benutzer diesen Button fokussiert und die Enter-Taste drückt, wird dieses Ereignis ausgelöst. Das erleichtert Ihnen und dem Benutzer das Leben. Lohnt sich, oder?
Siehe den Pen Button click example von Andy Bell (@hankchizljaw) auf CodePen.
Sorgen Sie für eine korrekte Überschriftenhierarchie
Es ist sehr üblich, dass Screenreader-Nutzer eine Seite anhand der Überschriftenstruktur navigieren. Das bedeutet, wir sollten ihnen helfen und eine schöne Hierarchie für sie schaffen. Werfen wir einen Blick auf einen Standard-Blogbeitrag
<main id="main-content">
<article>
<!-- The page title is up in the main <header> in this instance -->
<h2>My awesome blog post</h2>
<p>Vestibulum id ligula porta felis euismod semper.</p>
<p>Vestibulum id ligula porta felis euismod semper.</p>
<h3>A sub-section of this post</h3>
<p>Vestibulum id ligula porta felis euismod semper.</p>
<h4>A sub-section of the sub-section</h4>
<p>Vestibulum id ligula porta felis euismod semper.</p>
</article>
</main>
Mit diesem Beispiel kann der Benutzer zum Anfang von „Mein toller Blogbeitrag“ navigieren und dann problemlos zu Unterabschnitten und verschachtelten Unterabschnitten springen. Sie können auch zurück nach oben springen. Es ist einfach eine nette Möglichkeit, ihnen den Konsum der von Ihnen erstellten Inhalte so einfach wie möglich zu machen.
Es kann empfohlen werden, dass eine Seite ein einziges <h1>-Element hat, auch wenn die W3C HTML5-Spezifikation besagt, dass Sie mehrere haben können. Ich persönlich stimme der Verwendung eines einzigen <h1> zu, aber Sie können mehrere haben, solange Sie eine schöne Struktur und Hierarchie befolgen. Das ist hier der Schlüssel.
Stellen Sie den richtigen Farbkontrast sicher
Um WCAG 2.0 AA-konform zu sein, benötigen Sie ein Kontrastverhältnis von 4,5:1 für normalen Text. Das betrifft Ihre Absätze, Buttons, Navigation usw. Für größeren Text, wie Überschriften, benötigen Sie ein Verhältnis von 3:1. Ich würde sagen, das sollte Ihr Minimum sein, da es mit Tools wie Tota11y, Contrast und dem WebAim Kontrastprüfer unglaublich einfach zu erreichen ist. Sie können immer noch viel Farbbalance und Variation in Ihrem Design erzielen.
Der Grund, warum Kontrast so wichtig ist, liegt darin, dass es so viele Umweltvariationen gibt, die Sie wahrscheinlich gar nicht berücksichtigen, wie z. B. helles Sonnenlicht und schlecht belichtete Displays. Hinzu kommt eine Sehbeeinträchtigung oder, sagen wir, eine Migräne, und Sie verursachen potenziell Probleme für Ihre Benutzer.
Die richtige Kontrastierung wird einen großen, positiven Effekt auf ein breites Spektrum Ihrer Benutzer haben.
Verantwortungsvolle Textbeschriftungen
Wir alle haben eine Liste von Elementen mit einem nicht aussagekräftigen, aber visuell ansprechenden „Mehr“-Button erstellt, oder? Mehr was aber? Wir müssen hier verantwortungsvoller sein und etwas Kontext liefern.
Eine Möglichkeit, dies zu erreichen, ist die visuelle Verbergung beschreibenden Textes mit CSS und die Verbergung des nicht beschreibenden Textes vor Screenreadern. Es ist verlockend, display: none; zu verwenden, aber Screenreader können Elemente ignorieren, bei denen dies gesetzt ist, also müssen wir kreativer sein. Ich benutze so etwas wie diesen kleinen Helfer
.visually-hidden {
display: block;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px);
clip: rect(1px, 1px, 1px, 1px);
clip-path: inset(1px);
white-space: nowrap;
position: absolute;
}
Mit diesem CSS können wir etwas wie das tun
<a href="/link-to-your-page">
<!-- This is hidden from a screen reader, but visible visually -->
<span aria-hidden="true">More</span>
<!-- This is visible to a screen reader, but visually hidden -->
<span class="visually-hidden">Continue reading: "Your post title here"</span>
</a>
Ein sehender Benutzer sieht nur „Mehr“ und ein Screenreader-Benutzer hört „Weiterlesen: ‚Ihr Posttitel hier‘“. Beide Benutzertypen sind glücklich.
Sie können das oben Erwähnte auch erreichen, indem Sie ein aria-label im <a>-Tag verwenden. Dies überschreibt den Text darin für einen Screenreader
<a href="/link-to-your-page" aria-label="Continue reading: 'Your post title here'">
More
</a>
Kleine Typografie-Anpassungen mit großer Wirkung
Es ist immer erwähnenswert, dass Menschen mit Sehbehinderungen oder Lernschwierigkeiten versuchen könnten, Ihre Inhalte zu lesen, daher können einige kleine Anpassungen Ihrer Typografie weit reichen.
Ein Textkörper wie ein Artikel sollte mindestens 16px (oder eine entsprechende Einheit) groß sein. Es lohnt sich auch, Ihre line-height auf etwa 1,5 zu erhöhen. Der Abstand zwischen den Zeilen kann Lesern mit Legasthenie helfen, Ihre Inhalte besser zu verstehen. Die Kombination aus Größe und Abstand ist auch großartig für ältere und/oder kurzsichtige Menschen. Auch kleine Zusammenfassungen und Randnotizen sollten mindestens 12px (oder eine entsprechende Einheit) groß sein. Alles, was kleiner ist, schließt Benutzer aus, die Schwierigkeiten beim Lesen haben.
Ein weiterer Trick ist, Schlüsselwörter und Phrasen hervorzuheben, wenn Ihr Inhalt recht komplex ist. Dies kommt nicht nur Benutzern zugute, die Inhalte etwas langsamer verarbeiten, sondern hilft auch Menschen, die gerne einen Artikel überfliegen, so wie ich.
Zuletzt in diesem Abschnitt rate ich Ihnen, vorsichtig mit Ihrer Font-Auswahl zu sein. Fonts mit komplexen Ligaturen und dekorativen Elementen können sehr ablenkend sein, also beschränken Sie die Verwendung solcher Fonts vielleicht nur auf wichtige, große Überschriften. Es wurde auch empfohlen, dass serifenlose Schriften für Legastheniker besser sind. Lesen Sie diesen Artikel für mehr darüber und andere Tipps zur Textformatierung.
Verbessern Sie die Tastaturunterstützung
Es gibt ein paar kleine Anpassungen, die Sie vornehmen können, um Benutzern zu helfen, die hauptsächlich ihre Tastatur zur Navigation auf Ihrer Website verwenden.
Nehmen wir an, Sie haben einen kleinen Button, der ein Dialogfeld anzeigt, wenn Sie darauf klicken. Sie sollten ein Ereignis für die Escape-Taste anhängen, das es ausblendet. Hier ist ein Beispiel-Snippet
document.addEventListener('keyup', (evt) => {
if(evt.keyCode === 27) {
// Run whatever code hides your dialogue
}
});
Siehe den Pen Escape key demo von Andy Bell (@hankchizljaw) auf CodePen.
Eine weitere Anpassung, die Sie für unsere tastaturnavigierenden Freunde vornehmen können, ist, ihnen den Fokus nicht zu verbergen. Browser stellen uns kostenlose Fokus-Zustände mit outline zur Verfügung. Ich weiß, dass es hässlich aussehen kann, aber verdammt nützlich für Tastaturnutzer ist. Wenn Sie diesen blauen Schein loswerden wollen, verstehe ich das – aber bitte verwenden Sie den :focus-Pseudo-Selektor, um ihm stattdessen eine offensichtliche Zustandsänderung hinzuzufügen. Hier ist ein Beispiel
.your-element {
background: red;
}
.your-element:focus {
outline: none; /* Reset the default */
box-shadow: 0 0 0 3px black; /* A very obvious state change */
}
Verlassen Sie sich nicht nur auf Farbe, um Zustandsänderungen zu kommunizieren
Beenden wir mit einem wirklich wichtigen Punkt. Farbe sollte nicht allein verwendet werden, um Zustandsänderungen zu kommunizieren. Nehmen wir dieses Szenario als Beispiel
Sie haben einen Button, der ein Formular absendet. Sie haben ein nettes JavaScript geschrieben, das ihn grau werden lässt, während die Daten gesendet werden. Dann wird er entweder grün oder rot, je nachdem, was der Status ist.
Für einen Farbenblinden ist das ein Albtraum. Für ihn hat sich die Farbe des Buttons vielleicht kaum genug geändert, um sie zu bemerken, sodass er vielleicht immer wieder klickt und frustriert ist. Das ist nicht ideal.
Lassen Sie uns also anstatt sich auf Farbe zu verlassen, dies mit einer Statusmeldung ergänzen, die den Zustand des Buttons als Reaktion unterstützt.
Siehe den Pen Enhanced state change communication demo von Andy Bell (@hankchizljaw) auf CodePen.
Dieses Beispiel ist eine großartige Möglichkeit, dem Benutzer schnell mitzuteilen, dass sich etwas geändert hat, und die Verwendung von Farbe, Text und Symbolen kommuniziert diese Änderung deutlich. Das Deaktivieren des Buttons während der Verarbeitung der Antwort ist ebenfalls eine große Hilfe für den Benutzer.
Zusammenfassend
Diese kleinen Tipps sollten für Ihre Benutzer einen großen Unterschied machen, und ich hoffe, Sie tauchen in Ihre Projekte ein und implementieren einige davon.
Sie sollten auch weiterhin über Barrierefreiheit lernen. Ich empfehle, Leuten wie Heydon Pickering, Scott O’Hara, Laura Kalbag und Rob Dobson auf Twitter zu folgen. Ich empfehle Ihnen auch, sich Ressourcen wie Inclusive Components und das A11y Project anzusehen.
Je größer Ihr Wissen wird, desto besser werden Ihre Websites und Produkte für ein viel größeres Publikum sein. Das kann nur gut sein, oder?
Verdammt, das war ein guter Artikel, danke!
Danke, Brian! Ich hoffe, es hilft Ihnen, einige großartige barrierefreie Websites zu erstellen.
Ich verstehe die Verwendung eines einzigen Hauptelements, aber ich frage mich, was das jetzt bedeutet, da in HTML5.2 mehrere Hauptelemente auf einer Seite als gültiges HTML gelten.
Soweit ich weiß, kann zu einem bestimmten Zeitpunkt nur ein
<main>-Element sichtbar sein. Andere<main>-Elemente sollten versteckt sein, wie folgt:<main hidden>. Dies versteckt es vor einem Screenreader. Sie könnten alternativ auch CSS verwenden und die Eigenschaftaria-hidden="true"hinzufügen, wie ich oben erwähnt habe.Das
hidden-Attribut ist eine völlig gültige Methode, um Elemente visuell und vor Screenreadern zu verbergen, also ist es ein nützliches Werkzeug.Tatsächlich betrachtet WHATWG mehrere Hauptelemente als gültig (sodass Sie in jedem Abschnitt einen Header, Main und Footer haben können). Aber das kann sich in Zukunft ändern. Es gibt einen aktuellen Vorschlag, das zu ändern.
Übrigens, meines Wissens unterstützt kein Screenreader das Main-Tag. Sie springen alle zum ersten h1-Element, und h1 sollte direkt über dem Hauptinhalt stehen.
Die CSS-Eigenschaft CLIP ist veraltet, aber Sie können CLIP-PATH für neue Browser verwenden. Trotzdem ein toller Artikel :)
Ah, vielen Dank, Mino. Sieht so aus, als müsste ich mir für die Zukunft einen neuen Weg ausdenken,
clip-pathzu verwenden. Hoffentlich ist die Prämisse,clipzu verwenden, für die Leute immer noch nützlich.Bootstrap, so sehr ich es auch verabscheue, verwendet die .sr-only-Klasse für den Sprungnavigationslink mit
Würden Sie sagen, das ist in Ordnung? Ich meine, ist das CSS so korrekt, oder kann ich einfach visibility: hidden auf den Skip-to-main-Link anwenden?
Referenz
https://a11yproject.com/posts/skip-nav-links/
https://v4-alpha.getbootstrap.com/getting-started/accessibility/#skip-navigation
https://github.com/twbs/bootstrap/blob/v4-dev/dist/css/bootstrap.css#L7365
Das CSS ist auf jeden Fall in Ordnung. Das Bootstrap-Team macht keine Witze :)
Ziemlich clevere Anpassungen tatsächlich. Kleinere Änderungen, aber sehr hilfreich. Danke.
Kein Problem. Ich hoffe, es hilft Ihnen, anderen zu helfen :)
Sehr guter Artikel :) Es macht das Nachdenken über Barrierefreiheit viel einfacher, wenn man ein paar „Quick Wins“ kennt, die man von Anfang an umsetzen kann.
Eine Sache, die es wert sein könnte, hinzuzufügen, ist das Bewusstsein für „zusammengeschobenen Text außerhalb des Bildschirms“ (https://medium.com/@jessebeach/beware-smushed-off-screen-accessible-text-5952a4c2cbfe), wenn Text sichtbar verborgen wird. Das Hinzufügen von
white-space: nowrapwirkt Wunder.Gut gemacht! Das füge ich meiner Leseliste hinzu. Danke :)
Wirklich guter Artikel! Prost
Danke :)
Ich habe immer eine etwas andere Klasse für versteckte Beschreibungen verwendet, die sich im Laufe der Jahre weiterentwickelt hat
Ich glaube (bin mir aber nicht ganz sicher), dass clip verschiedene Syntax-Iterationen durchlaufen hat, daher die Komma-Version von rect, die einige verschiedene Vendor-Implementierungen erfasst hat, bevor sie ausgemustert wurde. Das neue clip-path mit inset scheint das alte clip-Verhalten korrekt zu replizieren und ist die bevorzugte Methode, wenn Sie keine Fallbacks benötigen.
Die Verwendung von Höhe und Breite von 0 kann ein Element manchmal genauso verstecken wie display:none, daher ist eine Breite und Höhe von 1px sicherer.
Die anderen Eigenschaften halten den Text aus dem Seitenfluss heraus, wobei Overflow und Umbrüche ordnungsgemäß funktionieren.
Ailwyn war schneller als ich, speziell die Deklaration von
white-space: nowrap;. Wenn diese fehlt, können Screenreader den versteckten Text Buchstabe für Buchstabe vorlesen, da sie versuchen, den Versuch des Browsers zu honorieren, den Text im winzigen Container umzubrechen. Weitere Informationen finden Sie in Jesse Beachs Artikel: https://medium.com/@jessebeach/beware-smushed-off-screen-accessible-text-5952a4c2cbfeDer Non-Comma-Clip –
rect(1px 1px 1px 1px)– zielt auf IE6 und IE7 ab.Danke dafür. Das ist eine toll aussehende Klasse.
Ich habe früher .visually-hidden mit absolute Positionierung selbst verwendet, hatte aber Probleme mit fokussierbaren Elementen, wie z. B. Checkboxen, die visuell versteckt waren, wenn sie außerhalb des Bildschirms oder in einem Container mit
overflow: scroll/autowaren.Großartig, danke Adrian! Einige wirklich nützliche Rückmeldungen. Ich werde das Snippet in diesem Artikel basierend auf Ihrem und dem Feedback anderer aktualisieren.
Danke!
Toller Artikel! Bezüglich Textbeschriftungen, was ist der Vorteil von „aria-label“ gegenüber einem einfachen „title“?
Grundsätzlich besteht die Möglichkeit, dass er nicht von einem Screenreader gelesen wird. Dieser Artikel ist alt, aber gut: https://silktide.com/i-thought-title-text-improved-accessibility-i-was-wrong/
Viele Leute stylen den Fokus nicht, weil sie nicht mögen, dass er den Stil sowohl für Tastatur- als auch für Mausfokus anwendet. Es gibt einen CSS-Stil für :focus-ring, der es Ihnen ermöglicht, den Fokus nur per Tastatur zu stylen. Derzeit nicht weit verbreitet, aber es gibt ein großartiges Polyfill dafür!
Ich denke, viele Leute stylen :focus nicht, weil sie sich der Notwendigkeit nicht bewusst sind, dass er sich von :hover unterscheidet. Ich musste den Unterschied schon mehr als einmal argumentieren!
Ich habe eine Frage zur Kopfzeilenstruktur. Ich habe gelesen, dass man mehrere H1-Tags haben kann, ein Beispiel wäre die Startseite eines Blogs. Die Struktur würde so aussehen.
Main
H1
Artikel
Überschrift
H1
/Header
{content}
/Artikel
Artikel
Überschrift
H1
/Header
{content}
/Artikel
Artikel
Überschrift
H1
/Header
{content}
/Artikel
/Main
Ist das richtig? Und wenn Sie mehrere Section-Tags haben, kann jeder einen H1 haben? Oder müssen Sie Ihre H-Tags inkrementieren?
Ihre Überschriftenstruktur sollte den Inhalt widerspiegeln, nicht die Verwendung von
section,articleusw. Der Rat, alleh1s (oder sogar mehrere) zu verwenden, stammte vom vorgeschlagenen Document Outline Algorithm. Er wurde jedoch nie in einem Browser implementiert und wird es wahrscheinlich auch nicht. Idealerweise eineh1pro Seite, und sie sollte widerspiegeln, worum es auf der Seite geht (und demtitle-Element entsprechen).Dennoch rate ich den Autoren, weder
sectionnocharticlezu verwenden, es sei denn, sie beginnen mit einerh#(auf welcher Ebene auch immer). Das liegt daran, dass diese Elemente in HTML Abschnittselemente sind und zugängliche Namen haben sollten, damit assistive Technologien sie den Benutzern vermitteln können. Die Verwendung vonh#gibt Ihnen das. Andernfalls verwenden Sie diese Elemente möglicherweise als Styling-Hooks, was nicht ihr Zweck ist.Der Schlüssel ist die Hierarchie. Haben Sie also viele H1s in vielen Abschnitten, aber stellen Sie sicher, dass die Überschriften innerhalb des Abschnitts einer Hierarchie folgen.
Der Grund, warum ich ein H1 mag, ist, dass es Ihnen eine Hauptüberschrift gibt, dann werden die H2s verwendet, um Top-Level-Abschnitte auf einer Seite zu kennzeichnen. Aber wie gesagt, es ist völlig gültig, viele H1s zu haben.
Andy, mehrere
h1s sind gültig, aber oft benachteiligend für diejenigen, die sie am meisten benötigen. Meine eigenen Usability-Tests, gepaart mit allgemeinen Umfragen (siehe die neueste WebAIM Screen Reader User Survey unter https://webaim.org/projects/screenreadersurvey7/#heading), sagen mir, dass der ideale Weg ein einzelnesh1ist.Das ist eine sehr nützliche Einsicht, Adrian. Vielen Dank. Ich war immer etwas passiv bezüglich mehrerer
h1s, aber ich werde jetzt den Ansatz mit einem einzigenh1stark fördern und diese Forschung zitieren :).visually-hidden wirkt so nachgebastelt. Gibt es dafür noch kein ARIA-Attribut im HTML-Standard?
Danke für den Artikel, der die Grundlagen der Barrierefreiheit entmystifiziert. Das aria-label-Beispiel für den „Mehr“-Button legt für mich eine universellere Lösung nahe: Wenn der „Mehr“-Text für Benutzer von AT nicht klar ist, ist er vielleicht für niemanden klar? Eine gute Nutzung der Barrierefreiheitsfunktionen von Browsern bedeutet auch zu wissen, wann man sie NICHT verwenden sollte – das Web ist standardmäßig barrierefrei, und die Präsentation einer konsistenten Benutzeroberfläche für alle Benutzer ist einfacher und besser.
Warum die übermäßigen Eigenschaften bei .visually-hidden? Ist etwas falsch mit diesem
Die Klasse
.visually-hiddenist weniger auf Exzess ausgelegt, sondern auf Flexibilität. Sie können sie überall einfügen und sie sollte Ihr Layout nicht zerstören, und das ist es, was wir anstreben.ARIA ist im Wesentlichen eine separate Spezifikation und wird nur von Screenreadern unterstützt, sodass ein ARIA-Attribut Nicht-Screenreader-Benutzern nicht zugutekommt (es sei denn, Sie verwenden sie für CSS-Selektoren). Ein Attribut, um Dinge nur visuell zu verstecken, ist Domäne von CSS, nicht von HTML. Mir scheint, dass der obige Ansatz, obwohl umständlich, die Trennung der Zuständigkeiten einhält. Wenn Sie einen greifbaren Vorschlag haben, nur zu, bitte schlagen Sie ihn vor. Das W3C sucht immer nach Feedback von mehr Entwicklern, insbesondere wenn sie Ideen auf Basis praktischer Erfahrungen haben.
Als Blockelement wird es ohne explizite Breite trotzdem Platz einnehmen. Es kann auch Scrollbalken anzeigen. Es reicht auch nicht aus, um in die IE-Welt zurückzufallen. Der IE-Teil ist wichtig, da viele Leute, die auf assistierende Technologien angewiesen sind, bei IE feststecken, aufgrund der Unterstützung durch ihren Arbeitgeber, den Anbieter und sogar Richtlinien.
Andy Bell, danke für Ihren Artikel und dafür, dass Sie die Botschaft verbreiten :) Nur eine kurze Anmerkung: Ein Fokus-Stil, der nur auf Box-Shadow basiert, ist problematisch mit Windows High Contrast Mode, da dieser jeden Hintergrund und Box-Shadow entfernt. Das Ergebnis wäre kein Fokus-Stil. Outline und Border funktionieren weiterhin.
Danke für das Feedback, Andrea – das ist gut zu wissen. Ich lerne viel aus diesem Kommentar-Thread :)
Ich hoffe, die Quintessenz ist eher „Ich muss sicherstellen, dass meine Fokus-Zustände offensichtlich sind“, als spezifische CSS-Eigenschaften. Ich werde diese kleine Wissensnugget aber in meinem Arsenal behalten.
Das Beispiel mit aria-hidden innerhalb eines Links ist ebenfalls etwas umstritten. Screenreader lesen das möglicherweise trotzdem vor, zum Beispiel liest VoiceOver beim Navigieren durch Inhalte Zeichen für Zeichen "Mehr" vor. Ich bin ziemlich sicher, dass andere Screenreader das auch vorlesen. Außerdem kann es für sprachgesteuerte assistierende Technologien (Spracherkennungssoftware), die zwei verschiedene Texte bereitstellen (einen für die visuelle Anzeige und den anderen für Software, die ARIA versteht), problematisch sein und den Benutzern den Zugriff auf diese Steuerung verwehren, wie in der ARIA-Empfehlung klar dargelegt.
Auch gut zu wissen. Danke Andrea :)
Großartiger Artikel!
Nur eine Beobachtung: In der Sektion „Don’t Rely on Color Alone to Communicate State Changes“ haben Sie Recht, mit der Ausnahme, dass die Zustandsänderung beim Überfahren des Buttons mit der Maus zu klein ist. Die Farbunterschiede zwischen dem normalen und dem Hover-Zustand des Buttons sind zu subtil.
Für mich ist Hovering eine Zustandsänderung :)
Gute Beobachtung, Victor! Ich habe die Pens ein wenig angepasst :)
Eine MILLION Daumen hoch für den Vorschlag zur Funktionalität der
esc-Taste. Die Maus ist mit meiner Behinderung eine solche Qual. Ich drücke immer diese Taste, um Pop-ups zu schließen, und melde unweigerlich dem Website-Betreiber, wenn dies (oder eine ähnliche Verknüpfung) nicht funktioniert.Ich finde das selbst auch unglaublich frustrierend. Ich hoffe, dieser Artikel wird ein gewisses Bewusstsein schaffen und dass Sie in Zukunft weniger Beispiele dafür in freier Wildbahn finden werden :)
Ich bin behindert und bediene den Computer per Spracherkennung. Viele beliebte Websites wie Facebook und Pinterest sind auf Tastaturereignisse angewiesen, um Code in der Suchleiste auszuführen. Spracherkennungssoftware wie Dragon NaturallySpeaking löst jedoch manchmal keine Tastatur- oder Maustastenereignisse aus. Wenn jemand diktiert, löst er stattdessen Windows Journal-Ereignisse unter Windows aus. Das ist ein riesiges Problem bei Facebook. Ich habe es umgangen, indem ich benutzerdefinierten Code geschrieben habe, um Tastendrücke zu emulieren, wenn ich diktiere. Dies funktioniert jedoch nicht, wenn ich Makros verwende.
Es wäre großartig, wenn die Richtlinien für Barrierefreiheit auch das Beobachten von Windows Journal-Ereignissen beinhalten würden. Ich hoffe, dass dies Teil der WCAG-Richtlinien wird. Bisher habe ich jedoch noch keine Fortschritte in dieser Hinsicht gesehen.
Ich hoffe, Sie können die Verdienste dieses Vorschlags berücksichtigen und ihn in Ihre Empfehlung aufnehmen.
Als Entwickler ist es so schwer, das alles zu berücksichtigen. Ich bin so froh, dass Sie kommentiert haben, denn ich habe heute definitiv etwas gelernt.
Ich würde Entwicklern persönlich empfehlen, das
input-Ereignis für die Erkennung von Eingaben zu verwenden. Ich frage mich, ob das in Ihrem Szenario helfen würde, da für jedes eingefügte oder gelöschte Zeichen ein Ereignis ausgelöst wird?Ich glaube, dass „Skip to main content“ das erste fokussierbare Element auf der Seite sein sollte und nicht innerhalb des
<header>-Elements und nach dem<h1>-Seitentitel platziert werden sollte, wie im Beispiel gezeigt.