Sie möchten etwas auf einer Seite ausblenden, also
.hide {
display: none;
}
Aber warten Sie! Indem Sie diese Klasse einem Element zuweisen, haben Sie diesen Inhalt sofort für Screenreader „unzugänglich“ gemacht. Das wissen Sie wahrscheinlich schon immer, aber dennoch schleicht sich der vergiftete Apfel gelegentlich in unseren Code.
Ich möchte nicht alle Einzelheiten wiederholen. Am besten lesen Sie „Now You See Me“ von Aaron Gustafson auf A List Apart, um ein Verständnis dafür zu bekommen, falls Sie es noch nicht haben.
Eine Möglichkeit, sich zu ermutigen, das Richtige zu tun, besteht darin, passendere Klassennamen zu erstellen. Ihre normale Ausblendklasse sollte den Inhalt vom Bildschirm verschieben, wodurch er für Screenreader weiterhin zugänglich bleibt.
.hide {
position: absolute !important;
top: -9999px !important;
left: -9999px !important;
}
Ich verwende hier !important, denn wenn Sie sich die Mühe gemacht haben, etwas eine „Ausblend“-Klasse zuzuweisen, meinen Sie es wahrscheinlich ernst und möchten nicht zu viel darüber nachdenken, ob die Spezifität ausreichend stark ist. Und wenn Sie wissen, dass Sie etwas mit display: none ausblenden müssen, sollte die Klasse Ihnen dabei helfen, dies zu verstehen.
.remember-this-will-NOT-be-read {
display: none !important;
}
Eine weitere Option für das zugängliche Ausblenden stammt aus einigen Nachforschungen von Snook und dem HTML5-Boilerplate
.visuallyhidden {
position: absolute;
overflow: hidden;
clip: rect(0 0 0 0);
height: 1px; width: 1px;
margin: -1px; padding: 0; border: 0;
}
Okay, Sie haben es verstanden. Kinderleicht, wenn Sie die Klassennamen vollständig kontrollieren und nur anwenden und entfernen. Aber mit JS-Bibliotheken, die ihr eigenes CSS anwenden, wird es etwas kniffliger. Zum Beispiel haben Sie in jQuery nach dem Aufruf von .slideUp() ein display: none im Inline-CSS, mit dem Sie umgehen müssen. Ja, Screenreader führen JavaScript aus, und ja, das ist immer noch ein Problem.
Auch hier hat Aaron Gustafson uns abgedeckt, der vorschlägt, den zugänglichen Klassennamen nach Abschluss des Slidings anzuwenden und dann display: none durch das Sliden in die andere Richtung zu entfernen.
var $button = $('#myButton'),
$text = $('#myText'),
visible = true;
$button.click(function() {
if (visible) {
$text.slideUp('fast',function() {
$text.addClass('hide')
.slideDown(0);
});
} else {
$text.slideUp(0,function() {
$text.removeClass('hide')
.slideDown('fast');
});
}
visible = !visible;
});
Hier ist eine Demo davon
Sehen Sie den Pen Hiding with jQuery von CSS-Tricks (@css-tricks) auf CodePen.
Jetzt haben wir die Werkzeuge, die wir brauchen, um die Verwendung von display: none einzustellen und zugänglichere „Ausblend“-Methoden zu verwenden.

FAQ-Seiten
Wenn Sie die Antwort ausblenden, bis die Frage angeklickt wird, blenden Sie sie mit einer zugänglichen Klasse aus. Achten Sie darauf, dass Sie nicht .hide() aufrufen und dann slideToggle(), das ist nicht gut genug!

Labels
Es ist verlockend, placeholder-Text als Ersatz für Labels zu verwenden (besonders jetzt, wo einige Browser die UX verbessert haben und den Text so lange anzeigen, bis man tatsächlich tippt), aber blenden Sie die labels nicht mit display: none aus oder entfernen Sie sie nicht. Ich hörte kürzlich eine herzzerreißende Geschichte über ein blindes Mädchen, das sich für ein College bewarb und das Formular hatte fehlende labels, sodass sie keine Ahnung hatte, was sie in welche Felder eintragen sollte. Wenn Sie also placeholder-Text als Ersatz für Labels verwenden möchten, verwenden Sie eine zugängliche Ausblendtechnik für die Labels.

Tabs
Nur weil ein Inhaltsbereich nicht der „aktuell aktive“ ist, bedeutet das nicht, dass er unzugänglich sein sollte. Blenden Sie ihn stattdessen mit einer zugänglichen Ausblendtechnik aus. Oder vielleicht brauchen Sie das gar nicht. Wenn alle Bereiche die gleiche Höhe haben, können Sie einfach umschalten, welche sichtbar ist, indem Sie den z-index anpassen.

@media queries
Voice Over unter OS X aktivieren und Safari verwenden ist ein Screenreader. Stellen Sie sich nun vor, dieses Safari-Fenster wäre auf eine sehr schmale Breite eingestellt und die Seite hätte einige @media-Abfragen zur Handhabung kleinerer Ansichtsfenster. Und sagen wir, diese @media-Abfrage blendet einige Dinge mit display: none aus, um den Platz besser optisch zu nutzen. Das kann für die Barrierefreiheit gut oder schlecht sein. Blenden Sie einen Haufen Kram aus, der für die Seite unwichtig ist? Oder blenden Sie nützliche Dinge aus, auf die eine Person, die einen Screenreader verwendet, zugreifen sollte, so wie sie es normalerweise tun würde.
Kein Experte hier
Dieser gesamte Beitrag basiert auf der Prämisse, dass display: none schlecht für die Barrierefreiheit ist. Er basiert nicht auf meinem tiefen und gründlichen Verständnis von Screenreadern und allgemeiner Barrierefreiheit. Wenn Sie mehr hinzuzufügen haben, Dinge zu korrigieren haben oder persönliche Erfahrungen teilen möchten, tun Sie es bitte.
Das wusste ich nicht, toller Artikel!
Es ist schade, dass Dinge wie `placeholder` nicht besser im Standard spezifiziert sind. Wir haben Glück, dass Gurus auf dieses Problem hinweisen und eine Lösung anbieten. Ich schätze, wir werden noch lange warten müssen, bis es ein eigenes CSS-Attribut dafür gibt, vielleicht `display: screenreader;` oder so etwas.
Schade, dass es keine Art von Media Query für Screenreader gibt, mit der man diese Werte einfach auf `block` umstellen kann.
Es gibt einige Randfallprobleme bei der Verwendung von
top: -9999px;
left: -9999px;
http://snook.ca/archives/html_and_css/hiding-content-for-accessibility
das H5BP hat eine Hilfsklasse, die genau das tut
https://github.com/h5bp/html5-boilerplate/blob/master/css/style.css#L260
Ah ja! Danke! Habe das in den Beitrag aufgenommen.
Aber `display:none;` ist eine so nützliche Eigenschaft!!!
Ja, das ist sie, ohne Zweifel! Und das ist der Zweck dieses Artikels! Die dunkle Seite des Missbrauchs zu diskutieren!
Warum sollte man Dinge ausblenden und trotzdem wollen, dass sie gelesen werden? Das klingt widersprüchlich.
Bezüglich der Tabs: Warum stellt man nicht sicher, dass die Tabs per Tastatur zugänglich sind (also nicht nur einen Klick-Handler hinzufügen, sondern fokusierbare Elemente für die Tabs verwenden/erstellen und Tastatur-Handler dafür hinzufügen und prüfen, dass die Tabulatorreihenfolge sinnvoll ist)? Fügen Sie einige WAI-ARIA-Rollen hinzu, und moderne Browser und Screenreader sollten sie genauso nutzen können wie sehende Benutzer.
Dies berührt einen wichtigeren Punkt: Gehen Sie nicht davon aus, dass „Screenreader-Benutzer“ und „normale Benutzer“ alle abdecken. Wenn Sie nur Hover verwenden, um Inhalte ein- oder auszublenden, machen Sie bereits etwas falsch (und wie Sie Inhalte ausblenden, ist weniger wichtig als sicherzustellen, dass Personen ohne Maus sie einblenden können).
Ich stimme zu.
Was ist der Sinn des Ausblendens von etwas, ohne es wirklich auszublenden? Ich habe noch nie einen Screenreader gesehen, und vielleicht gibt es dafür einen Grund, aber für mich ist das Problem eher, wie man etwas für Screenreader einblendet.
Überschriften für wichtige Inhaltsabschnitte, um eine vollständigere Überschriftenhierarchie für nicht-ARIA-bewusste ATs zu erstellen, zum Beispiel Gijs?
Skip-Links? (Obwohl sie nur auf großen Bildschirmen jemals vom Bildschirm verschwinden sollten.)
Um nur zwei zu nennen.
Und Vexal, wenn Sie noch nie einen Screenreader (oder, nehme ich an, irgendein anderes AT) gesehen haben, dann müssen Sie ihn unbedingt ausprobieren. Es gibt keine Entschuldigung dafür, dass irgendein Frontend-Entwickler nicht bereit ist, nur ein wenig Zeit mit NVDA, Orca, VoiceOver oder sogar einer Testversion von JAWS zu verbringen.
„Warum sollte man Dinge ausblenden und trotzdem wollen, dass sie gelesen werden? Das klingt widersprüchlich.“
Ich vermute, das ist eine faux naivete, um einen Punkt zu machen?
Menschen blenden Dinge in Benutzeroberflächen aus, damit sie als Ergebnis einer Benutzerinteraktion angezeigt werden können.
Ade: gute Beispiele. Der Grund für diese Beispiele ist jedoch, zusätzlichen Inhalt für Screenreader-Benutzer bereitzustellen, der für normale Benutzer ausgeblendet ist. Das ist bei den Beispielen im Blogbeitrag nicht der Fall.
Dave: Faux naivete — nein, ernsthafte Frage. Wenn Sie Dinge ausblenden, um sie nach Benutzerinteraktion wieder anzuzeigen, dann stellen Sie einfach sicher, dass Screenreader-Benutzer sie wie jeder andere anzeigen können. Die meisten haben JS-Unterstützung; wenn nicht, sollten sie (für den Zweck dieser spezifischen Elemente) wie jeder andere ohne JS behandelt werden, und der Inhalt hätte wahrscheinlich nicht ausgeblendet werden dürfen.
Ein weiterer Aspekt ist, dass Elemente, auf die
display: none;angewendet wird, vom Ladevorgang des DOM ausgeschlossen sind.Dies ist unpraktisch, wenn man ein Ladeereignis für ein nicht angezeigtes Inline-Bild bindet oder die Abmessungen eines Elements ermitteln möchte, das nicht angezeigt wird.
Спасибо, sehr interessante Übersicht, aber sie impliziert einen erheblichen Arbeitsaufwand für die Neufassung von Skripten und CSS.
Genau meine Gedanken!
Google-Übersetzung
Danke, sehr interessante Übersicht, aber sie impliziert einen erheblichen Arbeitsaufwand für die Neufassung von Skripten und CSS.
Wenn Sie Text auf einer FAQ-Seite ausblenden, mit der Absicht, ihn mit JS anzuzeigen, sollten Sie ihn auch mit JS ausblenden, sonst können Leute, die normale CSS-fähige Browser verwenden, aber mit deaktiviertem JS, den Text nie sehen, wodurch Sie eine unbrauchbare FAQ-Seite haben!
Ausgezeichneter Punkt. Entfernen Sie ihn (visuell), sobald der DOM geladen ist.
Um die Diskussion nicht abzugleiten, aber warum sind Einzeiler-Kommentare auf dieser Seite so hochrangig?
Eine schöne Option dafür ist, Dinge, die so ausgeblendet werden müssen, mit CSS auszublenden, aber unter einer Klasse, die von JS gesetzt wird, wie z.B.
CSS
.js .visuallyHide {
position: absolute;
overflow: hidden;
clip: rect(0 0 0 0);
height: 1px; width: 1px;
margin: -1px; padding: 0; border: 0;
}
JavaScript
$("html").addClass("js");
Danke, Chris, Artikel wie diese bringen das Web voran :-)
Prost!
Der HTML5-Placeholder war nicht dazu gedacht, die Labels zu ersetzen. Er soll eher ein Beispiel dafür geben, was im Feld erwartet wird. Zum Beispiel:
E-Mail-Adresse: [email protected]
Telefon: (000) 999 9999
Sehr guter Punkt!
Wenn Sie Less/Sass verwenden, müssen Sie nicht einmal eine Klasse wie .hide (ich verwende .hidden) im HTML hinzufügen, sondern können sie als Mixins verwenden. Das erspart Ihnen die Mühe (und das unangenehme Gefühl), `!important` verwenden zu müssen, und Sie benötigen keine Backend-Änderungen, wenn sich das Design später ändert.
Was Tabs und Tastaturzugänglichkeit angeht, das wird Screenreader-Benutzern nicht wirklich helfen. `display:none` ist eine schlechte Praxis, es ist schade, dass jQuery und andere so sehr darauf angewiesen sind.
Was lässt Sie glauben, dass Tabulatoren/Tastaturzugriff Screenreader-Benutzern nicht hilft?
Leider ist das eine traurige Wahrheit. Eine weitere traurige Tatsache ist der Mangel an Standard-Screenreadern. Zum Beispiel wird das Label auch mit `display: none` in Jaws (für Windows) vorgelesen. Aber es ist ein Punkt, auf den man achten muss. Danke.
Einfach, direkt und sehr erhellend! Danke!
Machen Sie nicht die möglicherweise falsche Annahme, dass Screenreader kein JavaScript „haben“.
Es besteht die Möglichkeit, dass der Screenreader den Bildschirm über dem Browser liest. Es ist sinnvoll, etwas mit `display:none` (mit JavaScript) auszublenden, wie in Ihrem FAQ-Beispiel.
Der Browser kann in die FAQ-Frage wechseln, sie lesen, dann Enter drücken, um sie zu öffnen und (mithilfe von #Ankern) zum Anfang der Antwort springen. Wenn sie die Antwort nicht sehen wollen, fahren sie mit der nächsten Frage in der Liste fort, anstatt *alle Fragen* und *alle Antworten* lesen zu müssen, wie es passieren würde, wenn die .hide-Antworten vom Bildschirm verschoben werden.
Hinweis: Wenn Sie möchten, setzen Sie das Element standardmäßig auf `display:none` und überschreiben Sie es sofort in einer Datei namens z. B. `noscript.css`. Verwenden Sie JavaScript, um die Datei `noscript.css` zu entfernen. Dies würde die Anzeige aller geöffneten Elemente vermeiden, bevor JS beim DOM-Ready greift.
Dies ist ein großartiges Beispiel dafür, wie knifflig Webentwicklung sein kann. Sie verbringen vielleicht Ihre Zeit damit, sicherzustellen, dass Ihre Inhalte für Screenreader zugänglich sind, nur um es für diese Leute mühsam zu machen, tatsächlich mit Ihrer Website zu interagieren. Ich glaube, es war Roger Johansson (456 Berea St.), der darauf hingewiesen hat, dass nur weil jemand assistierende Technologien nutzt, das nicht bedeutet, dass er nicht das gleiche Browsing-Erlebnis wie jeder andere haben möchte.
Persönlich verwende ich die Klassen `.no-js` / `.js` (mit Modernizr), um sicherzustellen, dass meine Inhalte für Personen ohne JS zugänglich sind, während ich gleichzeitig ein angenehmes Benutzererlebnis für Personen mit JS biete, und dann verwende ich `.visuallyhidden`-Klassen für jeglichen „Hilfstext“ für Screenreader.
In meinem Fall sind ausgeblendete Texte ein nützliches Werkzeug für die Barrierefreiheit. Hier in Brasilien schätzen Screenreader-Benutzer, wenn wir ihnen sagen, wo sie sich befinden und wie dieser Inhalt angezeigt wird.
Zum Beispiel:
Ich verwende normalerweise die `visuallyhidden`-Klasse von h5bp.com, um diese Art von Text auszublenden, da sie für „normale“ Benutzer offensichtlich und für Screenreader-Benutzer eine willkommene Information ist.
PS: Ich versuche immer noch herauszufinden, wie sich das auf SEO auswirkt.
Toller Beitrag. Ich fange gerade an, etwas über Barrierefreiheit zu lernen, daher fand ich das sehr informativ.
Anstatt Ihre „hidden“-Klasse zu setzen und das Gegenteil der jQuery-Animation auszuführen, die Ihnen ein „display:none“ eingebracht hat, wäre es nicht besser/einfacher/effizienter, entweder das `style`-Attribut einfach zu entfernen oder die `.show()`-Methode zu verwenden?
Das wollte ich auch fragen. Warum etwas animieren, das man nicht animiert sehen wird? Man könnte einfach `hide()` und `show()` verwenden. Ich schätze, wenn man etwas bräuchte, das diese nicht tun, könnte man jQuery erweitern und etwas wie: `.readable()` erstellen, das alles einstellt, was eingestellt werden muss, ohne etwas zu animieren, das sich nicht sichtbar ändert.
Außerdem könnte man vielleicht die Funktionsweise von `.animate()` am Anfang Ihres Dokuments aktualisieren, um einen `{readable: true}`-Parameter zu akzeptieren? Man könnte es so einrichten, dass es sogar von Dingen wie `slideDown` übergeben wird, was sofort die Barrierefreiheit abdeckt.
Danke, dass Sie die Beispiele beigefügt haben, sie waren äußerst hilfreich.
Ich dachte immer, dass die Verwendung von CSS mit `top: -9999px;` schlecht für SEO ist. Im Grunde genommen gehen Spinnen davon aus, dass Sie SEO-optimierte Inhalte auf Ihrer Seite verstecken, diese aber nicht als Teil der Website angezeigt werden sollen. Sie könnten zum Beispiel eine Reihe von Schlüsselwörtern in eine Div einfügen und sie außerhalb der Seite verstecken. Wenn die Crawler eine Div finden, die so positioniert ist, würde dies Ihr Ranking senken.
Ich habe das Gefühl, das Problem liegt eher bei den Screenreadern und weniger bei der Art und Weise, wie Dinge zum Coden entworfen wurden...
Das ist ein nicht sehr gut durchdachter Kommentar. Screenreader und die meisten anderen ATs sollen `display:none` (außer im Formularmodus) wegen seines primären Zwecks respektieren. Und darüber hinaus sind ATs, die auf die Barrierefreiheits-API angewiesen sind, den Launen dessen ausgeliefert, was in dieser API enthalten ist.
Danke für den Beitrag. Gute Informationen. Joe, das habe ich früher auch gedacht, aber entscheidend ist Ihre *Absicht* beim Ausblenden des Textes. Lesen Sie, was Google dazu auf Google Webmaster Central sagt.
Das Problem ist, wie definieren Google Crawler Ihre Absicht? Ich wünschte, der von Ihnen verlinkte Artikel würde das klarer machen. Dies ist, was er besagt: „Wenn Ihre Website den Eindruck erweckt, versteckten Text und Links mit betrügerischer Absicht zu enthalten, kann Ihre Website aus dem Google-Index entfernt werden und wird nicht auf den Suchergebnisseiten angezeigt. Bewerten Sie Ihre Website, um festzustellen, ob sie versteckten Text oder Links enthält. Gibt es Text oder Links, die ausschließlich für Suchmaschinen bestimmt sind und nicht für Besucher sichtbar sind?“
Und dann endet er mit: „Wenn Sie versteckten Text oder Links auf Ihrer Website finden, entfernen Sie diese oder machen Sie sie leicht sichtbar, wenn sie für die Besucher Ihrer Website relevant sind.“
Ich interpretiere das vielleicht falsch, aber dieser Artikel beschreibt eindeutig das Ausblenden von Inhalten, damit sie nicht leicht sichtbar sind. Er hat buchstäblich eine Klasse namens „visuallyhidden“.
Soweit ich weiß, analysiert Google nichts in einem Element mit `display: none;`. Es analysiert jedoch Inhalt mit `left: -999em;`. Wenn es das Erstere analysiert, wirkt sich das nicht auf Ihre SEO aus, aber wenn es das Letztere analysiert, wird es den Inhalt des Elements scannen und prüfen, ob Sie versuchen, deren System zu manipulieren.
Ich irre mich vielleicht, aber das ist mein aktuelles Verständnis.
Hier habe ich einen Blogartikel gefunden (etwas veraltet) über dieses Konzept
http://luigimontanez.com/2010/stop-using-text-indent-css-trick/
http://maileohye.com/html-text-indent-not-messing-up-your-rankings/
Offensichtlich haben sich die Dinge geändert und sie bieten keine Möglichkeiten, das Problem außer mit Media Queries zu umgehen. Ich vermeide es immer noch, Dinge auf diese Weise vom Bildschirm auszublenden.
Noch eine letzte Antwort von mir.
Es scheint, dass Sie weitgehend richtig liegen. Websites, die diese Technik nutzen, werden von Google nur markiert – nicht bestraft. Wenn sie weitere SEO-Spamming auf Ihrer Website entdecken, kann die versteckte Technik verwendet werden, um Ihre Website weiter zu bestrafen, aber die Technik allein reicht nicht aus, um die SEO Ihrer Website zu beschädigen.
Wie Sie erwähnt haben, spielt die Absicht eine Rolle. Aber ohne dass Google seine Algorithmen veröffentlicht, scheint es, dass wir nie wirklich wissen, was was tut, ohne Versuch und Irrtum.
Danke für diesen Beitrag. Ich fange gerade an, ein paar Websites zu erstellen, auf denen die Benutzer höchstwahrscheinlich Screenreader verwenden werden, und das hat sehr geholfen… Danke
Es ist immer gut, Entwickler daran zu erinnern, dass `display:none` Inhalte für Screenreader unzugänglich macht. Es wird oft, wenn auch unbeabsichtigt, falsch verwendet.
Dennoch gibt es viele Fälle, in denen `display:none` die richtige Vorgehensweise ist. Screenreader-Benutzer erwarten im Allgemeinen, dass die bereitgestellten Seiteninhalte die tatsächlich auf dem Bildschirm angezeigten Seiteninhalte darstellen. Beachten Sie auch, dass nicht alle Screenreader blind sind.
Zusätzliche Inhalte wie Überschriften oder explizite Formularbeschriftungen, die vom Bildschirm verschoben sind, wo diese dazu dienen, Screenreadern programmatisch zu helfen, den Benutzern ein besseres Verständnis der Seitenstruktur oder der Beziehungen zu vermitteln, sind völlig in Ordnung, wenn sie visuell überflüssig sind. In anderen Fällen, zum Beispiel bei nicht ausgewählten Tab-Panels, würde ich argumentieren, dass `display:none` erforderlich ist.
Richtig implementierte Tab-Schnittstellen sind Screenreader-Benutzern vertraut, die eine Erwartung an ihre Funktionalität haben. In dieser vertrauten Darstellung ist nur das aktuell ausgewählte Tab-Panel für den Screenreader oder jeden anderen Benutzer zugänglich. Dies ist Teil des Zustands der Tab-Schnittstelle: Wenn die zweite Tabulatorsteuerung aktiv ist, ist nur das zweite Tab-Panel verfügbar. Wenn alle Tab-Panel-Inhalte zugänglich bleiben, auch wenn sie außerhalb des Bildschirms positioniert sind, wird nicht nur ein Screenreader alles ankündigen, was einen sehenden Screenreader-Benutzer fragen lässt, welche Inhalte gelesen werden, da sie nicht auf dem Bildschirm sichtbar sind, sondern es wird für blinde Screenreader-Benutzer auch nicht klar sein, welche Tabulatorkontrolle gerade aktiv ist, da alle Tab-Panels verfügbar sind. Und wenn der außerhalb des Bildschirms positionierte Tab-Panel-Inhalt fokussierbare Elemente enthält, bleiben diese in der Tastatur-TAB-Reihenfolge erhalten und fügen zusätzliche, aber effektiv unsichtbare TAB-Stopps hinzu. Aber wenn sie den Fokus erhalten, wird dieser Fokus auf dem Bildschirm nicht sichtbar sein, was alle Tastaturbenutzer, ob visuell beeinträchtigt oder nicht, beeinträchtigt und möglicherweise verwirrt.
Hier ist ein guter Artikel, der sich mit diesem allgemeinen Problem befasst: http://simplyaccessible.com/article/better-for-accessibility/
Beste Grüße
Der Artikel von Derek Featherstone, den Sie, Jason, verlinkt haben, war der genaue Grund, warum ich kommentieren wollte. Schön zu sehen, dass Sie mir zuvorgekommen sind! :-) Er ist eine gute Einführung dazu, warum `display:none` manchmal angemessen und manchmal nicht ist.
Wenn Sie an die Verwendung von `z-index` denken, vergessen Sie nicht den maximalen Wert von z-index!
Frage: Warum möchten Sie ausgeblendeten Inhalt überhaupt für einen Screenreader verfügbar machen? Wenn Sie nach einer Benutzeraktion Inhalte „ausblenden“, warum sollte er dann für den Screenreader verfügbar sein, da ihn ein normaler Benutzer nicht sehen kann? Wir haben den Inhalt redundant gemacht, warum wird er dann noch benötigt? Es sieht für mich nach einer überdachten Lösung für ein nicht existierendes Problem aus.
Okay, das ist ziemlich wichtig!
Ich verwende es mit mehrstufigen Menüs, reinem CSS mit CSS3-Übergängen.
Die WAI-ARIA-Spezifikation definiert einen hidden state, der verwendet werden sollte und einige **sehr** wichtige Punkte zur Sichtbarkeit in der Barrierefreiheit enthält.
Chris —
Ausgezeichnete Punkte und äußerst relevant. So oft, wenn unsere Kunden es nicht verlangen oder eine Zielgruppe es benötigt, um eine Website zu nutzen, vergessen wir diese wichtigen Dinge.
Für diejenigen, die nach einem guten Screen-Reader-Emulator suchen, hat Firefox ein großartiges Add-on namens „Fangs“ (basierend auf JAWS) hier: http://bit.ly/io5aks . Wir verwenden es, um zu sehen, was der Reader ausspuckt, und es war wirklich hilfreich.
Danke für den Beitrag!
Ich lese ständig Kommentare darüber, dass man für Leute entwirft, die JavaScript deaktivieren. Deaktiviert wirklich jemand JavaScript auf einem modernen Computer mit einem modernen Browser?
Abgesehen von den vielen Nutzern von NoScript kann ich nur für mich selbst sprechen. Wenn ich Firefox benutze, ja, JS bleibt deaktiviert, außer für eine Whitelist. Ansonsten benutze ich unter Linux Dillo. In beiden Fällen ist der Hauptgrund Usability/Barrierefreiheit.
Sehr informativer Beitrag. Ich lerne gerade etwas über Barrierefreiheit und wie man Websites entsprechend gestaltet und codiert. Danke für den Beitrag!
Moment, können Sie nicht einfach
???
Für ATs verhält sich das aufgrund ihrer Nutzung einer Accessibility-Schicht genauso wie display:none. Wäre also in Ordnung zu verwenden, wenn display:none ebenfalls angemessen ist, wenn Sie den Effekt von vis:hidden wünschen, aber wenn etwas zugänglich bleiben muss, wird es das nicht.
Danke für die Info, werde es testen und damit herumspielen.
Es ist jedoch traurig, wie die Richtlinien für Behinderte im Laufe der Jahre beiseite geschoben wurden und es ist ernüchternd, die Folgen davon zu sehen.
Danke für den Artikel.
Das ergibt Sinn, während wir unser neues Rekrutierungssystem entwickelten, haben wir versucht, Bildschirmsprachausgaben zu berücksichtigen. Ich habe noch nie so viele Titel-Tags in meinem Leben verwendet!
Gute Lektüre, ich habe mir darüber nie viele Gedanken gemacht. Ich werde es von nun an für zusätzliche Barrierefreiheit nutzen.
Viele Grüße,
Chris
Bei der Arbeit in einer Agentur ist den meisten unserer Kunden Barrierefreiheit egal, solange es auf Tablets und Handys funktioniert, und oft nicht einmal das. Alles basiert darauf, wie wenig sie bezahlen können und trotzdem bekommen, was sie von uns wollen. So etwas würde nie bezahlt werden, aber es ist eine gute Idee. Trotzdem sehe ich keinen Sinn darin, Screenreadern etwas anzuzeigen, das man verstecken möchte.
Tun Sie das nicht? Lesen Sie die anderen Kommentare: Der Sinn der Erstellung von Inhalten für ATs (nicht nur für Screenreader) wurde behandelt.
Und wenn Kunden nicht bereit wären, für einen respektablen grundlegenden Standard an Barrierefreiheit zu zahlen, hätte ich kein Geschäft.
Was für ein Mist ist dieser Trick, aber ich muss sagen, The Filament Group hat einen großartigen Artikel über versteckte Elemente geschrieben, der auch Diskussionen über die Verwendung von ARIA-Attributen enthielt. Es gibt auch einen guten Verweis auf einige der Vor- und Nachteile der 4 Prinzipien, die von den WCAG dargelegt wurden und erfüllt sein müssen, um sicherzustellen, dass Inhalte zugänglich sind.
http://filamentgroup.com/lab/expand_and_collapse_content_accessibly_with_progressive_enhancement_jquery
Ich benutze diese Technik erst seit ein paar Wochen... es hat mich endlich getroffen!
Ich habe Thumbnails von Beiträgen auf der Startseite unseres Blogs und habe bisher nur den Daumen angezeigt... aber jetzt habe ich es so eingestellt, dass der Daumen, der Titel und die Zusammenfassung angezeigt werden und diese aus der Seite heraus versteckt sind, so dass Sie diese Inhalte im Code haben.
Sagen Sie damit, dass wenn Inhalt bei anfänglichem Laden der Seite mit display:none versteckt wird, er niemals von Screenreadern gelesen werden kann, egal welche Änderungen am DOM nach dem Laden der Seite vorgenommen werden?
Es geht nicht wirklich um den DOM, da wenige ATs (und keine Screenreader, soweit ich weiß) direkt darauf zugreifen: Es geht um eine Accessibility-Schicht eines Browsers und disp:none soll Elemente aus der Schicht heraushalten.
Und ich habe vergessen zu erwähnen, dass das Element in die Schicht aufgenommen werden sollte, wenn disp:none entfernt wird, obwohl es oft vorkommt, dass die Änderung von der AT nicht erkannt wird, es sei denn, ARIA wird verwendet (und diese ist ARIA-fähig).
Gute Informationen Chris. Ich werde mir das notieren, wenn ich Gefahr laufe, hochwertige Inhalte zu verlieren, aber ich würde argumentieren, dass wir, anstatt am Code herumzufummeln und unseren Arbeitsaufwand zu erhöhen, einfach Horden von großartigen Inhalten produzieren (genug, damit ein paar display:none nichts trüben) und Google die guten Seiten von den schlechten sortieren lassen.
Was ist mit meinem Portfolio-Tutorial? :)
Vielen Dank für den großartigen Artikel Chris. In meiner aktuellen Position muss ich sicherstellen, dass unsere Website barrierefrei und 508-konform ist. Wir verwenden kein display:none;, sondern die von Ihnen beschriebene Technik, um Inhalte vom Bildschirm aus zu verstecken.
Zusätzlich zur Barrierefreiheit muss die andere Hälfte der Gleichung sicherstellen, dass die Website nutzbar ist. Das bedeutet, der Grund, warum Sie Inhalte verstecken könnten, ist, dass Sie einen Link hinzufügen und verstecken möchten, der die Navigation überspringt und zum Hauptinhalt der Seite verlinkt.
Warum? Stellen Sie sich vor, Sie verwenden einen Screenreader und müssen durch einen Header mit einigen Links, dann durch die Navigation mit vielen Links und vielleicht einer kleinen Auswahl an Social-Media-Links tabben, das ist eine Menge Inhalt, den der Benutzer vielleicht nicht benötigt. Aber wenn er auf der Seite landet und der erste Link, den er anklicken kann, "Link zum Hauptinhalt überspringen" heißt, ermöglicht dies dem Benutzer, "nutzlose" Inhalte zu überspringen und zu dem zu gelangen, was er möchte, dem Hauptinhalt der Seite.
Diejenigen, die keine AT verwenden, nehmen es als selbstverständlich hin, dass wir einfach schauen und klicken können, um zu bekommen, was wir wollen.
Und ja, Fangs für Firefox ist eine großartige Möglichkeit, zu simulieren, was ein Screenreader ausgibt, und wenn Sie Lust haben, schauen Sie sich FireEyes für Firefox an, es ist kostenlos (kein Sprecher!).
woh! sehr wichtige Sache. Ich werde das im Hinterkopf behalten. Danke fürs Teilen :)
Negative Offsets erzeugen immer noch eine riesige Box, die außerhalb des Bildschirms gerendert werden muss.
Eine schnellere Methode ist
.hide-text {
text-indent: 100%;
white-space: nowrap;
overflow: hidden;
}
Via http://www.zeldman.com/2012/03/01/replacing-the-9999px-hack-new-image-replacement/
Eine Ergänzung zur Namensgebung: „.visuallyhidden“ ist mir zu lang. Deshalb habe ich in meinen Projekten „.hidden“ in „.away“ umbenannt (weil es physisch nicht mehr da ist) und „.visuallyhidden“ in „.hidden“ (weil es... nun ja... außerhalb des Viewports versteckt ist).
Ich habe display:none so oft benutzt. Ich frage mich, ob es eine Möglichkeit gibt, dafür serverseitige Skripte (PHP) zu verwenden.
Meine Sorge ist nicht nur, das Element zu verstecken, sondern es auch nicht zu laden, wenn es versteckt ist. Zum Beispiel verstecke ich auf einem Stylesheet für mobile Geräte bestimmte Elemente, die in der Desktop-Ansicht angezeigt werden; und gleichzeitig möchte ich nicht, dass sie in der mobilen Version geladen werden, da dies die Seite möglicherweise ein wenig verlangsamt. Irgendwelche Ideen?
Screenreader sind ziemlich auf dem Niveau von IE6.
Das ist einer der plumpsten, schlecht informiertesten und völlig falschen Kommentare hier.
Es ist ziemlich informiert, aber nicht das, was Sie hören wollen. Ich bin ziemlich sicher, dass die Verbreitung von SR so gering ist, dass es sich nicht lohnt, sich so viel Mühe zu geben, um ein paar wenige zufriedenzustellen. Wenn Sie davon abweichen, würde ich gerne einige reale Statistiken sehen, die das Gegenteil beweisen.
Wenn Sie irgendeine AT verwendet haben, wissen Sie, dass die meisten von ihnen, insbesondere Screenreader, ausgefeilter sind als jeder Browser, am allerwenigsten IE6.
Es erfordert sehr wenig Aufwand, AT-freundliche Websites zu erstellen. Nur etwas Wissen, Empathie und Nachdenken. Dinge, die alle Entwickler besitzen sollten. Es gibt nicht viel, was nicht zu wissen erklärt, wie dieses spezielle Thema, über das seit Jahren so oft geschrieben wurde.
Wenn die Leute Benutzerdaten wollen, können sie diese von jeder nationalen Körperschaft erhalten, die behinderte Menschen vertritt. Aber zu versuchen, behinderte Menschen wie mich auf bloße Statistiken zu reduzieren, ist unproduktiv, rücksichtslos und ziemlich beleidigend. Und solche Daten sind weitgehend irrelevant, weil wir alle Websites erstellen können und sollten, die für jeden nutzbar sind, der das Web nutzen kann. Wenn jemand Website A nutzen kann, sollte er auch die ähnliche Website B nutzen können, weil sie auf dem gleichen Standard aufgebaut werden kann. Ob dies zusätzliche 0,1%, 1% oder 10% unterbringt, ist im Kontext der Inklusion orthogonal und darf niemals als Entschuldigung dafür verwendet werden, keinen angemessenen Standard an Barrierefreiheit zu gewährleisten. Oder anders gesagt, seine Arbeit nicht richtig zu machen. Entwickler sollten sich nicht beschweren, sehr einfache Dinge zu tun, die für einige von uns einen entscheidenden Unterschied machen.
Großartige Punkte und Tutorial. Eine weitere Sache, über die die Leute nicht nachdenken, ist, dass display:none und visibility:hidden Ihren Code bei Malware-Scans zusammen mit gzip, eval und base64 decode-Anweisungen aufgeführt werden. Gut zu hören, dass es eine weitere (oder bessere) Möglichkeit gibt, den versteckten Code-Kram zu machen.
Danke für den Blogbeitrag!
Was ist der unterschiedliche Effekt der Verwendung von beiden in Bezug auf die Bestrafung wegen „Geisterinhalten“?
Es ist ein sehr informativer, auf den Punkt gebrachter Artikel mit einigen guten Ressourcen. Vielen Dank für das Teilen.
Beachten Sie, dass
display:nonein Bezug auf a11y nicht immer schlecht ist.Zum Beispiel kann es mit komplexen Menüs im Dropdown- oder Fly-out-Stil verwendet werden.
Das liegt daran, dass die Verwendung von
display:none(im Gegensatz zuposition:absolutemit einem negativen Offset) Elemente aus dem Tabbing-Fluss entfernt, was den Benutzern hilft, durch sehr lange Menüs zu navigieren... und die Seite.display:none; ist immer noch nützlich für Elemente, die nicht unbedingt lesbar sind...
Was ist falsch mit visibility:hidden?