WCAG 1.3.4: Orientering

Vad den här regeln innebär

WCAG 1.3.4 Orientation är ett kriterium på nivå AA som introducerades i WCAG 2.1 och fördes vidare till WCAG 2.2. Det anger att innehåll inte får låsa sig till en enda skärmorientering – antingen stående (vertikal) eller liggande (horisontell) – om inte just den orienteringen är väsentlig för innehållets funktion. I praktiken innebär detta att webbsidor och webbaserade applikationer måste reagera korrekt och förbli fullt användbara oavsett om användarens enhet hålls vertikalt eller horisontellt, eller om orienteringen styrs av enhetens operativsystem eller av användarens egna inställningar.

Kriteriet riktar in sig på situationer där utvecklare använder CSS media queries, JavaScript eller enhets-API:er för att medvetet begränsa innehåll till en orientering. Ett vanligt brott är att visa ett meddelande som "Vänligen rotera din enhet till liggande läge" samtidigt som allt interaktivt innehåll i stående läge döljs eller inaktiveras. Ett annat brott uppstår när en webbapplikation tillämpar en CSS-transformering eller tvingar visningsytan att rotera och därmed åsidosätter användarens inställning för enhetens orientering.

Vad som räknas som godkänt: Innehållet är tillgängligt i både stående och liggande orientering. All text, interaktiva element, formulär, navigering och media förblir synliga och användbara oavsett hur enheten är orienterad. Layouten kan anpassas – med responsiva designtillämpningar som CSS Flexbox, CSS Grid eller media queries – men inget tas bort eller görs oanvändbart enbart baserat på orientering.

Vad som räknas som underkänt: Innehåll som döljer, inaktiverar eller blockerar interaktion i en orientering; meddelanden som instruerar användare att rotera sin enhet utan att tillhandahålla ett fungerande alternativ; JavaScript som lyssnar på DeviceOrientationEvent eller screen.orientation och sedan låser eller inaktiverar delar av gränssnittet; eller CSS som använder @media (orientation: portrait) för att visa en blockerande overlay eller display: none på kritiskt innehåll.

Det väsentliga undantaget: WCAG erkänner att visst innehåll har ett inneboende orienteringsspecifikt syfte. En pianotangentbordsapplikation kan legitimt kräva liggande läge eftersom en stående layout inte kan visa tillräckligt många tangenter för att vara musikaliskt användbar. En funktion för insättning av bankcheck som bygger på att kameran fångar en horisontell check kan kräva liggande läge. Ett gränssnitt för ett virtual reality-headset kan kräva en fast orientering för att fungera. Ribban för vad som är "väsentligt" är dock hög – ren utvecklarbekvämlighet eller estetiska preferenser kvalificerar inte. Undantaget måste motiveras av ett grundläggande krav i själva innehållet, inte ett designval.

Varför det är viktigt

Orienteringsbegränsningar drabbar oproportionerligt personer med fysiska och motoriska funktionsnedsättningar. Tänk på en rullstolsanvändare vars surfplatta är monterad i ett fast stående läge på stolens armstöd. Hen kan inte fysiskt luta enheten, så allt innehåll som kräver liggande orientering blir fullständigt otillgängligt. Detta är inte ett hypotetiskt extremfall – att montera hjälpmedelsenheter i fasta orienteringar är en vanlig anpassning för personer med tillstånd som cerebral pares, ryggmärgsskador, ALS eller svår artrit.

Utöver monterade enheter förlitar sig många användare på operativsystemets orienteringslås av skäl som inte är relaterade till funktionsnedsättning. En användare som ligger i sängen kan låsa sin telefon i stående läge för att förhindra att skärmen ständigt roterar. En användare med vestibulär störning – ett tillstånd som påverkar innerörat och balansen – kan uppleva plötsliga layoutskiften orsakade av orienteringsändringar som desorienterande eller fysiskt illamående. Att tvinga dessa användare att låsa upp enhetens orientering för att få åtkomst till ditt innehåll skapar ett onödigt och diskriminerande hinder.

Kognitiv tillgänglighet är också en faktor. Användare med kognitiva funktionsnedsättningar drar ofta nytta av konsekventa, förutsägbara layouter. En applikation som plötsligt blockerar innehåll eller visar ett fel-liknande meddelande som ber om enhetsrotation kan vara förvirrande och oroande, särskilt för användare som kanske inte förstår varför deras enhet visar en varning i stället för det förväntade innehållet.

Ur ett användbarhets- och affärsperspektiv skadar orienteringsbegränsningar alla användare. En betydande del av mobil webbtrafik sker i stående läge, och att begränsa en webbplats till liggande läge kan leda till omedelbart avhopp. Sökmotorer tar också i allt högre grad hänsyn till mobilvänlighet och Core Web Vitals – inklusive stabilt layoutbeteende – i sina rankningsalgoritmer, vilket innebär att orienteringsrelaterade problem kan ha en mätbar negativ inverkan på SEO-prestanda och organisk trafik.

Globalt lever cirka 1,3 miljarder människor med någon form av funktionsnedsättning enligt Världshälsoorganisationen. En betydande andel av denna grupp använder mobila enheter som sitt primära eller enda sätt att få tillgång till internet, vilket gör tillgänglighet kopplad till mobil orientering särskilt betydelsefull.

Relaterade Axe-core-regler

WCAG 1.3.4 Orientation kräver manuell testning. Det finns ingen automatiserad axe-core-regel som pålitligt upptäcker orienteringsbegränsningar, eftersom överträdelsen beror på beteende vid körning, villkorad renderingslogik och enhetens fysiska tillstånd – inget av detta kan utvärderas med statisk DOM-analys eller automatiserad genomsökning av sidan. Följande förklarar varför automatisering inte räcker och vad manuella testare måste leta efter:

• Ingen automatiserad axe-core-regel (manuell testning krävs): Automatiserade tillgänglighetsskannrar som axe-core, Lighthouse eller IBM Equal Access Checker analyserar DOM och CSSOM vid en enda tidpunkt. De kan inte simulera att en enhet roteras, utvärdera vad som händer med layouten när screen.orientation ändras eller avgöra om ett CSS-block @media (orientation: landscape) döljer kritiskt innehåll. En skanner kan se att alla element finns och tekniskt sett är synliga i den orientering den testade, utan att veta att hälften av dem försvinner i den alternativa orienteringen. Det är därför WCAG 1.3.4 klassas som ett kriterium som kräver manuell testning – inget verktyg kan ersätta att faktiskt rotera en riktig enhet eller simulera rotation i en webbläsares utvecklarverktyg.
• Upptäckt av JavaScript-orienteringslås: Skript som anropar screen.orientation.lock() eller lyssnar på window.addEventListener('orientationchange', ...) för att omdirigera eller inaktivera innehåll kan inte upptäckas med statisk analys. En linter skulle kunna flagga användningen av dessa API:er i källkoden, men den kan inte avgöra om det resulterande beteendet utgör en WCAG-överträdelse utan mänsklig bedömning av om ett väsentligt undantag är tillämpligt.
• CSS-baserade blockerande overlays: Ett stilmall kan använda @media (orientation: portrait) { .orientation-warning { display: block; } } för att visa ett helskärms blockerande meddelande i stående läge. Axe-core, som skannar sidan i liggande läge, skulle aldrig stöta på detta element i ett synligt tillstånd och skulle rapportera att inget problem finns. Endast testning i stående läge – eller inspektion av CSS efter orienteringsberoende blockeringsmönster – avslöjar överträdelsen.

Hur man testar

1. Kör en automatiserad skanning som baslinje: Öppna sidan i Chrome, Firefox eller Edge. Använd webbläsartillägget axe DevTools eller kör en Lighthouse-tillgänglighetsgranskning för att etablera en baslinje. Även om dessa verktyg inte direkt upptäcker orienteringsöverträdelser kan de flagga relaterade problem med responsiv design, problem med viewport-meta-taggen eller saknad ARIA som förstärker tillgänglighetsfel kopplade till orientering. Observera att en ren automatiserad rapport inte bekräftar efterlevnad av 1.3.4.
2. Använd enhetsemulering i webbläsarens DevTools: Öppna DevTools (F12) i Chrome eller Edge, klicka på ikonen för enhetsverktygsfältet (Ctrl+Shift+M / Cmd+Shift+M) och välj en mobil enhet som iPhone 14 eller Galaxy S21. Växla mellan stående och liggande orientering med rotationsikonen i enhetsverktygsfältet. Verifiera systematiskt att allt innehåll – navigering, rubriker, brödtext, formulär, knappar, bilder och media – förblir synligt och användbart i båda orienteringarna. Leta efter blockerande overlays, dolda sektioner eller inaktiverade interaktiva element som visas i en orientering men inte i den andra.
3. Testa på riktiga enheter: Anslut en Android- eller iOS-enhet och öppna sidan i mobilwebbläsaren. Rotera enheten fysiskt mellan stående och liggande läge. Bekräfta att operativsystemets orienteringslås (när det är aktiverat) inte gör att innehållet går sönder eller visar en rotationsuppmaning. Testa med orienteringslåset både på och av.
4. Skärmläsartestning med orienteringssimulering: På iOS med VoiceOver aktiverat (trippelklicka på sidoknappen), navigera på sidan i stående orientering med svepgester. Rotera sedan till liggande läge och verifiera att VoiceOvers läsordning och tillgängliga namn förblir korrekta. På Android med TalkBack utför du samma test. Använd NVDA med Firefox på skrivbordet och simulera orientering via DevTools för att verifiera att tillgänglighetsträdet är konsekvent mellan orienteringarna.
5. Inspektera CSS och JavaScript efter orienteringsbegränsningar: Öppna panelen Sources eller Elements i DevTools och sök i stilmallen efter media queries orientation: portrait och orientation: landscape. Granska vad varje block gör: döljer det innehåll med display: none, tillämpar det en blockerande overlay eller justerar det bara layouten? Sök i JavaScript-filer efter screen.orientation, orientationchange och screen.orientation.lock. Bedöm om några hittade mönster låser gränssnittet eller blockerar innehåll.
6. Verifiera det väsentliga undantaget: Om webbplatsen avsiktligt begränsar orientering, bekräfta att det finns ett dokumenterat, motiverat väsentligt användningsfall. Undantaget måste vara innehållsdrivet, inte kosmetiskt. Dokumentera din iakttagelse med en skärmdump och den specifika motiveringen.

Hur man åtgärdar

CSS-blockerande overlay i stående läge — Felaktigt

<!-- En helskärms-overlay som bara visas i stående läge och blockerar allt innehåll -->
<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-blockerande overlay i stående läge — Korrekt

<!-- Ta bort den blockerande overlayen helt. Använd responsiv CSS för att anpassa layouten i stället. -->
<style>
  /* Stående layout: stapla element vertikalt */
  @media (orientation: portrait) {
    .dashboard-grid {
      grid-template-columns: 1fr;
    }
  }
  /* Liggande layout: kolumner sida vid sida */
  @media (orientation: landscape) {
    .dashboard-grid {
      grid-template-columns: 1fr 1fr;
    }
  }
</style>
<main id='app-content'>
  <div class='dashboard-grid'>
    <!-- Innehållet anpassar layouten men är alltid tillgängligt -->
  </div>
</main>

JavaScript-orienteringslås — Felaktigt

<script>
  // Låser skärmen till liggande läge och visar ett fel om det misslyckas (t.ex. på 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-orienteringslås — Korrekt

<script>
  /*
    Lås inte orienteringen via JavaScript.
    Lyssna i stället på orienteringsändringar och anpassa UI:t
    utan att dölja eller inaktivera innehåll.
  */
  window.addEventListener('orientationchange', function() {
    var isPortrait = window.matchMedia('(orientation: portrait)').matches;
    // Justera layoutklass endast för styling — dölj aldrig innehåll
    document.body.classList.toggle('portrait-layout', isPortrait);
    document.body.classList.toggle('landscape-layout', !isPortrait);
  });
</script>
<div id='main-content'>
  <!-- Allt innehåll förblir synligt och användbart i båda orienteringarna -->
</div>

Viewport-meta-tagg som förhindrar orienteringsändring — Felaktigt

<!-- Vissa äldre implementationer försökte fixa orientering via viewport -->
<meta name='viewport' content='width=device-width, initial-scale=1, user-scalable=no'>
<!--
  Även om 'user-scalable=no' inte direkt låser orienteringen,
  är det en känd anti-pattern att kombinera det med CSS-transformeringar
  som roterar visningsytan, vilket skapar tillgänglighetsfel kopplade till orientering.
-->
<style>
  /* Anti-pattern: rotera hela body för att simulera liggande läge på en stående enhet */
  @media (orientation: portrait) {
    body {
      transform: rotate(90deg);
      transform-origin: left top;
      width: 100vh;
      overflow-x: hidden;
    }
  }
</style>

Viewport-meta-tagg som förhindrar orienteringsändring — Korrekt

<!-- Använd en standard responsiv viewport-tagg. Rotera aldrig body via CSS-transformeringar. -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!--
  Låt webbläsaren och operativsystemet hantera orienteringen naturligt.
  Designa responsivt så att innehållet fungerar vid alla visningsförhållanden.
  Använd CSS Grid och Flexbox för att omflöda innehåll, inte transformeringar.
-->

Vanliga misstag

• Att använda @media (orientation: portrait) för att tillämpa display: none på navigationsmenyer, sidofält eller huvudområden med innehåll. Alla CSS-orienteringsfrågor som tar bort innehåll från vyn – i stället för att bara ompositionera det – är en potentiell överträdelse. Granska varje media query för orientering i din stilmall för att säkerställa att den bara ändrar layout, inte innehållets tillgänglighet.
• Att anropa screen.orientation.lock() för icke-väsentliga applikationer. Detta webb-API är avsett för spel och specifika mediabaserade användningsfall. Att använda det i en standardwebbapplikation eller e-handelssajt för att "förbättra estetiken" i liggande läge kvalificerar inte som ett väsentligt undantag och skapar en direkt överträdelse av WCAG 1.3.4.
• Att visa en "rotera din enhet"-startskärm utan ett tillgängligt alternativ. Även om en kort orienteringshint visas får den aldrig blockera åtkomst till innehållet. Om den visas alls måste den gå att stänga, inte täcka huvud-innehållet och förmedlas som ett förslag snarare än ett krav.
• Att anta att mobila användare alltid föredrar liggande läge för videoinnehåll. Att bädda in en videospelare som inaktiverar uppspelningskontroller eller play-knappen i stående läge – och tvingar användare att rotera innan de kan interagera – bryter mot 1.3.4 om inte videoformatet verkligen inte kan återges i stående läge (vilket nästan aldrig stämmer för standard webbvideo).
• Att tillämpa CSS transform: rotate(90deg) på <body> eller en rotcontainer i en orientering. Detta simulerar orienteringsändring i CSS i stället för att låta enheten hantera den naturligt, vilket skapar trasiga layouter, innehåll utanför skärmen och allvarlig förvirring i tillgänglighetsträdet för skärmläsare.
• Att inte testa orienteringsbeteende under QA eftersom team bara testar i skrivbordswebbläsare. Simulering av orientering i DevTools på skrivbordet används inte alltid under standard-QA-cykler. Orientering bör vara en uttrycklig punkt i mobila testplaner, verifierad på både iOS- och Android-enheter.
• Att åsidosätta orienteringsbeteende inuti iframes utan att ta hänsyn till den överordnade sidans orienteringstillstånd. Tredjepartswidgets, inbäddade kartor och betalnings-iframes kan oberoende låsa orientering. Även om din sida är kompatibel gör en låst iframe din sida icke-kompatibel om inte iframe:ens väsentliga undantag är dokumenterat.
• Att använda serverbaserad user-agent-detektering för att leverera en "endast liggande"-version av en sida till mobila användare. Att omdirigera mobila användare till en separat URL som bara fungerar i liggande läge, utan att tillhandahålla en stående-kompatibel reservlösning, är en systematisk överträdelse som också skapar ett SEO- och kanoniseringsproblem för URL:er.
• Att tillämpa orienteringsbegränsningar endast i produktionsbyggen, vilket gör dem osynliga under utvecklingstestning. Funktionsflaggor eller A/B-testningsramverk aktiverar ibland orienteringslåsande kod endast i specifika miljöer eller för specifika användarsegment, vilket gör att överträdelsen missas under tillgänglighetsgranskningar före lansering.
• Att anta att det väsentliga undantaget gäller eftersom en designer föredrar layouten i liggande läge. Det väsentliga undantaget är en hög juridisk och etisk ribba. Det kräver att innehållets primära funktion är fundamentalt omöjlig i den alternativa orienteringen – inte bara att det ser bättre ut eller att teamet fick slut på tid för att implementera en responsiv layout i stående läge.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular No. 2025/10, publicerad i den officiella tidningen (Resmî Gazete) nr 32933 den 21 juni 2025, etablerar ett omfattande nationellt ramverk för digital tillgänglighet. Cirkuläret föreskriver att berörda aktörer ska följa WCAG 2.2 nivå AA, vilket uttryckligen inkluderar WCAG 1.3.4 Orientation. Detta innebär att alla digitala tjänster eller webbplatser som drivs av en berörd aktör inte får begränsa innehåll till en enda orientering, vilket återspeglar cirkulärets avsikt att säkerställa att alla medborgare – inklusive personer med funktionsnedsättning – kan få tillgång till digitala tjänster oavsett hur de fysiskt interagerar med sina enheter.

De aktörer som omfattas av cirkuläret och måste uppnå överensstämmelse på nivå AA inkluderar: offentliga institutioner och myndigheter (alla statliga organ som driver webbplatser och digitala tjänster), banker och finansiella institutioner, sjukhus och vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, e-handelsplattformar, resebyråer, privata transportföretag och privatskolor auktoriserade av Ministry of National Education (MoNE). För dessa aktörer utgör orienteringsbegränsningar som bryter mot 1.3.4 – såsom myndighetsportaler som kräver åtkomst endast i liggande läge eller bankappar som låser till stående läge av icke-väsentliga skäl – direkt bristande efterlevnad av bindande nationell reglering.

Accessibility Logo (Erişilebilirlik Logosu), utfärdad av Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı), är ett certifieringsmärke som signalerar överensstämmelse med den nationella tillgänglighetsstandarden. Att uppnå överensstämmelse på nivå AA är ett krav för att få denna logotyp. Organisationer som söker Erişilebilirlik Logosu måste visa att deras digitala tillgångar klarar alla kriterier på nivå A och nivå AA, inklusive 1.3.4. Ett fel kopplat till orienteringsbegränsning – även i en mindre del av en webbplats – kan äventyra hela certifieringen.

Eftersom WCAG 1.3.4 kräver manuell testning och inte kan bekräftas enbart genom automatiska skanningar bör berörda aktörer inkludera orienteringsspecifika testfall i sina formella tillgänglighetsgranskningsprocesser. Dokumentation av testresultat i både stående och liggande orientering på riktiga enheter bör upprätthållas som en del av de tillgänglighetsöverensstämmelseregister som krävs för regelefterlevnad och logocertifiering. Accsible SDK hjälper organisationer att identifiera och åtgärda orienteringsrelaterade hinder som en del av ett holistiskt angreppssätt för att uppfylla Turkiets utvecklande krav på digital tillgänglighet.