WCAG 1.3.4: Ausrichtung

WCAG 1.3.4 verlangt, dass sich Inhalte nicht auf eine einzige Bildschirmausrichtung beschränken – Hochformat und Querformat müssen beide bedienbar sein, es sei denn, eine bestimmte Ausrichtung ist für die Funktion unverzichtbar. Verboten sind damit Sperren im Manifest, „Bitte drehen Sie Ihr Gerät“-Overlays und Inhalte, die in einer Ausrichtung abgeschnitten oder unbedienbar sind.

(Englisch: Orientation. Der BIK-BITV-Test nennt den Prüfschritt „Keine Beschränkung der Bildschirmausrichtung“.)

Das Wichtigste in Kürze

• Beide Ausrichtungen müssen funktionieren – nicht identisch aussehen. Ein anderes Layout im Querformat ist ausdrücklich erwünscht, solange alles erreichbar bleibt.
• Eine dynamische Anpassung ist nicht verlangt. Der Prüfschritt lässt zu, dass der Inhalt in der neuen Ausrichtung neu geladen wird.
• Media Queries auf orientation sind erlaubt, um zu optimieren – nicht, um eine Ausrichtung zu sperren.
• Die Ausnahme ist eng: Nur wenn eine Ausrichtung für die Funktion unverzichtbar ist – Klavier-App, Scheck-Scan, Präsentationsfolien, bestimmte VR-Anwendungen.
• Der häufigste Grund für das Kriterium sind fest montierte Geräte: Tablets am Rollstuhl, am Bettgestell, an der Halterung. Sie lassen sich nicht drehen.
• Wer viel vergrößert, arbeitet im Querformat. Bei starkem Zoom passt in eine breite, flache Zeile schlicht mehr Text.
• Geprüft wird auf einem echten Gerät mit ausgeschalteter Rotationssperre – der Emulator der DevTools reicht dem Prüfschritt nicht.
• Häufigste Fundstellen: progressive Web-Apps mit orientation im Manifest, Videoplayer im Vollbild, Signaturfelder, Spiele-Einbettungen und Modals, die im Querformat nicht scrollen.

Darf ich Hochformat erzwingen?

Nein – Inhalte müssen in Hoch- und Querformat bedienbar bleiben, es sei denn, eine bestimmte Ausrichtung ist für die Funktion unverzichtbar.

Der Normtext ist knapp: Der Inhalt beschränkt seine Darstellung und Bedienung nicht auf eine einzige Bildschirmausrichtung – außer die Ausrichtung ist unverzichtbar. Drei Dinge fallen darunter, und sie sehen im Code sehr unterschiedlich aus.

Die harte Sperre. In einer progressiven Web-App ein "orientation": "portrait" im Manifest, oder ein Aufruf der Screen-Orientation-API. Das Gerät kann sich drehen, die Anwendung dreht sich nicht mit.

Die weiche Sperre. Ein Overlay, das im Querformat erscheint und zum Drehen auffordert. Technisch dreht sich alles, praktisch ist der Inhalt weg. Der Prüfschritt bewertet das ausdrücklich als „nicht erfüllt“: Eine Meldung, die zum Wechsel der Ausrichtung auffordert, ist ein Verstoß.

Der kaputte Inhalt. Kein Overlay, keine Sperre – aber im Querformat ist die Fußzeile mit dem Absenden-Knopf nicht erreichbar, das Modal lässt sich nicht scrollen, das Video liegt halb außerhalb des Bildes. Das ist der Fall, den man beim Entwickeln am ehesten übersieht.

Zwei Klarstellungen aus dem Prüfschritt helfen bei der Bewertung:

Eine dynamische Anpassung ist nicht Pflicht. Es wird nicht verlangt, dass sich das Layout beim Drehen live umbaut. Der Inhalt darf in der neuen Ausrichtung neu geladen werden – Hauptsache, er funktioniert dort.

Alternative Darstellungen sind zulässig. Inhalte dürfen in einer Ausrichtung über Ausklappbereiche oder Verweise angeboten werden, statt vollständig sichtbar zu sein. Was zählt, ist die Erreichbarkeit.

Und die Ausnahme: „unverzichtbar“ meint, dass die Funktion ohne die feste Ausrichtung verloren ginge. Der Prüfschritt nennt als Beispiele einen Bankscheck, den man zum Einlesen quer halten muss, ein Online-Klavier, Präsentationsfolien und Virtual-Reality-Anwendungen. Ein Formular gehört nicht dazu, ein Onlineshop erst recht nicht.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 1.3.4; das deutsche Prüfvorgehen beschreibt der Prüfschritt 1.3.4 des BIK BITV-Tests.

Wen betrifft es besonders?

Menschen, deren Gerät fest montiert ist, sind der Anlass für dieses Kriterium. Bei vielen motorischen Einschränkungen sitzt das Tablet in einer Halterung am Elektrorollstuhl, am Bett oder am Schreibtischarm – in genau einer Ausrichtung, ausgerichtet auf Blickwinkel und Reichweite. Die Aufforderung, das Gerät zu drehen, lässt sich nicht befolgen. Für diese Nutzer ist ein „Bitte drehen“-Overlay keine Unbequemlichkeit, sondern das Ende des Vorgangs.

Wer stark vergrößert, bevorzugt oft das Querformat – aus einem simplen Grund: Bei großer Schrift passen in eine breite Zeile mehr Wörter, und man muss seltener zeilenweise horizontal scrollen. Der Prüfschritt nennt das ausdrücklich als Begründung.

Menschen mit eingeschränkter Handmotorik oder mit nur einer nutzbaren Hand halten das Gerät so, wie sie es greifen können. Ein Handy im Querformat lässt sich mit beiden Daumen bedienen, ein Handy im Hochformat einhändig – welche Haltung möglich ist, entscheidet nicht die App.

Und die situative Gruppe: alle, die im Liegen lesen (das Gerät folgt dem Kopf, nicht umgekehrt), die eine Tastaturhülle nutzen, die das Handy in einer Autohalterung haben oder deren Rotationssperre gerade aktiv ist.

Richtig & falsch im Code

Die klassische Sperre steht im Manifest der Web-App. Sie fällt bei einem Audit sofort auf – man muss nur hineinschauen:

// Falsch: erzwungene Ausrichtung in manifest.webmanifest
{
  "name": "Terminportal",
  "display": "standalone",
  "orientation": "portrait"
}

// Richtig: keine Vorgabe – das Gerät entscheidet
{
  "name": "Terminportal",
  "display": "standalone"
}

Die zweite Variante versteckt sich im CSS. Sie ist verbreiteter, weil sie oft als Notlösung entsteht: „Im Querformat sieht es kaputt aus, also blenden wir es aus.“

/* Falsch: Inhalt im Querformat ausblenden und zum Drehen auffordern */
@media (orientation: landscape) {
  .app-inhalt { display: none; }
  .bitte-drehen { display: block; }
}

/* Richtig: die Ausrichtung nutzen, statt sie zu verbieten */
@media (orientation: landscape) and (max-height: 30rem) {
  .kopfbereich { position: static; } /* klebt nicht mehr, spart Höhe */
  .formular { grid-template-columns: 1fr 1fr; }
}

Auch die Screen-Orientation-API gehört auf die Verbotsliste:

// Falsch: Ausrichtung per JavaScript festnageln
await screen.orientation.lock('portrait');

// Richtig: gar nicht sperren. Wenn das Layout in einer Ausrichtung
// klemmt, ist das ein Layout-Problem, kein Ausrichtungsproblem.

Der eigentliche Aufwand liegt selten in der Sperre, sondern im Layout. Querformat heißt: viel Breite, wenig Höhe. Zwei Muster lösen die meisten Fälle:

/* Klebende Leisten kosten im Querformat den meisten Platz */
@media (max-height: 26rem) {
  .site-header { position: static; }
  .cookie-banner { max-block-size: 60vh; overflow-y: auto; }
}

/* Dialoge müssen scrollen können, statt oben und unten abzuschneiden */
.modal {
  max-block-size: 90dvh;
  overflow-y: auto;
}

Die Einheit dvh (dynamic viewport height) ist hier wichtiger als sie aussieht: Sie berücksichtigt die ein- und ausfahrenden Browserleisten auf Mobilgeräten, wo vh regelmäßig zu große Werte liefert. Wer 1.4.10 Reflow sauber umgesetzt hat, bekommt 1.3.4 in der Regel geschenkt: Querformat ist nur ein anderer Ausschnitt desselben flexiblen Layouts.

So testest du es

1. Ein echtes Mobilgerät nehmen. Der Prüfschritt verlangt Chrome unter Android oder Safari unter iOS auf einem aktuellen Gerät. Der Geräteemulator in den DevTools zeigt das Layout, nicht das Verhalten des Betriebssystems.
2. Die Rotationssperre ausschalten. Sonst testest du nur, ob dein Gerät sich dreht – ein überraschend häufiger Fehlschluss.
3. Die Seite in der ersten Ausrichtung laden und Darstellung wie Bedienung prüfen: Ist alles sichtbar, lesbar, erreichbar?
4. Um 90 Grad drehen und neu laden. Dasselbe noch einmal prüfen. Dass sich das Layout beim Drehen live umbaut, ist nicht verlangt – dass es nach dem Neuladen funktioniert, schon.
5. Nach Aufforderungen zum Drehen suchen. Overlays, Hinweistexte, Weiterleitungen auf eine andere Ansicht. Jede davon ist ein Befund.
6. Ins Manifest schauen. orientation im manifest.webmanifest, ein screen.orientation.lock() im JavaScript, eine orientation-Media-Query mit display: none im CSS – drei Suchen, drei mögliche Funde.
7. Die kritischen Seiten gezielt im Querformat prüfen: Formulare, Dialoge, Cookie-Banner, Videoplayer im Vollbild, Bezahlseiten. Dort ist die Höhe knapp und der Fokus schnell verdeckt.

Häufiger Fehler in der Praxis

Der auffälligste Fall ist das „Bitte drehen“-Overlay, und es entsteht fast immer aus guter Absicht: Das Querformat sah unfertig aus, die Zeit war knapp, also wurde es abgeschaltet statt repariert. Das Muster stammt aus nativen Apps und Spielen, wo es Konvention ist. Im Web ist es ein AA-Verstoß – und für jemanden mit fest montiertem Tablet die Endstation.

Der zweite ist das orientation-Feld im Manifest, das niemand mehr auf dem Schirm hat. Es wurde beim Anlegen der PWA gesetzt, weil ein Beispiel im Netz es so hatte, und steht seitdem dort. Ich würd dir raten, das Manifest bei jedem Audit einmal zu öffnen – die Suche dauert zehn Sekunden und findet regelmäßig etwas.

Der dritte ist der Dialog ohne Bildlauf. Im Hochformat passt das Modal bequem auf den Schirm, im Querformat ragen Überschrift und Absenden-Knopf oben und unten heraus – und weil overflow: hidden gesetzt ist, kommt man nicht heran. Der Inhalt ist da, die Bedienung nicht. Genau das meint der Normtext mit „Bedienbarkeit“.

Und ein Grenzfall, der oft falsch bewertet wird: Ein Video, das im Vollbild ins Querformat wechselt, ist kein Verstoß – das macht der Player des Betriebssystems, und der Nutzer hat den Vollbildmodus selbst ausgelöst. Ein Verstoß wäre es, wenn die Seite drumherum sich weigert, im Querformat zu arbeiten.

Häufige Fragen

Darf ich Media Queries auf orientation verwenden?

Ja, uneingeschränkt – solange du damit optimierst statt sperrst. Im Querformat zweispaltig zu layouten, klebende Leisten zu lösen oder Abstände zu reduzieren, ist genau der erwünschte Umgang. Unzulässig ist erst die Kombination aus @media (orientation: landscape) und display: none für den eigentlichen Inhalt.

Muss sich das Layout beim Drehen automatisch anpassen?

Nein. Der Prüfschritt hält ausdrücklich fest, dass keine dynamische Anpassung verlangt wird – der Inhalt darf in der neuen Ausrichtung neu geladen werden. Entscheidend ist allein, dass er dort vollständig darstellbar und bedienbar ist.

Wann ist eine feste Ausrichtung wirklich unverzichtbar?

Wenn die Funktion ohne sie verloren geht. Genannt werden das Einlesen eines Bankschecks, ein Online-Klavier, Präsentationsfolien und bestimmte Virtual-Reality-Anwendungen. Der Maßstab ist die Funktion, nicht das Design: „Sieht im Querformat nicht so gut aus“ ist keine Ausnahme.

Gilt 1.3.4 auch für Desktop-Browser?

Praktisch spielt es dort kaum eine Rolle, weil Monitore nicht gedreht werden – außer sie sind hochkant montiert, was in der Entwicklung durchaus vorkommt. Wer ein flexibles Layout baut, deckt diesen Fall ohnehin mit ab. Der Prüfschritt testet ausdrücklich auf Mobilgeräten.

Was ist mit dem Vollbildmodus eines Videos?

Wenn der Player des Geräts beim Vollbild ins Querformat wechselt, ist das kein Verstoß gegen 1.3.4 – der Wechsel wurde vom Nutzer ausgelöst und vom System umgesetzt. Ein Befund entsteht erst, wenn die Seite selbst eine Ausrichtung erzwingt oder im Querformat unbedienbar wird.

Verwandte Themen

• 1.4.10 Reflow – flexible Layouts als gemeinsame Lösung
• 1.4.4 Textgröße ändern – warum viele Nutzer im Querformat lesen
• 2.4.11 Fokus nicht verdeckt – klebende Leisten bei wenig Höhe
• Reflow, Zoom & Textabstände – die Praxisseite dazu
• Motorische Einschränkungen – warum Geräte fest montiert sind