Sprechen wir über den *Zustand*. Genauer gesagt, wie wir den Zustand dem Benutzer mitteilen, nicht wie Anwendungsspeicher den Zustand in JavaScript-Objekten oder localStorage speichern. Wir werden darüber sprechen, wie wir unseren Benutzern den Zustand mitteilen können (denken Sie daran: ob ein Button deaktiviert ist oder nicht, oder ob ein Panel aktiv ist oder nicht) und wie wir CSS dafür verwenden können. Wir werden keine Inline-Stile oder, soweit möglich, Klassenselektoren verwenden, aus Gründen, die im Laufe des Artikels klar werden.
Immer noch hier? Cool. Legen wir los.
Alle dynamischen Komponenten einer Anwendung haben einen standardmäßigen benutzersichtbaren Zustand, und dieser Zustand muss gespeichert und aktualisiert werden, während Benutzer mit diesen Komponenten interagieren.
Wenn beispielsweise ein Button gedrückt wird, passieren Dinge (dafür sind Buttons da). Wenn diese *Dinge* passieren, werden sie typischerweise *visuell* in der Benutzeroberfläche dargestellt. Der Hintergrund des Buttons kann sich ändern, um anzuzeigen, dass er gedrückt wurde. Wenn der Button andere Komponenten in der Benutzeroberfläche steuert, ändern sich diese Komponenten wahrscheinlich visuell im Stil, oder in manchen Fällen wird ihre Sichtbarkeit umgeschaltet. Ein Element wird gelöscht, eine Benachrichtigung erscheint, ein Fehlerstil wird angewendet, usw.
Sie haben vielleicht bemerkt, dass wir den "visuellen" Zustand von Komponenten ziemlich oft erwähnt haben. Genau das ist die Art von Problem, die ich bei vielen Tutorials, Artikeln und allgemeinen Diskussionen über Zustand festgestellt habe.
In den meisten Fällen verwenden Entwickler "zustandsbehaftete" Klassen, um den Zustand einer Komponente zu verwalten. Aber das ist sehr unzureichend, da **eine Komponente aus mehr besteht als nur aus ihrem Aussehen.** Es gibt zugrunde liegende Semantik, die zusammen mit der visuellen Darstellung der Komponente verwaltet werden muss. Das Versäumnis, diese zugrunde liegenden Semantiken zu verwalten, wird sofort offensichtlich, sobald Sie über Tastatur und/oder Screenreader damit interagieren.
Dies ist ein Artikel darüber, wie der Zustand angemessen vermittelt werden kann, damit Benutzer, über sehende, mausnutzende Benutzer hinaus, mit unseren Benutzeroberflächen interagieren können.
Der Zustand ist mehr als nur das Aussehen
Abgesehen davon, dass CSS verwendet wird, um Inhalte für sehende Benutzer und assistierende Technologien angemessen zu verbergen, hat CSS kaum absichtliche Auswirkungen auf die Semantik oder den zugänglichen Zustand eines Elements. Was ich damit meine, ist, dass CSS außerhalb von Eigenschaften wie dem nicht unterstützten 'speak' ('speak'), Pseudo-Inhalten vor/nach und Medienabfragen zur spezifischen Neugestaltung von Komponenten basierend auf Benutzereinstellungen, wie der Reduced Motion Media Query und anderen vorgeschlagenen User Queries, **CSS allein nicht dazu gedacht ist, die Semantik eines Elements zu ändern**.
Warum bringe ich das alles zur Sprache? Weil die Verwaltung des Zustands allein mit CSS-Klassen größtenteils unzureichend ist, um den Zustand allen Benutzern zu vermitteln. Als Sprache für präsentationszwecke hat das Hinzufügen einer Klasse wie .has-error zu einem Eingabefeld, um die Rahmenfarbe zu einer Rottönung zu ändern, keinen semantischen Wert. Soweit CSS betroffen ist, *Das ist, wie Sie dieses Eingabefeld gestalten wollten. Cool. Ich unterstütze Sie! Bitten Sie mich nur nicht, nach oben im DOM zu gestalten. Da ziehe ich die Grenze, Kumpel...*
Stattdessen sollten wir, um den Zustand zu verwalten und zu vermitteln, Attribute auf den entsprechenden Elementen aktualisieren. Und nein, ich meine nicht data-Attribute. Die bedeuten auch nichts. Wenn wir diesen Ansatz verfolgen, brauchen wir in vielen Fällen keine zustandsbehafteten Klassen mehr, abgesehen von Klassen, die die display-Eigenschaft eines Elements umschalten.
Haben wir vergessen, dass wir mit Attributselektoren gestalten können?
HTML und ARIA haben eine ganze Reihe von Attributen, die verwendet werden sollten, um den aktuellen Zustand einer Komponente angemessen zu vermitteln.
Denken Sie daran, eine Klasse .is-disabled auf Ihrem <button></button> oder <input type="text" /> zu verwenden? Das wird ihn nur visuell deaktivieren. Sie müssen immer noch programmgesteuert Klick- und Tastaturereignisse für dieses Element deaktivieren. Verwenden Sie stattdessen das [disabled]-Attribut, und Sie haben einen CSS-Selektor, um Ihr Element zu gestalten, und der Browser erledigt die gesamte angemessene Arbeit, um dieses Element für Sie zu deaktivieren!
Also statt
input.is-disabled {
opacity: .65;
}was nur ein Eingabefeld visuell verändert, verwenden Sie
input[disabled] {
opacity: .65;
}Dies erzielt den gleichen visuellen Effekt wie die Verwendung der Klasse .is-disabled, aber stattdessen nutzen wir den Attributselektor aus dem Attribut, das wir **setzen müssen**, um den aktuellen Zustand an den Browser und die Benutzer zu vermitteln. Alles, ohne die oben genannten zusätzlichen Arbeiten mit JavaScript ausführen zu müssen, um die Eingabe zu deaktivieren, wenn wir nur eine Klasse umschalten würden.
Beispiel: "Aktiv" sein
Um einige tiefere Einblicke zu geben, betrachten wir eine Situation, in der Sie eine Klasse .is-active verwenden könnten. Für verschiedene Komponenten kann "aktiv" etwas völlig anderes bedeuten, weshalb ich den Wunsch nach einer einzelnen, wiederverwendbaren Klassennamen nachvollziehen kann, anstatt zu bestimmen, welches Attribut verwaltet werden muss, um den Zustand angemessen zu vermitteln. Aber die Zustandsverwaltung für Entwickler einfacher zu machen, hilft nicht unbedingt den Benutzern, also machen wir es richtig.
Aktive Navigationslinks
Betrachten wir zunächst die Anzeige des aktuell aktiven Links in einer Navigation. Der folgende Pen enthält zwei Beispiele. Das erste verwendet eine Klasse .is-active, um das aktuelle Navigationselement anzuzeigen. Das zweite verwendet aria-current="page".
Sehen Sie den Pen .is-active vs aria-current=’page’ von Scott (@scottohara) auf CodePen.
Obwohl sie alle genau gleich aussehen, werden Sie, wenn Sie Jaws 18, Voice Over oder NVDA 2017.2 (wenn es veröffentlicht wird) verwenden, um durch das Beispiel zu navigieren, etwas hören wie: "Features, current page." bei der Interaktion mit dem Beispiel, das aria-current verwendet. Schauen Sie sich den Artikel von Léonie Watson über [aria-current] an, um viele weitere Beispiele zu finden, wo dieses Attribut zur Gestaltung anstelle einer Klasse .is-active verwendet werden könnte.
Aktive Buttons
Je nach Zweck des Buttons muss der aktive Zustand des Buttons für Screenreader-Benutzer möglicherweise durch eines der folgenden ARIA-Attribute erweitert werden
aria-expanded– gibt an, dass der Button eine andere Komponente in der Benutzeroberfläche steuert und den aktuellen Zustand dieser Komponente wiedergibt.aria-pressed– gibt an, dass der Button ähnlich wie ein Kontrollkästchen funktioniert, in dem sein Zustand zwischen gedrückt und ungedrückt wechselt.
Ohne eines der oben genannten Attribute hat ein Button keine inhärente Möglichkeit, zu kommunizieren, ob er interagiert wurde oder nicht. Das ist völlig in Ordnung, wenn eine Situation es nicht erfordert, aber wenn Sie kommunizieren müssen, dass ein Button aktiviert wurde, dann können wir das hier mit aria-pressed tun
Sehen Sie den Pen Toggle Button Example von Scott (@scottohara) auf CodePen.
Im obigen Beispiel haben wir einen Button, mit dem ein Artikel in einen Warenkorb gelegt werden kann. Um anzuzeigen, wann ein Artikel hinzugefügt wurde, schalten wir anstelle einer Klasse den booleschen Wert des Attributs aria-pressed um und verwenden [aria-pressed="true"] als unseren Styling-Hook, um den aktiven Zustand visuell zu vermitteln. Bei der Interaktion mit dem Button über einen Screenreader wird er als "checked" oder "unchecked", add to cart, toggle button angekündigt.
Für eine eingehende Betrachtung der Überlegungen, die man bei der Entwicklung von zugänglichen Toggle-Buttons berücksichtigen sollte, muss man nicht weiter suchen als Heydon Pickerings Artikel über Toggle Buttons. Heydon legt detailliert dar, warum es keine gute Idee ist, das sichtbare Label des Buttons zu ändern, und weist sogar darauf hin, dass Sie möglicherweise keinen Toggle-Button benötigen, sondern stattdessen einen Schalter in Betracht ziehen sollten.
Zustandsverwaltung für Akkordeons
Für unser letztes Beispiel werfen wir einen Blick darauf, wie wir den Zustand in einer Akkordeon-Komponente verwalten würden.
Sehen Sie den Pen ARIA Accordion Example von Scott (@scottohara) auf CodePen.
Wenn Sie die Kommentare im CSS und JavaScript lesen, werden Sie feststellen, dass diese Demo einige Dinge tut.
Erstens ist das Markup-Muster des Akkordeons so aufgebaut, dass, wenn JavaScript aus irgendeinem Grund deaktiviert wird, kein Inhalt für diese Benutzer unzugänglich ist, da die Panels nur versteckt werden, wenn die Klasse .js vorhanden ist.
Zweitens, um die Notwendigkeit von tatsächlichen <button></button>-Elementen innerhalb jeder Akkordeon-Panel-Überschrift zu umgehen, wandeln wir stattdessen ihre verschachtelten <a>s in "Buttons" um, indem wir die ARIA-Eigenschaft role="button" anwenden und dann die gesamte erwartete Tastaturfunktionalität über den Keydown-Event-Listener hinzufügen. Zusätzlich wurde jedem ARIA-Button ein tabindex="0" zugewiesen, um sicherzustellen, dass der "Button" für Tastaturbenutzer zugänglich ist.
Schließlich verwenden wir hier das Attribut aria-expanded, um den aktuellen Zustand des Akkordeon-Panels zu vermitteln, so dass, wenn ein Benutzer den Akkordeon-Trigger mit einem Screenreader fokussiert, dieser "Accordion Heading, collapsed (or expanded) button" ansagt.
Sie werden feststellen, dass die Akkordeon-Panels eine Klasse .is-active verwenden, um ihren sichtbaren Zustand umzuschalten. Igitt! Aber Moment mal, das ist das Einzige, worauf wir uns bei CSS allein verlassen können, um uns zu helfen. Wenn wir uns die beteiligten Selektoren genauer ansehen
.js .accordion__panel {
border-bottom: 1px solid;
overflow: hidden;
padding: 0 1em;
max-height: 0px;
transition:
max-height .2s ease-in-out,
visibility .2s ease-in-out;
visibility: hidden;
}
.js .accordion__panel.is-active {
max-height: 100vh;
visibility: visible;
}Der erste Selektor, der von der Verfügbarkeit von JavaScript abhängt, verwendet visibility: hidden, um die Inhalte des Panels sowohl für sehende Benutzer als auch für Benutzer assistierender Technologien inklusiv zu verstecken. Die Eigenschaften overflow, max-height und transition werden dann gesetzt, um das Panel zu komprimieren und es auf seine erweiterte Form vorzubereiten, sobald die Klasse .is-active zum Akkordeon-Panel hinzugefügt wird. Ich hätte stattdessen display: none umschalten oder das Attribut hidden programmgesteuert zu den Panels hinzufügen und entfernen können, aber wir hätten die Möglichkeit verloren, das Panel zu animieren. Und jeder mag eine gute Animation, oder?
Zum Abschluss
Das Wichtigste, was Sie von all dem mitnehmen sollten, ist, dass Sie den Zustand wahrscheinlich nicht angemessen an Benutzer assistierender Technologien vermitteln, wenn Sie nur Klassen umschalten, um den Zustand Ihrer Komponenten visuell zu verwalten.
Sie müssen die entsprechenden Elemente verwenden (<button></button> sind Ihr Freund!) und die entsprechenden Attribute und ihre Werte verwalten, um wirklich zugängliche Benutzererlebnisse zu schaffen. Sicher, Sie könnten diese Dinge tun *und* weiterhin zustandsbehaftete Klassen umschalten, um Ihr Styling zu steuern. Aber wenn wir Attribute und ihre Werte aktualisieren müssen und diese ebenfalls gültige CSS-Selektoren sind, warum sollten wir dann mehr Arbeit leisten, als nötig ist, indem wir auch Klassen umschalten?
Großartiger Artikel, Scott.
Ich bin gerade dabei, eine Reihe unserer Barrierefreiheits-Codes zu überprüfen – insbesondere Dinge wie Akkordeons, Tabs, Navigationsleisten – und werde ernsthaft darüber nachdenken, "is-state"-Klassen zu entfernen und stattdessen entsprechende Attributselektoren zu verwenden.
Und Heydon Pickerings Artikel hat die Grundlage für ein Toggle-Button-POC gelegt – http://codepen.io/basherkev/pen/jmZpyv – das ich nun in unsere UI-Komponentenbibliothek integriert habe.
Außerdem freue ich mich sehr, dass in letzter Zeit so viele großartige A11Y-Artikel und Ressourcen erscheinen.
Danke!
Tolle Informationen, ich arbeite als Webentwickler und unser Unternehmen macht große Schritte, um sicherzustellen, dass alle unsere Dienste/Websites WCAG 2.0 AA-konform sind. Nach dem Lesen dieses Artikels habe ich eine Kombination aus aria-controls und aria-expanded verwendet, um unsere Navigationsinteraktion zu handhaben. (Zuvor wurden Klassen verwendet).
Nicht nur ist das Menü jetzt zugänglicher, sondern auch der Code dahinter ist semantischer und leichter zu verstehen.
Das ist großartig, Shane! Freut mich, dass es für Sie hilfreich war.
Ich mag die Idee dieses Artikels und ich denke, er war sehr gut präsentiert, aber ich habe einen kleinen Einwand. Die Prämisse des Artikels scheint diese zu sein:
Das Problem dabei ist, dass CSS-Klassen mit Abstand der skalierbarste Weg sind, Dinge zu gestalten. Sind Sie mit SMACSS vertraut?
https://smacss.com/
Während ich zustimme, dass wir alle bestrebt sein sollten, die richtigen Attribute für den Zustand festzulegen, denke ich, dass es sich lohnt, auch Klassen umzuschalten, um auf großen Projekten ein skalierbares Stylesheet beizubehalten.
Hallo Scott,
Während Sie teilweise richtig liegen, dass ich mich dafür einsetze, die uns zur Verfügung stehenden Attributselektoren zu nutzen, wenn wir den benutzerorientierten Zustand unserer Komponenten angemessen aktualisieren, würde ich vorschlagen, dass die Prämisse des Artikels wirklich lautet: "Bauen Sie Dinge zugänglich und Sie erhalten viele zustandsbehaftete Styling-Hooks kostenlos." Und wie ich in meinem Schlusswort zusammenfasse: Da wir diese Hooks kostenlos erhalten, warum zusätzliche Arbeit leisten, indem wir auch zusätzliche Klassen und JS in den Mix bringen und diese auch verwalten müssen?
Was SMACSS angeht, bin ich damit recht vertraut. Ich schätze und mag die meisten Ideen dahinter, aber ich unterwerfe mich ihm auch nicht vollständig, oder irgendeiner einzelnen CSS-Methodik. Ich persönlich denke, dass CSS eine tiefe Sprache ist, die viel zu bieten hat, und nicht auf eine einzige Art von Selektor beschränkt sein sollte, 'weil sie am besten skaliert.' Die verschiedenen Selektoren gibt es aus guten Gründen. Wenn wir sie kollektiv besser nutzen, dann werden sich vielleicht viele dieser "CSS ist kaputt"-Gespräche von selbst lösen :)
Aber ich sehe wirklich keinen (skalierbaren) Unterschied zwischen
.tab-is-open { /* von der SMACSS-Website */ }
vs
.tab[aria-expanded=”true”] {}
Der erstere tut nichts, um Junior-Entwicklern zu vermitteln, dass es mehr gibt, als nur visuell ein paar Farben zu tauschen, um den Zustand zu kommunizieren. Während der letztere sie dazu bringen *sollte*, "Was ist das? Ich sollte lernen, was das bedeutet." zu denken.
Unabhängig davon könnte ich buchstäblich einen ganzen Unterartikel hier in den Kommentaren dazu schreiben, aber ich würde lieber mit Ihnen darüber sprechen. Daher ist die Einladung offen, mich zu kontaktieren und wir können diese Diskussion fortsetzen, wenn Sie möchten.
Danke :)
Warum ist SMACSS also wertvoll? Zwei Gründe. Semantische Selektoren und schwache Selektoren. Ich stimme zu, dass Ihre Methoden in diesem Artikel äußerst semantisch sind. Kudos. Aber klassenbasierte Selektoren sind semantisch genug und weit schwächer. Im von Ihnen zitierten Beispiel,
.tab-is-open { /* von der SMACSS-Website */ }vs.tab[aria-expanded=”true”] {}ist der Unterschied in der Skalierbarkeit offensichtlich: Die SMACCS-Version ist "doppelt" so skalierbar, weil sie halb so stark ist (nehmen Sie meine fiktive Skalierbarkeit ... äh ... Skala hin). Der Punkt ist, SMACCS verwendet einen einzelnen Klassennamen, und Sie verwenden eine Klasse plus ein Attribut. Sie sind damit einen Schritt weiter in Richtung!important, und dort liegt der Wahnsinn.Schwache Selektoren zu halten, gehört zu den wichtigsten Anliegen in einem großen Projekt. Ich werde nicht dogmatisch sein und sagen, dass es das wichtigste Anliegen ist, aber verdammt, es ist ganz oben dabei.
Hallo Scott,
Ihre Antwort bezieht sich nicht auf diesen Teil der SMACSS-Website bezüglich zustandsbehafteter Klassen
"Da der Zustand wahrscheinlich den Stil eines komplexeren Regelwerks überschreiben muss, ist die Verwendung von !important erlaubt und, wage ich zu sagen, empfohlen. (Ich habe früher gesagt, dass !important niemals benötigt wird, aber in komplexen Systemen ist es oft eine Notwendigkeit.)"
Bezüglich Ihrer Kritik am Beispiel, das ich verwendet habe: Was versuchen Sie dort zu skalieren? Warum sollte man eine 'tab-is-open'-Klasse auf etwas anderes als das ursprüngliche '.tab'-Element anwenden? Wie ist die Verwendung des strengeren Selektors hier eine schlechte Wahl, wenn diese zustandsbehaftete Klasse keine Berechtigung hat, auf irgendeiner anderen Komponente verwendet zu werden, und sie *soll* das Standardstyling des Tabs überschreiben?
Selbst etwas generischeres wie eine 'wiederverwendbare' is-open-Klasse. In welchem Kontext wird sie verwendet? Ein Tab, ein Off-Screen-Menü, ein Tooltip, ein Akkordeon? Ich würde argumentieren, dass das Styling für jede dieser Komponenten unterschiedlich sein müsste, je nachdem, ob sie einen CSS-Übergang benötigen oder nicht, oder ob der ursprüngliche Zustand des Inhalts wirklich vor allen Benutzern verborgen war, oder ob der Inhalt lediglich visuell versteckt war (denken Sie an ein Dropdown-Menü, das geöffnet werden muss, im Gegensatz zu einem Dropdown-Menü, das beim Hover/Fokus des Hauptauslösers geöffnet werden sollte, oder irgendeines der Kindelemente des Dropdown-Menüs).
Was ist also an einer wiederverwendbaren Klasse skalierbar, die nicht über ihren Namen hinaus wiederverwendbar ist? Namenserkennung? Machen Sie sich stattdessen mit Attributselektoren wie [disabled] und [aria-expanded] vertraut, da diese tatsächlich etwas bedeuten und oft zugunsten von zustandsbehafteten Klassen vernachlässigt werden.
Schließlich: "Aber klassenbasierte Selektoren sind semantisch genug..."
Wie Sie aus der Lektüre des Artikels wissen sollten, widerspreche ich dieser Ansicht. Ich halte es für weitaus wichtiger, dass Entwickler Dinge auf intelligente, zugängliche Weise erstellen und alle uns zur Verfügung stehenden Werkzeuge dafür nutzen.
Nochmals vielen Dank für die Antwort, da dies Themen sind, in die ich im Artikel nicht zu tief einsteigen wollte, um nicht den Eindruck zu erwecken, dass ich SMACSS schlecht mache. Nochmals, ich denke, SMACSS ist insgesamt eine ausgezeichnete Methodik für CSS... aber ich kann das denken und trotzdem einen Aspekt davon kritisieren, und stattdessen dafür plädieren, es auf eine Weise zu tun, die ähnliche Styling-Effekte erzielt, aber durch die Verwendung von Selektoren mit tatsächlicher Semantik dahinter.
Re: !important. Yup. Dem stimme ich auch zu. Aber der Punkt, den ich mit diesem Zitat gemacht habe, war, dass Zustandsklassen *spezifischer sein sollten*. Sie konzentrieren sich auf den !important-Teil und ignorieren die Tatsache, dass es in Ordnung ist, stärkere Selektoren zu haben, wenn Sie den Standardzustand überschreiben.
Was Ihr Gegenbeispiel angeht: Es ist schwer, gegen ein vages Szenario wie das zu argumentieren, denn während Sie sagen, es wäre unzureichend, denke ich an ähnliche Szenarien, in denen es perfekt funktioniert hat. Aber um es hier angemessen zu besprechen, wären erheblich mehr Kontext über das Verhalten der Markup-Elemente und die Benutzererwartungen der Interaktionen erforderlich.
Und ich bin froh, dass wir nicht über die Verwaltung von Attributen streiten, da das das Wichtigste hier ist. Aber da ich bereits zugegeben habe, dass ich SMACSS nicht strikt befolge, weiß ich nicht, was es zu gewinnen gibt, indem wir diesen Thread fortsetzen? Sie stimmen meiner Ansicht zu CSS-Selektoren nicht zu, und das ist in Ordnung. Sie stimmen zu, dass es mehr Vorarbeit ist, sowohl Klassen als auch Attribute zu verwalten. OK...
Es scheint, als würden wir lediglich CSS-Methodologien debattieren, und das wird nirgendwo hinführen. Denn für jedes Beispiel, das Sie mir geben, könnte ich Ihnen Beispiele zurückgeben, um meine Haltung zu unterstützen.
Daher sage ich aufrichtig: Passen Sie auf, Scott, und danke für die Diskussion :)
Touchè, er räumt ein, dass
!importantnicht das Worst-Case-Szenario ist, aber der nächste Satz lautet: "Lassen Sie !important weg, bis Sie es tatsächlich und wirklich brauchen". Wenn Sie schwache Selektoren zur obersten Priorität machen, werden Sie ihn nicht brauchen.Ihr Beispiel mit dem Szenario 'tab-is-open' hat mich kurz verwirrt, denn ich stimme zu, dass es auf den ersten Blick so aussieht, als ob Ihr Attributselektor niemals überschrieben werden muss, was die Selektorenstärke zu einem Nebenaspekt macht. Allerdings habe ich in meiner Arbeit gerade ein Gegenbeispiel, das meiner Meinung nach ziemlich üblich ist: Eine Reihe von Tabs, von denen die meisten ein Dropdown-Menü auslösen, aber einer löst ein Suchfeld aus, und sie erhalten dabei sehr unterschiedliche Stile. Mir scheint klar, dass Attributselektoren hier allein nicht ausreichen würden. Sie müssen über Klassen irgendeiner Art gestalten, und durch die Einbeziehung von Attributselektoren erhöhen Sie unnötigerweise die Stärke Ihrer Auswahl.
Ich streite mich sicherlich nicht gegen die Verwaltung Ihrer Attribute bei Zustandsänderungen, ich glaube nur aus persönlicher Erfahrung, dass es sich lohnt, auch Klassen zu verwalten. Sie nennen es zusätzliche Arbeit, und im Voraus ist es das definitiv. Aber es zahlt sich aus, wenn ein Projekt älter und größer wird, und Sie können Module fröhlich hinzufügen oder ändern, ohne in einen Selektorenkrieg zu geraten.
Alles klar, danke für das Gespräch und den zum Nachdenken anregenden Artikel.
Ich empfehle die Verwendung von summary und Details für Akkordeons – wie alle anderen HTML-Elemente haben sie integrierte Barrierefreiheit – ich weiß, MS unterstützt sie immer noch nicht. Aber einerseits funktioniert der Fallback (nur Boxen). Außerdem gibt es Polyfills – ich würde https://mathiasbynens.be/notes/html5-details-jquery empfehlen.
Sie kommen sogar mit dem "open"-Attribut, das Sie sowohl für das Styling als auch für weitere JS-Verbesserungen verwenden können. Egal ob mit Js oder nicht: Summary und Details sind die Elemente, die Sie für erweiterbare Inhalte verwenden möchten, so wie hx für Überschriften oder Buttons für Buttons verwendet werden sollte. Immer!
Hallo Marc,
Guter Punkt bezüglich der Verwendung von Details/Summary. Wenn der Inhalt es diktiert, dass dies das passende Markup-Muster ist, dann sollte es definitiv das Mittel der Wahl sein, natürlich mit Polyfill.
Ich wollte mich auf das ARIA-Akkordeon konzentrieren, da es für mein Argument besser geeignet war, Attribute anstelle von Klassen mit JavaScript umzuschalten. Ein Details/Summary würde kein JavaScript oder Klassenumschaltung erfordern (sollte es nicht), daher war es, obwohl es eine geeignete Komponente sein mag, nicht wirklich das Thema, das ich hervorheben wollte, nämlich dass JS-Komponenten den Zustand nicht korrekt vermitteln.
Ich hoffe, das klärt etwaige Fragen, die Sie vielleicht dazu hatten, warum ich diesen Weg gewählt habe.
Danke!
Sie haben Recht – ich habe nicht darüber nachgedacht, was Sie erklären wollten, und natürlich weiß ich, dass es Projektanforderungen gibt, die es notwendig machen, andere Elemente als Details/Summary zu verwenden – manchmal bedeutsamere. Außerdem hat Details/Summary einen wichtigen Nachteil: Meiner Meinung nach ist es eher ein präsentationsbezogenes Markup als Semantik. Oft möchte ich tatsächlich article/hx oder etwas anderes verwenden, anstatt Details/Summary.
Jedenfalls scheint es mir, dass einige Entwickler diese Elemente einfach vergessen haben – vielleicht gab es lange Zeit schlechte Browserunterstützung und Entwickler gewöhnten sich zu sehr an jQuery-Plugins für Akkordeons, die eigentlich ein Workaround sein sollten, aber zu einem bequemen Bestandteil ihres Werkzeugkastens wurden.
Daher halte ich es für eine gute Idee, Details/Zusammenfassungen immer wieder zu erwähnen – insbesondere wenn es um inklusives Design geht. – Wenn Sie ein Akkordeon erstellen möchten, das nur ein einziges geöffnetes Detail zulässt, ist sowieso JS erforderlich. Aber auch hier ist es sehr praktisch, dass Sie das "open"-Attribut verwenden (und manipulieren) können.
Ich hoffe, das kann einigen Leuten helfen, ihren Werkzeugkasten ein wenig aufzuräumen ;-)