Aloha ;)
Beim Checkboxen-Hack sind Checkboxen zweckentfremdet (wie der Name „Hack“ schon sagt).
Nur weil etwas Hack heißt bedeutet das nicht, dass es diesen Namen auch verdient hat.
Screenreader lesen aber Checkboxen vor.
Auch solche mit display=none
? Das kann sein, würde mich jetzt aber doch stark wundern.
Er will eine Aktion auf der Seite ausführen. Das UI-Element für Aktionen auf einer Seite sind nicht Checkboxen, sondern Buttons. Ein Button wird als Button vorgelesen und ist verständlich.
Und ein label
-Element mit role="Button"
und aria-pressed
ist nicht verständlich?
Ja, die Beispiele im Wiki haben das im Moment nicht. Glaube ich.
Das liegt unter anderem daran, dass ich, was ARIA angeht, gedanklich manchmal noch nicht so weit bin und das manchmal nicht auf dem Schirm habe.
Für mich stellt sich das - tut mir leid - so dar, dass die Checkbox-Hack-Lösung durchaus auch so realisiert werden kann, dass sie auch für Screenreader benutzbar und verständlich ist.
Das wäre ein deutliches Argument dafür, dass man nicht sagen sollte „auf keinen Fall machen“, sondern „wenn machen, dann richtig“.
Es ist sinnfrei, auf Teufel komm raus auf JS verzichten zu wollen.
Das will ich nicht! Ich will dafür nichts opfern, schon gar keine Barrierefreiheit! Aber ich denke immer noch, dass eine Lösung ohne Javascript und mit Checkboxen durchaus auch barrierefrei sein kann - und solange ich da nicht vom Gegenteil überzeugt bin will ich das versuchen zu erreichen, ja.
Oder dann eben [JS] nur als progressive enhancemenct,
Natürlich als PE. Das heißt, dass ohne JS alle Inhalte ausgeklappt sind.
Bei einer Navigationsleiste die visuell im vollständig ausgeklappten Zustand bspw. über dem Inhalt der Seite liegt oder sich gegenseitig überdeckt? Da finde ich die Idee, den Checkbox-Hack barrierefrei zu gestalten und keinem sowas zuzumuten doch erheblich reizvoller!
Grüße,
RIDER