Screen Orientation API et expériences responsives
Utiliser les changements d’orientation comme état de mise en page tout en préservant accessibilité, choix et vie privée.
Vous voulez la documentation structurée pour Empreinte ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Screen Orientation API permet d’observer l’orientation actuelle et, dans les contextes compatibles, de demander une orientation préférée. Le design responsive doit considérer l’orientation comme un état de mise en page qui change, pas comme une étiquette d’appareil. Un téléphone peut être tenu dans les deux sens, une fenêtre peut être redimensionnée et une vue partagée peut être plus étroite que l’écran. Basez le rendu sur l’espace disponible, conservez la tâche et n’utilisez l’orientation que lorsqu’elle modifie une décision visible.
La spécification W3C Screen Orientation définit l’objet d’orientation, type, angle, les événements et les conditions de verrouillage. La référence MDN documente l’interface et la compatibilité. Ces sources décrivent ce qu’un navigateur peut exposer ; elles n’imposent ni verrouillage ni historique d’orientation.
Pour la géométrie associée, consultez le guide écran et viewport et le guide d’accessibilité des pointeurs.
Traiter l’orientation comme un état de mise en page
screen.orientation.type décrit des catégories comme portrait-primary ou landscape-primary, tandis que angle indique l’angle par rapport à l’orientation naturelle. Les deux peuvent changer pendant une rotation et l’ordre des événements dépend du navigateur et du système. Attendez que la fenêtre se stabilise plutôt que de considérer un seul événement comme toute la transition.
La plupart des décisions appartiennent au CSS. Les médias (orientation: portrait) peuvent changer une grille et les requêtes de conteneur permettent à un composant de répondre à sa largeur dans une vue partagée ou un document intégré. JavaScript peut utiliser matchMedia ou l’objet d’orientation pour une action précise, comme redimensionner un canevas. Le branchement doit viser un résultat visible, pas un catalogue d’appareils.
L’orientation n’identifie ni téléphone, ni tablette, ni ordinateur, ni session distante. Interface du navigateur, gestion des fenêtres, zoom, aides et clavier virtuel changent l’espace réel. Une fenêtre étroite sur ordinateur reste un état valable. N’inférez pas identité, lieu, âge ou capacité depuis cette valeur.
Préserver la tâche pendant la rotation
La rotation peut survenir pendant une lecture, une édition ou un formulaire. Conservez les données saisies, le défilement pertinent, l’onglet choisi et le contrôle focalisé. Ne reconstruisez pas la page et ne naviguez pas pour un simple changement. Si un composant doit être recréé, restaurez le focus et n’annoncez qu’un changement utile.
Utilisez des pistes flexibles, des libellés qui se replient, des images responsives et des seuils dictés par le contenu. Un formulaire à deux colonnes peut devenir une colonne ; une table large peut montrer les colonnes prioritaires et une vue de débordement accessible au clavier. Un contrôle caché en portrait doit avoir une action équivalente. Une action essentielle ne doit jamais dépendre d’un geste propre à une orientation.
Clavier virtuel, barre du navigateur et séparation d’une vue peuvent masquer du contenu. Gardez le champ actif visible, évitez les actions fixes recouvertes et repositionnez les dialogues lorsque la fenêtre visuelle change. La spécification CSSOM View décrit la géométrie ; le produit doit garantir une interaction possible.
Demander une orientation pour un besoin réel
screen.orientation.lock() est une demande, pas une commande universelle. Visibilité, contexte, activation utilisateur, plein écran et politique de plateforme imposent des conditions. La promesse peut être rejetée. La page doit rester utilisable lorsque le verrouillage est impossible.
Un jeu, un aperçu caméra ou une présentation peuvent nécessiter un rapport stable. Expliquez l’effet avant la demande, offrez une sortie claire et libérez le verrou à la fin. Ne verrouillez pas pour simplifier une mise en page de bureau, classer les visiteurs ou empêcher l’adaptation responsive.
Un mode global doit commencer par une action explicite. Une page ouverte par un lien ne doit pas tourner soudainement ni enfermer la personne. En cas de refus, affichez la mise en page responsive normale et conservez la tâche. Le refus est un résultat de compatibilité, pas une information sur l’appareil.
Utiliser les événements sans course
L’objet d’orientation expose change. Le gestionnaire lit l’état courant, ne met à jour que le composant concerné et accepte les notifications répétées. Ajoutez resize ou la fenêtre visuelle si l’espace réel compte ; ces changements sont liés mais différents.
Évitez le travail synchrone coûteux. Planifiez une mise à jour limitée, annulez le travail périmé et gardez les entrées réactives. Pour un média, une carte ou un canevas, conservez le contenu sémantique en changeant seulement le rendu. Un échec de redessin doit laisser une alternative, pas une zone vide.
Protégez le comportement optionnel par une détection de fonctionnalité, vérifiez la méthode et capturez le rejet de lock(). Les requêtes CSS et la gestion du redimensionnement constituent un repli correct. N’accumulez pas silencieusement orientation, angle, fenêtre et écran lorsque l’API manque.
Garder accessibilité et contrôle visibles
Le reflow doit préserver titres, régions, libellés et ordre de lecture. Testez le clavier après rotation, notamment les indicateurs de focus près du bord visible. Un lecteur d’écran reçoit un état utile lorsque les contrôles ont réellement bougé, pas l’angle brut de chaque rotation.
Respectez zoom, agrandissement du texte, réduction des mouvements et contraste élevé ou couleurs forcées. Une interface correcte à l’échelle par défaut peut échouer avec texte agrandi ou clavier ouvert. Conservez cibles, contraste et messages d’erreur. WCAG 2.2 guide ces résultats ; l’orientation seule ne décide pas de la conformité.
Un mode dépendant de l’orientation doit offrir une sortie visible, accessible au clavier et sans perte de travail. Expliquez quand le navigateur ou le système contrôle la rotation et quand l’application ne fait que demander une préférence. Ne présentez pas un refus comme une mauvaise configuration de l’utilisateur.
Tester les comportements, pas les catégories d’appareils
Testez portrait et paysage, fenêtres étroites et larges, texte agrandi, clavier virtuel, entrée clavier et tactile, mouvement réduit et navigateur sans l’API. Vérifiez la lecture, l’action principale, la récupération d’erreur et la sortie du mode verrouillé. Ajoutez une largeur intermédiaire propice aux retours à la ligne défectueux.
Consignez version, fenêtre, orientation et préférences comme configuration de test. Une capture prouve seulement cette configuration, pas une caractéristique stable de la personne. Utilisez des données synthétiques et n’envoyez pas d’historique brut à l’analytique. Si une télémétrie est nécessaire, préférez un résultat agrégé à un ensemble d’angles, dimensions et durées.
Définir un contrat responsive respectueux
Avant de lire une propriété, écrivez la décision utilisateur qu’elle sert : placer un aperçu à côté des contrôles lorsque le composant est assez large, par exemple. Préférez CSS et matchMedia local. Si un service a réellement besoin d’un résultat, documentez but, durée, accès et choix de la personne, puis supprimez les champs inutiles.
L’orientation peut contribuer à une empreinte avec d’autres valeurs, mais un layout responsive n’a pas besoin de ce profil. N’utilisez pas portrait ou paysage pour un compte, un risque ou une éligibilité. Ordinateur partagé, écran pivoté, émulateur et fenêtre redimensionnée donnent la même valeur. Une valeur absente ou grossière est normale.
Vérifiez séparément la fenêtre visuelle : barre du navigateur et clavier peuvent masquer un champ après la rotation. Les zones sûres et recouvrements temporaires sont des contraintes de rendu, pas des propriétés durables de l’appareil.
Définissez un résultat pour chaque état, par exemple ouvrir et fermer la navigation sans perdre le focus ou conserver sous-titres et action principale quand un aperçu change de taille. Ces résultats valent mieux qu’une liste de modèles et facilitent la révision de compatibilité.
Pour les analyses et expériences, mesurez le résultat de la tâche plutôt qu’un profil d’angle, de dimensions et de durées. L’affectation expérimentale doit rester indépendante de la demande de verrouillage afin que son refus laisse l’interface de base disponible.
Revoyez le contrat lorsqu’une fonction dépendante de l’orientation est ajoutée, supprimez les propriétés sans décision visible et conservez les formulations conditionnelles et le repli accessible dans chaque traduction.
Le repli accessible fait partie de la fonction : titres, libellés et données restent présents lorsque le verrou est refusé, afin de poursuivre dans une fenêtre portrait ou redimensionnée.
Les choix d’orientation doivent être réversibles. Stockez la préférence explicite séparément des observations du navigateur et proposez une réinitialisation, sans en faire une conclusion sur l’appareil.
Le repli conserve aussi la récupération d’erreur et indique clairement l’action suivante.
Il doit également afficher l’état et l’étape suivante afin qu’un résultat de compatibilité ne bloque pas la personne.
Les contrôles restent visibles et utilisables même sans le rapport attendu.
Checklist pratique
- Utilisez CSS ou des requêtes de conteneur pour le reflow ; JavaScript reste ciblé.
- Conservez valeurs, focus, ordre de lecture et récupération pendant la rotation.
- Demandez le verrou après une action et prévoyez un repli responsive en cas de refus.
- Testez zoom, clavier, aides et largeurs intermédiaires dans les deux orientations.
- Gardez les mesures locales sauf décision optionnelle documentée.
Prévoir transitions et récupération
Une rotation peut accompagner une navigation, une requête ou une erreur de validation. Gardez ces états séparés et ne soumettez pas deux fois un formulaire. Médias, canevas et composants intégrés doivent conserver contenu, sous-titres et focus ; fournissez une alternative lisible si l’espace manque. L’URL et l’historique restent stables. Un rendu serveur peut commencer de façon prudente puis confirmer la fenêtre sans effacer le texte. Les requêtes de conteneur conviennent aux panneaux et iframes. Les animations restent interruptibles et respectent la réduction des mouvements. Documentez les navigateurs testés et le repli sans garantir un ordre identique des événements. Pour diagnostiquer, notez le résultat visible et la configuration, pas un inventaire persistant de l’écran.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.