Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Abgedunkelte Inhalte muss keiner lesen

Modale und barrierefreie Dialogfenster

Abgedunkelte Inhalte muss keiner lesen

Mit Accessible Rich Internet Applications (ARIA) 1.1 werden einige neue Rollen und Attribute eingeführt, die für die barrierefreie Frontend-Entwicklung wichtig sind. Eines dieser Attribute ist aria-modal, das signalisiert, ob ein Dialogfenster modal ist oder nicht. Mit diesem Attribut könnt ihr die barrierefreie Nutzung von Dialogfenstern in einem Screenreader verbessern.

Modalfenster im Web zeichnen sich dadurch aus, dass der Inhalt einer Webseite leicht abgedunkelt wird und andere Inhalte im Vordergrund stehen. Die abgedunkelten Inhalte sind inaktiv und normalerweise können Nutzer im vordergründigen Inhalt etwas eingeben oder auswählen.

Vergrößertes modale Darstellung von Peter Stöger mit der Bildbeschriftung: Erfolgreicher Start als BVB-Trainer
Vergrößerte modale Darstellung von Peter Stöger mit der Bildbeschriftung: Erfolgreicher Start als BVB-Trainer

Das Problem bei Modalfenstern ist oft, dass sie zwar mit der Maus gut funktionieren, aber mit der Tastatur oder mit einem Screenreader stoßen Nutzer schnell auf Barrieren. Häufig sind solche Probleme auf ein fehlendes Fokus-Management zurückzuführen. Unbedacht kann ein Modalfenster zulassen, dass das Drücken der Tab-Taste den Fokus in den inaktiven Bereich der Seite führt und unsichtbar wird. Allerdings könnt ihr mit wenigen Zeilen Code den Fokus im Modalfenster »einsperren« (siehe unten).

Hinzu kommt die Nutzung in Screenreadern, die ebenfalls optimiert werden muss. Screenreader verfügen über verschiedene Modi. In einem Lesemodus orientieren sich Screenreader an den Document Object Model (DOM). Genauer gesagt werden Inhalte und Semantik aus dem DOM vom Browser über eine Accessibility-API an den Accessibility-Tree des Betriebssystems geschickt. Hilfsmittel wie Screenreader, Vergrößerungssysteme oder Spracheingaben holen die Informationen vom Accessibility-Tree ab und bereiten daraus eine alternative Benutzungsschnittstelle auf.

Im Fall von Modalfenstern ist es oft so, dass die abgedunkelten Inhalte per Maus und Tastatur nicht zugänglich sind, aber immer noch im DOM stehen und an den Accessibility-Tree geschickt werden. Dadurch sind viele Modalfenster mit einem Screenreader kaum auffindbar – das Modalfenster steht »irgendwo« auf der Seite. Eine Maßnahme, die ihr ergreifen könnt, damit ein Modalfenster mit einem Screenreader sofort aufgespürt werden kann, ist den Fokus auf das Modalfenster zu setzen, sobald das Modalfenster geöffnet wird. Allerdings gibt es bei der Sache einen Haken: Obwohl Screenreadernutzer die Tastatur intensiv einsetzen, so wird per Tab-Taste nicht unbedingt navigiert, denn Screenreader bieten eine alternative Benutzungsschnittstelle z.B. mit der strukturellen Navigation.

Im Lesemodus bieten Screenreader bei unzähligen Tasten Sonderfunktionen, damit Nutzer effizienter auf Webseiten navigieren können. Beispielsweise wird mit der Taste »H« in vielen Screenreadern die nächste Überschrift und mit der Taste »F« das nächste Formularelement angesprungen. Die Pfeiltasten werden ebenfalls von Screenreadern »gekapert« und das Drücken dieser Tasten führt das aus, was der Screenreader dafür vorsieht (und nicht was der Browser oder ein Skript auf der Webseite damit beabsichtigt). Wenn ihr also Inhalte nur abdunkelt, sie aber nicht vor Screenreadern versteckt, bleiben diese Inhalte im Screenreader zugänglich und navigierbar. Es ist natürlich ohne Weiteres möglich, dass ein Modalfenster dann nicht einmal bemerkt wird, weil es am Anfang oder am Ende des DOM eingefügt wird, während der Fokus ganz woanders steht.

Die Lösung des Problems ist, die Weitergabe der abgedunkelten Inhalte an den Accessibility-Tree zu unterbinden. Bisher musstet ihr dafür die abgedunkelten Inhalte mit aria-hidden-Attributen vor dem Accessibility-Tree verbergen (und bei Schließen des Modalfensters wieder zugänglich machen). Zukünftig reicht die Zuweisung eines aria-modal-Attributs auf das Element mit der Rolle »dialog« aus, und das Verstecken der abgedunkelten Inhalte mit aria-hidden ist nicht mehr notwendig.

Zweckmäßigkeit von Modalfenstern

Da Modalfenster in vielen Fällen eine »Unterbrechung« bedeuten, indem der Kontext der Webseite nicht mehr unmittelbar gegeben ist, sind sie mit Bedacht einzusetzen. Eine Bildergalerie oder eine Eingabemaske sind oft sinnvoll in einem Modalfenster darzustellen, aber die Notwendigkeit eines Modalfensters muss immer in Frage gestellt werden. Im Prinzip muss gelten: Das Modalfenster sollte in sich aussagekräftig sein; außerdem muss ein Modalfenster eine eindeutige Schließfunktion besitzen, damit Nutzer zur Webseite bzw. zur Webanwendung zurückkehren können.

In diesem Beitrag geht es insbesondere um die Kriterien für ein barrierefreies, modales Dialogfenster. Die Entwicklung eines Plug-ins für welche JavaScript-Bibliothek auch immer ist nicht beabsichtigt; vielmehr geht es darum, dass ihr ein Gefühl für die Barrierefreiheit von Widgets bekommt. Idealerweise könnt ihr die Barrierefreiheit euerer Modalfenster nachher selbst überprüfen. Am Ende des Beitrags gibt es einen Link auf ein funktionierendes Beispiel mit einem komplexen Modalfenster.

Dieser Beitrag setzt auf das erst in ARIA 1.1 spezifizierte Attribut aria-modal. Dieses Attribut muss nicht zwingend für Modalfenster eingesetzt werden, denn es gibt andere Techniken, um einen Teilinhalt als vordergründig zu markieren. Das aria-modal-Attribut ist aber derzeit eine einfache Möglichkeit, Modalfenster barrierefreier zu machen.

Verschiedene Dialogfenster

Modalfenster im Web werden seit vielen Jahren mit HTML simuliert und bestehen im einfachsten Fall aus zwei div-Elementen sowie dem Inhalt des Modalfensters. Ein »echtes« Fenster ist zwar in der aktuellen HTML-Spezifikation beschrieben, allerdings unterstützen nicht alle Browser dieses Feature.

ARIA fügt Semantik zu den div-Konstrukten hinzu, so dass Hilfsmittel wie Screenreader die Inhalte als vordergründig identifizieren können. Dabei gibt es zwei Arten von Dialogen, die ihr beide mit ARIA auszeichnen solltet:

  1. Dialogfenster sind nachgelagerte Fenster zum primären Fenster einer Webanwendung oder einer Webseite, die vom Nutzer jederzeit geschlossen werden können. Das primäre Fenster wird im Allgemeinen durch das body-Element repräsentiert. Dialogfenster sind meist, müssen aber nicht modal sein. Ihr solltet Dialogfenstern die Rolle »dialog« zuweisen und sie einsetzen, wenn ihr eine Eingabe oder eine Reaktion vom Nutzer erwartet.
  2. Meldungsfenster sind solche Dialogfenster, die die volle Aufmerksamkeit des Nutzers beanspruchen, um in einem Prozess fortzufahren. Sie werden modal gestaltet und werden erst dann geschlossen, wenn der Nutzer eine Option aktiviert (z.B. »Fortfahren« oder »Abbrechen«). Ihr solltet Meldungsfenstern eine Rolle »alertdialog« zuweisen und außerdem den Fokus darauf setzen, sobald das Fenster geöffnet wird.

Wenn ein Dialog- oder Meldungsfenster modal eingesetzt wird, könnt ihr es zusätzlich mit dem aria-modal-Attribut kennzeichnen, damit Screenreader und andere Hilfsmittel die vordergründigen Inhalte entsprechend behandeln können (z.B. indem sie den abgedunkelten Inhalt im Lesemodus ignorieren). Das Attribut darf nur auf Elemente angewandt werden, die die Rolle »dialog« oder »alertdialog« besitzen.

Wichtig: ARIA-Attribute beeinflussen weder die Gestaltung noch das Verhalten im Browser. Sie dienen ausschließlich dazu, dem Browser mitzuteilen, was an den Accessibility-Tree weitergegeben wird.

Nach der aktuellen HTML-Spezifikation kann außerdem das dialog-Element für ein Dialogfenster eingesetzt werden, allerdings unterstützen Browser die Zugänglichkeit aktuell (Dezember 2017) kaum.

Ausschnitt einer Kompatibilitätstabelle; Element dialog wird nur von Chrome unterstützt
Ausschnitt einer Kompatibilitätstabelle; Element dialog wird nur von Chrome unterstützt

Die Übermittlung der erforderlichen Informationen an den Accessibility-Tree ist derzeit nur auf Chrome/Opera für das dialog-Element gegeben, aber nicht in Edge, Firefox oder Safari.

Wie viele andere ARIA-Attribute auch, ist die Vergabe der Rolle »dialog« eine Art Übergangslösung. Bis Browser das native HTML auf einer zugänglichkeitsunterstützenden Weise implementiert haben solltet ihr ARIA einsetzen.

Die wichtigste Regel beim Einsatz von ARIA ist aber: Wenn es mit HTML geht, dann muss auf ARIA verzichtet werden. Wenn also Browser das dialog-Element unterstützen, dann dürft ihr die Rolle »dialog« nicht auf das dialog-Element anwenden. Das dialog-Element besitzt bereits die implizite Rolle »dialog«.

Was macht ein Modalfenster barrierefrei?

Es gibt einige Kriterien der Barrierefreiheit, die bei Modalfenstern besonders beachtet werden sollten und leider oft vergessen oder unvollständig umgesetzt werden. Natürlich gibt es zahlreiche weitere Anforderungen aus den Web Content Accessibility Guidelines (WCAG) 2.0 bzw. der Barrierefreien Informationstechnik-Verordnung – BITV 2.0, die ihr auf Modalfenster genauso wie auf andere Inhalte anwenden solltet, aber diese stehen hier nicht im Mittelpunkt.

Damit euere Modalfenster barrierefrei werden, müsst ihr folgende vier Aspekte berücksichtigen:

1. Die Semantik des Modalfensters muss stimmen.

Das Element, das für das Modalfenster eingesetzt wird, benötigt insbesondere eine Rolle und einen Namen. Die Rolle könnt ihr mit dem role-Attribut bestimmen. Wenn das Modalfenster eine sichtbare Beschriftung hat, dann solltet ihr das Modalfenster mit aria-labelledby beschriften:

  1. <div role="dialog" aria-labelledby="modalTitle">
  2. <h1 id="modalTitle">Beschriftung des Modalfensters</h1>
  3. <!-- Eingabemasken o.ä. -->
  4. </div>

Besitzt das Modalfenster keine Beschriftung, so solltet ihr das Modalfenster mit aria-label direkt bezeichnen:

  1. <div role="dialog" aria-label="Beschriftung des Modalfensters">
  2. <!-- Eingabemasken o.ä. -->
  3. </div>

Rolle und Name werden im Accessibility-Tree des Betriebssystems abgelegt und Hilfsmittel wie Screenreader holen die Informationen dort ab. In den beiden vorhergehenden Beispielen sollten Hilfsmittel das div-Element anhand der Rolle und des Namens identifizieren.

2. Inaktive Inhalte müssen für alle deaktiviert sein

Inaktive (abgedunkelte) Inhalte sollten für Screenreader und andere Hilfsmittel als hintergründig gekennzeichnet werden, d.h. ihr müsst dem Browser mitteilen, dass die inaktiven Inhalte nicht an den Accessibility-Tree des Betriebssystems übertragen werden dürfen. Ein allgemeines Attribut, um Inhalte generell zu deaktivieren, bietet HTML nicht. Es gibt nur ARIA-Attribute, die ihr hierfür einsetzen könnt.

Die bisherige Technik mit aria-hidden

Um abgedunkelte Inhalte hinter einem Modalfenster vor Hilfsmitteln zu verstecken, musstet ihr bislang ein Konstrukt wie das Folgende wählen:

  1. <body>
  2. <div role="dialog" aria-label=" Beschriftung des Modalfensters" style="z-index:2;">Inhalte des Modalfensters </div>
  3. <div class="opacity" style="z-index:1;"></div>
  4. <div id="inhalt" aria-hidden="true"> Inhalte der Seite</div>
  5. </body>

Das aria-hidden-Attribut mit einem Wert »true« entfernt einen Knoten samt Kindknoten aus dem Accessibility-Tree – endgültig! Das war in der Praxis manchmal verwirrend. Mit dem folgenden Aufbau wird zwar der Inhalt vor dem Accessibility-Tree verborgen, aber das Modalfenster bleibt ebenfalls unzugänglich:

  1. <!-- Bitte nicht benutzen, der Code ist nicht barrierefrei. -->
  2. <body>
  3. <div class="opacity" style="z-index:1;"></div>
  4. <div id="inhalt" aria-hidden="true">
  5.   Inhalte der Seite
  6.   <div role="dialog" aria-label=" Beschriftung des Modalfensters" aria-hidden="false" style="z-index:2;">Inhalte des Modalfensters </div>
  7. </div>
  8. </body>

Erhält ein Knoten einmal ein aria-hidden="true", sind alle Kindknoten vom Accessibility-Tree ausgeschlossen; das aria-hidden="false" hat im vorherigen Beispiel keine Auswirkungen auf die Barrierefreiheit. Das div-Element für das Modalfenster muss auf gleicher oder höherer Ebene in der DOM-Hierarchie stehen im Vergleich zum abgedunkelten Inhalt.

Die neue Technik mit aria-modal

Mit ARIA 1.1 wurde das aria-modal-Attribut für HTML und SVG eingeführt. Es kann die Werte »true« oder »false« erhalten. Wenn der Wert auf »true« gesetzt ist, soll der Inhalt von Hilfsmitteln als vordergründig zu anderen Inhalten behandelt werden.

  1. <body>
  2. <div id="opacity" style="z-index:1;"></div>
  3. <div role="dialog" aria-modal="true;" aria-label=" Beschriftung des Modalfensters" style="z-index:2;"> Inhalte des Modalfensters </div>
  4. <div id="inhalt">Inhalte der Seite</div>
  5. </body>

Hinweis: Folgendes solltet ihr bei Modalfenstern mit aria-modal beachten:

  • Alle aktiven Elemente des Modalfensters müssen tatsächliche Kindelemente des Elements mit der Rolle »dialog« sein.
  • Elemente außerhalb des Elements mit der Rolle aria-modal werden nicht als vordergründig behandelt.
  • Auch bei anderen (nicht modalen) Dialogfenstern sollten alle Inhalte Kindelemente des Elements mit der Rolle »dialog« sein, denn die richtige Zuordnung mit dem aria-owns-Attribut funktioniert noch nicht zuverlässig in den verschiedenen Browser-Screenreader-Kombinationen.
Ansicht von Iaccessible2: Neben Name und Rolle ist auch der Status modal erkennbar
Ansicht von Iaccessible2: Neben Name und Rolle ist auch der Status modal erkennbar

3. Das Modalfenster muss mit der Tastatur bedient werden können

Wichtig: Die Tastaturbedienung ist unabhängig von Screenreadern und betrifft die reine Browserfunktionalität. Das hat nichts mit einem Screenreader zu tun, denn bei Fokus auf einem aktiven Element reichen Screenreader das Drücken der Tab-Taste durch an den Browser. Das heißt auch, dass die hintergründigen Inhalte per Tab-Taste erreicht werden können – mit oder ohne Screenreader. Es spielt dabei keine Rolle, ob ein Modalfenster ein aria-modal="true" besitzt oder nicht.

Zunächst müsst ihr sicherstellen, dass alle aktiven Elemente innerhalb des Modalfensters auch per Tastatur zugänglich sind. Anschließend müsst ihr die Fokus-Reihenfolge auf die aktiven Elemente innerhalb des Modalfensters beschränken, um zu verhindern, dass der Fokus per Tab-Taste in den abgedunkelten Bereich der Seite gebracht werden kann und (wahrscheinlich) keinen sichtbaren Fokus mehr hat. Schließlich gibt es noch einige Best-Practice-Empfehlungen für die Tastaturbedienung.

Per Tastatur zugänglich

Ob ein Modalfenster per Tastatur zugänglich ist, könnt ihr leicht mit der Tab-Taste überprüfen. Aber nicht nur müssen alle aktiven Elemente innerhalb eines Modalfensters per Tab-Taste erreicht werden können, sondern sie müssen aktiviert (bei Buttons oder Links) und bedient (z.B. bei Auswahllisten) werden können.

Ein häufiges Problem bei Modalfenstern ist beispielsweise, dass ein Schließen-Button nicht fokussierbar ist:

  1. <div role="dialog" aria-modal="true" aria-labelledby="modalTitle">
  2. <h1 id="modalTitle">Beschriftung des Modalfensters</h1>
  3. <span id="modalClose" onclick="modalClose()">X</span>
  4. <!-- Eingabemasken o.ä. -->
  5. </div>

Für sehende Mausnutzer dürfte das »X« ausreichend intuitiv bedienbar sein, aber für Tastaturnutzer ist das span-Element nicht fokussierbar. Natürlich macht ein tabindex="0" das span-Element fokussierbar, aber das Element besitzt immer noch keine Rolle (z.B. role="button") und auch keine beschreibende Beschriftung (z.B. »Modalfenster schließen«). Daher solltet ihr statt den ungenügenden Code zu »reparieren« gleich ein Element einsetzen, das neben der Tastaturbedienbarkeit auch eine passende Rolle aufweist, und das Element mit einem beschreibenden Text beschriften :

  1. <div role="dialog" aria-modal="true" aria-labelledby="modalTitle">
  2. <h1 id="modalTitle">Beschriftung des Modalfensters</h1>
  3. <p><button id="modalClose" onclick="modalClose()">Modalfenster schließen</button></p>
  4. <!-- Eingabemasken o.ä. -->
  5. </div>
Sichtbarer Fokus

Wenn ihr die Tastaturbedienung innerhalb des Modalfensters sichergestellt habt, müsst ihr die inaktiven (abgedunkelten) Inhalte aus der Fokus-Reihenfolge entfernen. Dabei gibt es verschiedene Strategien, um das zu bewerkstelligen.

Ihr könnt auf ein Event-Handling setzen, das den Fokus innerhalb des Modalfensters »einsperrt«. Hierzu haben verschiedene Accessibility-Evangelisten ihren Code bereits in den Ring geworfen. Insbesondere möchte ich auf einen Beitrag von Nicholas Zakas aus dem Jahr 2013 hinweisen, der eine einfache Lösung beschreibt.

Auch Scott O'Hara hat sich dem Thema angenommen und bietet funktionierende Scripts für ein tastaturbedienbares Modalfenster.

Weiteres Event-Handling innerhalb des Modalfensters

Grundsätzlich kann auf ein Event-Handling für Tastendrücke nicht verzichtet werden. Insbesondere sollte das Dialogfenster durch Drücken der Esc-Taste jederzeit geschlossen werden können. Falls der Fokus nicht innerhalb des Modalfensters »eingesperrt« wird, müssen außerdem das Drücken der Tab-Taste und der Tastenkombination Umschalt+Tab-Taste berücksichtigt werden.

Tastendrücke für Dialogfenster
TastendruckErläuterung
Escschließt das Modalfenster (entspricht »Abbrechen«)
Tabführt zum nächsten aktiven Element, aber beim letzten Element innerhalb des Modalfensters führt dieser Tastendruck zum ersten aktiven Element innerhalb des Modalfensters.
Umschalt+Tabführt zum vorherigen aktiven Element, aber beim ersten Element innerhalb des Modalfensters führt dieser Tastendruck zum letzten aktiven Element innerhalb des Modalfensters.

Eine Entscheidung, die ihr für eine Dialoggestaltung treffen müsst, ist ob die Fokus-Reihenfolge innerhalb der Dialogfenster zirkulieren soll oder nicht. Für Meldungsfenster ist die Einsperrung des Fokus sinnvoll, solange Nutzer vor einer Ja/Nein-Entscheidung gestellt werden. Bei sonstigen Modalfenstern mit der Rolle »dialog« führt eine zirkulierende Fokus-Reihenfolge dazu, dass die Adress- und Werkzeugleisten des Browsers nicht in der Fokus-Reihenfolge stehen. Für die weniger versierten Tastaturnutzer könnte die zirkulierende Fokus-Reihenfolge deshalb irritierend sein. Allerdings gibt es zahlreiche andere Tastendrücke, die gleiche Funktionen ausführen, und die Tab-Taste ist »nur« eine von mehreren alternativen Tastendrücken.

Beim Öffnen und Schließen des Modalfensters den Fokus managen

Sowohl wenn ein Modalfenster geöffnet wird, als auch wenn es wieder geschlossen wird, solltet ihr den Fokus steuern.

Beim Öffnen eines Modalfensters sollte der Fokus auf ein Element im Dialogfenster gesetzt werden. Je nach Inhalt des Modalfensters kann das zu fokussierende Element unterschiedlich sein:

  1. Im Allgemeinen solltet ihr dem ersten fokussierbaren Element innerhalb des Modalfensters den Fokus mit el.focus() geben.
  2. Wenn der Inhalt des Modalfensters so groß ist, dass das Fokussieren des ersten aktiven Elements Inhalte nach oben außerhalb des Browserfensters schiebt, dann solltet ihr die Beschriftung oder den ersten sichtbaren Text des Modalfensters mit einem tabindex="-1" ergänzen und den Fokus darauf setzen.
  3. Wenn das erste fokussierbare Element innerhalb des Modalfensters eine nicht rückgängig zu machende Aktion auslösen kann (z.B. der Abschluss eines Vertrags oder das endgültige Löschen eines Kontos), dann solltet ihr ein Element mit geringeren Auswirkungen für den Fokus bevorzugen.
  4. Sofern das Modalfenster nur eine Bestätigung erfordern (z.B. in einem Meldungsfenster), könnt ihr den Fokus auch auf ein Element setzen, das wahrscheinlich aktiviert wird (z.B. »Weiter«).

Wenn das Modalfenster geschlossen wird, solltet ihr den Fokus ebenfalls managen. Normalerweise solltet ihr den Fokus auf das ursprünglich zum Aufruf des Modalfensters genutzte Element setzen. In einem Beitrag beschreibt Marco Zehe sehr plastisch, warum das wichtig ist. Falls das nicht geht (z.B. weil das Element nicht mehr im DOM steht), dann solltet ihr den Fokus auf ein Element setzen, wo ein Nutzer vernünftigerweise weiterarbeiten wird.

Schlussbemerkungen

In den WAI-ARIA Authoring practices findet ihr ein Best-Practice-Beispiel für ein Modalfenster mit aria-modal. Sofern ihr Widgets entwickelt, gehört die Seite zu euren Bookmarks, denn dort findet ihr genaue Anleitungen, Anforderungen und Beispiele für barrierefreie Widgets.

Das Best-Practice-Beispiel für Modalfenster haben wir übrigens im Dezember mit den Screenreadern JAWS 2018 und NVDA 2017.4 auf Internet Explorer, Chrome und Firefox getestet. Das Ergebnis war weitgehend zufriedenstellend, d.h. im Lesemodus präsentierten die beiden Screenreader nur das Modalfenster. Im Einzelnen:

  • JAWS mit Internet Explorer unterstützt aria-modal offenbar nicht, denn die Hintergrundinformationen blieben im Lesemodus zugänglich.
  • Mit Firefox und Chrome muss die Esc-Taste gedrückt werden, um in den Lesemodus zu wechseln. Grundsätzlich stellt das aber kein Problem dar.

Je mehr ihr euch mit barrierefreien Widgets befasst, desto mehr werdet ihr feststellen, dass das nicht so simpel ist:

  1. Traut niemals der Aussage, etwas sei barrierefrei. Ihr müsst das jedesmal überprüfen, wenn ihr ein Plug-in herunterladet.
  2. Das ARIA-Testing findet nicht im Browser, sondern vor allem im Accessibility-Tree statt.
  3. Besser noch ist ein Testing mit verschiedenen Browser-Screenreader-Kombinationen – macht euch für die neuen Herausforderungen bereit.

Das solltet ihr auch lesen

Die Kommentare sind geschlossen.