Screen Orientation API y experiencias adaptables
Usa los cambios de orientación como estado del diseño adaptable y conserva accesibilidad, elección y privacidad.
Quieres la documentación estructurada de Huella digital?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Screen Orientation API permite observar la orientación actual y, en contextos compatibles, solicitar una orientación preferida. El diseño adaptable debe tratar la orientación como una condición cambiante del diseño, no como una etiqueta del dispositivo. Un teléfono puede sostenerse en ambos sentidos, una ventana de portátil puede redimensionarse y una vista dividida puede ser más estrecha que la pantalla. Diseña según el espacio disponible, conserva la tarea de la persona y usa orientación solo cuando cambie una decisión visible del producto.
La especificación W3C Screen Orientation define el objeto de orientación, type, angle, los eventos de cambio y las condiciones para bloquearla. La referencia de MDN documenta la interfaz y la compatibilidad. Estas fuentes describen lo que un navegador puede exponer; no obligan a bloquear la pantalla ni a guardar un historial.
Para la geometría relacionada, consulta la guía de pantalla y viewport y la guía de accesibilidad de puntero.
Trata la orientación como estado de diseño
screen.orientation.type describe categorías como portrait-primary o landscape-primary, y angle indica el ángulo respecto a la orientación natural. Ambos pueden cambiar durante una rotación y el orden de eventos depende del navegador y del sistema operativo. Espera a que el viewport se estabilice en vez de asumir que un evento representa toda la transición.
La mayoría de decisiones pertenecen a CSS. Las consultas (orientation: portrait) pueden cambiar una cuadrícula y las consultas de contenedor permiten que un componente responda a su propio ancho en una vista dividida o un documento incrustado. JavaScript puede usar matchMedia o el objeto de orientación para una conducta concreta, como cambiar un lienzo. La condición debe corresponder al resultado visible, no a un catálogo de dispositivos.
La orientación no identifica un teléfono, tableta, escritorio o sesión remota. La interfaz del navegador, la gestión de ventanas, el zoom, la asistencia y el teclado virtual cambian el espacio efectivo. Una ventana estrecha de escritorio sigue siendo válida. No deduzcas identidad, ubicación, edad o capacidad a partir de este valor.
Conserva la tarea durante la rotación
La rotación puede ocurrir mientras alguien lee, edita o rellena un formulario. Conserva los datos escritos, el desplazamiento útil, la pestaña seleccionada y el control enfocado. No reconstruyas la página ni navegues solo por un cambio de orientación. Si debes reconstruir un componente, restaura el foco de forma explícita y anuncia únicamente un cambio relevante.
Usa pistas flexibles, etiquetas que puedan saltar de línea, imágenes adaptables y puntos de corte basados en el contenido. Un formulario de dos columnas puede pasar a una; una tabla ancha puede mostrar columnas prioritarias y una vista de desbordamiento accesible por teclado. Un control oculto en vertical debe tener una acción equivalente. Una acción esencial nunca debe depender de un gesto de una sola orientación.
El teclado virtual, la barra del navegador o una ventana dividida pueden cubrir contenido. Mantén visible el campo activo, evita acciones fijas tapadas y recoloca diálogos cuando cambie el viewport visual. La especificación CSSOM View define la geometría; el producto debe garantizar el resultado operable.
Solicita orientación solo cuando sea necesario
screen.orientation.lock() es una solicitud, no una orden universal. La especificación y la documentación del navegador imponen condiciones de visibilidad, contexto, activación del usuario, pantalla completa y política de plataforma. La promesa puede rechazarse. La página debe seguir funcionando si no se puede bloquear.
Un juego, una vista de cámara o una presentación pueden necesitar una proporción estable. Explica el efecto antes de solicitarlo, ofrece una salida visible y libera el bloqueo al terminar. No bloquees para simplificar un diseño de escritorio, clasificar visitantes o impedir que el diseño adaptable responda.
El modo debe comenzar con una acción explícita. Una página abierta desde un enlace no debe girar de repente ni atrapar a la persona. Si el navegador rechaza la solicitud, muestra el diseño normal y conserva la tarea. El rechazo es un resultado de compatibilidad, no una señal sobre el dispositivo.
Usa eventos sin carreras
El objeto de orientación expone el evento change. El controlador debe leer el estado actual, actualizar solo el componente afectado y tolerar notificaciones repetidas. Combínalo con resize o viewport visual cuando importe el espacio real; son cambios relacionados, pero no equivalentes.
Evita trabajo síncrono costoso. Programa una actualización acotada, cancela trabajo obsoleto y conserva la respuesta de entrada. Al redimensionar medios, mapas o lienzos, conserva su contenido semántico. Un redibujado fallido debe dejar una alternativa útil y no una zona vacía.
Protege el comportamiento opcional con detección de capacidades, comprueba el método que usarás y captura el rechazo de lock(). Las consultas CSS y resize son un retorno válido. No recolectes silenciosamente orientación, ángulo, viewport y pantalla cuando falte la API.
Mantén visibles accesibilidad y control
El reflujo debe conservar títulos semánticos, regiones, etiquetas y orden de lectura. Prueba la navegación con teclado después de girar, incluidos los indicadores de foco cerca del borde visible. Un lector de pantalla solo necesita un mensaje útil, no el ángulo bruto de cada giro.
Respeta zoom, aumento de texto, movimiento reducido y alto contraste o colores forzados. Una interfaz que cabe al tamaño predeterminado puede fallar con texto ampliado o el teclado abierto. Conserva objetivos táctiles, contraste y mensajes de error. WCAG 2.2 orienta estos resultados; la orientación por sí sola no determina la conformidad.
Un modo dependiente de orientación necesita una salida visible y alcanzable con teclado que no borre el trabajo. Explica cuándo el navegador o el sistema controla el giro y cuándo la aplicación solo solicita una preferencia. No presentes el rechazo como una configuración incorrecta de la persona.
Prueba conductas, no categorías de dispositivos
Prueba vertical y horizontal, ventanas estrechas y anchas, texto ampliado, teclado virtual, entrada de teclado y táctil, movimiento reducido y un navegador sin la API. En cada caso verifica lectura, acción principal, recuperación de errores y salida del modo bloqueado. Incluye un ancho intermedio donde el salto de línea sea difícil.
Registra versión del navegador, viewport, orientación y preferencias como configuración de prueba. Una captura solo demuestra esa configuración, no una característica estable de quien la ejecutó. Usa datos sintéticos y evita enviar historiales de orientación a analítica. Si necesitas telemetría, registra un resultado agregado, no un conjunto de ángulo, dimensiones y tiempos.
Define un contrato adaptable y respetuoso
Antes de leer una propiedad escribe la decisión que respalda, como colocar la vista previa junto a los controles cuando el componente sea suficientemente ancho. Prefiere CSS y matchMedia local. Si un servicio necesita un resultado para mejorar el producto, documenta finalidad, retención, acceso y elección, y elimina campos que no cambien la decisión.
La orientación puede contribuir a una huella junto con otros valores, pero el diseño adaptable no exige crear ese perfil. No uses vertical u horizontal como señal de cuenta, riesgo o elegibilidad. Un equipo compartido, un monitor girado, un emulador y una ventana redimensionada pueden dar el mismo valor. La ausencia o poca precisión son normales.
Comprueba el viewport visual por separado: una barra del navegador o el teclado pueden ocultar un campo después del giro. Las áreas seguras y las superposiciones temporales son límites de renderizado, no propiedades permanentes del dispositivo.
Define un resultado para cada estado, como abrir y cerrar la navegación sin perder el foco o mantener subtítulos y la acción principal al redimensionar una vista previa. Estos resultados son más útiles que una lista de modelos y ayudan a revisar la compatibilidad.
En análisis y experimentos registra el resultado de la tarea, no un perfil formado por ángulo, dimensiones y tiempos. La asignación del experimento debe ser independiente de la solicitud de bloqueo para que rechazarla no quite la interfaz básica.
Revisa el contrato al añadir una función dependiente de orientación, elimina propiedades que ya no sustentan una decisión visible y conserva el lenguaje condicional y el retorno accesible en todas las traducciones.
El retorno accesible forma parte de la función: conserva títulos, etiquetas y datos de la tarea cuando se rechaza el bloqueo, para que la persona continúe en una ventana vertical o redimensionada.
Las preferencias de orientación deben poder deshacerse. Guarda la elección explícita por separado de las observaciones del navegador y ofrece un restablecimiento, sin convertirla en una conclusión sobre el dispositivo.
El retorno debe conservar la recuperación de errores y explicar la siguiente acción.
También debe mostrar el estado y el siguiente paso para que la compatibilidad no deje a la persona sin salida.
Aunque falte la proporción esperada, los controles del componente deben seguir visibles y operables.
Lista práctica
- Usa CSS o consultas de contenedor para reflujo; reserva JavaScript para una conducta concreta.
- Conserva valores, foco, orden de lectura y recuperación al girar.
- Solicita el bloqueo tras una acción del usuario y ofrece retorno adaptable si se rechaza.
- Prueba zoom, teclado, asistencia y anchos intermedios en ambas orientaciones.
- Mantén las mediciones locales salvo una decisión opcional y documentada.
Planifica transiciones y recuperación
Un giro puede coincidir con navegación, una petición pendiente o un error de validación. Mantén esos estados separados y conserva el borrador sin repetir el envío. Medios, lienzos y componentes incrustados deben conservar contenido, subtítulos y foco; ofrece una alternativa legible si no caben. La URL y el historial no deben cambiar por la orientación. La interfaz renderizada en servidor puede empezar de forma conservadora y reconciliar el viewport sin borrar texto. Prefiere consultas de contenedor en paneles e iframe. Las animaciones deben poder interrumpirse y respetar movimiento reducido. Documenta navegadores probados y el comportamiento de retorno, sin prometer el mismo orden de eventos. Para investigar un fallo registra el resultado visible y la configuración de prueba, no un inventario persistente de pantalla.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.