Disclosure widgets

Was ist ein disclosure widget?
disclosure = Veröffentlichung, Enthüllung, Aufdeckung
widget = Widget, Komponente einer Benutzeroberfläche, »Dingsbums«

Ein disclosure Widget ist also ein Dings, das etwas sichtbar macht.

Ein disclosure Widget ist eine Steuerfläche (ein Button, ein Trigger), dessen einziger Zweck es ist, einen bestimmten Inhalt (ein Panel, ein Feld) zu verstecken bzw. sichtbar zu machen (zu zeigen). Wenn der Button (Trigger) aktiviert wird, schaltet er einen Inhalt oder einen Container mit Inhalt von sichtbar auf unsichtbar (und umgekehrt) um.

Wo werden disclosure Widgets verwendet? In Accordeons, Drop-Downs, Off-Canvas-Navigations ...

HTML oder ARIA?

Wir kommen wieder zur 1. ARIA-Regel: wenn es ein natives HTML-Element gibt, das die erforderliche Semantik und das Verhalten gleich mitbringt, dann verwende dieses.

Ein natives HTML disclosure Widget ...

mit eingebauter Semantik und Verhalten: <details> und <summary> – siehe Definition im HTML-Standard.

Das <details> Element ist der Container, das <summary> Element der Trigger.

Wenn kein <summary> Element vergeben wird, macht HTML selbst eines (generisches Details-label) – das will man aber eigentlich nicht haben.

<!-- this is a native disclosure widget -->
<details>
  <summary>[ trigger label ]</summary>

  <!-- disclosure content/panel -->
  <p>...</p>

</details>

Wenn das <details> Element aktiviert wird, wird diesem das Attribut open="" hinzugefügt, das wiederum toggelt ein list-style-type: disclosure-open für das (erste) <summary> Element. (Es kann theoretisch mehrere <summary> Elemente geben, aber man sollte immer nur eines verwenden. Der Browser wird immer nur das erste öffnen.)

Disclosure widget:

Disclosure Trigger

Disclosure Panel content goes here ...

Wie alle nativen HTML-Control-Elemente haben <details> und <summary> die semantischen Rollen, den Status und die Keyboard-Interaktionen eingebaut. <details> wird auf die role="group" Rolle gemappt, und <summary> auf die role="button" Rolle. Wenn man in die HTML Accessibility API Mappings schaut, sieht man, dass nicht alle Screenreader die Elemente gleich ansagen. Je nach Plattform und Accesitility API (und Browser- bzw. Screenreader-Kombinationen) werden die Elemente ganz unterschiedlich angesagt. NVDA (mit FF auf Windows) erwähnt das Dreieck als Teil des <summary> Elements und sagt auch noch dazu, in welche Richtung das Dreieck zeigt.
Das ist aber kein Grund zur Besorgnis und sollte auch nicht mit Gewalt überschrieben werden (weil sonst z.B. das erwünschte Verhalten verloren gehen kann).

Styling <details> und <summary> mit CSS

Falls das default triangle ersetzt werden muss: aufpassen! Infos im Video ab Minute 6:00!

Können wir <details> und <summary> für alle Zwecke benutzen?

Es kommt drauf an! Man muss immer schauen, wofür es verwendet werden soll.

Text, der in einem <summary> Element enthalten ist, wird z.B. bei einer Suche mit Chrome (Browserfunktionalität) auf der Seite gefunden, das Panel wird automatisch aufgeklappt. Achtung! FF findet das nicht! Das ist nicht immer erwünscht.

Eigenes ARIA disclosure Widget

Dazu brauchen wir:

  • einen Trigger (üblicherweise ein <button>-Element und)
  • einen Container mit Inhalt, das der Trigger auf- und zuklappen soll
  • ein Skript, das bei Klick auf den Trigger den Status aria-expanded=[ true | false ] setzt und für das ausklappbare Panel die Klasse .hidden toggelt
<div class="disclosure-widget">
  <button class="trigger" aria-expanded="false" aria-controls="panel">
    <svg width="12" height="8" viewBox="-2 -2 14 12" aria-hidden="true">
      <g fill="none" transform="rotate(-90 6 4)">
        <path fill="currentColor" d="M1.41.59l4.59 4.58 4.59-4.58 1.41 1.41-6 6-6-6z" />
        <path d="M-6-8h24v24h-24z" />
      </g>
    </svg>
    <span>Disclosure trigger</span>
  </button>
  <div id="panel" class="panel">
    <p>Disclosure content goes here.</p>
  </div>
</div>
<script>
  let trigger = document.querySelector(".disclosure-widget .trigger");
  let panel = document.querySelector(".disclosure-widget .trigger + .panel");

  trigger.addEventListener("click", function() {
    if ( this.getAttribute("aria-expanded") === "true" ) {
      this.setAttribute("aria-expanded", "false");
      panel.setAttribute("hidden", "");
    }
    else {
      this.setAttribute("aria-expanded", "true");
      panel.removeAttribute("hidden");
    } 
  });
</script>

Disclosure content goes here.

Relevante Success Criteria

SC 2.1.1 Keyboard (Level A) – Regel 3
xxx

APG - der ARIA Authoring Practices Guide

Der APG ist eine sehr nützliche, aber auch oft missverstandene und missbrauchte Referenz für Accessibility. Der Hauptzweck des APG ist es zu demonstrieren, wie man ARIA in Übereinstimmung mit der ARIA Spezifikation verwendet, wie man ARIA interpretiert und benutzt, um (einfache bis komplexe) Widget zu erstellen.

Diese Pattern kommen mit einer Warnung: No ARIA is better than Bad ARIA. Die APG sind kein Standard, sie sind nicht einmal eine offizielle W3C Empfehlung.

Die APG sind keine Spezifikation, sie sind nicht-normativ, sie listen keine Anforderungen auf, die man erfüllen muss. Und es ist nicht nötig, der Referenz zu folgen, da es einfach darauf ankommt, was man macht. Außerdem sind nicht alle der Pattern production-ready, nicht alle wurden vollständig getestet, insbesondere nicht auf Mobilgeräten. Ein Zweck des APG ist es außerdem, die Patterns zu testen.

How to use them (by Sara)

  1. HTML-Elemente nehmen, wenn es irgendwie geht
  2. die Interaktionen vereinfachen (under-engineering) wann immer es geht
  3. die ARIA-Attribute kennen
  4. die APG für maßgeschneiderte Widgets konsultieren
  5. andere Implementierungen für ein bestimmtes Pattern recherchieren
  6. die Implementierung mit verschiedenen AT und AT Usern testen

Man kann eigentlich immer nur dann sicher sein, dass etwas funktioniert, wenn man andere Leute beobachtet, die die Widgets bzw. Komponenten erfolgreich benutzen.

Links