Barrierefreies Webdesign ein zugängliches und nutzbares Internet gestalten

Tri-State-Checkbox veröffentlicht in 2014/2016

Wenn eine Checkbox mit HTML erzeugt wird:

<p>
  <label>
        <input type="checkbox" name="gemuese" value="1">
        Ich esse Gemüse
</label>
</p>

dann hat die Checkbox alles, was sie für eine barrierefreie Bedienung benötigt:

Wenn Checkboxen mit Grafiken gestaltet werden und die Funktionalität mit JavaScript nachgebildet wird, dann fehlen oft die oben aufgezählten Aspekte der Barrierefreiheit. Es gibt nur zwei Gründe, auf HTML-Checkboxen zu verzichten:

  1. Die Checkbox soll drei statt zwei Zustände besitzen können. Neben "Aktiviert" und "nicht aktiviert" soll auch "teilweise aktiviert" dargestellt werden können.
  2. Die Checkbox soll optisch anders dargestellt werden, wobei die Möglichkeiten mit CSS für die gewünschte Darstellung nicht ausreichen.

Drei statt zwei Zustände

Wenn eine Checkbox drei Zustände haben soll:

Mehrere Checkboxen mit den Zuständen: aktiviert, nicht aktiviert und teilweise aktiviert.

sieht HTML die indeterminate-Eigenschaft für den Zwischenzustand zwischen "aktiviert" und "nicht aktiviert" für <input type="checkbox"> vor. Die Kennzeichnung einer teilweise aktivierten Checkbox mit der indeterminate-Eigenschaft ist nach der HTML-Spezifikation Extern, englischsprachig: eine reine visuelle Angelegenheit, d.h. in HTML gibt es keine semantische Auszeichnung für eine Tri-State-Checkbox.

Hinweis: Die Attribute role="checkbox" und aria-checked dürfen nach der ARIA-Spezifikation nicht auf eine HTML-Checkbox angewandt werden.

Weil die Darstellung von "teilweise aktiviert" semantisch mit HTML nicht möglich ist, muss eine Grafik für diesen Zustand eingesetzt werden. Die Grafik sollte als IMG mit leerem Alternativtext eingebunden werden. CSS-Techniken sollten für die Einbindung der Grafik vermieden werden, weil sie im Kontrastmodus Probleme verursachen können.

Mit den ARIA-Attributen role="checkbox" und aria-checked (mit den Werten "true", "false" oder "mixed") können HTML-Elemente als Checkboxen bestimmt werden. Die Rolle beeinflusst dabei die visuelle Darstellung oder die Funktionalität des HTML in keinster Weise. Vielmehr handelt es sich bei diesen ARIA-Attributen um Anweisungen an den Browser, wie die Semantik an den Intern: Accessibility-Tree übermittelt werden soll.

Über die Zuweisung der Semantik hinaus muss das Widget auch per Tastatur fokussiert werden können. Das wird durch ein tabindex="0" erreicht:

<p role="checkbox" aria-checked="false" tabindex="0">
  <img src="nicht-aktiviert.png" alt="">
  Ich esse Gemüse
</p>

Was in diesem Beispiel noch fehlt, ist das Event-Handling für Tastatur und Maus.

Event-Handling

Bevor eine barrierefreie Tri-State-Checkbox erzeugt wird, müssen folgende Voraussetzungen geschaffen werden:

  1. Eine Tri-State-Checkbox kann nicht mit einer HTML-Checkbox erzeugt werden. Anstelle der Checkbox müssen Grafiken eingesetzt werden, d.h. es sind drei Grafiken für die drei Zustände erforderlich.
  2. Das Widget selbst (das Element, an dem die Event-Handler gehängt werden) kann wie oben ein P-Element oder ein anderes (aber nicht beliebiges) Element sein. Bevor ein Element die Rolle einer Checkbox erhält, sollten die Extern, englischsprachig: Konformitätsbedingungen für den Einsatz von ARIA in HTML konsultiert werden.
  3. Bei einer Tri-State-Checkbox handelt es sich um eine Checkbox, die drei Zustände annehmen kann, und untergeordnete Optionen — z.B. HTML-Checkboxen. Sowohl die Tri-State-Checkbox als auch die zugehörigen Optionen benötigen Event-Handler:
    • wenn die Tri-State-Checkbox per Klick oder per Leertaste aktiviert oder deaktiviert wird, müssen die zugehörigen Optionen ebenfalls aktiviert bzw. deaktiviert werden
    • wenn die Optionen (z.B. Checkboxen) aktiviert oder deaktiviert werden, müssen alle Optionen durchlaufen werden, um zu bestimmen, ob die Tri-State-Checkbox einen aktivierten, einen nicht aktivierten oder einen teilweise aktivierten Zustand erhalten soll.

Es werden zwei gleichartige Beispiele als Demonstrationen bereitgestellt:

Weitere Features

Für Screenreader gibt es zwei weitere Aspekte, die berücksichtigt werden sollten:

  1. Wenn die Optionen einer Tri-State-Checkbox bedient werden, kann sich der Zustand der Tri-State-Checkbox ändern. Solche dynamischen Änderungen des Kontextes müssen nach den WCAG 2.0 angekündigt werden.
  2. In manchen Formularen stehen die einzelnen Formularbeschriftungen in einem Zusammenhang, z.B. mit einer Frage. Die Formularbeschriftungen sind ohne den Zusatztext nicht nachvollziehbar. Es ist also in manchen Situationen erforderlich, diese Beziehung technisch (und nicht nur visuell) herzustellen.

Änderung des Kontextes

Wenn Werte in einem Formular oder andere Inhalte auf einer Seite dynamisch geändert werden, dann erfährt ein Screenreadernutzer die Änderung nicht zwingend. Wenn dynamische Änderungen oben auf einer Seite und die Bedienung unten auf der Seite stattfindet, muss der Nutzer sich der Stelle mit den Änderungen bewusst sein und dorthin navigieren, um die geänderten Inhalte lesen zu können. Deshalb ist bei dynamischen änderungen der Nutzer über diese Möglichkeit textlich zu informieren. Die oben verlinkten Beispiele berücksichtigen diesen Aspekt.

Visuelle Beziehungen technisch abbilden

Eine Technik, für Formularelemente einen Kontext herzustellen, ist mit FIELDSET und LEGEND:

<fieldset>
  <legend>Welches Gemuese essen Sie?</legend>
    <p><input id="checkbox1" type="checkbox"><label for="checkbox1">Aubergine</label></p>
    <p><input id="checkbox2" type="checkbox"><label for="checkbox2">Moehren</label></p>
</fieldset>

Die Gruppenbeschriftung (Text im LEGEND-Element)wird dann den Formularbeschriftungen vorangestellt, z.B. "Welches Gemüse essen Sie? Aubergine". Je nach Screenreader wird die Gruppenbeschriftung vor jeder Formularbeschriftung oder nur bei der ersten Formularbeschriftung vorangestellt. Die Gruppenbeschriftung sollte deshalb kurz und präzise formuliert sein.