WCAG-succescriteria · Level AA

WCAG 1.3.4: Oriëntatie

WCAG 1.3.4 Oriëntatie vereist dat content de weergave en bediening niet beperkt tot één enkele schermoriëntatie, zoals staand of liggend, tenzij een specifieke oriëntatie essentieel is. Dit criterium zorgt ervoor dat gebruikers die hun apparaten niet fysiek kunnen draaien—zoals mensen met gemonteerde tablets of motorische beperkingen—nog steeds toegang hebben tot alle content.

Wat Deze Regel Betekent

WCAG 1.3.4 Orientation is een criterium op niveau AA dat is geïntroduceerd in WCAG 2.1 en overgenomen in WCAG 2.2. Het stelt dat content zichzelf niet mag vastzetten op één enkele schermoriëntatie—ofwel portret (verticaal) of landschap (horizontaal)—tenzij die specifieke oriëntatie essentieel is voor de functie van de content. In de praktijk betekent dit dat webpagina’s en webgebaseerde applicaties correct moeten reageren en volledig bedienbaar moeten blijven, ongeacht of het apparaat van de gebruiker verticaal of horizontaal wordt gehouden, of dat de oriëntatie wordt beheerd door het besturingssysteem van het apparaat of door de voorkeuren van de gebruiker zelf.

Het criterium richt zich op situaties waarin ontwikkelaars CSS media queries, JavaScript of apparaat-API’s gebruiken om content bewust te beperken tot één oriëntatie. Een veelvoorkomende overtreding is het tonen van een bericht zoals “Draai uw apparaat naar de liggende modus” terwijl tegelijkertijd alle interactieve content in portretmodus wordt verborgen of uitgeschakeld. Een andere overtreding doet zich voor wanneer een webapplicatie een CSS-transform toepast of de viewport geforceerd roteert, waarbij de oriëntatie-instelling van het apparaat van de gebruiker wordt overschreven.

Wat telt als een voldoende resultaat: Content is toegankelijk in zowel portret- als landschapsoriëntatie. Alle tekst, interactieve elementen, formulieren, navigatie en media blijven zichtbaar en bedienbaar, ongeacht hoe het apparaat is georiënteerd. De lay-out mag zich aanpassen—met behulp van responsive designtechnieken zoals CSS Flexbox, CSS Grid of media queries—maar er mag niets worden verwijderd of onbedienbaar worden gemaakt op basis van alleen de oriëntatie.

Wat telt als een onvoldoende resultaat: Content die in één oriëntatie interactie verbergt, uitschakelt of blokkeert; berichten die gebruikers instrueren hun apparaat te draaien zonder een werkend alternatief te bieden; JavaScript dat luistert naar DeviceOrientationEvent of screen.orientation en vervolgens delen van de UI vergrendelt of uitschakelt; of CSS die @media (orientation: portrait) gebruikt om een blokkerende overlay weer te geven of display: none toe te passen op kritieke content.

De essentiële uitzondering: WCAG erkent dat sommige content van nature een oriëntatiespecifiek doel heeft. Een pianoklavier-applicatie mag legitiem landschapsmodus vereisen omdat een portretlay-out niet genoeg toetsen kan weergeven om muzikaal bruikbaar te zijn. Een functie voor het storten van bankcheques die afhankelijk is van de camera om een horizontale cheque vast te leggen, kan landschap vereisen. Een interface voor een virtualreality-headset kan een vaste oriëntatie nodig hebben om te functioneren. De lat voor “essentieel” ligt echter hoog—louter gemak voor de ontwikkelaar of esthetische voorkeur komt niet in aanmerking. De uitzondering moet worden gerechtvaardigd door een fundamentele eis van de content zelf, niet door een ontwerpkeuze.

Waarom Het Belangrijk Is

Oriëntatiebeperkingen treffen mensen met fysieke en motorische beperkingen in het bijzonder. Denk aan een rolstoelgebruiker van wie de tablet in een vaste portretstand op de armleuning van de stoel is gemonteerd. Die persoon kan het apparaat fysiek niet kantelen, waardoor alle content die landschapsoriëntatie vereist volledig ontoegankelijk wordt. Dit is geen hypothetisch randgeval—het monteren van hulpmiddelen in vaste oriëntaties is een veelvoorkomende voorziening voor mensen met aandoeningen zoals cerebrale parese, dwarslaesies, ALS of ernstige artritis.

Naast gemonteerde apparaten vertrouwen veel gebruikers op de oriëntatievergrendeling van het besturingssysteem om redenen die niets met een beperking te maken hebben. Een gebruiker die in bed ligt, kan de telefoon op portret vergrendelen om te voorkomen dat het scherm voortdurend draait. Een gebruiker met een evenwichtsstoornis—een aandoening die het binnenoor en het evenwicht aantast—kan plotselinge lay-outverschuivingen door oriëntatiewijzigingen desoriënterend of fysiek misselijkmakend vinden. Deze gebruikers dwingen de oriëntatievergrendeling van hun apparaat uit te zetten om toegang te krijgen tot uw content, creëert een onnodige en discriminerende barrière.

Cognitieve toegankelijkheid is ook een factor. Gebruikers met cognitieve beperkingen hebben vaak baat bij consistente, voorspelbare lay-outs. Een applicatie die plotseling content blokkeert of een foutachtig bericht weergeeft met het verzoek het apparaat te draaien, kan verwarrend en verontrustend zijn, vooral voor gebruikers die mogelijk niet begrijpen waarom hun apparaat een waarschuwing toont in plaats van de verwachte content.

Vanuit gebruiksvriendelijkheid en zakelijk perspectief schaden oriëntatiebeperkingen alle gebruikers. Een aanzienlijk deel van het mobiele webverkeer vindt plaats in portretmodus, en het beperken van een site tot landschap kan leiden tot onmiddellijke afhaken. Zoekmachines houden in toenemende mate rekening met mobielvriendelijkheid en Core Web Vitals—waaronder stabiel lay-outgedrag—in hun algoritmen voor ranking, wat betekent dat oriëntatiegerelateerde problemen een meetbaar negatief effect kunnen hebben op SEO-prestaties en organisch verkeer.

Wereldwijd leven volgens de Wereldgezondheidsorganisatie ongeveer 1,3 miljard mensen met een of andere vorm van beperking. Een aanzienlijk deel van deze groep gebruikt mobiele apparaten als hun primaire of enige manier om toegang te krijgen tot het internet, waardoor toegankelijkheid van mobiele oriëntatie bijzonder belangrijk is.

Gerelateerde Axe-core Regels

WCAG 1.3.4 Orientation vereist handmatige tests. Er is geen geautomatiseerde axe-core-regel die oriëntatiebeperkingen betrouwbaar detecteert, omdat de overtreding afhangt van runtime-gedrag, conditionele renderlogica en de fysieke toestand van een apparaat—zaken die geen van beide door statische DOM-analyse of geautomatiseerde paginascans kunnen worden beoordeeld. Het volgende legt uit waarom automatisering tekortschiet en waar handmatige testers op moeten letten:

  • Geen geautomatiseerde axe-core-regel (handmatige test vereist): Geautomatiseerde toegankelijkheidsscanners zoals axe-core, Lighthouse of IBM Equal Access Checker analyseren de DOM en CSSOM op één enkel moment. Ze kunnen niet simuleren dat een apparaat wordt gedraaid, beoordelen wat er met de lay-out gebeurt wanneer screen.orientation verandert, of bepalen of een CSS-@media (orientation: landscape)-blok kritieke content verbergt. Een scanner kan zien dat alle elementen aanwezig en technisch zichtbaar zijn in de oriëntatie die hij testte, zonder te weten dat de helft ervan verdwijnt in de alternatieve oriëntatie. Daarom wordt WCAG 1.3.4 geclassificeerd als een criterium dat handmatige tests vereist—geen tool kan het daadwerkelijk draaien van een echt apparaat of het simuleren van rotatie in de ontwikkelaarstools van een browser vervangen.
  • Detectie van JavaScript-oriëntatievergrendeling: Scripts die screen.orientation.lock() aanroepen of luisteren naar window.addEventListener('orientationchange', ...) om content te omleiden of uit te schakelen, kunnen niet worden gedetecteerd door statische analyse. Een linter kan het gebruik van deze API’s in broncode markeren, maar kan niet bepalen of het resulterende gedrag een WCAG-overtreding vormt zonder menselijke beoordeling van de vraag of een essentiële uitzondering van toepassing is.
  • CSS-gebaseerde blokkerende overlays: Een stylesheet kan @media (orientation: portrait) { .orientation-warning { display: block; } } gebruiken om in portretmodus een blokkerend bericht op volledig scherm te tonen. Axe-core, dat de pagina in landschap scant, zal dit element nooit in een zichtbare toestand tegenkomen en geen probleem rapporteren. Alleen testen in portretmodus—of het inspecteren van de CSS op oriëntatie-conditionele blokkeringspatronen—onthult de overtreding.

Hoe te Testen

  1. Voer een geautomatiseerde scan uit als basislijn: Open de pagina in Chrome, Firefox of Edge. Gebruik de axe DevTools-browserextensie of voer een Lighthouse-toegankelijkheidsaudit uit om een basislijn vast te stellen. Hoewel deze tools oriëntatieovertredingen niet direct detecteren, kunnen ze gerelateerde problemen met responsive design, viewport-meta-tags of ontbrekende ARIA markeren die oriëntatietoegankelijkheidsproblemen verergeren. Let op dat een schoon geautomatiseerd rapport geen naleving van 1.3.4 bevestigt.
  2. Gebruik apparaat-emulatie in browser DevTools: Open in Chrome of Edge DevTools (F12), klik op het apparaatpictogram in de toolbar (Ctrl+Shift+M / Cmd+Shift+M) en selecteer een mobiel apparaat zoals iPhone 14 of Galaxy S21. Schakel tussen portret- en landschapsoriëntatie met het rotatiepictogram in de apparaattoolbar. Controleer systematisch of alle content—navigatie, koppen, hoofdtekst, formulieren, knoppen, afbeeldingen en media—zichtbaar en bedienbaar blijft in beide oriëntaties. Let op blokkerende overlays, verborgen secties of uitgeschakelde interactieve elementen die in de ene oriëntatie wel en in de andere niet verschijnen.
  3. Test op echte apparaten: Verbind een Android- of iOS-apparaat en open de pagina in de mobiele browser. Draai het apparaat fysiek tussen portret en landschap. Bevestig dat de oriëntatievergrendeling van het besturingssysteem (indien ingeschakeld) er niet toe leidt dat content breekt of een rotatieprompt weergeeft. Test met de oriëntatievergrendeling zowel aan als uit.
  4. Screenreader-testen met oriëntatiesimulatie: Schakel op iOS met VoiceOver ingeschakeld (drie keer op de zijknop drukken) naar de pagina in portretoriëntatie met veeggebaren. Draai vervolgens naar landschap en controleer of de leesvolgorde van VoiceOver en de toegankelijke namen correct blijven. Voer op Android met TalkBack dezelfde test uit. Gebruik NVDA met Firefox op desktop en simuleer oriëntatie via DevTools om te verifiëren dat de toegankelijkheidsboom consistent is in alle oriëntaties.
  5. Inspecteer CSS en JavaScript op oriëntatiebeperkingen: Open in DevTools het paneel Sources of Elements en zoek in de stylesheet naar media queries orientation: portrait en orientation: landscape. Bekijk wat elk blok doet: verbergt het content met display: none, past het een blokkerende overlay toe, of past het alleen de lay-out aan? Zoek in JavaScript-bestanden naar screen.orientation, orientationchange en screen.orientation.lock. Beoordeel of gevonden patronen de UI vergrendelen of content blokkeren.
  6. Verifieer de essentiële uitzondering: Als de site oriëntatie bewust beperkt, controleer dan of er een gedocumenteerde, gerechtvaardigde essentiële usecase bestaat. De uitzondering moet door de content worden gedreven, niet door cosmetische redenen. Documenteer uw bevinding met een screenshot en de specifieke rechtvaardiging.

Hoe te Herstellen

CSS-blokkerende overlay in portretmodus — Onjuist

<!-- 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-blokkerende overlay in portretmodus — Juist

<!-- 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-oriëntatievergrendeling — Onjuist

<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-oriëntatievergrendeling — Juist

<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 die oriëntatiewijziging verhindert — Onjuist

<!-- 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 die oriëntatiewijziging verhindert — Juist

<!-- 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.
-->

Veelvoorkomende Fouten

  • @media (orientation: portrait) gebruiken om display: none toe te passen op navigatiemenu’s, sidebars of hoofdcontentgebieden. Elke CSS-oriëntatiequery die content uit beeld verwijdert—in plaats van deze alleen te herpositioneren—is een potentiële overtreding. Controleer elke oriëntatiemediaquery in uw stylesheet om te verzekeren dat deze alleen de lay-out wijzigt en niet de beschikbaarheid van content.
  • screen.orientation.lock() aanroepen voor niet-essentiële applicaties. Deze Web API is bedoeld voor games en specifieke mediagevallen. Het gebruik ervan in een standaard webapplicatie of e-commercesite om de “esthetiek” in landschapsmodus te verbeteren, komt niet in aanmerking als essentiële uitzondering en vormt een directe WCAG 1.3.4-overtreding.
  • Een splashscreen “draai uw apparaat” weergeven zonder een toegankelijke alternatieve toegang. Zelfs als slechts een korte oriëntatiehint wordt getoond, mag deze nooit de toegang tot de content blokkeren. Als het al wordt getoond, moet het te sluiten zijn, de hoofdcontent niet bedekken en als suggestie worden gecommuniceerd in plaats van als vereiste.
  • Aannemen dat mobiele gebruikers altijd de voorkeur geven aan landschap voor videocontent. Een videospeler insluiten die afspeelknoppen of de playknop in portretmodus uitschakelt—waardoor gebruikers worden gedwongen te draaien voordat ze kunnen interageren—schendt 1.3.4, tenzij het videoformaat werkelijk niet in portret kan worden weergegeven (wat voor standaard webvideo vrijwel nooit het geval is).
  • CSS transform: rotate(90deg) toepassen op de <body> of een rootcontainer in één oriëntatie. Dit simuleert oriëntatiewijziging in CSS in plaats van het apparaat deze natuurlijk te laten afhandelen, wat leidt tot kapotte lay-outs, content buiten beeld en ernstige verwarring in de toegankelijkheidsboom voor screenreaders.
  • Verzuimen om oriëntatiegedrag tijdens QA te testen omdat teams alleen op desktopbrowsers testen. Oriëntatiesimulatie in DevTools van desktopbrowsers wordt niet altijd gebruikt tijdens standaard QA-cycli. Oriëntatie moet een expliciet onderdeel zijn van mobiele testplannen, geverifieerd op zowel echte iOS- als Android-apparaten.
  • Oriëntatiegedrag binnen iframes overschrijven zonder rekening te houden met de oriëntatiestatus van de ouderpagina. Widgets van derden, ingesloten kaarten en betaal-iframes kunnen onafhankelijk oriëntatie vergrendelen. Zelfs als uw pagina voldoet, maakt het hosten van een vergrendeld iframe uw pagina niet-conform, tenzij de essentiële uitzondering voor het iframe is gedocumenteerd.
  • Server-side user-agent-detectie gebruiken om een “alleen-landschap”-versie van een pagina aan mobiele gebruikers te serveren. Mobiele gebruikers omleiden naar een aparte URL die alleen in landschap werkt, zonder een portret-compatibele fallback te bieden, is een systematische overtreding die ook een SEO- en canonicalisatieprobleem voor URL’s creëert.
  • Oriëntatiebeperkingen alleen in productie-builds toepassen, waardoor ze onzichtbaar zijn tijdens testen in de ontwikkelfase. Featureflags of A/B-testframeworks activeren soms oriëntatievergrendelende code alleen in specifieke omgevingen of voor specifieke gebruikerssegmenten, waardoor de overtreding tijdens toegankelijkheidsaudits vóór de lancering onopgemerkt blijft.
  • Aannemen dat de essentiële uitzondering van toepassing is omdat een ontwerper de landschapslay-out verkiest. De essentiële uitzondering is een hoge juridische en ethische drempel. Ze vereist dat de primaire functie van de content fundamenteel onmogelijk is in de alternatieve oriëntatie—niet alleen dat deze er beter uitziet of dat het team geen tijd meer had om een responsive portretlay-out te implementeren.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular No. 2025/10, gepubliceerd in het Staatsblad (Resmî Gazete) nr. 32933 op 21 juni 2025, stelt een uitgebreid nationaal kader voor digitale toegankelijkheid vast. De circulaire verplicht betrokken entiteiten om te voldoen aan WCAG 2.2 niveau AA, dat expliciet WCAG 1.3.4 Orientation omvat. Dit betekent dat elke digitale dienst of website die door een betrokken entiteit wordt geëxploiteerd, content niet mag beperken tot één enkele oriëntatie, in lijn met de bedoeling van de circulaire om ervoor te zorgen dat alle burgers—waaronder mensen met een beperking—toegang hebben tot digitale diensten, ongeacht hoe zij fysiek met hun apparaten omgaan.

De entiteiten die onder de circulaire vallen en niveau AA-conformiteit moeten bereiken, omvatten: publieke instellingen en agentschappen (alle overheidsorganen die websites en digitale diensten exploiteren), banken en financiële instellingen, ziekenhuizen en zorgaanbieders, telecommunicatiebedrijven met 200,000 of meer abonnees, e-commerceplatforms, reisagentschappen, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministry of National Education (MoNE). Voor deze entiteiten vormen oriëntatiebeperkingen die 1.3.4 schenden—zoals overheidsportalen die uitsluitend toegang in landschap eisen of bankapps die om niet-essentiële redenen op portretmodus worden vergrendeld—directe niet-naleving van bindende nationale regelgeving.

Het Accessibility Logo (Erişilebilirlik Logosu), uitgegeven door het Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı), is een certificeringsmerk dat conformiteit met de nationale toegankelijkheidsstandaard aangeeft. Het bereiken van niveau AA-conformiteit is een voorwaarde voor het verkrijgen van dit logo. Organisaties die de Erişilebilirlik Logosu willen verkrijgen, moeten aantonen dat hun digitale eigendommen slagen voor alle criteria op niveau A en niveau AA, inclusief 1.3.4. Een oriëntatiebeperkingsfout—zelfs in een klein deel van een site—kan de gehele certificering in gevaar brengen.

Omdat WCAG 1.3.4 handmatige tests vereist en niet uitsluitend door geautomatiseerde scans kan worden bevestigd, moeten betrokken entiteiten oriëntatiespecifieke testcases opnemen in hun formele toegankelijkheidsauditprocessen. Documentatie van testresultaten in zowel portret- als landschapsoriëntatie op echte apparaten moet worden bijgehouden als onderdeel van de toegankelijkheidsconformiteitsdossiers die vereist zijn voor naleving van de regelgeving en logocertificering. De Accsible SDK helpt organisaties bij het identificeren en aanpakken van oriëntatiegerelateerde barrières als onderdeel van een holistische benadering om te voldoen aan de zich ontwikkelende verplichtingen op het gebied van digitale toegankelijkheid in Turkije.