WCAG 1.3.2: Bedeutungstragende Reihenfolge

WCAG 1.3.2 verlangt, dass die Reihenfolge, in der Inhalte im Quelltext stehen, dem Sinn folgt – denn genau dieser Reihenfolge folgen Screenreader, Braillezeilen und der Tabulator. CSS darf frei anordnen, solange die Ausgabe für Hilfsmittel verständlich bleibt; erst wenn die Umsortierung den Sinn zerstört, ist das Kriterium verletzt.

(Englisch: Meaningful Sequence. Im BIK-BITV-Test heißt der Prüfschritt „1.3.2 Sinnvolle Reihenfolge“.)

Das Wichtigste in Kürze

• Maßgeblich ist die Quelltextreihenfolge, nicht das, was auf dem Bildschirm steht. Screenreader lesen das DOM von oben nach unten.
• Der BIK-BITV-Test prüft mit aktiviertem CSS, nicht mit abgeschaltetem. Der alte „Stylesheet aus“-Test ist ein Hilfsmittel, aber nicht der Maßstab.
• Nicht jede Abweichung ist ein Fehler. Eine bewusste Umsortierung ist zulässig, solange die Ausgabereihenfolge verständlich bleibt.
• Grid-Layouts sind laut Prüfschritt die häufigste Ursache – vor allem grid-area-Platzierungen, die Zellen frei verschieben.
• Beschriftung vor Feld ist der Klassiker unter den echten Verstößen: Wenn das Label im Quelltext nach dem Eingabefeld steht, stimmt die Zuordnung nicht mehr.
• Versteckte Inhalte gehören wirklich versteckt. Ausgeklappte Menüs und Akkordeoninhalte, die nur visuell verschwinden, bleiben für Screenreader lesbar und zerschießen die Reihenfolge.
• 1.3.2 und 2.4.3 sind Geschwister, aber nicht dasselbe: hier geht es ums Lesen, dort ums Fokussieren.
• Stufe A, seit WCAG 2.0 unverändert und über die EN 301 549 verbindlich.

Darf ich Inhalte per CSS umsortieren?

Nur solange die Quelltext-Reihenfolge weiter dem Sinn folgt – Screenreader, Braillezeile und Tabulator folgen dem DOM, nicht dem Layout.

Der Normtext sagt: Wenn die Reihenfolge, in der Inhalte präsentiert werden, ihre Bedeutung beeinflusst, muss die korrekte Lesereihenfolge programmatisch bestimmbar sein. Übersetzt heißt das: Der Quelltext muss die Geschichte in der Reihenfolge erzählen, in der sie Sinn ergibt.

Der Grund ist technisch simpel. Screenreader und Braillezeilen sehen kein Layout; sie arbeiten sich linear durch den Baum der Elemente. Was im Quelltext an dritter Stelle steht, kommt an dritter Stelle an – auch wenn es auf dem Bildschirm ganz oben prangt.

Ein Punkt, der 1.3.2 von der landläufigen Erklärung unterscheidet und im Prüfvorgehen des BIK-BITV-Tests ausdrücklich steht: Bewertet wird die Seite mit aktiviertem CSS. Der beliebte Test „Stylesheet abschalten und schauen, ob es noch Sinn ergibt“ ist als Werkzeug brauchbar, aber er ist nicht der Prüfmaßstab. Eine Seite darf im Quelltext eine andere Reihenfolge haben als auf dem Schirm, solange die Ausgabe für Hilfsmittel verständlich bleibt. Umgekehrt kann eine Seite den CSS-aus-Test bestehen und trotzdem durchfallen – etwa wenn ein Akkordeoninhalt nur optisch verborgen ist.

Damit sind drei Fallgruppen prüfrelevant:

Positionierung durch CSS. order in Flexbox, grid-area und grid-auto-flow: dense im Grid, absolute Positionierung, row-reverse. Der Prüfschritt nennt Grid-Layouts ausdrücklich als häufige Fehlerquelle, weil sich dort Zellen ohne jede Rücksicht auf den Quelltext platzieren lassen.

Zusammengehöriges, das auseinanderfällt. Überschrift und zugehöriger Text, Label und Eingabefeld, Bild und Bildunterschrift, Preis und Produktname. Wenn diese Paare im Quelltext auseinandergerissen werden, entsteht in der linearen Ausgabe Kauderwelsch.

Dynamisch verborgene Inhalte. Der Prüfschritt widmet dem einen eigenen Absatz: Elemente, die visuell ausgeblendet sind, müssen auch für Screenreader unzugänglich sein. Ein Dropdown, das mit opacity: 0 oder height: 0 verschwindet, bleibt im Lesefluss – und schiebt sich mitten in den Inhalt.

Der Normtext steht im Understanding-Dokument des W3C zu 1.3.2, das deutsche Prüfvorgehen im Prüfschritt „1.3.2 Sinnvolle Reihenfolge“.

Wen betrifft es besonders?

Screenreader-Nutzende merken einen Reihenfolgefehler nicht als Fehler. Sie hören einen Satz, der nicht passt, und suchen den Fehler bei sich – „habe ich etwas überhört?“. Das Tückische daran: Man zweifelt eher an sich selbst als am Fehler auf der Seite.

Braillezeilen-Nutzende trifft es noch direkter, weil sie den Text zeichenweise abtasten. Sie können nicht „drüberfliegen“ und aus dem Kontext raten; was in der falschen Reihenfolge steht, kommt in der falschen Reihenfolge an.

Tastaturnutzende sind indirekt betroffen: Die Tabulator-Reihenfolge folgt ebenfalls dem Quelltext. Ein Feld, das visuell links steht und im Quelltext zuletzt kommt, wird zuletzt fokussiert – das ist dann ein Fall für 2.4.3 Fokus-Reihenfolge, hat aber dieselbe Ursache.

Und schließlich alle, die mit starker Vergrößerung arbeiten. Sie sehen einen Ausschnitt von vielleicht einem Viertel des Bildschirms und folgen dem Fokus. Springt der quer über die Seite, weil das Layout die Reihenfolge umgestellt hat, verlieren sie bei jedem Sprung die Orientierung.

Richtig & falsch im Code

Der Klassiker aus jedem Produktlisting – der Preis wird visuell nach oben gezogen:

<!-- Ausgangslage: das DOM erzählt Name, Beschreibung, Preis -->
<article class="produkt">
  <h3>Ergonomische Tastatur</h3>
  <p class="beschreibung">Geteiltes Layout, mechanische Schalter.</p>
  <p class="preis">89 €</p>
</article>

/* Falsch: Der Preis rutscht visuell nach oben,
   im Quelltext bleibt er am Ende */
.produkt { display: flex; flex-direction: column; }
.produkt .preis { order: -1; }

<!-- Richtig: Reihenfolge im Quelltext ändern,
     CSS ordnet innerhalb dieser Logik -->
<article class="produkt">
  <h3>Ergonomische Tastatur</h3>
  <p class="preis">89 €</p>
  <p class="beschreibung">Geteiltes Layout, mechanische Schalter.</p>
</article>

Beim Grid ist die Falle subtiler, weil sie sich über grid-area und Zeilennummern versteckt:

/* Falsch: Die Seitenleiste steht im Quelltext vor dem Hauptinhalt,
   wird aber rechts platziert – gelesen wird sie trotzdem zuerst */
.layout { display: grid; grid-template-columns: 260px 1fr; }
.seitenleiste { grid-column: 2; }
.inhalt { grid-column: 1; }

/* Richtig: Hauptinhalt steht im Quelltext zuerst und wird
   per Media Query nach Bedarf verschoben */
.layout { display: grid; grid-template-columns: 1fr; }
@media (min-width: 60rem) {
  .layout { grid-template-columns: 1fr 260px; }
}

Der zweite große Block sind versteckte Inhalte. Hier trennt sich brauchbar von kaputt:

/* Falsch: nur optisch weg – Screenreader lesen weiter mit */
.menu-zu {
  opacity: 0;
  height: 0;
  overflow: hidden;
  pointer-events: none;
}

<!-- Falsch: sichtbarer Text, der für Hilfsmittel ausgeblendet wird –
     der umgekehrte Fehler, ebenso häufig -->
<p class="hinweis" aria-hidden="true">Nur noch 2 Plätze frei.</p>

<!-- Richtig: hidden entfernt das Element aus beiden Welten -->
<ul id="untermenue" hidden>
  <li><a href="/produkte/tastaturen.html">Tastaturen</a></li>
</ul>

<!-- Richtig: nur visuell versteckt, absichtlich vorlesbar -->
<label for="suche" class="visually-hidden">Website durchsuchen</label>
<input type="search" id="suche" name="q" />

Die Regel dahinter lässt sich in einem Satz sagen: Erst den Quelltext in Sinn-Reihenfolge schreiben, dann layouten. Wenn ein Entwurf zwingend eine andere visuelle Ordnung verlangt, ist meistens das Markup falsch herum aufgebaut – das Umsortieren kostet weniger als die dauerhafte Doppelerzählung. Mehr dazu unter „div-soup“ vermeiden und Landmarks & Outline.

So testest du es

1. Mit aktiviertem CSS prüfen – das ist der Maßstab des Prüfschritts. Die Seite in Chrome oder Firefox öffnen und die Elementreihenfolge im Quelltext ansehen.
2. Linear lesen lassen. Mit NVDA im Lesemodus mit der Pfeiltaste nach unten durch kritische Bereiche gehen: Karten, mehrspaltige Layouts, Formulare, Produktlisten.
3. Auf die Paare achten: Steht jedes Label vor seinem Feld? Jede Überschrift vor ihrem Abschnitt? Jede Bildunterschrift beim Bild?
4. Ausgeklappte Bereiche schließen und dann lesen. Tauchen Menüpunkte, Akkordeoninhalte oder Dialogtexte auf, die eigentlich zu sein müssten? Dann sind sie nur optisch versteckt.
5. Im CSS gezielt suchen. Jedes order, jedes grid-area, jedes row-reverse und jedes position: absolute ist ein Prüfkandidat – nicht automatisch ein Fehler, aber eine Stelle zum Hinsehen.
6. Den Linearisierungs-Test als Gegenprobe nutzen. Die Web Developer Toolbar in Firefox kann die Seite linearisieren; das zeigt schnell, wo Layouttabellen oder Grids den Fluss zerlegen.
7. Bei Responsive-Layouts alle Bruchpunkte durchgehen. Viele Reihenfolgefehler entstehen nur in einer Breite – oft in der mittleren, die niemand testet.

Häufiger Fehler in der Praxis

Der häufigste echte Verstoß ist das Label nach dem Feld. In Formularen mit schwebenden Beschriftungen wird das Label oft hinter das Eingabefeld gesetzt, weil sich die CSS-Animation so einfacher bauen lässt. Optisch stimmt alles, in der Ausgabe kommt erst das leere Feld und dann seine Beschriftung. Wenn zusätzlich das for-Attribut fehlt, ist es gleich ein Fall für 3.3.2 Beschriftungen oder Anweisungen und Labels & Beschriftungen.

Der zweite ist das Grid, das im Entwurf entstanden ist. Ein Designwerkzeug liefert die Anordnung, jemand baut sie mit grid-area nach – und der Quelltext bekommt die Reihenfolge, in der die Kästen im Entwurf angelegt wurden. Das ist Zufall, keine Logik. Ich würd bei jedem Grid-Layout einmal den Quelltext durchlesen, bevor die Seite live geht; das dauert zwei Minuten und findet zuverlässig die Stellen, an denen die Seitenleiste vor dem Artikel steht.

Der dritte ist der Mobile-First-Rest. Für die schmale Ansicht wird eine Reihenfolge gebaut, für die breite per order eine andere – und niemand prüft, ob die Quelltextreihenfolge in beiden Fällen tragfähig ist. Besonders gern trifft es den Filterbereich in Shops, der mobil unten und am Desktop links steht.

Und der vierte, der in Selbstchecks nie auffällt: das halb versteckte Menü. Das Untermenü ist geschlossen, aber nur mit opacity: 0 und pointer-events: none weggeblendet. Für Screenreader ist es voll lesbar und schiebt sich mitten in die Navigation. Der Prüfschritt nennt genau dieses Muster – die Lösung ist hidden oder display: none, nicht Transparenz.

Häufige Fragen

Muss die Quelltextreihenfolge exakt der visuellen entsprechen?

Nein. Der Prüfschritt hält ausdrücklich fest, dass bewusste Abweichungen zulässig sind, solange die Ausgabereihenfolge verständlich bleibt. Ein Beispiel: Ein Bildbereich, der visuell rechts steht, aber im Quelltext nach dem Text kommt, ist unproblematisch. Kritisch wird es erst, wenn zusammengehörige Inhalte auseinander gerissen werden oder die Aussage kippt.

Ist der Test „CSS abschalten“ noch gültig?

Als Werkzeug ja, als Maßstab nein. Der BIK-BITV-Test bewertet die Seite mit aktiviertem CSS. Der CSS-aus-Test findet zuverlässig grobe Umsortierungen, übersieht aber genau das Problem, das heute häufiger ist: Inhalte, die nur optisch versteckt sind und trotzdem gelesen werden.

Verstößt flex-direction: row-reverse gegen 1.3.2?

Nicht automatisch. Bei einer Reihe gleichwertiger Elemente – etwa Logos oder Sozialmedien-Icons – trägt die Reihenfolge keine Bedeutung, und das Umdrehen ist folgenlos. Sobald die Reihenfolge Bedeutung hat, etwa bei Schritten eines Ablaufs oder bei Vorher-Nachher-Paaren, wird daraus ein Verstoß.

Was ist der Unterschied zu 2.4.3 Fokus-Reihenfolge?

1.3.2 betrifft das Lesen aller Inhalte, 2.4.3 das Fokussieren der bedienbaren Elemente. Beide folgen normalerweise dem Quelltext, weshalb dieselbe Ursache oft beide Kriterien reißt. Getrennt bewertet werden sie trotzdem: Eine Seite kann eine saubere Fokusreihenfolge und trotzdem eine unlesbare Textreihenfolge haben.

Wie verstecke ich Inhalte richtig?

Für „ganz weg“: das hidden-Attribut oder display: none – beides entfernt das Element aus Layout und Ausgabe. Für „nur optisch weg, aber vorlesbar“: eine visually-hidden-Klasse mit Clip-Technik, wie sie für Skip-Links und versteckte Labels üblich ist. Nicht geeignet sind opacity: 0, height: 0 und visibility ohne Zusatz.

Verwandte Themen

• 2.4.3 Fokus-Reihenfolge – dasselbe Prinzip für die Tastatur
• 1.3.1 Info und Beziehungen – Struktur im Markup statt im Layout
• „div-soup“ vermeiden – ein sauberes DOM als Ausgangspunkt
• Landmarks & Outline – die grobe Gliederung, die vor der Reihenfolge kommt
• Labels & Beschriftungen – Label vor Feld, mit sauberer Verknüpfung
• Mit NVDA testen – linear durch die Seite lesen lassen