Welche Schwierigkeiten ergeben sich bei der barrierefreien Gestaltung (Accessibility) mit den Standard-Komponenten von Foundation?

Melden

Obwohl Foundation for Sites (von ZURB) ab Version 6 explizit mit dem Fokus auf Barrierefreiheit (A11y) entwickelt wurde, ergeben sich in der Praxis dennoch einige Schwierigkeiten. Diese liegen oft im Zusammenspiel zwischen den automatisierten Funktionen des Frameworks und der individuellen Implementierung.

Hier sind die zentralen Schwierigkeiten bei der barrierefreien Gestaltung mit Foundation-Standard-Komponenten:

1. Fokus-Management bei komplexen Komponenten

Foundation bietet integrierte ARIA-Attribute für Komponenten wie Modals (Reveal), Tabs oder Accordions. Das Problem:

  • Initialer Fokus: Wenn sich ein Modal (Reveal) öffnet, wird der Fokus nicht immer zuverlässig auf das erste interaktive Element gesetzt.
  • Focus Trapping: In älteren Versionen oder bei Fehlkonfigurationen kann der Tab-Fokus aus dem Modal heraus in den Hintergrund "entwischen", was für Screenreader-Nutzer extrem desorientierend ist.
  • Rücksprung-Punkt: Nach dem Schließen einer Komponente muss der Fokus exakt auf das auslösende Element zurückspringen. Bei dynamisch nachgeladenen Inhalten verliert Foundation diesen Kontext oft.

2. Automatische vs. Manuelle ARIA-Attribute

Foundation fügt via JavaScript viele ARIA-Attribute (wie aria-expanded, aria-hidden, role="tablist") automatisch hinzu.

  • Synchronisationsfehler: Wenn Entwickler den DOM manuell verändern (z. B. durch Vue, React oder einfaches jQuery), ohne die Foundation-eigenen Methoden zu nutzen, geraten die ARIA-Zustände aus dem Takt. Ein Menü wird optisch ausgeblendet, aber für den Screenreader bleibt aria-expanded="true".
  • Überfrachtung: Foundation neigt dazu, sehr viele Rollen zu vergeben. Wenn ein Entwickler zusätzlich eigene Rollen definiert, kann es zu Konflikten kommen, die Screenreader verwirren.

3. Tastaturnavigation in Menüs (Navigation Patterns)

Foundation bietet verschiedene Menü-Typen (Dropdown, Drilldown, Accordion).

  • Erwartungshaltung: Nutzer erwarten bei Dropdown-Menüs oft die Steuerung über Pfeiltasten (nach WAI-ARIA Authoring Practices). Foundation nutzt jedoch primär die Tab-Taste zur Navigation. Das entspricht zwar den Basis-Standards, ist aber für Power-User oft nicht das "erwartete" Verhalten eines App-Menüs.
  • Drilldown-Menü: Das Drilldown-Menü (häufig für Mobile genutzt) ist schwer barrierefrei umzusetzen, da der visuelle Kontextwechsel (Hineinsliden in Untermenüs) für blinde Nutzer nur schwer über die reine Ansage von "Eingeklappt/Ausgeklappt" vermittelbar ist.

4. Visuelle Barrierefreiheit (Kontraste & Focus States)

  • Default-Styles: Die Standard-Farben von Foundation (z. B. das helle Blau für Buttons oder das Grau für Texte) erfüllen in der Basiskonfiguration nicht immer die strengen Kontrastanforderungen der WCAG 2.1 AA (mindestens 4,5:1).
  • Focus Outline: Wie viele Frameworks neigt Foundation dazu, die Standard-Fokus-Umrandung (Outline) der Browser zu unterdrücken oder durch sehr dezente Styles zu ersetzen. Für Nutzer mit Sehbehinderung, die auf Tastaturnavigation angewiesen sind, ist der "Focus Indicator" dann oft unsichtbar.

5. Semantisches HTML vs. Framework-Logik

Entwickler neigen dazu, die Klassen von Foundation auf beliebige Elemente anzuwenden.

  • Beispiel: Ein <a>-Tag wird als Button gestylt (class="button"). Foundation fügt zwar oft role="button" hinzu, aber die native Funktionalität eines Buttons (Aktivierung durch die Leertaste) muss bei einem Link manuell via JS nachgerüstet werden. Foundation löst das nicht immer konsistent für alle Komponenten.
  • Div-Suppe: Um komplexe Layouts (Grid) zu bauen, werden oft viele verschachtelte <div>-Container genutzt, was die semantische Struktur für Screenreader verwässern kann, wenn nicht konsequent Landmark-Roles (header, main, nav, etc.) eingesetzt werden.

6. Fehlertoleranz bei dynamischen Inhalten

Foundation initialisiert seine JavaScript-Plugins beim Laden der Seite.

  • Wenn Inhalte via AJAX nachgeladen werden (z.B. neue Formularfelder oder Tooltips), müssen die Accessibility-Funktionen für diese Elemente manuell neu initialisiert werden (Foundation.reInit()). Wird dies vergessen, sind diese neuen Elemente für assistierende Technologien oft "tot" oder unbeschriftet.

7. Tooltips und Overlays

Die Standard-Tooltips von Foundation sind für Screenreader oft problematisch:

  • Sie erscheinen meist bei hover oder focus.
  • Schwierigkeit: Sie sind oft nicht "dismissible" (mit der ESC-Taste schließbar) oder "hoverable" (man kann nicht mit der Maus über den Tooltip fahren, ohne dass er verschwindet), was gegen neuere WCAG-Erfolgskriterien verstößt.

Fazit und Empfehlung

Foundation ist im Vergleich zu vielen anderen Frameworks "out-of-the-box" sehr weit, was Barrierefreiheit angeht. Die größten Schwierigkeiten entstehen jedoch durch:

  1. Zu viel Vertrauen darauf, dass das Framework alles regelt.
  2. Mangelnde Anpassung der Standard-Kontraste und Fokus-Styles.
  3. Fehlerhafte DOM-Manipulationen, die die ARIA-Logik des Frameworks aushebeln.

Tipp: Nutzen Sie Tools wie Axe oder WAVE, um Foundation-Projekte zu prüfen, und verlassen Sie sich niemals darauf, dass die Komponente allein durch das Hinzufügen der CSS-Klasse barrierefrei ist. Jede interaktive Komponente muss manuell mit der Tastatur und einem Screenreader getestet werden.