WCAG 1.3.4 : Orientation

Ce que signifie cette règle

WCAG 1.3.4 Orientation est un critère de niveau AA introduit dans WCAG 2.1 et reconduit dans WCAG 2.2. Il stipule que le contenu ne doit pas se verrouiller sur une seule orientation d’affichage — soit portrait (verticale), soit paysage (horizontale) — sauf si cette orientation spécifique est essentielle à la fonction du contenu. En pratique, cela signifie que les pages web et les applications web doivent réagir correctement et rester entièrement utilisables, que l’appareil de l’utilisateur soit tenu verticalement ou horizontalement, et que l’orientation soit contrôlée par le système d’exploitation de l’appareil ou par les préférences de l’utilisateur.

Le critère vise les situations où les développeurs utilisent des media queries CSS, du JavaScript ou des API d’appareil pour restreindre délibérément le contenu à une seule orientation. Une violation courante consiste à afficher un message du type « Veuillez faire pivoter votre appareil en mode paysage » tout en masquant ou désactivant simultanément tout le contenu interactif en mode portrait. Une autre violation se produit lorsqu’une application web applique une transformation CSS ou force la rotation de la fenêtre d’affichage, en ignorant le réglage d’orientation de l’appareil de l’utilisateur.

Ce qui est considéré comme conforme : Le contenu est accessible à la fois en orientation portrait et paysage. Tous les textes, éléments interactifs, formulaires, éléments de navigation et médias restent visibles et utilisables quelle que soit l’orientation de l’appareil. La mise en page peut s’adapter — en utilisant des techniques de design responsive telles que CSS Flexbox, CSS Grid ou des media queries — mais rien n’est supprimé ou rendu inutilisable sur la seule base de l’orientation.

Ce qui est considéré comme non conforme : Un contenu qui masque, désactive ou bloque l’interaction dans une orientation ; des messages demandant aux utilisateurs de faire pivoter leur appareil sans fournir d’alternative fonctionnelle ; du JavaScript qui écoute DeviceOrientationEvent ou screen.orientation puis verrouille ou désactive des parties de l’interface ; ou du CSS qui utilise @media (orientation: portrait) pour afficher une superposition bloquante ou appliquer display: none à un contenu critique.

L’exception d’essentiel : WCAG reconnaît que certains contenus ont une finalité intrinsèquement liée à une orientation spécifique. Une application de clavier de piano peut légitimement exiger le mode paysage, car une mise en page en portrait ne peut pas afficher suffisamment de touches pour être utile musicalement. Une fonctionnalité de dépôt de chèque bancaire qui repose sur la capture par la caméra d’un chèque horizontal peut nécessiter le mode paysage. Une interface de casque de réalité virtuelle peut nécessiter une orientation fixe pour fonctionner. Cependant, le seuil pour « essentiel » est élevé — la simple commodité du développeur ou une préférence esthétique ne suffisent pas. L’exception doit être justifiée par une exigence fondamentale du contenu lui-même, et non par un choix de design.

Pourquoi c’est important

Les restrictions d’orientation affectent de manière disproportionnée les personnes ayant des handicaps physiques et moteurs. Considérons une personne en fauteuil roulant dont la tablette est fixée en position portrait sur l’accoudoir de son fauteuil. Elle ne peut pas physiquement incliner l’appareil, de sorte que tout contenu qui exige l’orientation paysage devient totalement inaccessible. Ce n’est pas un cas marginal hypothétique — le montage d’appareils de technologie d’assistance dans des orientations fixes est une adaptation courante pour les personnes atteintes de pathologies telles que la paralysie cérébrale, les lésions de la moelle épinière, la SLA ou une arthrite sévère.

Au-delà des appareils montés, de nombreux utilisateurs s’appuient sur la fonction de verrouillage d’orientation du système d’exploitation pour des raisons sans lien avec le handicap. Une personne allongée dans son lit peut verrouiller son téléphone en mode portrait pour empêcher l’écran de basculer constamment. Une personne atteinte de troubles vestibulaires — une pathologie affectant l’oreille interne et l’équilibre — peut trouver les changements brusques de mise en page causés par les changements d’orientation désorientants ou physiquement nauséeux. Forcer ces utilisateurs à déverrouiller l’orientation de leur appareil pour accéder à votre contenu crée une barrière inutile et discriminatoire.

L’accessibilité cognitive est également un facteur. Les personnes ayant des handicaps cognitifs bénéficient souvent de mises en page cohérentes et prévisibles. Une application qui bloque soudainement le contenu ou affiche un message de type erreur demandant de faire pivoter l’appareil peut être déroutante et alarmante, en particulier pour les utilisateurs qui peuvent ne pas comprendre pourquoi leur appareil affiche un avertissement au lieu du contenu attendu.

D’un point de vue ergonomique et commercial, les restrictions d’orientation nuisent à tous les utilisateurs. Une part significative du trafic web mobile se fait en mode portrait, et restreindre un site au mode paysage peut entraîner un abandon immédiat. Les moteurs de recherche prennent également de plus en plus en compte la compatibilité mobile et les Core Web Vitals — y compris la stabilité de la mise en page — dans leurs algorithmes de classement, ce qui signifie que les problèmes liés à l’orientation peuvent avoir un impact négatif mesurable sur les performances SEO et le trafic organique.

À l’échelle mondiale, environ 1,3 milliard de personnes vivent avec une forme de handicap selon l’Organisation mondiale de la Santé. Une proportion significative de ce groupe utilise des appareils mobiles comme principal, voire unique, moyen d’accès à internet, ce qui rend l’accessibilité liée à l’orientation sur mobile particulièrement déterminante.

Règles Axe-core associées

WCAG 1.3.4 Orientation nécessite des tests manuels. Il n’existe aucune règle axe-core automatisée qui détecte de manière fiable les restrictions d’orientation, car la violation dépend du comportement à l’exécution, de la logique de rendu conditionnel et de l’état physique d’un appareil — autant d’éléments qu’aucune analyse statique du DOM ni aucun scan automatisé de page ne peuvent évaluer. Ce qui suit explique pourquoi l’automatisation est insuffisante et ce que les testeurs manuels doivent rechercher :

• Aucune règle axe-core automatisée (tests manuels requis) : Les analyseurs d’accessibilité automatisés tels qu’axe-core, Lighthouse ou IBM Equal Access Checker analysent le DOM et le CSSOM à un instant donné. Ils ne peuvent pas simuler la rotation d’un appareil, évaluer ce qui arrive à la mise en page lorsque screen.orientation change, ni déterminer si un bloc CSS @media (orientation: landscape) masque un contenu critique. Un analyseur peut constater que tous les éléments sont présents et techniquement visibles dans l’orientation testée, sans savoir que la moitié d’entre eux disparaissent dans l’orientation alternative. C’est pourquoi WCAG 1.3.4 est classé comme nécessitant des tests manuels — aucun outil ne peut remplacer le fait de faire réellement pivoter un appareil ou de simuler la rotation dans les outils de développement d’un navigateur.
• Détection de verrouillage d’orientation en JavaScript : Les scripts qui appellent screen.orientation.lock() ou écoutent window.addEventListener('orientationchange', ...) afin de rediriger ou de désactiver du contenu ne peuvent pas être détectés par une analyse statique. Un linter pourrait signaler l’utilisation de ces API dans le code source, mais il ne peut pas déterminer si le comportement qui en résulte constitue une violation de WCAG sans jugement humain sur l’application ou non d’une exception essentielle.
• Superpositions bloquantes basées sur le CSS : Une feuille de style peut utiliser @media (orientation: portrait) { .orientation-warning { display: block; } } pour afficher un message bloquant en plein écran en mode portrait. Axe-core, en scannant la page en mode paysage, ne rencontrera jamais cet élément dans un état visible et ne signalera aucun problème. Seuls des tests en mode portrait — ou l’inspection du CSS à la recherche de modèles de blocage conditionnels à l’orientation — révèlent la violation.

Comment tester

1. Exécuter un scan automatisé comme base de référence : Ouvrez la page dans Chrome, Firefox ou Edge. Utilisez l’extension de navigateur axe DevTools ou lancez un audit d’accessibilité Lighthouse pour établir une base de référence. Bien que ces outils ne détectent pas directement les violations liées à l’orientation, ils peuvent signaler des problèmes de design responsive connexes, des problèmes de balise meta viewport ou des ARIA manquants qui aggravent les échecs d’accessibilité liés à l’orientation. Notez qu’un rapport automatisé sans erreur ne confirme pas la conformité au critère 1.3.4.
2. Utiliser l’émulation d’appareil des DevTools du navigateur : Dans Chrome ou Edge, ouvrez DevTools (F12), cliquez sur l’icône de la barre d’outils d’appareil (Ctrl+Shift+M / Cmd+Shift+M) et sélectionnez un appareil mobile tel qu’un iPhone 14 ou un Galaxy S21. Basculez entre les orientations portrait et paysage à l’aide de l’icône de rotation dans la barre d’outils d’appareil. Vérifiez systématiquement que tout le contenu — navigation, titres, texte principal, formulaires, boutons, images et médias — reste visible et utilisable dans les deux orientations. Recherchez des superpositions bloquantes, des sections masquées ou des éléments interactifs désactivés qui apparaissent dans une orientation mais pas dans l’autre.
3. Tester sur de vrais appareils : Connectez un appareil Android ou iOS et ouvrez la page dans le navigateur mobile. Faites physiquement pivoter l’appareil entre les modes portrait et paysage. Confirmez que le verrouillage d’orientation du système d’exploitation (lorsqu’il est activé) ne provoque pas de dysfonctionnement du contenu ni l’affichage d’une invite de rotation. Testez avec le verrouillage d’orientation activé et désactivé.
4. Tests avec lecteur d’écran et simulation d’orientation : Sur iOS avec VoiceOver activé (triple clic sur le bouton latéral), parcourez la page en orientation portrait à l’aide des gestes de balayage. Puis passez en mode paysage et vérifiez que l’ordre de lecture de VoiceOver et les noms accessibles restent corrects. Sur Android avec TalkBack, effectuez le même test. Utilisez NVDA avec Firefox sur ordinateur et simulez l’orientation via DevTools pour vérifier que l’arbre d’accessibilité reste cohérent entre les orientations.
5. Inspecter le CSS et le JavaScript à la recherche de restrictions d’orientation : Dans DevTools, ouvrez le panneau Sources ou Elements et recherchez dans la feuille de style les media queries orientation: portrait et orientation: landscape. Examinez ce que fait chaque bloc : masque-t-il du contenu avec display: none, applique-t-il une superposition bloquante ou se contente-t-il d’ajuster la mise en page ? Recherchez dans les fichiers JavaScript les occurrences de screen.orientation, orientationchange et screen.orientation.lock. Évaluez si les modèles trouvés verrouillent l’interface ou bloquent du contenu.
6. Vérifier l’exception d’essentiel : Si le site restreint intentionnellement l’orientation, confirmez qu’un cas d’usage essentiel documenté et justifié existe. L’exception doit être motivée par le contenu, non par l’esthétique. Documentez votre constat avec une capture d’écran et la justification spécifique.

Comment corriger

Superposition CSS bloquante en mode portrait — Incorrect

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

Superposition CSS bloquante en mode portrait — Correct

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

Verrouillage d’orientation en JavaScript — Incorrect

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

Verrouillage d’orientation en JavaScript — Correct

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

Balise meta viewport empêchant le changement d’orientation — Incorrect

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

Balise meta viewport empêchant le changement d’orientation — Correct

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

Erreurs courantes

• Utiliser @media (orientation: portrait) pour appliquer display: none aux menus de navigation, barres latérales ou zones de contenu principal. Toute media query CSS liée à l’orientation qui retire du contenu de l’affichage — plutôt que de simplement le repositionner — est une violation potentielle. Auditez chaque media query d’orientation dans votre feuille de style pour vous assurer qu’elle ne modifie que la mise en page, pas la disponibilité du contenu.
• Appeler screen.orientation.lock() pour des applications non essentielles. Cette API Web est destinée aux jeux et à certains cas d’usage média spécifiques. L’utiliser dans une application web standard ou un site e-commerce pour « améliorer l’esthétique » en mode paysage ne relève pas de l’exception essentielle et crée une violation directe de WCAG 1.3.4.
• Afficher un écran de démarrage « faites pivoter votre appareil » sans alternative accessible. Même si un bref rappel d’orientation est affiché, il ne doit jamais bloquer l’accès au contenu. S’il est affiché, il doit pouvoir être ignoré, ne pas recouvrir le contenu principal et être présenté comme une suggestion plutôt qu’une exigence.
• Supposer que les utilisateurs mobiles préfèrent toujours le mode paysage pour le contenu vidéo. Intégrer un lecteur vidéo qui désactive les contrôles de lecture ou le bouton de lecture en mode portrait — obligeant les utilisateurs à faire pivoter l’appareil avant de pouvoir interagir — viole le critère 1.3.4, sauf si le format vidéo ne peut réellement pas être rendu en portrait (ce qui est presque jamais vrai pour la vidéo web standard).
• Appliquer transform: rotate(90deg) en CSS à l’élément <body> ou à un conteneur racine dans une orientation. Cela simule un changement d’orientation en CSS plutôt que de laisser l’appareil le gérer naturellement, ce qui crée des mises en page cassées, du contenu hors écran et une confusion sévère de l’arbre d’accessibilité pour les lecteurs d’écran.
• Ne pas tester le comportement d’orientation pendant la QA parce que les équipes ne testent que sur des navigateurs de bureau. La simulation d’orientation dans les DevTools des navigateurs de bureau n’est pas toujours utilisée pendant les cycles de QA standard. L’orientation doit être un élément explicite des plans de test mobile, vérifié sur de vrais appareils iOS et Android.
• Outrepasser le comportement d’orientation à l’intérieur d’iframes sans tenir compte de l’état d’orientation de la page parente. Les widgets tiers, cartes intégrées et iframes de paiement peuvent verrouiller l’orientation de manière indépendante. Même si votre page est conforme, héberger une iframe verrouillée rend votre page non conforme, à moins que l’exception essentielle de l’iframe ne soit documentée.
• Utiliser une détection d’agent utilisateur côté serveur pour servir une version « paysage uniquement » d’une page aux utilisateurs mobiles. Rediriger les utilisateurs mobiles vers une URL distincte qui ne fonctionne qu’en mode paysage, sans fournir de solution de repli compatible portrait, constitue une violation systémique qui crée également un problème de SEO et de canonisation d’URL.
• Appliquer des restrictions d’orientation uniquement dans les versions de production, les rendant invisibles pendant les tests de développement. Les feature flags ou les frameworks d’A/B testing activent parfois le code de verrouillage d’orientation uniquement dans des environnements spécifiques ou pour certains segments d’utilisateurs, ce qui fait que la violation est manquée lors des audits d’accessibilité pré-lancement.
• Supposer que l’exception essentielle s’applique parce qu’un designer préfère la mise en page paysage. L’exception essentielle est un seuil juridique et éthique élevé. Elle exige que la fonction principale du contenu soit fondamentalement impossible dans l’orientation alternative — et non qu’elle soit simplement plus esthétique ou que l’équipe ait manqué de temps pour implémenter une mise en page portrait responsive.

Lien avec la réglementation d’accessibilité de la Turquie

La Circulaire présidentielle n° 2025/10 de la Turquie, publiée au Journal officiel (Resmî Gazete) n° 32933 le 21 juin 2025, établit un cadre national complet pour l’accessibilité numérique. La Circulaire impose aux entités concernées de se conformer à WCAG 2.2 niveau AA, qui inclut explicitement WCAG 1.3.4 Orientation. Cela signifie que tout service numérique ou site web exploité par une entité couverte ne doit pas restreindre le contenu à une seule orientation, reflétant l’intention de la Circulaire de garantir que tous les citoyens — y compris les personnes handicapées — puissent accéder aux services numériques, quelle que soit la manière dont ils interagissent physiquement avec leurs appareils.

Les entités couvertes par la Circulaire et tenues d’atteindre la conformité de niveau AA comprennent : les institutions et organismes publics (tous les organismes gouvernementaux exploitant des sites web et des services numériques), les banques et institutions financières, les hôpitaux et prestataires de soins de santé, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les plateformes d’e-commerce, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE). Pour ces entités, les restrictions d’orientation qui violent le critère 1.3.4 — telles que des portails gouvernementaux qui exigent un accès en mode paysage uniquement ou des applications bancaires verrouillées en mode portrait pour des raisons non essentielles — constituent une non-conformité directe à une réglementation nationale contraignante.

Le Logo d’accessibilité (Erişilebilirlik Logosu), délivré par le ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı), est une marque de certification qui signale la conformité à la norme nationale d’accessibilité. L’obtention de la conformité de niveau AA est un prérequis pour obtenir ce logo. Les organisations qui souhaitent obtenir l’Erişilebilirlik Logosu doivent démontrer que leurs propriétés numériques satisfont à tous les critères de niveau A et de niveau AA, y compris 1.3.4. Un échec lié à une restriction d’orientation — même dans une section mineure d’un site — peut compromettre l’ensemble de la certification.

Parce que WCAG 1.3.4 nécessite des tests manuels et ne peut pas être confirmé par des scans automatisés uniquement, les entités couvertes devraient intégrer des cas de test spécifiques à l’orientation dans leurs processus formels d’audit d’accessibilité. La documentation des résultats de test en orientations portrait et paysage sur de vrais appareils devrait être conservée dans le cadre des dossiers de conformité en matière d’accessibilité exigés pour la conformité réglementaire et la certification du logo. Le SDK Accsible aide les organisations à identifier et à traiter les obstacles liés à l’orientation dans le cadre d’une approche globale visant à répondre aux obligations croissantes de la Turquie en matière d’accessibilité numérique.