Tipps, um sicherzustellen, dass versteckte Inhalte zugänglich sind (oder nicht!)
Wie wir bereits besprochen haben, können Screenreader-Benutzer nach bestimmten Inhalten wie Überschriften, Orientierungspunkten, Links und mehr navigieren. Auf diese Weise können Leute, die sich auf diese Technologie verlassen, ziemlich schnell einen Inhalt finden.
Ein Problem kann jedoch auftreten, wenn Links, Beschriftungen, Schaltflächen usw. ihren Zweck nicht ausreichend vermitteln; Ihr Daseinszweck sollte in ihrem zugänglichen Namen gut genug erklärt werden. Wenn der Name nicht eindeutig ist oder möglicherweise der gleiche Elementtyp mit genau dem gleichen Namen wiederholt wird, kann dies zu Verwirrung oder Frustration für den Benutzer führen.
Ein weiteres Problem kann auftreten, wenn sehende Nur-Tastatur-Benutzer durch Inhalte navigieren und nur die Fokusanzeige verschwindet! Dies liegt oft an Inhalten, die "außerhalb des Bildschirms" liegen, aber über die Tastatur erreichbar sind. Auch dies kann wiederum zu Verwirrung führen.
Sehen wir uns einige Beispiele an und erläutern, wie diese potenziellen Probleme behoben werden können.
Wiederholter Inhalt
Wiederholter Inhalt kann als Inhalt betrachtet werden, der mehrmals auf einer einzelnen Seite oder Ansicht erscheint. Dieser Inhalt liegt normalerweise als Callout-Links oder Bilder vor, die in Listen- oder Tabellenzellen vorhanden sind.
Wie bereits erwähnt, besteht hier das Problem, wenn ein Screenreader-Benutzer nur durch eine bestimmte Art von Inhalt navigiert: Links, Formularsteuerelemente, Überschriften usw. Wenn der Benutzer den wiederholten Inhalt ohne weiteren Kontext hört, könnten wir darauf stoßen einige Usability-Probleme.
Nehmen wir zum Beispiel den klassischen „Weiterlesen“-Link. Diese Links erscheinen oft auf Blog- oder Nachrichtenlistenseiten und ermutigen den Benutzer, darauf zu klicken, um weitere Details anzuzeigen.
Ein Beispiellink könnte wie folgt gekennzeichnet sein:
<a href="article/how-to-make-pasta-sauce.html"> Read more </a>
Wenn jemand auf einer Blogbeitragsseite mit Links zu Beiträgen nur über Links navigiert, hört er etwas in der Art von:
"Weiterlesen, Link – Weiterlesen, Link – Weiterlesen, Link"
Da jeder Link genau gleich klingt, weil er dieselbe Textbezeichnung teilt, gibt es keine Möglichkeit festzustellen, wohin ein bestimmter Link führen könnte.
Kontext bereitstellen, ohne das Design zu stören
Es gibt ein paar Methoden, um Links wie diesen mehr Kontext zu geben, ohne das beabsichtigte Design zu stören.
Natürlich wäre es ideal, zusätzlichen sichtbaren Text hinzuzufügen, da dies Menschen mit kognitiven Beeinträchtigungen mit klarer Kennzeichnung oder Menschen mit Sehbehinderung zugute käme, die auf Zoom- Software angewiesen sind. Aber wenn Sie die Dinge nicht in diese Richtung bewegen können, schauen wir uns ein paar Alternativen an.
Visuell verborgener Text
Die Verwendung der CSS .visuallyhidden ist eine Möglichkeit, Textinhalte visuell vor sehenden Benutzern zu verbergen, der Inhalt bleibt jedoch für Benutzer von Screenreadern verfügbar. Dies wird manchmal auch als sr-only, Zugänglichkeit oder andere verwandte Klassennamen bezeichnet.
<a href="article/how-to-make-pasta-sauce.html"> Read more <span class="visuallyhidden">about How to Make Pasta Sauce</span> </a>
Um auf das Link-Beispiel „Weiterlesen“ zurückzukommen, sehen wir hier, dass der HTML-Code genauso aussieht wie zuvor, jedoch mit dem Hinzufügen eines neuen span Elements. Diese span verfügt über die Klasse .visuallyhidden , was dazu führt, dass der darin enthaltene Textinhalt vor sehenden Benutzern verborgen wird, wodurch das ursprüngliche Design erhalten bleibt, aber auch den zusätzlichen Kontext bietet, der für Benutzer von Bildschirmleseprogrammen benötigt wird.
Wenn nun jemand, der einen Screenreader verwendet, auf diesen Link stößt, würde er hören,
"Lesen Sie mehr über die Zubereitung von Pastasauce, Link"
Der Arie-Label-Ansatz
Die Verwendung des Attributs aria-label ist eine Alternative zur CSS-Methode .visuallyhidden . Dieser Ansatz legt den beabsichtigten verborgenen Inhalt direkt als zugänglichen Namen für das Element fest.
Wenn wir uns das vorherige Link-Beispiel noch einmal ansehen, ist dieser Code im Vergleich zum .visuallyhidden Beispiel etwas sauberer und einfacher zu lesen.
<a href="article/how-to-make-pasta-sauce.html" aria-label="Read more about How to Make Pasta Sauce" > Read more </a> Eine Sache, die Ihnen vielleicht aufgefallen ist, ist der wiederholte Inhalt von „Weiterlesen“ im Attribut „ aria-label “. Dies ist erforderlich, damit ein Screenreader den Text als Ergebnis der Verwendung des Attributs aria-label vollständig ankündigen kann. Der Attributwert hat Vorrang vor allem anderen, das innerhalb des Link-Elements platziert wird. Mit anderen Worten, wenn Sie das Attribut aria-label anwenden, wird jeglicher Text innerhalb des Elements von Screenreadern vollständig ignoriert .
WCAG-Erfolgskriterien
Dies kommt auf 2.4.4 Link Purpose zurück, wo es heißt:
„Der Zweck jedes Links kann aus dem Linktext allein oder aus dem Linktext zusammen mit seinem programmgesteuert festgelegten Linkkontext bestimmt werden, es sei denn, der Zweck des Links wäre für Benutzer im Allgemeinen mehrdeutig.“
Noch ein paar Beispiele…
Sehen wir uns ein paar häufigere Situationen an, in denen Off-Screen-Text hilfreich wäre.
Eine Tabelle mit Schaltflächen
Stellen Sie sich ein table vor, und jedes Element kann mithilfe einer button aus der table entfernt werden. Diese Steuerelemente können wie folgt gekennzeichnet sein:
<button>Remove</button>
Da wir wissen, dass Screenreader-Benutzer nach bestimmten Inhalten navigieren können, ist es nicht sehr hilfreich, „Entfernen“ mehrmals zu hören (vorausgesetzt, es gibt mehrere Elemente in der table ). Was genau entfernen?
Lassen Sie uns ein aria-label Attribut verwenden, um jedem der Steuerelemente Kontext zu geben:
<button aria-label="Remove {item title}"> Remove </button>
Mit dem aria-label , das jeder Instanz des button -Steuerelements hinzugefügt wird, und dem {item title} , das zu seiner Ausgabe hinzugefügt wird, können wir zusätzlichen Kontext für jedes Steuerelement bereitstellen.
Sternebewertungen
Es ist üblich, eine visuelle Darstellung einer Bewertung auf einer Produktseite zu sehen. Oft wird dies durch eine Reihe von Symbolen dargestellt, typischerweise Sternsymbole, die einen Bereich von 0 bis 5 darstellen. Die visuelle Bedeutung des Sternbilds ist normalerweise für sehende Benutzer verständlich genug, aber wie stellen wir jemandem, der einen Bildschirmleser verwendet, eine genaue Textalternative zur Verfügung?
Hier ist ein typisches Beispiel für ein Sternbewertungs-Markup, das Symbole ausgibt, wobei ein i -Element verwendet wird, um eine Reihe von Symbolen auszugeben:
<i class="icon icon-star star-4"></i>
Nach dem Klassennamen star-4 zu raten, könnte dies eine visuelle Bewertung von "4 von 5" ausgeben, aber wenn jemand einen Bildschirmleser verwendet, ist nichts verfügbar, um dieselben Informationen zu übermitteln.
Dazu können wir etwas .visuallyhidden Text hinzufügen, um eine Textalternative bereitzustellen (und auch das i -Element gegen eine span austauschen, da i eine semantische Bedeutung hat ):
<span class="icon icon-star star-4"> <span class="visuallyhidden">4 out of 5 stars</span> </span>
Wenn nun ein Screenreader auf diesen Inhalt trifft, wird die .visuallyhidden -Textalternative angekündigt, die dem Benutzer Inhalt bereitstellt, damit er die aktuelle Produktbewertung versteht:
"4 von 5 Sternen"
Offscreen-Navigation
Heutzutage ist es ein gängiges Muster für Webdesign, die primäre Navigation in einer „Offscreen-Schublade“ zu verstecken, die durch eine Hamburger-Menüsteuerung umgeschaltet wird. Dieses Muster wird normalerweise für einen kleinen Bildschirm oder mobilen Kontext eingesetzt, obwohl es auch auf Desktop-Websites zu sehen ist.
Ein Zugänglichkeitsproblem bei diesem Muster tritt auf, wenn der Schubladeninhaltscontainer nur über die CSS- position außerhalb des Bildschirms positioniert wird. Das Menü ist optisch versteckt, aber wenn jemand mit einer Tastatur durch den Seiteninhalt navigiert, sind diese visuell "versteckten" Links immer noch fokussierbar, wodurch im Wesentlichen versteckte Tabstopps entstehen. Dies ist ein Problem, da der Nur-Tastatur-Benutzer nicht in der Lage ist, die aktuelle Fokusposition auf dem Bildschirm zu bestimmen und verwirrt oder frustriert werden kann.
Vollständiges Ausblenden von Inhalten
Um Inhalte vollständig vor sehenden Benutzern, Nur-Tastatur-Benutzern und Bildschirmleser-Benutzern zu verbergen, gibt es einige Methoden, die wir anwenden können:
- Das Anwenden von CSS
display: noneauf den Drawer-Container führt zu dem gewünschten Effekt, den Inhalt vor Tastaturbenutzern zu verbergen. Ein Hinweis zu dieser Lösung ist, dass diedisplaynicht animiert werden kann, ohne dass ein zusätzlicher JavaScript-Code den Eigenschaftswert zu einem bestimmten Zeitpunkt festlegt. - Das Anwenden der CSS-Eigenschaft
visibility: hiddenführt im Wesentlichen zu einem ähnlichen Ergebnis wie die Verwendung vondisplay: none. Der Unterschied besteht darin, dass die Eigenschaft „Sichtbarkeit“ einfacher zu animieren ist, insbesondere wenn sie zusammen mit der CSS-Eigenschaft „Opacity“ verwendet wird. - Schließlich würde die Anwendung des
hiddenHTML-Attributs auf den Schubladencontainer dasselbe Ergebnis wie die CSS-Eigenschaftdisplay: noneerzeugen; vollständiges Verbergen des Inhalts vor visuellen und nicht-visuellen Benutzern.
Wenn es visuell verborgen ist, verstecken Sie sich auch vor Benutzern von Tastaturen und Hilfstechnologien
Dies dient dazu, ein gleichwertiges Benutzererlebnis zu gewährleisten. Wenn etwas visuell nicht sichtbar ist, sollte dieser Inhalt auch vor dem Zugriff über Tastatur und Screenreader verborgen werden.
WCAG-Erfolgskriterien
Dies kommt auf 2.4.3 zurück: Focus Order , wo es heißt:
"Wenn eine Webseite sequentiell navigiert werden kann und die Navigationssequenzen die Bedeutung oder Bedienung beeinflussen, erhalten fokussierbare Komponenten den Fokus in einer Reihenfolge, die Bedeutung und Bedienbarkeit bewahrt."
Warnung des Benutzers, wenn ein Link ein Fenster öffnet
Wenn wir das Muster target="_blank" rel="noopener" in einem Link verwenden oder sehen, liegt es in unserer Verantwortung als Webautoren, einen Hinweis einzufügen, dass der Link ein neues Fenster öffnet.
Wieso den? Ohne diesen Kontext könnten die Leute glauben, dass sie einem internen Website-Link im selben Browserfenster folgen. Das Öffnen eines neuen Tabs im Namen des Benutzers würde für sehende Benutzer, die nur Tastatur verwenden, und Benutzer von Bildschirmleseprogrammen zusätzliche Arbeit verursachen. Wenn sie nicht darauf vorbereitet sind, die aktuelle Website zu verlassen, müssen sie sich anstrengen, um zum vorherigen Tab oder Fenster zurückzukehren.
Geben Sie dem Benutzer Macht – lassen Sie ihn entscheiden, wie er fortfahren möchte
Die Idee ist, dem Benutzer Macht zu geben; Informieren Sie den Benutzer darüber, was passieren könnte, damit er entscheiden kann, wie und wann er fortfahren möchte.
Wie Sie dies erreichen
Eine empfohlene Lösung, um Personen darüber zu informieren, dass ein Link ein neues Fenster öffnet, beinhaltet:
- Hinzufügen eines neuen Containerelements zum DOM, das die erforderlichen Varianten der Warnmeldung enthält
- Jedes Variantenelement hat eine eindeutige
IDREF, auf die an anderer Stelle in der App verwiesen werden kann - Wenn ein Link die Attribute
target="_blank" rel="noopener", fügen Sie das Attributaria-describedbyhinzu und setzen Sie seinen Wert auf die entsprechendeidder anzukündigenden Nachricht
Sehen wir uns ein aktuelles Beispiel an, um besser zu verstehen, worum es geht.
Beispielmuster
Fügen Sie zuerst den HTML-Container (auch bekannt als Screenreader-Sprite-Sheet) hinzu, der die Variationen der Warnmeldung enthält:
<div hidden> <span id="new-window-0">Opens in a new window</span> <span id="new-window-1">Opens an external site</span> <span id="new-window-2">Opens an external site in a new window</span> </div> Möglicherweise stellen Sie fest, dass dieser div Container das hidden Attribut enthält. Dadurch soll sichergestellt werden, dass dieser Textabschnitt nicht sichtbar ist und Screenreader den Text nicht finden und ohne Kontext lesen können.
Da uns diese Warnmeldungen nun zur Verfügung stehen, können wir bei Bedarf einfach darauf verweisen.
Als nächstes, einschließlich der Warnmeldung in einem Link.
<a href="https://mysite.com" target="_blank" rel="noopener" aria-describedby="new-window-0" > My site </a>
Mit dem Attribut aria-describedby , das auf das erste Warnmeldungselement zeigt, lautet der Link:
"Meine Website — Wird in einem neuen Fenster geöffnet"
(Hinweis: Der lange Bindestrich hier soll nur darauf hinweisen, dass aria-describedby eine Pause zwischen dem Linktext und dem Inhalt der Warnmeldung erzeugt.)
Wenn dies eingerichtet ist, wird der Linktext laut vorgelesen, Pause, dann die Warnmeldung, dass der Link ein neues Fenster öffnet.
Was ist mit einem visuellen Angebot?
Ich habe vorhin nur sehende Tastaturbenutzer erwähnt. Wie teilen wir einem sehenden Benutzer visuell mit, dass sich ein neues Fenster öffnet?
Ein Ansatz ist die Verwendung eines Symbols neben dem Linktext. Mit einem Icon bekommt ein sehender Benutzer den Hinweis, dass etwas anderes passieren kann, wenn ich diesen Link aktiviere.
Ich glaube nicht, dass ein Symbol in allen Kontexten erforderlich ist, wie z. B. eine Auflistung von Social-Media-Symbollinks oder vielleicht Copyright-Links in einem Fußzeilenabschnitt. Wenn es jedoch um Links im Fließtext geht, ist es eine gute Idee, eine Art visuellen Indikator hinzuzufügen, so wie Leute, die einen Bildschirmleser verwenden, einen hörbaren Hinweis erhalten.
Ein Beispiel für die visuelle Anzeige
Angenommen, Sie haben ein passendes Symbol. Normalerweise ein kastenförmig aussehendes Symbol mit einem Pfeil, der nach oben zeigt, ähnlich dem Symbol für den externen Link von Shopify Polaris .
Jetzt, da wir unser Symbol haben, fügen wir es in den Link ein:
<a href="https://mysite.com" target="_blank" rel="noopener" aria-describedby="new-window-0" > My site <svg role="presentation" aria-hidden="true" focusable="false" ...> <path> <!-- ... --> </path> </svg> </a>
Mit dem Attribut aria-describedby auf dem Link zusammen mit dem Symbol „Neues Fenster“ neben dem Text können alle Benutzer eine fundierte Entscheidung treffen, ob und wann sie den Link aktivieren, entweder jetzt oder später, wenn sie bereit sind.
WCAG-Erfolgskriterien
Dies kommt auf 3.2.2 On Input zurück, wo es heißt:
"Das Ändern der Einstellung einer Komponente der Benutzeroberfläche führt nicht automatisch zu einer Änderung des Kontexts, es sei denn, der Benutzer wurde vor der Verwendung der Komponente auf das Verhalten hingewiesen."