Scott O’Hara veröffentlichte kürzlich „Inclusively Hidden“, einen schönen Überblick über die verschiedenen Arten, Dinge im Web zu verbergen. Nichts ist im Web jemals eindeutig! Was dies kompliziert, ist, dass sich *verbergen* die Frage stellt: *Für wen verbergen?* Unterschiedliche Antworten darauf haben unterschiedliche Lösungen
- Für alle verborgen?
display: none;odervisibility: hidden;oder dashidden-Attribut. (Aber Vorsicht bei diesemhidden-Attribut, sagt Monica Dinculescu.) - Visuell verborgen, aber für assistierende Technik vorhanden? Eine
.screen-reader-only-Klasse mit einer Reihe von Eigenschaften, um die Aufgabe korrekt zu erledigen. - Für assistierende Technik verborgen, aber nicht visuell? Das
aria-hidden="true"-Attribut/Wert.
Es lohnt sich, all das zu verstehen, denn es ist ein perfektes Beispiel dafür, warum HTML und CSS keine einfache Zusatzqualifikation für die Front-End-Webentwicklung sind. Dies sind kritische Dinge, die nicht so korrekt gemacht werden, wie sie sollten.
Wenn Sie Videos mögen, habe ich eines namens „Hiding Things with CSS“ gemacht, das sich mit vielen dieser Punkte befasst.
Die von Scott verwendete Klasse für visuell verborgene Elemente ist
/* Hiding class, making content visible only to screen readers but not visually */
/* "sr" meaning "screen-reader" */
.sr-only:not(:focus):not(:active) {
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;
}
Während ich dies schreibe, komme ich gerade von der Smashing Conf in San Francisco zurück. Sara Soueidan hielt einen wunderbaren Vortrag, der einige „Dinge verbergen“-Situationen abdeckte, die noch weniger intuitiv sind, als wir es gewohnt sind zu sehen.
Eine Sache, die sie behandelt hat, war das inert-Attribut und wie es verwendet werden kann, um interaktive Elemente vom Tastatur-Tabben zu überspringen. Es kann sogar auf ein übergeordnetes Element angewendet werden, wodurch alles darin nullifiziert wird. Ich habe das verstanden, aber nicht ganz, warum es nützlich ist, da es scheint, als ob man auch display: none; verwenden könnte, wenn ein Element verborgen ist *und* die darin enthaltenen Elemente nicht im Fokus sein sollen. Aber ich bin sicher, es liegt an meinem mangelnden Verständnis, daher freue ich mich darauf, dass Saras Video herauskommt, damit ich es noch einmal ansehen kann. Es hatte mit der Aufrechterhaltung einer nicht-awkwarden Tab-Reihenfolge zu tun.
Eine weitere Sache, die Sara angesprochen hat, ist, dass einige Personen, die assistierende Technologie nutzen, auch dazu neigen, Touchscreens mit Haptik zu erkunden und mit den Fingern über die Seite zu fahren, um nach interaktiven Elementen zu suchen. Wenn Sie zum Beispiel eine native Checkbox durch eine gestylte Checkbox ersetzen, ist es möglich, dies auf eine Weise zu tun, die *meistens* zugänglich ist, indem man eine echte Checkbox verwendet, die man verbirgt und durch eine Grafik ersetzt. Aber Sara hat gezeigt, wie man die Checkbox über dem Ersatz vergrößern und visuell mit opacity: 0; verbergen kann – das stellt sicher, dass jemand das Element auch per Berührung finden kann. Das scheint nicht die Standardmethode für diese Art von Dingen zu sein, so wie es gelehrt oder implementiert wird. Daher ist es großartig zu sehen, wie Sara darauf hinweist. Noch ein Beispiel dafür, dass HTML und CSS nuancierte und knifflige Sprachen sind.
„Inert“ wird besonders nützlich sein, um den Tastaturfokus von der Seite zu nehmen, die von einem Modal überdeckt wird. Wir wollen immer noch, dass die Seite hinter dem Modal angezeigt wird, aber nicht im Fokus. Die Möglichkeit, „inert“ auf das übergeordnete Element der Hintergrundseite anzuwenden, wird eine große Verbesserung sein. Die Alternative ist, tabindex=-1 auf alle fokussierbaren Elemente anzuwenden.