Un recorrido virtual debe recibir a quien utiliza ratón, pantalla táctil, teclado o tecnología de apoyo. La accesibilidad comienza en la tarea: entender un lugar y elegir el siguiente paso. La interfaz puede ofrecer varias maneras de lograrlo sin exigir gestos complejos o movimiento continuo para poder entrar.
Enumera las tareas esenciales antes de diseñar controles
Define qué información necesita obtener cualquier visitante. En un edificio conceptual podría ser reconocer la entrada principal, entender la conexión con el patio e identificar los espacios representados. Distingue estas tareas de los efectos opcionales. Girar continuamente el modelo permite inspeccionarlo, pero no es la única manera de comunicar esas relaciones arquitectónicas.
Escribe una ruta equivalente mediante destinos con nombre y una descripción legible. Quien elija “Entrada” y después “Patio” debería entender la conexión importante que observa otra persona al mover la cámara manualmente. Esto no exige crear un control para cada elemento decorativo. Exige mantener disponible la información arquitectónica relevante y la ruta de consulta mediante una secuencia comprensible.
Ofrece teclado útil y nombres claros
La guía de teclado de W3C pide alternativas a las funciones de puntero sin exigir tiempos precisos de pulsación. Utiliza botones y enlaces habituales cuando sea posible, con nombres como “Vista del edificio”, “Acercar” y “Restablecer vista”. Un foco visible indica dónde ocurrirá la acción. Evita controles que solo respondan cuando se sostiene una tecla durante un tiempo específico.
Mantén un orden de foco coherente con el orden visual. Entrar al visor no debe atrapar a la persona ni impedirle alcanzar el resto de la página. Cuando cambie la vista seleccionada, muestra su nombre en texto legible. Quien usa lector de pantalla necesita nombres y estados útiles, en lugar de iconos sin etiqueta. Prueba la ruta completa hasta el formulario, además del primer botón de cámara.
Incluye una alternativa de puntero al arrastre
El teclado y las alternativas a arrastrar resuelven problemas relacionados, pero diferentes. W3C explica que alguien con pantalla táctil o un puntero adaptado quizá pueda tocar sin lograr un arrastre preciso. Por ello, un lienzo que depende de arrastrar puede seguir siendo difícil de utilizar aunque exista una ruta mediante teclado.
Ofrece botones de vistas u otras acciones sencillas de toque que permitan completar la navegación importante. Acercar, alejar y restablecer reducen la necesidad de gestos repetidos. Haz controles cómodos y distingue claramente acciones contiguas. Comprueba el comportamiento en un dispositivo real: la página debe desplazarse de forma natural cuando se lee y la exploración debe comenzar mediante una acción intencional.
Permite controlar movimiento y orientación
El movimiento de cámara puede desorientar, sobre todo si empieza inesperadamente o continúa mientras se intenta leer. La orientación de W3C sobre animación recomienda respetar preferencias y permitir desactivar movimiento no esencial. Los cambios a destinos con nombre pueden ser inmediatos cuando se pide reducir movimiento. Restablecer ofrece un lugar confiable desde el cual recuperar orientación.
La animación continua no es un requisito del 3D interactivo. Three.js muestra cómo renderizar cuando cambian escena o cámara. Este enfoque puede sostener un visor tranquilo que espera instrucciones en vez de exigir atención. Si una transición resulta útil, dale un propósito y deja claro el destino final. Evita iniciar un giro interminable simplemente porque el visor apareció en pantalla.
Acompaña la escena con una explicación equivalente
El contenido visual necesita una alternativa textual apropiada. En una escena arquitectónica compleja, una etiqueta breve puede no comunicar las relaciones útiles. Añade una descripción general, nombres de espacios y una explicación de sus conexiones. Un esquema bidimensional puede ayudar a otros lectores y también requiere su propia explicación accesible.
La tabla presenta un vestíbulo hipotético. Las descripciones deben seguir la información aprobada del proyecto. Si los planos no confirman una ruta sin escalones, no la deduzcas de un modelo atractivo ni declares accesible el edificio. La accesibilidad de los controles web y la accesibilidad de la propuesta construida son preguntas de revisión diferentes.
| Función del visor | Información equivalente | Pregunta de revisión |
|---|---|---|
| Vista general | El vestíbulo conecta la entrada de calle con un patio central | ¿Se entiende la relación sin mover la cámara? |
| Vista del acceso | Ubicación identificada y espacios contiguos | ¿El nombre coincide con el plano vigente? |
| Vista del patio | Descripción de la conexión entre vestíbulo y patio | ¿Es posible regresar a la vista general? |
| Selección de materiales | Nombres escritos y estado seleccionado | ¿Se entiende sin depender solo del color? |
Distintas formas de interacción llegan a la misma información
- Define la tarea
- Ofrece destinos con nombre
- Añade teclado y toque
- Describe las conexiones
- Haz opcional el movimiento
- Continúa al formulario
Prueba una ruta real de varias maneras
Empieza utilizando solo el teclado: abre la página, llega a los controles, selecciona vistas, restablece y continúa a la consulta. Revisa el foco y comprueba que ninguna acción exija ratón. Después completa las mismas tareas esenciales con tacto, sin arrastrar. Aumenta el texto y verifica que los nombres no se superpongan ni desaparezcan sobre la escena.
Activa la preferencia de movimiento reducido y observa cómo se comunica la vista seleccionada. Revisa la explicación con el lienzo no disponible. Pide a alguien que desconozca el proyecto describir la conexión espacial. Una lista de comprobación ayuda a encontrar barreras, pero afirmar accesibilidad general requiere evaluar toda la experiencia. Registra lo revisado, corrige los problemas y conserva estas pruebas al preparar nuevas versiones.
Ideas para llevarte de esta guía
- Define la información arquitectónica necesaria para cualquier visitante.
- Utiliza botones con nombre, foco visible y orden lógico.
- Incluye alternativas por toque a las acciones de arrastre.
- Permite recuperar orientación mediante restablecer.
- Respeta movimiento reducido y evita animación inesperada.
- Prueba texto equivalente, teclado, tacto y la ruta de consulta.
La navegación accesible ofrece varias formas claras de entender un lugar. Diseña conjuntamente la información, los controles y su explicación textual.
Fuentes y lecturas
- W3C WAI — Understanding Keyboard ↗
- W3C WAI — Understanding Non-text Content ↗
- W3C WAI — Understanding Animation from Interactions ↗
- W3C WAI — Understanding Dragging Movements ↗
- Three.js — Rendering on Demand ↗
Guía editorial original con ejemplos hipotéticos. La documentación de los productos y los archivos aprobados del proyecto definen las capacidades y el alcance reales.
