jQuery slideToggle - Bereich schließen

[Orlok]

Hallo Marc

Erstmal Dank an dich und Gunnar für das Feedback. (…)

Bei den Elementen zur Steuerung der Sichtbarkeit der anderen Elemente sollte es sich um Buttons handeln.

Um Toggle-Buttons (Inclusive Components).

Ich finde die Verwendung von details und summary sinnvoller!

Aus dem von @Orlok genannten Grund: ein Nutzer entscheidet so selber, was geöffnet sein soll und was nicht.

Die Verwendung von details und summary schließt eine Implementierung ja nicht aus, bei der zu einem bestimmten Zeitpunkt immer nur ein Bereich geöffnet ist. Das wäre sogar viel einfacher zu bewerkstelligen, als wenn man alles von Hand schreiben würde, da hier der größte Teil der Umschaltlogik von Browser übernommen wird. Man muss nur einen Eventhandler registrieren und prüfen, ob es ein offenes details-Element gibt, auf das nicht geklickt wurde – und dieses dann schließen, indem man das gesetzte open-Attribut entfernt.

Mit jQuery könnte das ungefähr so aussehen:

$(function() {

    $('details').click(function() {
        const $openDetails = $('details[open]');

        if (!$(this).is($openDetails)) {
            $openDetails.removeAttr('open');
        }
    });

});

Die Verwendung von details und summary ist sinnvoller, weil es blödsinnig ist Sachen nachzubauen, für die es bereits eine native Implementierung gibt.

Eine Ausnahme wäre, wenn man ein Polyfill schreiben wollte. In diesem Fall könnte man sich fragen, ob es sinnvoll ist, aria-pressed zu summary hinzuzufügen. Die Antwort hängt dann davon ab, ob das in der Praxis tatsächlich zu einer Verbesserung der User Experience für Nutzer assistiver Software führt. Ob das so ist, weiß ich nicht, aber ich wage es zu bezweifeln.

Auf welche Rolle der jeweils genutzten Accessibility API summary abgebildet werden soll, dafür gibt es Vorgaben, nachzulesen in der HTML Accessibility API Mappings Spezifikation:

Abgesehen vom Mac, wo es mit disclosure Triangle eine native Rolle für diese Bestimmung gibt, wird summary auf dieselben Rollen abgebildet, wie Elemente mit role button, welche darüber hinaus nur die Standardwerte enthalten. Wird das aria-pressed-Attribut auf einem Button definiert, dann hat das Auswirkungen darauf, auf welche Rolle der Accessibility API des Betriebssystems das Element abgebildet wird. Die Präsenz des Attributs führt dazu, dass die Rolle Toggle-Button verwendet wird, die von fast allen Schnittstellen unterstützt wird. Das wäre dann was anderes als das, was für summary spezifiziert wurde. Das sollte man in die Überlegung einbeziehen.

Es wirft die Frage auf, aus welchem Grund in Abwesenheit einer passenderen Rolle trotz breiter Unterstützung nicht auf Toggle-Button zurückgegriffen wurde. Meine Vermutung ist, dass es in diesem speziellen Fall keinen zusätzlichen Nutzen bringt, sondern lediglich die Komplexität erhöht. Schließlich gibt es mit dem aria-expanded-Attribut bereits einen zweiwertigen Zustand, der in allen APIs abgebildet werden kann. Worin liegt der Vorteil, wenn zusätzlich zu expanded und collapsed noch pressed und not pressed angesagt wird?

Ich halte aria-pressed in diesem speziellen Fall nicht für sinnvoll und würde darum von dessen Gebrauch abraten. Aber ich lasse mich gerne eines Besseren belehren.

Viele Grüße,

Orlok