WCAG 1.3.4: Ausrichtung

WCAG 1.3.4 Ausrichtung verlangt, dass Inhalte ihre Ansicht und Bedienung nicht auf eine einzige Bildschirmausrichtung wie Hoch- oder Querformat beschränken, es sei denn, eine bestimmte Ausrichtung ist wesentlich. Dieses Kriterium stellt sicher, dass Nutzer, die ihre Geräte nicht physisch drehen können – etwa Personen mit fest montierten Tablets oder motorischen Beeinträchtigungen – weiterhin auf alle Inhalte zugreifen können.

Was diese Regel bedeutet

WCAG 1.3.4 Orientation ist ein Kriterium der Stufe AA, das in WCAG 2.1 eingeführt und in WCAG 2.2 fortgeführt wurde. Es besagt, dass Inhalte nicht auf eine einzige Anzeigeausrichtung – entweder Hochformat (vertikal) oder Querformat (horizontal) – festgelegt werden dürfen, es sei denn, diese spezifische Ausrichtung ist für die Funktion des Inhalts wesentlich. In der Praxis bedeutet dies, dass Webseiten und webbasierte Anwendungen korrekt reagieren und vollständig bedienbar bleiben müssen, unabhängig davon, ob das Gerät der Nutzerin oder des Nutzers vertikal oder horizontal gehalten wird oder ob die Ausrichtung durch das Betriebssystem des Geräts oder durch die eigenen Einstellungen der Nutzerin oder des Nutzers gesteuert wird.

Das Kriterium zielt auf Situationen ab, in denen Entwicklerinnen und Entwickler CSS-Media-Queries, JavaScript oder Geräte-APIs verwenden, um Inhalte bewusst auf eine Ausrichtung zu beschränken. Ein häufiger Verstoß ist die Anzeige einer Meldung wie „Bitte drehen Sie Ihr Gerät ins Querformat“, während gleichzeitig alle interaktiven Inhalte im Hochformat ausgeblendet oder deaktiviert werden. Ein weiterer Verstoß liegt vor, wenn eine Webanwendung eine CSS-Transformation anwendet oder den Viewport zwangsweise dreht und damit die Ausrichtungseinstellung des Geräts der Nutzerin oder des Nutzers überschreibt.

Was als erfüllt gilt: Inhalte sind sowohl im Hoch- als auch im Querformat zugänglich. Sämtlicher Text, alle interaktiven Elemente, Formulare, Navigation und Medien bleiben sichtbar und bedienbar, unabhängig davon, wie das Gerät ausgerichtet ist. Das Layout darf sich anpassen – etwa durch responsive Design-Techniken wie CSS Flexbox, CSS Grid oder Media Queries –, aber nichts wird allein aufgrund der Ausrichtung entfernt oder unbedienbar gemacht.

Was als nicht erfüllt gilt: Inhalte, die in einer Ausrichtung Interaktion verbergen, deaktivieren oder blockieren; Meldungen, die Nutzerinnen und Nutzer auffordern, ihr Gerät zu drehen, ohne eine funktionierende Alternative bereitzustellen; JavaScript, das auf DeviceOrientationEvent oder screen.orientation hört und anschließend Teile der Benutzeroberfläche sperrt oder deaktiviert; oder CSS, das @media (orientation: portrait) verwendet, um eine blockierende Overlay-Ebene anzuzeigen oder display: none auf kritische Inhalte anzuwenden.

Die wesentliche Ausnahme: WCAG erkennt an, dass einige Inhalte einen inhärent ausrichtungsspezifischen Zweck haben. Eine Klaviertastatur-Anwendung kann legitimerweise das Querformat erfordern, weil ein Layout im Hochformat nicht genügend Tasten darstellen kann, um musikalisch sinnvoll zu sein. Eine Funktion zur Einzahlung von Bankschecks, die darauf angewiesen ist, dass die Kamera einen horizontalen Scheck erfasst, kann das Querformat erfordern. Eine Benutzeroberfläche für ein Virtual-Reality-Headset kann eine feste Ausrichtung benötigen, um zu funktionieren. Die Hürde für „wesentlich“ ist jedoch hoch – bloße Bequemlichkeit der Entwicklerinnen und Entwickler oder ästhetische Vorlieben qualifizieren sich nicht. Die Ausnahme muss durch eine grundlegende Anforderung des Inhalts selbst gerechtfertigt sein, nicht durch eine Designentscheidung.

Warum es wichtig ist

Ausrichtungsbeschränkungen betreffen Menschen mit körperlichen und motorischen Behinderungen überproportional stark. Man denke an eine Rollstuhlnutzerin oder einen Rollstuhlnutzer, deren oder dessen Tablet in einer festen Hochformatposition an der Armlehne des Stuhls montiert ist. Sie oder er kann das Gerät nicht physisch kippen, sodass alle Inhalte, die das Querformat erfordern, vollständig unzugänglich werden. Dies ist kein hypothetischer Randfall – das Montieren von Assistenztechnologie-Geräten in festen Ausrichtungen ist eine gängige Anpassung für Menschen mit Erkrankungen wie Zerebralparese, Rückenmarksverletzungen, ALS oder schwerer Arthritis.

Über montierte Geräte hinaus verlassen sich viele Nutzerinnen und Nutzer aus Gründen, die nichts mit einer Behinderung zu tun haben, auf die Ausrichtungssperre des Betriebssystems. Eine Person, die im Bett liegt, kann ihr Telefon auf Hochformat sperren, um zu verhindern, dass der Bildschirm ständig rotiert. Eine Person mit vestibulärer Störung – einer Erkrankung des Innenohrs und des Gleichgewichts – kann plötzliche Layoutwechsel durch Ausrichtungsänderungen als desorientierend oder körperlich Übelkeit auslösend empfinden. Diese Nutzerinnen und Nutzer zu zwingen, die Ausrichtungssperre ihres Geräts zu deaktivieren, um auf Ihre Inhalte zuzugreifen, schafft eine unnötige und diskriminierende Barriere.

Kognitive Zugänglichkeit ist ebenfalls ein Faktor. Menschen mit kognitiven Beeinträchtigungen profitieren häufig von konsistenten, vorhersehbaren Layouts. Eine Anwendung, die plötzlich Inhalte blockiert oder eine fehlerähnliche Meldung anzeigt, in der um das Drehen des Geräts gebeten wird, kann verwirrend und beunruhigend sein – insbesondere für Nutzerinnen und Nutzer, die möglicherweise nicht verstehen, warum ihr Gerät eine Warnung statt der erwarteten Inhalte anzeigt.

Aus Nutzbarkeits- und Geschäftsperspektive schaden Ausrichtungsbeschränkungen allen Nutzerinnen und Nutzern. Ein erheblicher Teil des mobilen Web-Traffics findet im Hochformat statt, und die Beschränkung einer Website auf das Querformat kann zu sofortigem Abbruch führen. Suchmaschinen berücksichtigen zunehmend Mobilfreundlichkeit und Core Web Vitals – einschließlich stabilen Layoutverhaltens – in ihren Ranking-Algorithmen, was bedeutet, dass ausrichtungsbezogene Probleme messbare negative Auswirkungen auf die SEO-Performance und den organischen Traffic haben können.

Weltweit leben laut Weltgesundheitsorganisation etwa 1,3 Milliarden Menschen mit irgendeiner Form von Behinderung. Ein bedeutender Teil dieser Gruppe nutzt mobile Geräte als primäres oder einziges Mittel zum Zugang zum Internet, was die Zugänglichkeit in Bezug auf die mobile Ausrichtung besonders bedeutsam macht.

Wie man testet

Führen Sie einen automatisierten Scan als Ausgangsbasis durch: Öffnen Sie die Seite in Chrome, Firefox oder Edge. Verwenden Sie die Browsererweiterung axe DevTools oder führen Sie ein Lighthouse-Accessibility-Audit durch, um eine Ausgangsbasis zu schaffen. Auch wenn diese Tools Ausrichtungsverstöße nicht direkt erkennen, können sie auf verwandte Probleme im Responsive Design, auf Probleme mit dem Viewport-Meta-Tag oder auf fehlende ARIA-Hinweise aufmerksam machen, die Ausrichtungsprobleme bei der Barrierefreiheit verstärken. Beachten Sie, dass ein sauberer automatisierter Bericht keine Konformität mit 1.3.4 bestätigt.
Verwenden Sie die Geräteemulation der Browser-Entwicklertools: Öffnen Sie in Chrome oder Edge die DevTools (F12), klicken Sie auf das Gerätesymbol in der Toolbar (Strg+Umschalt+M / Cmd+Umschalt+M) und wählen Sie ein mobiles Gerät wie iPhone 14 oder Galaxy S21. Wechseln Sie mit dem Rotationssymbol in der Gerätetoolbar zwischen Hoch- und Querformat. Überprüfen Sie systematisch, dass alle Inhalte – Navigation, Überschriften, Fließtext, Formulare, Schaltflächen, Bilder und Medien – in beiden Ausrichtungen sichtbar und bedienbar bleiben. Achten Sie auf blockierende Overlays, versteckte Bereiche oder deaktivierte interaktive Elemente, die in einer Ausrichtung erscheinen, in der anderen jedoch nicht.
Testen Sie auf realen Geräten: Schließen Sie ein Android- oder iOS-Gerät an und öffnen Sie die Seite im mobilen Browser. Drehen Sie das Gerät physisch zwischen Hoch- und Querformat. Vergewissern Sie sich, dass die Ausrichtungssperre des Betriebssystems (falls aktiviert) nicht dazu führt, dass Inhalte fehlerhaft dargestellt werden oder eine Drehaufforderung erscheint. Testen Sie mit aktivierter und deaktivierter Ausrichtungssperre.
Screenreader-Tests mit Ausrichtungssimulation: Aktivieren Sie auf iOS VoiceOver (dreifacher Klick auf die Seitentaste) und navigieren Sie im Hochformat mit Wischgesten durch die Seite. Drehen Sie dann ins Querformat und prüfen Sie, ob die Lesereihenfolge von VoiceOver und die zugänglichen Namen weiterhin korrekt sind. Führen Sie denselben Test auf Android mit TalkBack durch. Verwenden Sie NVDA mit Firefox auf dem Desktop und simulieren Sie die Ausrichtung über die DevTools, um sicherzustellen, dass der Accessibility-Tree in allen Ausrichtungen konsistent ist.
Untersuchen Sie CSS und JavaScript auf Ausrichtungsbeschränkungen: Öffnen Sie in den DevTools das Panel „Sources“ oder „Elements“ und durchsuchen Sie das Stylesheet nach Media Queries orientation: portrait und orientation: landscape. Prüfen Sie, was jeder Block bewirkt: Blendet er Inhalte mit display: none aus, zeigt er ein blockierendes Overlay an oder passt er lediglich das Layout an? Durchsuchen Sie JavaScript-Dateien nach screen.orientation, orientationchange und screen.orientation.lock. Bewerten Sie, ob gefundene Muster die Benutzeroberfläche sperren oder Inhalte blockieren.
Überprüfen Sie die wesentliche Ausnahme: Wenn die Website die Ausrichtung absichtlich einschränkt, vergewissern Sie sich, dass ein dokumentierter, gerechtfertigter wesentlicher Anwendungsfall vorliegt. Die Ausnahme muss inhaltlich begründet sein, nicht kosmetisch. Dokumentieren Sie Ihre Feststellung mit einem Screenshot und der konkreten Begründung.

Wie man es behebt

CSS-blockierendes Overlay im Hochformat – Falsch

<!-- A full-screen overlay shown only in portrait that blocks all content -->
<style>
  .rotate-prompt {
    display: none;
    position: fixed;
    inset: 0;
    background: #fff;
    z-index: 9999;
    text-align: center;
    padding: 2rem;
  }
  @media (orientation: portrait) {
    .rotate-prompt {
      display: flex; /* blocks all underlying content */
    }
  }
</style>
<div class='rotate-prompt'>
  <p>Please rotate your device to landscape mode.</p>
</div>
<main id='app-content'>
  <!-- All application content here -->
</main>

CSS-blockierendes Overlay im Hochformat – Richtig

<!-- Remove the blocking overlay entirely. Use responsive CSS to adapt the layout instead. -->
<style>
  /* Portrait layout: stack elements vertically */
  @media (orientation: portrait) {
    .dashboard-grid {
      grid-template-columns: 1fr;
    }
  }
  /* Landscape layout: side-by-side columns */
  @media (orientation: landscape) {
    .dashboard-grid {
      grid-template-columns: 1fr 1fr;
    }
  }
</style>
<main id='app-content'>
  <div class='dashboard-grid'>
    <!-- Content adapts layout but is always accessible -->
  </div>
</main>

JavaScript-Ausrichtungssperre – Falsch

<script>
  // Locks screen to landscape and shows an error if it fails (e.g. on iOS)
  screen.orientation.lock('landscape').catch(function() {
    document.getElementById('orientation-error').style.display = 'block';
    document.getElementById('main-content').style.display = 'none';
  });
</script>
<div id='orientation-error' style='display:none'>
  This application only works in landscape mode.
</div>
<div id='main-content'>
  <!-- Application content -->
</div>

JavaScript-Ausrichtungssperre – Richtig

<script>
  /*
    Do not lock orientation via JavaScript.
    Instead, listen for orientation changes and adapt the UI
    without hiding or disabling content.
  */
  window.addEventListener('orientationchange', function() {
    var isPortrait = window.matchMedia('(orientation: portrait)').matches;
    // Adjust layout class for styling only — never hide content
    document.body.classList.toggle('portrait-layout', isPortrait);
    document.body.classList.toggle('landscape-layout', !isPortrait);
  });
</script>
<div id='main-content'>
  <!-- All content remains visible and operable in both orientations -->
</div>

Viewport-Meta-Tag, das Ausrichtungswechsel verhindert – Falsch

<!-- Some older implementations tried to fix orientation via viewport -->
<meta name='viewport' content='width=device-width, initial-scale=1, user-scalable=no'>
<!--
  While 'user-scalable=no' does not directly lock orientation,
  combining it with CSS transforms that rotate the viewport
  is a known anti-pattern that creates orientation accessibility failures.
-->
<style>
  /* Anti-pattern: rotating the entire body to simulate landscape on a portrait device */
  @media (orientation: portrait) {
    body {
      transform: rotate(90deg);
      transform-origin: left top;
      width: 100vh;
      overflow-x: hidden;
    }
  }
</style>

Viewport-Meta-Tag, das Ausrichtungswechsel verhindert – Richtig

<!-- Use a standard responsive viewport tag. Never rotate the body via CSS transforms. -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!--
  Let the browser and operating system handle orientation naturally.
  Design responsively so the content works at all viewport aspect ratios.
  Use CSS Grid and Flexbox to reflow content, not transforms.
-->

Häufige Fehler

Verwendung von @media (orientation: portrait), um display: none auf Navigationsmenüs, Sidebars oder Hauptinhaltsbereiche anzuwenden. Jede CSS-Ausrichtungsabfrage, die Inhalte aus der Ansicht entfernt – statt sie lediglich neu zu positionieren –, ist ein potenzieller Verstoß. Überprüfen Sie jede Ausrichtungs-Media-Query in Ihrem Stylesheet, um sicherzustellen, dass sie nur das Layout ändert, nicht die Verfügbarkeit von Inhalten.
Aufruf von screen.orientation.lock() für nicht wesentliche Anwendungen. Diese Web-API ist für Spiele und bestimmte Medienanwendungsfälle gedacht. Ihre Verwendung in einer Standard-Webanwendung oder einer E-Commerce-Site, um die „Ästhetik“ im Querformat zu verbessern, erfüllt nicht die Anforderungen an eine wesentliche Ausnahme und stellt einen direkten Verstoß gegen WCAG 1.3.4 dar.
Anzeige eines „Drehen Sie Ihr Gerät“-Splashscreens ohne barrierefreie Alternative. Selbst wenn ein kurzer Hinweis zur Ausrichtung angezeigt wird, darf er niemals den Zugriff auf die Inhalte blockieren. Falls er überhaupt angezeigt wird, muss er ausblendbar sein, darf den Hauptinhalt nicht überdecken und muss als Empfehlung, nicht als Voraussetzung vermittelt werden.
Die Annahme, dass mobile Nutzerinnen und Nutzer für Videoinhalte immer das Querformat bevorzugen. Das Einbetten eines Videoplayers, der im Hochformat Wiedergabesteuerungen oder die Wiedergabetaste deaktiviert – und Nutzerinnen und Nutzer zwingt, das Gerät zu drehen, bevor sie interagieren können –, verstößt gegen 1.3.4, es sei denn, das Videoformat kann im Hochformat tatsächlich nicht dargestellt werden (was bei Standard-Webvideo so gut wie nie der Fall ist).
Anwendung von CSS transform: rotate(90deg) auf das <body>-Element oder einen Root-Container in einer Ausrichtung. Dies simuliert eine Ausrichtungsänderung in CSS, statt das Gerät sie natürlich handhaben zu lassen, und führt zu fehlerhaften Layouts, Inhalten außerhalb des sichtbaren Bereichs und massiver Verwirrung im Accessibility-Tree für Screenreader.
Unterlassene Tests des Ausrichtungsverhaltens während der Qualitätssicherung, weil Teams nur auf Desktop-Browsern testen. Die Ausrichtungssimulation der DevTools von Desktop-Browsern wird in Standard-QA-Zyklen nicht immer genutzt. Die Ausrichtung sollte ein expliziter Punkt in mobilen Testplänen sein und sowohl auf realen iOS- als auch Android-Geräten überprüft werden.
Überschreiben des Ausrichtungsverhaltens innerhalb von iframes, ohne den Ausrichtungszustand der übergeordneten Seite zu berücksichtigen. Drittanbieter-Widgets, eingebettete Karten und Zahlungs-iframes können die Ausrichtung unabhängig voneinander sperren. Selbst wenn Ihre Seite konform ist, macht das Hosten eines gesperrten iframes Ihre Seite nicht konform, sofern die wesentliche Ausnahme für das iframe nicht dokumentiert ist.
Verwendung serverseitiger User-Agent-Erkennung, um mobilen Nutzerinnen und Nutzern eine „nur Querformat“-Version einer Seite bereitzustellen. Das Weiterleiten mobiler Nutzerinnen und Nutzer auf eine separate URL, die nur im Querformat funktioniert, ohne eine kompatible Hochformat-Alternative bereitzustellen, ist ein systemischer Verstoß, der zudem ein SEO- und Kanonisierung-Problem der URL verursacht.
Anwendung von Ausrichtungsbeschränkungen nur in Produktions-Builds, wodurch sie während der Entwicklungstests unsichtbar bleiben. Feature-Flags oder A/B-Testing-Frameworks aktivieren manchmal ausrichtungssperrenden Code nur in bestimmten Umgebungen oder für bestimmte Nutzersegmente, sodass der Verstoß während der Barrierefreiheitsaudits vor dem Launch unentdeckt bleibt.
Die Annahme, dass die wesentliche Ausnahme gilt, weil eine Designerin oder ein Designer das Querformat-Layout bevorzugt. Die wesentliche Ausnahme ist eine hohe rechtliche und ethische Hürde. Sie erfordert, dass die Hauptfunktion des Inhalts in der alternativen Ausrichtung grundsätzlich unmöglich ist – nicht nur, dass sie besser aussieht oder dass dem Team die Zeit fehlte, ein responsives Hochformat-Layout zu implementieren.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung Nr. 2025/10, veröffentlicht im Amtsblatt (Resmî Gazete) Nr. 32933 am 21. Juni 2025, etabliert einen umfassenden nationalen Rahmen für digitale Barrierefreiheit. Die Verfügung verpflichtet die erfassten Stellen zur Einhaltung von WCAG 2.2 Stufe AA, die WCAG 1.3.4 Orientation ausdrücklich einschließt. Das bedeutet, dass kein digitaler Dienst und keine Website, die von einer erfassten Stelle betrieben wird, Inhalte auf eine einzige Ausrichtung beschränken darf, was die Absicht der Verfügung widerspiegelt, sicherzustellen, dass alle Bürgerinnen und Bürger – einschließlich Menschen mit Behinderungen – unabhängig davon, wie sie physisch mit ihren Geräten interagieren, Zugang zu digitalen Diensten haben.

Zu den von der Verfügung erfassten Stellen, die Konformität mit Stufe AA erreichen müssen, gehören: öffentliche Institutionen und Behörden (alle staatlichen Stellen, die Websites und digitale Dienste betreiben), Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200,000 oder mehr Abonnentinnen und Abonnenten, E-Commerce-Plattformen, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind. Für diese Stellen stellen Ausrichtungsbeschränkungen, die gegen 1.3.4 verstoßen – etwa Regierungsportale, die ausschließlich den Zugriff im Querformat verlangen, oder Banking-Apps, die aus nicht wesentlichen Gründen auf das Hochformat festgelegt sind –, eine direkte Nichtkonformität mit verbindlichen nationalen Vorschriften dar.

Das Barrierefreiheitslogo (Erişilebilirlik Logosu), das vom Ministerium für Familie und Soziale Dienste (Aile ve Sosyal Hizmetler Bakanlığı) vergeben wird, ist ein Zertifizierungszeichen, das die Konformität mit dem nationalen Barrierefreiheitsstandard signalisiert. Das Erreichen der Konformität mit Stufe AA ist eine Voraussetzung für den Erhalt dieses Logos. Organisationen, die das Erişilebilirlik Logosu anstreben, müssen nachweisen, dass ihre digitalen Angebote alle Kriterien der Stufen A und AA erfüllen, einschließlich 1.3.4. Ein Ausrichtungsfehler – selbst in einem kleineren Abschnitt einer Website – kann die gesamte Zertifizierung gefährden.

Da WCAG 1.3.4 manuelle Tests erfordert und nicht allein durch automatisierte Scans bestätigt werden kann, sollten erfasste Stellen ausrichtungsspezifische Testfälle in ihre formalen Barrierefreiheitsauditprozesse aufnehmen. Die Dokumentation der Testergebnisse im Hoch- und Querformat auf realen Geräten sollte als Teil der Barrierefreiheitsnachweise geführt werden, die für die Einhaltung der Vorschriften und die Logo-Zertifizierung erforderlich sind. Das Accsible SDK unterstützt Organisationen dabei, ausrichtungsbezogene Barrieren zu identifizieren und zu beheben, als Teil eines ganzheitlichen Ansatzes zur Erfüllung der sich weiterentwickelnden digitalen Barrierefreiheitsverpflichtungen der Türkei.