Wirklich nur kurze Frage zu classList.toggle
Foxtrott_01
- html
- javascript
Hallo,
ich habe eigentlich nur eine kurze Frage bezüglich korrekter Semantik:
...und zwar setzte ich ein DIV ein, welchem via Klick-EventListener eine Klasse via classList.toggle
hinzugefügt / entfernt wird.
Ich habe dann bemerkt, dass (da es sich um die einzige Klasse des DIVs handelt), wenn die Klasse entfernt wird, <div class>
übrig bleibt - das class-Attribut schwebt sozusagen seelenlos durch Zeit und Raum.
Ist das ein Problem?
Danke für die Aufklärung!
LG, F.
@@Foxtrott_01
...und zwar setzte ich ein DIV ein, welchem via Klick-EventListener eine Klasse via
classList.toggle
hinzugefügt / entfernt wird.
Für welches Element ist der Eventhandler? Wenn für das div
: nein, nicht machen.
Click-Events sollte man nur für interaktive Elemente (Buttons, Links) als Targets verwenden. div
s sind nicht interaktiv; sie mögen für einige Nutzer per Maus clickbar sein, für viele andere (Tastatur-Nutzer) sind sie nicht clickbar.
Du willst vermutlich einen <button>
. Einen Toggle-Button.
Ich habe dann bemerkt, dass …
<div class>
übrig bleibt - das class-Attribut schwebt sozusagen seelenlos durch Zeit und Raum.Ist das ein Problem?
Nein, das ist kein Problem.
LLAP 🖖
Hallo Gunnar,
Danke für die Ausführungen!
Stimmt, eigentlich sollte das ein Button sein. Empfiehlst du diesbezüglich irgendwelche weiterführende Lektüren zu dem Thema Accessibility?
Danke, F.
@@Foxtrott_01
Empfiehlst du diesbezüglich irgendwelche weiterführende Lektüren zu dem Thema Accessibility?
Ebenfalls auf Inclusive Components: der Artikel zu Menus & Menu Buttons.
Das ganze Ding ist lesenswert – online und in erweiterter Form als Buch: eBook oder gedruckt.
Auch Heydon Pickerings vorheriges Buch Inclusive Design Patterns ist die Anschaffung wert.
Speziell zu Formularen: Adam Silvers Form Design Patterns.
Und natürlich Laura Kalbags Accessibility for Everyone.
LLAP 🖖
Hallo Gunnar
Ebenfalls auf Inclusive Components: der Artikel zu Menus & Menu Buttons.
leider wird da den verwendeten HTML-Elementen mir einigem an Aria-Attributen und Javascript die Zugänglichkeit nachgerüstet. Warum nimmt man nicht die Elemente, die fürs „Aufklappen“ gedacht sind? https://wiki.selfhtml.org/wiki/HTML/Interaktiv/details
Gruß
Jürgen
@@JürgenB
Ebenfalls auf Inclusive Components: der Artikel zu Menus & Menu Buttons.
leider wird da den verwendeten HTML-Elementen mir einigem an Aria-Attributen und Javascript die Zugänglichkeit nachgerüstet.
Warum leider? Mit JavaScript wird da nicht die Zugänglichkeit nachgerüstet, sondern das ganze Ein-/Ausklappen funktioniert nur mit JavaScript.
Warum nimmt man nicht die Elemente, die fürs „Aufklappen“ gedacht sind? https://wiki.selfhtml.org/wiki/HTML/Interaktiv/details
Ich weiß grad nicht, wie es um die Umsetzung von details
in Screenreadern steht. Ich vermute, Toggle-Buttons und aria-expanded
werden besser unterstützt.
Und wie willst du mit details
ein responsives Menü hinbekommen?
LLAP 🖖
Hallo Gunnar,
Warum nimmt man nicht die Elemente, die fürs „Aufklappen“ gedacht sind? https://wiki.selfhtml.org/wiki/HTML/Interaktiv/details
Ich weiß grad nicht, wie es um die Umsetzung von
details
in Screenreadern steht. Ich vermute, Toggle-Buttons undaria-expanded
werden besser unterstützt.
nach dem, was ich dazu gefunden habe, soll das OK sein.
Und wie willst du mit
details
ein responsives Menü hinbekommen?
ich habe das auf meiner Seite und im Wiki mal versucht.
Gruß
Jürgen
@@Gunnar Bittersmann
Ich weiß grad nicht, wie es um die Umsetzung von
details
in Screenreadern steht. Ich vermute, Toggle-Buttons undaria-expanded
werden besser unterstützt.
Ich hab da mal nachgefragt …
LLAP 🖖
Hallo Gunnar,
die Artikel habe ich seinerzeit eher so verstanden, dass details/summary von Screenreadern unterstützt wird, aber z.B. bei Navigationsmenüs (noch) davon abgeraten wurde, weil es ja andere Lösungen gibt. Dass man Screenreader-User mit einer hinter einem Details-Element versteckten Navigation verwirrt, ist neu für mich. Ist das nur eine Einzelmeinung? @Marc's Freund hat das anders gesehen: https://forum.selfhtml.org/self/2020/jan/13/zugangliche-menu-komponente/1762983#m1762983
Gruß
Jürgen
Hej JürgenB,
die Artikel habe ich seinerzeit eher so verstanden, dass details/summary von Screenreadern unterstützt wird, aber z.B. bei Navigationsmenüs (noch) davon abgeraten wurde, weil es ja andere Lösungen gibt.
Das fasst es ziemlich gut zusammen. Verschachtelte Liste mit JS ist der empfohlene Weg.
In dem englischen Artikel "[Details / Summary Are Not insert control here]" steht, was summary und details nicht sind (auch wenn Screenreader damit prinzipiell zurecht kommen) und warum das so ist. Es gibt aber viel schwerwiegendere "Sünden", als diese Elemente einzusetzen - zumal sich die Situation bei der Browserimplementierung bessert.
Marc (marctrix)
Hej Gunnar,
@@Gunnar Bittersmann
Ich weiß grad nicht, wie es um die Umsetzung von
details
in Screenreadern steht. Ich vermute, Toggle-Buttons undaria-expanded
werden besser unterstützt.Ich hab da mal nachgefragt …
Domingos kommt damit klar. So aus dem Kopf scheinen mir auch die wesentlichen Punkte aus dem BITV-Test dadurch bestanden zu werden.
Es schadet nicht, Meinungen einzuholen und es mag bessere Möglichkeiten geben.
Die Frage ist nur: machen wir uns derzeit nicht zu viel Gedanken über Screenreader (und das bedeutet zu wenig über andere Nutzergruppen). Die Accessibility-Diskussion in letzter Zeit wird zu gefühlt 90% über die Wünsche (nicht die Notwendigkeiten) von Screenreader-Nutzern geführt. Zum Beispiel, ob es komfortabel genug ist, einen Skiplink anzubieten, der direkt zum Inhalt führt, oder ob man unbedingt auch eine h1 über den Inhalt stellen muss und den Hauptinhalt auch noch mit main auszeichnen muss, damit jeder Screenreader-nutzer es so bequem wie irgend möglich hat.
Bitte an alle Accessibility-Interessierten: es gibt nicht nur Blinde. Tatsächlich sind die sogar relativ wenige. Die sollen natürlich dennoch unterstützt werden, aber macht euch bitte bewusst: bis auf ein paar hakelige Fälle (Dogge-Buttons, Dropdowns u.ä.) ist es recht trivial eine Website für Blinde zugänglich zu machen. Sauberes HTML, vernünftige Reihenfolge und text-Alternativen für alle nichttextualen Inhalte sind 98% der Miete. Kein Blinder würde sich beschweren, wenn das alle Webseiten liefern würden!
Marc (marctrix)
P.S. War gerade kurz auf deiner Website - Divitis ist heilbar! XD
Hallo Foxtrott_01,
P.S. War gerade kurz auf deiner Website - Divitis ist heilbar! XD
Aber nur, wenn es semantisch passende Elemente gibt.
Bis demnächst
Matthias
@@Foxtrott_01
P.S. War gerade kurz auf deiner Website - Divitis ist heilbar! XD
??
LLAP 🖖
@@Foxtrott_01
Divitis ist heilbar! XD
(Gerade einen Anlass gehabt, das wieder mal rauszukramen.)
Und prompt findet sich auch wieder jemand ein, der den Sinn der Bewertungsfunktion nicht verstanden hat. Falls die Bewertungsfunktion überhaupt einen Soinn hat.
🖖 Stay hard! Stay hungry! Stay alive! Stay home!