Ich schreibe gerne kleine Gedanken auf, wie ich sie sehe. Kürzlich haben wir einen Artikel von Facundo Corradini verlinkt, der einen Tweet von uns kritisiert, in dem wir <em> verwendet haben, wo wir wahrscheinlich <i> hätten verwenden sollen.
Bruce Lawson prüft, ob Screenreader Opfer dieser semantischen Fehler werden…
Immer wenn ich „einige Browser“ oder „einige Screenreader“ lese, frage ich mich immer „aber welche?“, ebenso wie Ilya Streltsyn, der mich fragte: „Wie ist der aktuelle Stand der Textsemantik in der HTML-Realität?“
Léonie Watson zur Rettung! Über Twitter schrieb Watters
Die meisten sind in der Lage, diese Dinge auf Anfrage zu melden, tun dies aber nicht standardmäßig. Sie hören also nicht die Text-/Schrifteigenschaften, die beim Lesen angesagt werden, aber Sie können ein Zeichen/Wort usw. abfragen, um seine Eigenschaften zu ermitteln. Dies basiert jedoch auf der visuellen Darstellung des Textes und nicht auf der Erkennung der Elemente selbst.
Was, wie ich vermute, bedeutet, dass Sie sich entspannen können, wenn Sie sich wirklich Sorgen darüber machen, dass Screenreader die nuancierte Verwendung Ihrer semantischen Hervorhebung falsch interpretieren.
Bruce's Artikel führte mich zu Steve Faulkner's Artikel „Screen Reader fehlt Betonung“ aus dem Jahr 2008.
Die Verwendung der semantischen Elemente strong und em vermittelt unter typischen Browserbedingungen keine nützlichen Informationen für Benutzer von JAWS oder Window Eyes. Obwohl es gut ist, dies zu wissen, ist es kein Grund, diese Elemente nicht zu verwenden, um Bedeutung zu vermitteln. Barrierefreiheit betrifft nicht nur Menschen mit Sehbehinderungen, sondern alle Benutzer mit Behinderungen, und Webstandards sind nicht nur Barrierefreiheit.
Also, in einem Jahrzehnt hat sich da nicht viel geändert. Es ist mir unklar, ob sich die Dinge hier ändern sollten oder nicht, aber wenn sich virtuelle Stimmen verbessern, ist es logisch, dass sie besser darin werden, Stimminflektionen zu verwenden, die Betonung vermitteln. Ich denke sicherlich über Stimmbetonung nach, wenn ich diese HTML-Tags schreibe.
Diese Idee von zu viel Barrierefreiheit war ein bisschen ein Thema.
- Eric Baily befasste sich damit, wie WIA-ARIA, wenn es falsch verwendet wird, mehr schaden als nutzen kann.
- Jared Smith antwortet auf eine Frage eines Studenten: „Ist es möglich, dass eine Webseite übermäßig barrierefrei ist?“
- Vor 11 Jahren erstellte Patrick H. Lauke eine Präsentation namens Zu viel Barrierefreiheit, die Dinge wie übermäßige Explizitheit behandelt.
Bitte lesen Sie diesen Artikel nicht als Vorschlag, dass wir uns zu viele Sorgen um Barrierefreiheit machen – nur, dass es möglich ist, sich um die falschen Dinge zu sorgen und sogar die Barrierefreiheit im Prozess zu vermasseln, wie bei allem anderen auch.
Tolle kleine Denkanstöße. Danke!
CSS-Durchstreichung ist etwas anderes, das von Screenreadern nicht wirklich kommuniziert wird, aber viel visuelle Bedeutung hat. z. B. Verkaufspreis / Normalpreis. Keine Semantik, da das strike-Tag veraltet ist, aber in der gleichen Arena. Der beste Weg, um das zu wissen, ist das Testen. Kreative aria-label oder visuell versteckter Text kann in diesem Fall Bedeutung aufbauen.
Das <s>-Element ist nicht veraltet (es war das <strike>-Element, das veraltet war, weil es aus irgendeinem Grund zwei davon gab…) und tatsächlich sind Verkaufspreise genau das vorgesehene Beispiel in den Spezifikationen: https://www.w3.org/TR/html51/textlevel-semantics.html#the-s-element
Aber ja, Screenreader werden es nicht ansagen (um die Ausführlichkeit zu reduzieren), also muss man vorsichtig sein, wie man den Text innerhalb dieses Tags formuliert, damit er auch ohne den Hinweis noch vernünftig klingt.
Verwenden Sie ein
<del>-Tag, um Semantik für etwas wie einen Normalpreis bereitzustellen, der durch einen Verkaufspreis ersetzt wurde, und fügen Sie CSS-Durchstreichung hinzu.Das
<del>-Element wird in allen Browsern mit einer Durchstreichungsformatierung implementiert, aber keine OS-Barrierefreiheits-API erkennt es mit einer besonderen Bedeutung, sodass es semantisch einem neutralen Span-Element entspricht.Das Problem liegt bei alten OS-Barrierefreiheits-APIs, denen es insgesamt an den meisten Textsemantiken mangelt.
Wie kann Barrierefreiheit zu viel sein? Das klingt nach einer Ausrede, um faul zu sein. Kümmern Sie sich nicht nur um den aktuellen Zustand. Kümmern Sie sich auch um den zukünftigen Zustand.
Ich denke, der Titel vermittelt den Punkt nicht so gut, wie ich es von den Punkten im Artikel erwarte. Im Wesentlichen ist es möglich, rücksichtslos Aria-Attribute auf Elemente zu werfen und zu glauben, dass man damit Benutzern hilft, wenn dies tatsächlich mehr Probleme verursachen kann.
Normalerweise ist eine Menge Aria-Attribute ein Zeichen für ein größeres Problem im Design. Zum Beispiel, wenn
role="button"auf etwas wie ein Div angewendet wird. Sicher, es gibt Fälle, in denen man das tun kann, aber oft wäre ein normales Button ausreichend und tatsächlich viel besser zu verwenden.Der beste Weg, eine Website barrierefrei zu gestalten, ist durch gut strukturierte semantische Markup und bewusstes, barrierefreies Design, das Best Practices folgt. Es sollte nicht viel mehr Arbeit oder Gedanken erfordern, und wenn Sie das tun müssen, ist etwas mit Ihrem ursprünglichen Design falsch.
Das fühlt sich wie ein Kommentar an, der sagt: „Ich habe den Titel gelesen und springe jetzt ins Kommentarfeld“, oder?
@chris das scheint etwas voreilig zu sein. Hier ist, warum ich William zustimme
Der Hauptpunkt des Artikels ist, dass es scheinbar keine Fälle gibt, in denen aktuelle Browser bestimmte semantische Markup anders/besser darstellen als Markup, das als weniger semantisch gilt.
Der ganze Sinn des Schreibens von Code für das Web ist nicht, ihn nur für heute funktionsfähig zu machen. Er muss zukunftsgerichtet sein und auch in den Browsern von morgen funktionieren. Das W3C hat schon immer versucht, Entwickler zu einem semantischeren Web zu führen und empfiehlt Dinge wie
<em>anstelle von<i>, wenn der Text mehr als nur visuelle Betonung benötigt.Als verantwortungsbewusste Entwickler sollten wir uns nicht damit zufriedengeben, Dinge nur zum Laufen zu bringen. Wir sollten versuchen, Situationen zu berücksichtigen, die noch nicht eingetreten sind. Deshalb ist responsives Design mehr als nur das Erstellen von Websites, die auf einem bestimmten festen mobilen Bildschirm funktionieren. Deshalb werden Anstrengungen unternommen, Inhalte an die Verbindungsgeschwindigkeiten der Benutzer anzupassen, auch wenn wir nicht wissen, was unsere Benutzer haben könnten. Deshalb lernen wir ständig über neue Technologien, weil wir immer zukunftsgerichtet sein wollen.
Ich stimme vollkommen zu, dass wir Barrierefreiheit vermasseln können, aber ich glaube nicht, dass es daran liegt, zu hart zu versuchen. Ich denke, es liegt daran, dass wir es nicht verstehen. ARIA-Attribute über eine von
<div>-Elementen übersäte Seite zu werfen, ist falsch. Es scheint richtig, weil wir viel Zeit damit verbringen, also arbeiten wir hart, aber wir arbeiten an den falschen Dingen. ARIA war immer nur als Hilfsmittel gedacht, wenn semantische Markup versagte; aber semantische Markup sollte immer König sein.Deshalb stimme ich William zu. Wir müssen auf unser Markup achten, und leider fühlt es sich an, als ob dieser Beitrag nicht die besten Ratschläge gibt (oder zumindest nicht die besten Ratschläge auf die beste Weise).
„Vor 11 Jahren erstellte Patrick H. Lauke eine Präsentation…“ meine Güte, ich fühle mich jetzt alt…
Ich verbringe zu viel Zeit auf StackOverflow damit, Leuten zu sagen, dass sie keinen versteckten Text erzwingen müssen, um Daten oder Preise so zu sprechen, wie sie es wollen, nur weil ein Screenreader ihn nicht wie erwartet sagt. Übermäßige Ingenieursarbeit kann leicht entstehen, wenn wir die Technologie als Ziel und nicht den Benutzer betrachten.
Im Zusammenhang mit der Ankündigung von
<em>in Screenreadern schrieb Steve Faulkner auch einen großartigen Artikel darüber, wie man<mark>auffindbar macht: https://developer.paciellogroup.com/blog/2017/12/short-note-on-making-your-mark-more-accessible/Ich habe ihn erweitert, um
<del>,<ins>und<s>für mehr als nur Screenreader zu verarbeiten: http://adrianroselli.com/2017/12/tweaking-text-level-styles.htmlUm auf Chris' Punkt zurückzukommen: Da NVDA Unterstützung für
<del>und<ins>hinzufügt, werden einige Benutzer meiner Website jetzt zu viel Barrierefreiheit erleben: https://github.com/nvaccess/nvda/pull/8558Diese semantischen Elemente könnten in Zukunft implizite Rollen haben: https://github.com/w3c/aria/issues/698
Der Punkt war, dass Screenreader unser Versäumnis ausgleichen, guten semantischen Code bereitzustellen. Wenn wir
<em>-Tags korrekt verwenden würden, hätten sie schon seit Ewigkeiten Sprachbetonung hinzugefügt und viel menschlicher geklungen. Sie wechseln die Sprache für die korrekte Aussprache, wann immer wir Dinge wie<i lang="fr">verwenden, die Betonung sollte viel einfacher sein.