Chapitre 13.3 — Orientation & zoom

⏱️ TL;DR — Deux réglages mobiles cassent l’accessibilité si tu les verrouilles. L’orientation : ne force pas le portrait (ou le paysage) — le critère 1.3.4 exige que le contenu marche dans les deux sens, car beaucoup d’utilisateurs ont un appareil fixé en position (fauteuil, support). Le zoom : ne le désactive jamais. Le <meta viewport> avec user-scalable=no ou maximum-scale=1 empêche de pincer pour agrandir — un désastre pour les personnes malvoyantes. Le bon viewport laisse l’utilisateur zoomer librement.

🎯 Objectifs

• Comprendre le critère 1.3.4 Orientation et pourquoi ne pas verrouiller portrait/paysage.
• Écrire un <meta viewport> correct qui n’interdit pas le zoom.
• Reconnaître et bannir user-scalable=no et maximum-scale=1.
• Savoir où le zoom mobile rejoint le reflow (renvoi au chapitre dédié).

Orientation : laisse tourner l’écran

Le critère 1.3.4 Orientation (AA, WCAG 2.1) : le contenu ne doit pas se limiter à une seule orientation (portrait ou paysage), sauf si c’est essentiel (ex. un piano à l’écran, un chèque à photographier en paysage).

Pourquoi ? Parce que beaucoup d’utilisateurs ne peuvent pas tourner leur appareil :

• une personne en fauteuil roulant avec la tablette fixée sur un bras de support ;
• quelqu’un qui tient son téléphone dans un support au lit ou sur un bureau ;
• une personne dont la préhension ne permet pas de pivoter l’appareil à volonté.

Si ton app force le portrait, ces utilisateurs voient un écran de travers ou un message « Tournez votre appareil » qu’ils ne peuvent pas satisfaire.

/* ❌ Verrouiller une orientation via CSS casse le paysage */
@media (orientation: landscape) {
  .app { display: none; }
  .rotate-warning { display: block; }  /* « Tournez votre appareil » */
}

Ne bloque pas non plus l’orientation au niveau natif (manifeste PWA orientation: "portrait", screen.orientation.lock()) sans raison essentielle. Conçois un layout responsive qui s’adapte aux deux sens — c’est de toute façon meilleur pour tout le monde.

♿ Côté utilisateur — Pour une personne dont le téléphone est monté en paysage sur son fauteuil, une app « portrait uniquement » est tout simplement inutilisable : elle ne peut pas décrocher l’appareil pour le tourner. L’orientation forcée n’est pas une contrainte esthétique, c’est une porte fermée.

Zoom : ne le désactive JAMAIS

C’est l’une des erreurs les plus fréquentes et les plus graves. Pour « éviter que la mise en page bouge », des développeurs bloquent le zoom du navigateur dans la balise viewport :

<!-- ❌ INTERDIT : empêche de pincer pour zoomer -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

• user-scalable=no interdit purement le zoom.
• maximum-scale=1 le plafonne à 100 %, donc l’empêche en pratique.

Pour une personne malvoyante, pincer pour agrandir le texte est le geste de survie numéro un sur mobile. Le lui retirer rend des pans entiers du contenu illisibles. Les navigateurs récents ignorent parfois ces attributs par sécurité — mais tu ne dois jamais compter là-dessus ni les écrire.

Le bon viewport, celui à mettre partout :

<!-- ✅ Responsive ET zoom libre -->
<meta name="viewport" content="width=device-width, initial-scale=1">

width=device-width cale la largeur sur l’écran, initial-scale=1 fixe le zoom de départ à 100 % — sans jamais plafonner ni interdire le zoom de l’utilisateur.

⚠️ Piège — Le viewport qui bloque le zoom. On le copie-colle depuis un vieux template ou un tutoriel, « parce que ça évite le zoom involontaire sur les champs iOS ». Le remède est pire que le mal : tu casses l’accessibilité pour toute personne qui a besoin d’agrandir. La bonne solution au « zoom involontaire sur les inputs » iOS, c’est de mettre une taille de police ≥ 16 px sur les champs — pas de désactiver le zoom.

Zoom et reflow vont ensemble

Quand l’utilisateur zoome (au pincement sur mobile, ou via le zoom navigateur), le contenu doit se réagencer proprement sans provoquer de défilement horizontal ni couper du texte. C’est le sujet du reflow, traité en détail ailleurs.

/* ✅ Un layout fluide encaisse le zoom sans casser */
.card {
  max-width: 100%;
  overflow-wrap: break-word;   /* les longs mots ne débordent pas */
}

Retiens le principe : zoom autorisé + layout qui se réagence = contenu lisible à fort grossissement. Les détails (critère 1.4.10, largeur cible, pièges du overflow) sont couverts au chapitre dédié.

🧭 Sur A11yLearn — Le premier proto d’A11yLearn embarquait maximum-scale=1 (hérité d’un starter). Un testeur malvoyant n’arrivait pas à agrandir les énoncés de quiz : blocage total. On a remis le viewport standard (width=device-width, initial-scale=1), passé les champs de formulaire à font-size: 16px pour éviter le zoom auto iOS, et vérifié le reflow à 200 %. Le zoom au pincement fonctionne partout depuis.

📚 Aller plus loin — Critère 1.3.4 Orientation (AA, WCAG 2.1). Pour le zoom et le reflow : Chapitre 7.4 — Taille, zoom & reflow, qui détaille le redimensionnement du texte (1.4.4) et le reflow (1.4.10).

✏️ Exercices

Exercice 1 — Répare le viewport. Tu trouves cette balise dans le <head> : <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">. Qu’est-ce qui cloche, et quelle est la version correcte ?

<meta name="viewport" content="width=device-width, initial-scale=1">

Exercice 2 — L’app « portrait only ». Le PO veut verrouiller l’app en portrait « pour simplifier le design ». Quel critère l’en empêche, et quelle exception existe ?

🧠 Quiz de révision

Chapitre suivant : Lecteurs d’écran mobiles — VoiceOver, TalkBack et la navigation au balayage, ce qui change par rapport au desktop.