WCAG 1.3.4: Orientamento

Cosa Significa Questa Regola

WCAG 1.3.4 Orientation è un criterio di livello AA introdotto in WCAG 2.1 e mantenuto in WCAG 2.2. Stabilisce che i contenuti non devono bloccarsi su una sola orientazione dello schermo—verticale (portrait) o orizzontale (landscape)—a meno che quella specifica orientazione non sia essenziale per la funzione del contenuto. In pratica, ciò significa che pagine web e applicazioni basate sul web devono rispondere correttamente e rimanere pienamente utilizzabili indipendentemente dal fatto che il dispositivo dell’utente sia tenuto in verticale o in orizzontale, o che l’orientamento sia controllato dal sistema operativo del dispositivo o dalle preferenze dell’utente.

Il criterio prende di mira le situazioni in cui gli sviluppatori usano media query CSS, JavaScript o API del dispositivo per limitare deliberatamente i contenuti a una sola orientazione. Una violazione comune è mostrare un messaggio come "Ruota il dispositivo in modalità orizzontale" nascondendo o disabilitando allo stesso tempo tutti i contenuti interattivi in modalità verticale. Un’altra violazione si verifica quando un’applicazione web applica una trasformazione CSS o ruota forzatamente il viewport, ignorando l’impostazione di orientamento del dispositivo dell’utente.

Cosa è considerato conforme: Il contenuto è accessibile sia in orientamento verticale che orizzontale. Tutto il testo, gli elementi interattivi, i moduli, la navigazione e i media rimangono visibili e utilizzabili indipendentemente da come è orientato il dispositivo. Il layout può adattarsi—usando tecniche di design responsive come CSS Flexbox, CSS Grid o media query—ma nulla viene rimosso o reso inutilizzabile in base alla sola orientazione.

Cosa è considerato non conforme: Contenuti che nascondono, disabilitano o bloccano l’interazione in una delle due orientazioni; messaggi che istruiscono gli utenti a ruotare il dispositivo senza fornire un’alternativa funzionante; JavaScript che ascolta DeviceOrientationEvent o screen.orientation e poi blocca o disabilita parti dell’interfaccia; oppure CSS che usa @media (orientation: portrait) per mostrare un overlay bloccante o display: none su contenuti critici.

L’eccezione dell’essenzialità: WCAG riconosce che alcuni contenuti hanno uno scopo intrinsecamente legato a una specifica orientazione. Un’applicazione di tastiera per pianoforte può legittimamente richiedere la modalità orizzontale perché un layout verticale non può mostrare un numero sufficiente di tasti per essere musicalmente utile. Una funzionalità di deposito assegni bancari che si affida alla fotocamera per catturare un assegno orizzontale può richiedere la modalità orizzontale. Un’interfaccia per visori di realtà virtuale può richiedere un’orientazione fissa per funzionare. Tuttavia, la soglia per considerare qualcosa “essenziale” è alta—la semplice comodità dello sviluppatore o una preferenza estetica non sono sufficienti. L’eccezione deve essere giustificata da un requisito fondamentale del contenuto stesso, non da una scelta di design.

Perché È Importante

Le restrizioni di orientazione colpiscono in modo sproporzionato le persone con disabilità fisiche e motorie. Si pensi a una persona che usa una sedia a rotelle e il cui tablet è montato in posizione verticale fissa sul bracciolo. Non può fisicamente inclinare il dispositivo, quindi qualsiasi contenuto che richiede l’orientamento orizzontale diventa completamente inaccessibile. Non si tratta di un caso limite ipotetico—il montaggio di dispositivi di tecnologia assistiva in orientazioni fisse è un accomodamento comune per persone con condizioni come paralisi cerebrale, lesioni al midollo spinale, SLA o artrite grave.

Oltre ai dispositivi montati, molti utenti si affidano alla funzione di blocco dell’orientamento del sistema operativo per motivi non legati alla disabilità. Una persona sdraiata a letto può bloccare il telefono in verticale per evitare che lo schermo ruoti continuamente. Una persona con disturbo vestibolare—una condizione che colpisce l’orecchio interno e l’equilibrio—può trovare i cambiamenti improvvisi di layout causati dalle variazioni di orientamento disorientanti o fisicamente nauseanti. Costringere questi utenti a sbloccare l’orientamento del dispositivo per accedere ai contenuti crea una barriera inutile e discriminatoria.

L’accessibilità cognitiva è anch’essa un fattore. Le persone con disabilità cognitive traggono spesso beneficio da layout coerenti e prevedibili. Un’applicazione che all’improvviso blocca i contenuti o mostra un messaggio simile a un errore che chiede di ruotare il dispositivo può risultare confusa e allarmante, in particolare per chi potrebbe non capire perché il proprio dispositivo mostra un avviso invece dei contenuti attesi.

Dal punto di vista dell’usabilità e del business, le restrizioni di orientazione danneggiano tutti gli utenti. Una parte significativa del traffico web mobile avviene in modalità verticale, e limitare un sito alla modalità orizzontale può portare a un abbandono immediato. I motori di ricerca inoltre tengono sempre più conto della compatibilità mobile e dei Core Web Vitals—compreso il comportamento stabile del layout—nei loro algoritmi di ranking, il che significa che i problemi legati all’orientazione possono avere un impatto negativo misurabile sulle prestazioni SEO e sul traffico organico.

A livello globale, circa 1,3 miliardi di persone vivono con qualche forma di disabilità secondo l’Organizzazione Mondiale della Sanità. Una parte significativa di questo gruppo utilizza dispositivi mobili come mezzo principale o esclusivo per accedere a internet, rendendo l’accessibilità dell’orientazione mobile particolarmente rilevante.

Regole Axe-core Correlate

WCAG 1.3.4 Orientation richiede test manuali. Non esiste una regola automatizzata di axe-core che rilevi in modo affidabile le restrizioni di orientazione, perché la violazione dipende dal comportamento in fase di esecuzione, dalla logica di rendering condizionale e dallo stato fisico di un dispositivo—nessuno dei quali può essere valutato da un’analisi statica del DOM o da una scansione automatizzata della pagina. Quanto segue spiega perché l’automazione non è sufficiente e cosa devono cercare i tester manuali:

• Nessuna regola axe-core automatizzata (test manuale richiesto): Gli scanner di accessibilità automatizzati come axe-core, Lighthouse o IBM Equal Access Checker analizzano il DOM e il CSSOM in un singolo momento. Non possono simulare la rotazione di un dispositivo, valutare cosa succede al layout quando screen.orientation cambia, o determinare se un blocco CSS @media (orientation: landscape) stia nascondendo contenuti critici. Uno scanner potrebbe vedere che tutti gli elementi sono presenti e tecnicamente visibili nell’orientazione testata, senza sapere che metà di essi scompare nell’orientazione alternativa. Per questo motivo WCAG 1.3.4 è classificato come criterio che richiede test manuali—nessuno strumento può sostituire la rotazione effettiva di un dispositivo reale o la simulazione della rotazione negli strumenti di sviluppo del browser.
• Rilevamento del blocco di orientazione in JavaScript: Gli script che chiamano screen.orientation.lock() o ascoltano window.addEventListener('orientationchange', ...) per reindirizzare o disabilitare contenuti non possono essere rilevati tramite analisi statica. Un linter potrebbe segnalare l’uso di queste API nel codice sorgente, ma non può determinare se il comportamento risultante costituisca una violazione WCAG senza un giudizio umano sul fatto che si applichi o meno un’eccezione essenziale.
• Overlay bloccanti basati su CSS: Un foglio di stile potrebbe usare @media (orientation: portrait) { .orientation-warning { display: block; } } per mostrare un messaggio bloccante a schermo intero in modalità verticale. Axe-core, scansionando la pagina in orizzontale, non incontrerebbe mai questo elemento in stato visibile e non segnalerebbe alcun problema. Solo il test in modalità verticale—o l’ispezione del CSS alla ricerca di pattern di blocco condizionati all’orientazione—rivela la violazione.

Come Eseguire i Test

1. Esegui una scansione automatizzata come base: Apri la pagina in Chrome, Firefox o Edge. Usa l’estensione browser axe DevTools o esegui un audit di accessibilità con Lighthouse per stabilire una base. Sebbene questi strumenti non rilevino direttamente le violazioni legate all’orientazione, possono segnalare problemi correlati al design responsive, al meta tag viewport o ARIA mancanti che aggravano i problemi di accessibilità legati all’orientazione. Nota che un report automatico pulito non conferma la conformità al criterio 1.3.4.
2. Usa l’emulazione dei dispositivi negli strumenti di sviluppo del browser: In Chrome o Edge, apri DevTools (F12), fai clic sull’icona della barra degli strumenti del dispositivo (Ctrl+Shift+M / Cmd+Shift+M) e seleziona un dispositivo mobile come iPhone 14 o Galaxy S21. Alterna tra orientamento verticale e orizzontale usando l’icona di rotazione nella barra degli strumenti del dispositivo. Verifica sistematicamente che tutti i contenuti—navigazione, intestazioni, testo principale, moduli, pulsanti, immagini e media—rimangano visibili e utilizzabili in entrambe le orientazioni. Cerca overlay bloccanti, sezioni nascoste o elementi interattivi disabilitati che compaiono in un’orientazione ma non nell’altra.
3. Testa su dispositivi reali: Collega un dispositivo Android o iOS e apri la pagina nel browser mobile. Ruota fisicamente il dispositivo tra verticale e orizzontale. Conferma che il blocco dell’orientazione del sistema operativo (quando abilitato) non causi la rottura dei contenuti o la visualizzazione di un prompt di rotazione. Esegui il test con il blocco dell’orientazione sia attivato che disattivato.
4. Test con screen reader e simulazione dell’orientazione: Su iOS con VoiceOver abilitato (triplo clic sul tasto laterale), naviga nella pagina in orientamento verticale usando i gesti di scorrimento. Poi ruota in orizzontale e verifica che l’ordine di lettura di VoiceOver e i nomi accessibili rimangano corretti. Su Android con TalkBack, esegui lo stesso test. Usa NVDA con Firefox su desktop e simula l’orientazione tramite DevTools per verificare che l’albero di accessibilità sia coerente tra le diverse orientazioni.
5. Ispeziona CSS e JavaScript alla ricerca di restrizioni di orientazione: In DevTools, apri il pannello Sources o Elements e cerca nel foglio di stile le media query orientation: portrait e orientation: landscape. Esamina cosa fa ciascun blocco: nasconde contenuti con display: none, applica un overlay bloccante o si limita ad adattare il layout? Cerca nei file JavaScript screen.orientation, orientationchange e screen.orientation.lock. Valuta se i pattern trovati bloccano l’interfaccia o i contenuti.
6. Verifica l’eccezione essenziale: Se il sito limita intenzionalmente l’orientazione, conferma che esista un caso d’uso essenziale documentato e giustificato. L’eccezione deve essere guidata dal contenuto, non da aspetti cosmetici. Documenta la tua conclusione con uno screenshot e la giustificazione specifica.

Come Correggere

Overlay CSS bloccante in modalità verticale — Non corretto

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

Overlay CSS bloccante in modalità verticale — Corretto

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

Blocco dell’orientazione in JavaScript — Non corretto

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

Blocco dell’orientazione in JavaScript — Corretto

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

Meta tag viewport che impedisce il cambio di orientazione — Non corretto

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

Meta tag viewport che impedisce il cambio di orientazione — Corretto

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

Errori Comuni

• Usare @media (orientation: portrait) per applicare display: none a menu di navigazione, sidebar o aree di contenuto principale. Qualsiasi media query CSS sull’orientazione che rimuove i contenuti dalla vista—invece di limitarne il riposizionamento—è una potenziale violazione. Verifica ogni media query sull’orientazione nel tuo foglio di stile per assicurarti che modifichi solo il layout, non la disponibilità dei contenuti.
• Chiamare screen.orientation.lock() per applicazioni non essenziali. Questa Web API è pensata per giochi e specifici casi d’uso multimediali. Usarla in un’applicazione web standard o in un sito di e-commerce per “migliorare l’estetica” in modalità orizzontale non rientra nell’eccezione essenziale e crea una violazione diretta di WCAG 1.3.4.
• Mostrare una schermata iniziale “ruota il dispositivo” senza un’alternativa accessibile. Anche se viene mostrato un breve suggerimento sull’orientazione, non deve mai bloccare l’accesso ai contenuti. Se viene mostrato, deve poter essere chiuso, non coprire il contenuto principale e deve essere presentato come suggerimento, non come requisito.
• Dare per scontato che gli utenti mobile preferiscano sempre l’orientamento orizzontale per i contenuti video. Incorporare un lettore video che disabilita i controlli di riproduzione o il pulsante play in modalità verticale—costringendo gli utenti a ruotare prima di poter interagire—viola il criterio 1.3.4, a meno che il formato video non possa davvero essere reso in verticale (cosa quasi mai vera per i video web standard).
• Applicare transform: rotate(90deg) al <body> o a un contenitore radice in una delle due orientazioni. Questo simula il cambio di orientazione tramite CSS invece di lasciare che sia il dispositivo a gestirlo naturalmente, creando layout rotti, contenuti fuori dallo schermo e una grave confusione dell’albero di accessibilità per gli screen reader.
• Non testare il comportamento dell’orientazione durante il QA perché i team testano solo sui browser desktop. La simulazione dell’orientazione tramite DevTools dei browser desktop non viene sempre usata nei cicli standard di QA. L’orientazione dovrebbe essere un elemento esplicito nei piani di test mobile, verificato su dispositivi reali sia iOS che Android.
• Sovrascrivere il comportamento dell’orientazione all’interno di iframe senza tenere conto dello stato di orientazione della pagina padre. Widget di terze parti, mappe incorporate e iframe di pagamento possono bloccare l’orientazione in modo indipendente. Anche se la tua pagina è conforme, ospitare un iframe bloccato rende la tua pagina non conforme a meno che l’eccezione essenziale dell’iframe non sia documentata.
• Usare il rilevamento dell’user-agent lato server per fornire una versione “solo orizzontale” di una pagina agli utenti mobile. Reindirizzare gli utenti mobile a un URL separato che funziona solo in modalità orizzontale, senza fornire un’alternativa compatibile con la modalità verticale, è una violazione sistemica che crea anche un problema di SEO e di canonicalizzazione degli URL.
• Applicare restrizioni di orientazione solo nelle build di produzione, rendendole invisibili durante i test di sviluppo. I feature flag o i framework di A/B testing a volte attivano il codice di blocco dell’orientazione solo in ambienti specifici o per segmenti specifici di utenti, facendo sì che la violazione venga mancata durante gli audit di accessibilità pre-lancio.
• Supporre che l’eccezione essenziale si applichi perché un designer preferisce il layout orizzontale. L’eccezione essenziale è una soglia legale ed etica elevata. Richiede che la funzione principale del contenuto sia fondamentalmente impossibile nell’orientazione alternativa—non semplicemente che abbia un aspetto migliore o che il team non abbia avuto tempo di implementare un layout verticale responsive.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale n. 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale (Resmî Gazete) n. 32933 il 21 giugno 2025, stabilisce un quadro nazionale completo per l’accessibilità digitale. La Circolare impone ai soggetti interessati di conformarsi a WCAG 2.2 livello AA, che include esplicitamente WCAG 1.3.4 Orientation. Ciò significa che qualsiasi servizio digitale o sito web gestito da un soggetto coperto non deve limitare i contenuti a una sola orientazione, riflettendo l’intento della Circolare di garantire che tutti i cittadini—incluse le persone con disabilità—possano accedere ai servizi digitali indipendentemente da come interagiscono fisicamente con i loro dispositivi.

I soggetti coperti dalla Circolare e tenuti a raggiungere la conformità di livello AA includono: istituzioni e agenzie pubbliche (tutti gli enti governativi che gestiscono siti web e servizi digitali), banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari, società di telecomunicazioni con 200,000 o più abbonati, piattaforme di e-commerce, agenzie di viaggio, società di trasporto privato e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). Per questi soggetti, le restrizioni di orientazione che violano il criterio 1.3.4—come portali governativi che richiedono l’accesso solo in modalità orizzontale o app bancarie che si bloccano in modalità verticale per motivi non essenziali—costituiscono una non conformità diretta con una normativa nazionale vincolante.

Il Logo di Accessibilità (Erişilebilirlik Logosu), rilasciato dal Ministero della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı), è un marchio di certificazione che segnala la conformità allo standard nazionale di accessibilità. Raggiungere la conformità di livello AA è un prerequisito per ottenere questo logo. Le organizzazioni che richiedono l’Erişilebilirlik Logosu devono dimostrare che le loro proprietà digitali soddisfano tutti i criteri di livello A e AA, incluso il criterio 1.3.4. Una violazione relativa alle restrizioni di orientazione—anche in una sezione minore di un sito—può compromettere l’intera certificazione.

Poiché WCAG 1.3.4 richiede test manuali e non può essere confermato solo tramite scansioni automatizzate, i soggetti coperti dovrebbero integrare casi di test specifici per l’orientazione nei loro processi formali di audit di accessibilità. La documentazione dei risultati dei test in entrambe le orientazioni, verticale e orizzontale, su dispositivi reali dovrebbe essere mantenuta come parte dei registri di conformità all’accessibilità richiesti per l’osservanza normativa e per la certificazione del logo. L’SDK Accsible aiuta le organizzazioni a identificare e affrontare le barriere legate all’orientazione come parte di un approccio olistico al rispetto degli obblighi in evoluzione della Turchia in materia di accessibilità digitale.