The “Other” C in CSS
[ad_1]
Ich denke, es lohnt sich, alles anzuhören, was Sara Soueidan zu sagen hat. Das gilt insbesondere, wenn sie zum ersten Mal seit vier Jahren bei einer Veranstaltung spricht, wie es der Fall war, als sie die Bühne betrat bei CSS Day 2024 in Amsterdam. Was ich an Sara am meisten schätze, ist, wie sie nicht nur erklärt, Warum hinter allem, was sie präsentiert, aber sie präsentiert es auf eine Art und Weise, die bei mir ein „Aha!“ auslöst, anstatt „Oh Mist, ich mache alles falsch.“
(Oh, und Sie sollten ihren Kurs über Praktische Zugänglichkeit.)
Saras Präsentation „Das andere ‚C‘ in CSS“ war auf YouTube veröffentlicht erst letzte Woche. Es sind ungefähr 55 Minuten mit unverzichtbaren Punkten zu den verschiedenen Möglichkeiten, wie CSS die Zugänglichkeit beeinflussen kann und tut. Ich begann die Präsentation beiläufig anzusehen, öffnete aber schnell einen Ort, an dem ich mir ausführliche Notizen machen konnte, sobald ich mich selbst gefunden hatte. ooo-ing und ahhh-mitmachen.
Das sind also die Dinge, die ich aus Saras Präsentation mitgenommen habe. Sagen Sie mir Bescheid, wenn Sie auch Notizen gemacht haben, damit wir vergleichen können! Los geht’s, es gibt viel zu lernen.
Hier ist das Video
Ja, CSS beeinflusst die Zugänglichkeit
CSS ändert mehr als nur das visuelle Erscheinungsbild von Elementen, ob es uns gefällt oder nicht. Darüber hinaus wirken sich seine Auswirkungen auch auf HTML und den Zugänglichkeitsbaum (accTree) aus. Und wenn wir vom accTree sprechen, beziehen wir uns auf eine Liste von Objekten, die zugängliche Informationen über Elemente beschreiben und definieren.
Zu einem accTree-Objekt gibt es typischerweise vier Hauptinformationen:
- Rolle: was ist das für ein Ding? Die meisten HTML-Elemente werden ARIA-Rollen zugeordnet, aber nicht alle.
- Name: identifiziert das Element in der Benutzeroberfläche.
- Beschreibung: wie beschreiben wir die Sache weiter?
- Zustand: wie ist der aktuelle Stand? Sag es Bescheid!
Der Browser bietet interaktive Funktionen – beispielsweise das Aktivieren eines Kontrollkästchens, das die Informationen des Elements aktualisiert und anzeigt –, sodass der Benutzer weiß, was nach einer Interaktion geschieht.
Objekte des Zugänglichkeitsbaums können auch enthalten Eigenschaften Und Beziehungenetwa ob es Teil einer Gruppe ist oder durch ein anderes Element gekennzeichnet ist.
Beispiel: Listensemantik
CSS kann die zugängliche Rolle, den Namen, die Beschreibung eines Objekts oder sogar die Frage beeinflussen, ob es überhaupt im accTree angezeigt wird. Daher kann es die Ankündigung des Screenreaders direkt beeinflussen. Wir haben vor einiger Zeit erklärt, wie Entfernen list-style beeinflusst die Listensemantikinsbesondere im Fall von Safari, und Sara erklärt die Feinheiten.
/* Removes list role semantics in Safari */
/* Need to add aria-role=list */
ul {
list-style: none;
}
/* Does not remove role semantics in Safari */
nav ul {
list-style: none:
}
/* Removed unless specifically re-added in the markup */
ul:where([role="list"]) {
list-style: none;
}
/* Preserves list semantics */
ul {
list-style: "";
}display: contents
CSS kann die Präsenz eines Elements vollständig aus dem Zugänglichkeitsbaum entfernen. Ich habe einen Screenshot von einer von Saras Folien gemacht, aber es ist einfach so verdammt hilfreich, dass ich dachte, es wäre sinnvoller, die Informationen in eine Tabelle zu setzen:
| Sind Sie a11y-APIs ausgesetzt? | Über Tastatur zugänglich? | Visuell zugänglich (gerendert)? | Sind Kinder a11y-APIs ausgesetzt? | |
|---|---|---|---|---|
display: none |
||||
visibility: hidden |
||||
opactity: 0 Und filter: opacity(0) |
||||
clip-path: inset(100%) |
||||
position(off-canvas) |
||||
.visually-hidden |
||||
display: contents |
Der display: contents Methode tut mehr als sie soll. Kurz gesagt, wir wissen, dass display steuert den Typ der Box, die ein Element erzeugt. Ein Wert von noneerzeugt beispielsweise keine Box.
Der contents Wert ist so etwas wie none in dem nicht die Box generiert wird. Der Unterschied besteht darin, dass es keine Auswirkungen auf die untergeordneten Elemente des Elements hat. Mit anderen Worten, die Deklaration contents entfernt das Element oder seine untergeordneten Elemente nicht aus dem accTree. Darüber hinaus gibt es einen aktuellen Fehlerbericht, der besagt, dass die Deklaration contents in Firefox unterbricht die Verankerungswirkung eines an ein Element angehängten ID-Attributs.
Eric Bailey sagt, dass die Verwendung display: contents gilt als schädlich. Wenn Sie es verwenden, empfiehlt es sich, es auf einen generischen Wert einzustellen.
Dinge optisch verstecken
Viele, viele von uns verwenden eine Art .visibility-hidden Klasse als Dienstprogramm zum Ausblenden von Elementen, während Screenreader diese erkennen und den Inhalt ansagen können. TPGi bietet eine großartige Aufschlüsselung der Technik.
.visually-hidden:not(:focus):not(:active) {
width: 1px;
height: 1px;
overflow: hidden;
clip: rect(0 0 0 0); /* for IE only */
clip-path: inset(50%);
position: absolute;
white-space: nowrap;
}Das ist sehr nah an dem, was ich persönlich in meiner Arbeit verwende, aber die beiden :not() Anweisungen waren neu für mich und haben mich verwirrt. Sie sorgen dafür, dass der Selektor nur angewendet wird, wenn das Element weder fokussiert noch aktiviert ist.
Es ist einfach, diese Klasse auf Dinge zu klatschen, die wir verbergen möchten, und das war’s. Aber wir müssen vorsichtig sein und sie absichtlich verwenden, wenn die Situation es uns erlaubt, ein Element zu verbergen, aber dennoch anzukündigen. Wir würden dies beispielsweise nicht für interaktive Elemente verwenden wollen, da diese immer angezeigt werden sollten. Wenn Sie mit etwas interagieren, müssen wir es sehen können. Aber für allgemeine Textsachen ist alles in Ordnung. Auch Links zum Überspringen von Inhalten.
Es gibt eine Ausnahme! Wir möchten vielleicht ein animiertes Kontrollkästchen und müssen das native Steuerelement ausblenden. appearance so dass es verborgen bleibt, auch wenn CSS es so gestaltet, dass es sichtbar ist. Wir müssen immer noch die verschiedenen Zustände des Formularsteuerelements berücksichtigen und wie es der unterstützenden Technologie mitgeteilt wird. Wenn wir beispielsweise das native Kontrollkästchen für ein benutzerdefiniertes Kontrollkästchen verbergen, indem wir es weit außerhalb des Bildschirms positionieren, wird die unterstützende Technologie es bei Fokus oder Aktivierung nicht ankündigen. Es ist besser, das Kontrollkästchen absolut über dem benutzerdefinierten Kontrollkästchen zu positionieren, um die Vorteile der interaktiven Zugänglichkeit zu nutzen.
Fazit: Fragen Sie sich, ob ein interaktives Element sichtbar wird, wenn es den Fokus erhält, wenn Sie entscheiden, ob Sie ein .visually-hidden Dienstprogramm.
CSS und barrierefreie Namen
Der Browser folgt einem bestimmten Prozess, wenn er den zugänglichen Namen (accName) eines Elements bestimmt:
- Zunächst wird geprüft, ob
aria-labelledby. Falls vorhanden und wenn die ID im Attribut ein gültiger Verweis auf ein Element auf der Seite ist, wird der berechnete Text des Verweiselements als zugänglicher Name des Elements verwendet. - Andernfalls prüft es, ob
aria-label. - Andernfalls, sofern das Element nicht mit gekennzeichnet ist
role="presentation"oderrole="none"(d. h. das Element akzeptiert keinen accName mehr), prüft der Browser, ob das Element seinen eigenen Namen erhalten kann. Dies kann auf verschiedene Arten geschehen, unter anderem:- aus einem HTML-Element, wie zum Beispiel
altodertitle(am besten auf einem
- aus einem HTML-Element, wie zum Beispiel