3 praktische Barrierefreiheits-Tipps zum sofortigen Einsatz

Manchmal muss es schnell gehen, weil eine Deadline heranrückt. Die Barrierefreiheit beim Code schreiben bleibt da oft etwas auf der Strecke. Diese drei Tipps helfen beim Schreiben von barrierefreiem Code, denn mit diesen UI-Patterns kann man den Code doch gleich barrierefrei machen.

Tipp 1: Dropdown Menüs

Dropdowns kommen auf Website sehr häufig vor und sind sehr beliebt. Oft können sie aber von Tastatur und/oder Screenreadernutzern nicht richtig bedient werden, da sie mit generischen Elementen wie <div> oder <span> gebaut wurden. Fixen bzw. verhindern kann man dies, indem man gleich das richige semantische markup verwendet und Elemente nimmt, die ihren Zweck an den Browser und assistive Technologien kommunzieren können. In diesem Fall sind das:
<button> für den Auslöser des Dropdown und <ul> für die Liste der Optionen.

Dazu müssen noch ARIA Attribute hinzugefügt werden, wie z. B. aria-expanded und aria-controls. Diese Attribute geben Screenreader zusätzlichen Kontext, also ob ein Menü offen oder zu ist und welches Element das Dropdown kontrolliert.

Beispiel-Code:

<button aria-haspopup="true" aria-expanded="false" aria-controls="menu1">Options</button>  
<ul id="menu1" role="menu" aria-hidden="true">  
  <li role="menuitem">Option 1</li>  
  <li role="menuitem">Option 2</li>  
</ul>  

Erklärung:

• Das <button> Element mit aria-haspopup="true" sagt assistiven Technologien, dass dieser Button ein Dropdown öffnet.
• Das Attribut aria-expanded="false" sagt dem Nutzer, dass das Menü momentan geschlossen ist. Dieser Wert verändert sich dynamisch auf „true“, wenn das Menü offen ist.
• Das <ul> tag mit der role="menu" stellt sicher, dass die Liste vom Screenreader als Menü erkannt wird.
• Jedes <li> Element hat die role="menuitem", so dass Screenreader diese Listeneinträge als Menü-Optionen behandeln.
• aria-hidden="true" versteckt das Menü, bis der Nutzer es aktiviert, dann sollte das Attrubut entfernt werden.

Diese kleinen Änderungen führen dazu, dass die Benutzer über die Tastatur mit Ihrem Dropdown interagieren können, und Screenreader eine Rückmeldung über den Zustand des Dropdowns erhalten.

Tipp 2: Modals

Auch Modals sind beliebt und praktisch, um z. B. weitere Informationen darzustellen oder für Eingaben durch den Nutzer, ohne von der Webseite weg navigieren zu müssen. Ohne das richtige Fokusmanagement kann das Bedienen per Tastatur oder mit Screenreadern schwierig sein.

Wenn ein Modal geöffnet wird, muss der Fokus im Modal sein und nicht auf der Webseite dahinter. Auch kann das Modal nicht mehr geschlossen werden, wenn sich der Fokus nicht darin befindet.

Der Schlüssel ist hier, den Fokus im Modal selbst zu „trappen“. Das heißt, wenn ein Modal geöffnet wird, sollte sich der Fokus nur darin bewegen, bis das Modal geschlossen wird, damit der Nutzer nicht aus Versehen aus dem Modal heraus navigiert und sich auch auf den Inhalt konzentrieren kann.

So eine „Focus-Trap“ kann man mit javascript anlegen, welches herausfindet, ob das Modal geöffnet oder geschlossen ist, und entsprechend den Fokus innen hält. Zusätzlich versorgen die Aria Attribute role=“dialog“ und aria-modal=“true“ Screenreader mit dem nötigen Kontext zur Rolle und des Verhaltens des Modals.

Beispiel-Code:

<div role="dialog" aria-modal="true" aria-labelledby="modal-title">  
    <h1 id="modal-title">Sign Up</h1>  
    <button>Close</button>  
    <!-- Modal content -->  
</div> 

Erklärung:

• role="dialog" informiert assistives Technologien darüber, dass es sich um ein Dialog Fenster handelt.
• aria-modal="true" stellt sicher, dass Screenreader verstehen, dass Nutzer nicht mit Content außerhalb des Modals interagieren können sollen, bis es geschlossen wird.
• aria-labelledby="modal-title" hilft Nutzern, den Zweck des Dialogs zu verstehen, indem es mit dem Titel des Modals verknüpft wird

FYI: Das HTML <dialog> Element liefert role="dialog" for free, aber man muss immer noch aria-modal="true" definieren, um sicherzustellen, dass Screenreader verstehen, dass Nutzer nicht mit Inhalten außerhalb des Modals interagieren können sollen, wenn das Modal geöffnet ist.

Benötigt: javascript

Zusätzlich sollte JavaScript zum Kontrollien des Fokus benutzt werden. Wenn das Modal sich öffnet, sollte der Fokus automatisch auf dem ersten interaktiven Element im Modal geschickt werden, z. B. auf einem Formularfeld oder einem Schließen-Button. Wenn der Nutzer die Tabtaste drückt, sollte der Fokus in einer Schleife durch die interaktiven Elemente gehen, ohne das Modal zu verlassen. Schließlich sollte das Drücken der Escape-Taste das Modal auch schließen, so wie auch der Schließen-Button. Wenn das Modal geschlossen wird, sollte der Fokus wieder auf dem Button sein, der das Modal geöffnet hat.

Tipp 3: Tab Panels (Registerkarten Interfaces)

Oberflächen mit Registerkarten sind eine Möglichkeit, Inhalte zu organisieren, ohne die Benutzer zu überwältigen, aber nur, wenn sie richtig strukturiert sind. Wenn die Registerkarten-Navigation nicht richtig aufgebaut ist, können Benutzer, die auf die Tastaturnavigation oder Screenreader angewiesen sind, Schwierigkeiten haben zu verstehen, welche Registerkarte ausgewählt ist und wie sie zwischen verschiedenen Abschnitten navigieren können.

Die Tab-Buttons bei Tab panels werden auch oft mit <div> oder <span> umgesetzt, welche keinen Kontext für assistive Technologien bieten. Ohne ARIA roles können Screenreader nicht mitteilen, dass ein Tabpanel ein Teil eines Tabpanel-Sets ist, und welcher Button zu welchem Tabpanel-Inhalt gehört. Dazu können Tastaturnutzer nicht mit den Pfeiltasten zwischen den Tab-Panels hin und her navigieren.

Lösen kann man das Problem mit einer Kombination von ARIA roles und -Eigenschaften. Role="tablist" definiert den Container für alle Tabpanels, role="tab" identifiziert jeden Tab und role="tabpanel” spezifiziert den Inhalt für jedes Tabpanel.

Beispiel-Code:

<div role="tablist" aria-label="Sample Tabs">  
  <button role="tab" aria-selected="true" aria-controls="panel1" id="tab1">Tab 1</button>  
  <button role="tab" aria-selected="false" aria-controls="panel2" id="tab2">Tab 2</button>  
</div>  
<div id="panel1" role="tabpanel" aria-labelledby="tab1">  
  <p>Content for Tab 1.</p>  
</div>  
<div id="panel2" role="tabpanel" aria-labelledby="tab2">  
  <p>Content for Tab 2.</p>  
</div> 

Erklärung:

• role="tablist" sagt dem Screenreader, dass der Container ein Set mit Tabs und Tabpanels enthält.
• Jeder Button mit role="tab" ist Teil der Tab-Liste und verlinkt zum jeweiligen Tabpanel-Inhalt, indem er aria-controls benutzt
• aria-selected="true" sagt aus, welcher Tab gerade aktiv ist. Nur bei einem Tab sollte dieser Wert „true“ sein.
• role="tabpanel" stellt sicher, dass Screen reader durch den Inhalt navigieren können. aria-labelledby verknüpft den Tabpanel-Inhalt zurück zum zugeordneten Tab für klaren Kontext.

Um die Zugänglichkeit per Tastatur sicherzustellen, sollten Benutzer mit den Pfeiltasten navigieren können. Der Fokus sollte auch deutlich machen, wo man sich gerade befindet. Mehr Info zu barrierefreien Tab-Interfaces kann man in der sehr guten Ressource von Inclusive Components (englisch) finden.

Zusammenfassung

Die Entwicklung barrierefreier UX patterns muss nicht kompliziert sein, aber sie erfordert etwas Liebe zum Detail und Einfühlungsvermögen. Ein ein paar kleine Änderungen – wie die Verwendung von semantischem HTML, das Hinzufügen von ARIA-Rollen und die korrekte Verwaltung des Fokus – können Oberflächen viel inklusiver machen. Wenn wir ein Web schaffen wollen, das für alle funktioniert, müssen wir der Barrierefreiheit bei jeder Entscheidung, die wir treffen, Vorrang einräumen.

Noch viel mehr Info zu Aria auch zu anderen Komponenten-Typen finden sich in den ARIA Authoring Practices Guide Patterns (englisch).

Quelle: https://piccalil.li/blog/practical-accessibility-tips-you-can-apply-today/