Was ist ein barrierefreies Layout im Web und auf Mobilgeräten?

Ein barrierefreies Layout bleibt bei jedem Zoom, jeder Bildschirmgröße und Ausrichtung bedienbar. So geht es, mit WCAG-Regeln und typischen Fehlern.

Was ist ein barrierefreies Layout?

Ein barrierefreies Layout ist eine Seiten- oder Bildschirmstruktur, die Menschen unabhängig von Fähigkeiten, Gerät oder Einstellungen lesen, durchlaufen und bedienen können. Die Inhalte stehen in logischer Reihenfolge, nichts bricht bei hohem Zoom oder auf kleinen Displays, und Bedienelemente lassen sich treffen. Es ist ein Teil der WCAG, auf die sich die meisten Gesetze und Ausschreibungen beziehen.

So funktioniert ein barrierefreies Layout

Die Grundlage sind die POUR-Prinzipien: wahrnehmbar, bedienbar, verständlich, robust.

  • Struktur im HTML, nicht nur im CSS. Nutzen Sie Landmarks (header, nav, main, footer) und eine echte Überschriftenhierarchie, damit Screenreader-Nutzer springen können. ARIA kommt nur dazu, wo native Elemente nicht reichen.
  • Lese- und Fokusreihenfolge folgen der visuellen Reihenfolge. Die Tab-Taste sollte der Blickrichtung folgen, siehe Reihenfolge der Tastaturnavigation. CSS Grid oder Flexbox können das unbemerkt zerstören.
  • Reflow. WCAG 2.2, Erfolgskriterium 1.4.10 (Stufe AA): Inhalte müssen bei einer Breite von 320 CSS-Pixeln (bzw. 256 CSS-Pixeln Höhe bei horizontalem Scrollen) ohne Informationsverlust und ohne zweidimensionales Scrollen darstellbar sein, außer bei Inhalten, die ein zweidimensionales Layout brauchen, etwa Karten oder Datentabellen.
  • Textgröße ändern. Kriterium 1.4.4 (AA): Text muss ohne Hilfstechnik bis auf 200 Prozent vergrößerbar sein, ohne Verlust von Inhalt oder Funktion.
  • Ausrichtung. Kriterium 1.3.4 (AA): Inhalte dürfen nicht auf Hoch- oder Querformat festgelegt sein, es sei denn, eine bestimmte Ausrichtung ist wesentlich.
  • Zielgröße. Kriterium 2.5.8 (AA, neu in WCAG 2.2) verlangt mindestens 24 mal 24 CSS-Pixel für Zeigerziele, mit Ausnahmen für ausreichenden Abstand, Links im Fließtext, gleichwertige Bedienelemente und vom Browser gesteuerte Elemente.

Beispiel

Eine Shopseite zeigt ein Produktraster mit Filter-Seitenleiste. Bei 320 CSS-Pixeln Breite wird die Leiste zu einem Button "Filter" über dem Raster, das Raster einspaltig, und die Seite scrollt nur vertikal. Die Tab-Reihenfolge lautet Kopfbereich, Filter, Produkte, Fußbereich. Bei 200 Prozent Zoom bleiben Preis und Button "In den Warenkorb" sichtbar und antippbar.

Häufige Fehler

  • Feste Breiten und Schriftgrößen in Pixeln, die beim Zoomen seitliches Scrollen erzwingen.
  • CSS-Reihenfolge, absolute Positionierung oder tabindex über 0, sodass die Fokusreihenfolge nicht mehr zum Bild passt.
  • Icon-Buttons und eng gesetzte Links unter 24 mal 24 CSS-Pixel.
  • Überschriften nach Größe statt nach Ebene gewählt.
  • Eine App oder Web-View ohne Grund auf eine Ausrichtung festgelegt.

Layout, Tests und Monitoring

Ein Layout geht bei einem Release leicht kaputt, also prüfen Sie es auf echten Viewports und wiederholt. Wer Mobile First entwirft, bekommt meist ein gutes Reflow. Automatische Tools finden nur einen Teil der Probleme und nicht, ob die Reihenfolge Sinn ergibt, daher gehört ein manueller Tastatur- und Zoomtest dazu. Das Page-Speed-Monitoring von LoadFocus führt geplante Lighthouse-Audits aus 25 Cloud-Regionen aus und verfolgt neben der Performance auch einen Accessibility-Score. Mehr dazu im Beitrag warum Performance-Tests Barrierefreiheit einschließen sollten.

Häufige Fragen zum barrierefreien Layout

Was bedeutet Reflow in den WCAG?

Inhalte passen sich einem schmalen Viewport von 320 CSS-Pixeln Breite an, ohne Informationsverlust und ohne gleichzeitiges vertikales und horizontales Scrollen. Karten, Datentabellen und ähnliche zweidimensionale Inhalte sind ausgenommen.

Ist ein responsives Layout automatisch barrierefrei?

Nein. Responsive Design löst die Bildschirmgröße, Barrierefreiheit braucht aber zusätzlich logische Lese- und Fokusreihenfolge, nutzbare Touch-Ziele, skalierbaren Text und sinnvolle Überschriften und Landmarks.

Wie groß sollten Touch-Ziele sein?

WCAG 2.2, Kriterium 2.5.8, verlangt mindestens 24 mal 24 CSS-Pixel, mit Ausnahmen wie ausreichendem Abstand oder Links im Satz. Größere Ziele sind auf dem Smartphone ein guter Standard.

Darf ich meine App auf Hochformat festlegen?

Nur wenn eine bestimmte Ausrichtung wesentlich ist (WCAG 1.3.4). Sonst unterstützen Sie beide, da manche Nutzer ihr Gerät fest montieren.

Welche WCAG-Stufe sollte ein Layout erfüllen?

Reflow, Textgröße, Ausrichtung und Zielgröße sind Stufe AA, die Stufe, die die meisten Gesetze und Verträge verlangen.

Wie schnell ist Ihre Website?

Steigern Sie ihre Geschwindigkeit und SEO nahtlos mit unserem kostenlosen Geschwindigkeitstest.

Kostenloser Websitespeed-Test

Analysieren Sie die Ladegeschwindigkeit Ihrer Website und verbessern Sie ihre Leistung mit unserem kostenlosen Seitengeschwindigkeits-Checker.