Accesibilidad para entrada por voz, Switch Control y entrada alternativa: una guía práctica para crear interfaces que se puedan usar sin ratón (WCAG 2.1 AA)

greeden

hace 5 horas

Accesibilidad para entrada por voz, Switch Control y entrada alternativa: una guía práctica para crear interfaces que se puedan usar sin ratón (WCAG 2.1 AA)

Resumen rápido (puntos clave primero)

En la web, “que se pueda clicar con un ratón” no es suficiente. La accesibilidad consiste fundamentalmente en poder lograr los mismos objetivos usando diversos métodos de entrada: entrada por voz, Switch Control, seguimiento ocular, solo teclado y más.

La estrategia central es sorprendentemente simple: (1) HTML nativo, (2) soporte completo de teclado, (3) alineación etiqueta/nombre, (4) tamaño de objetivo adecuado, (5) alternativas para límites de tiempo, arrastrar y gestos complejos.

Con la entrada por voz, nombres vagos de botones significan que los usuarios “no pueden pulsarlo”. Con Switch Control, un orden de enfoque ilógico o demasiados elementos enfocables significa que los usuarios “no pueden llegar a él”. Entender esta diferencia estabiliza rápidamente las decisiones de diseño.

Esta guía se centra en contramedidas prácticas para 2.5.x (modalidades de entrada)—alternativas al arrastre, evitar gestos complejos y prevenir toques erróneos—junto con WCAG 2.1 AA (en especial 2.1.x, 2.4.x, 2.5.x, 3.3.x, 4.1.2).

Lectores objetivo: ingenieros front-end, diseñadores UI/UX, desarrolladores enterprise/line-of-business, responsables de sitios del sector público, operadores de e-commerce/reservas, QA, responsables de accesibilidad
Objetivo: cumplimiento WCAG 2.1 AA (relacionado: 2.1.x, 2.4.x, 2.5.x, 3.3.x, 4.1.2)

1. Por qué el método de entrada cambia “posible vs. imposible”, incluso en la misma UI

Las personas que usan control por voz, un único botón tipo switch, seguimiento ocular, seguimiento de cabeza, un trackball o teclados de una mano pueden encontrarse con una UI que de repente se vuelve “inoperable” simplemente porque el método de entrada es distinto.

Por ejemplo:

Un botón de cierre “×” diminuto que es fácil con ratón puede no recibir foco en Switch Control—por lo que el usuario ni siquiera puede alcanzarlo.
Con entrada por voz, decir “Toca Cerrar” puede fallar si el nombre del botón es en la práctica “icono” y no se reconoce.

La accesibilidad asume diversidad de entradas y ofrece múltiples rutas hacia el mismo objetivo. Este artículo te ayuda a revisar y corregir el diseño de UI desde la perspectiva de la entrada alternativa.

2. Panorama de entrada alternativa: modalidades comunes y puntos típicos de fallo

2.1 Entrada por voz (p. ej., Voice Control)

La coincidencia de etiquetas lo es todo: nombres vagos hacen que los controles no se puedan invocar
Demasiados elementos en pantalla incrementan el número de “objetivos” de voz y dificultan la selección
Múltiples controles con el mismo nombre incrementan la confusión de forma drástica

2.2 Switch control (p. ej., Switch Control)

Si el orden de foco es ilógico, los usuarios pueden no llegar nunca a un control
Demasiados elementos enfocables incrementan tiempo y fatiga
Sin una trampa de foco en modales, los usuarios se “pierden” en el fondo

2.3 Seguimiento ocular / seguimiento de cabeza

Objetivos demasiado pequeños causan selecciones erróneas
Botones demasiado juntos se vuelven difíciles de operar
Las UIs dependientes de hover son difíciles de usar

2.4 Solo teclado

Si algo no puede alcanzarse con Tab, es un fallo crítico
Arrastrar y soltar y gestos complejos necesitan alternativas
Si el foco no es visible, los usuarios no saben dónde están

3. La estrategia básica: corrige esto y muchas entradas alternativas mejoran a la vez

3.1 Usa HTML nativo (lo más importante)

button debe ser un botón real
a debe ser un enlace real
Asocia siempre label con los inputs

Esto por sí solo mejora de forma notable la entrada por voz, Switch Control y el comportamiento de lectores de pantalla.

Ejemplo: botón de icono

<button type="button" aria-label="Close">
  <img src="close.svg" alt="">
</button>

Entrada por voz: el usuario puede decir “Toca Close”
Switch Control: el elemento es enfocable y operable con Enter/Espacio

3.2 Mantén el orden de foco lógico (el orden del DOM es la base)

El orden visual y el orden de Tab deberían coincidir
Evita valores positivos de tabindex (1,2,3…) como regla
No crees paradas de foco innecesarias (enlaces decorativos, botones falsos)

3.3 Haz el foco visible—contundente y siempre obvio

Usa focus-visible para un foco de teclado claro.

:focus-visible{
  outline:3px solid #FF9900;
  outline-offset:3px;
}

3.4 Asegura un tamaño de objetivo suficiente (reduce errores de operación)

Un objetivo práctico es aproximadamente 44px x 44px.
Incluye espaciado alrededor del botón para que el “área clicable” sea realmente lo bastante grande.

4. UI amigable para voz: diseño de etiquetas y evitar duplicados

4.1 Haz coincidir etiquetas visibles con nombres accesibles

Los usuarios de voz suelen emitir comandos usando las palabras que ven en pantalla.
Así que si la etiqueta visible y el aria-label difieren, la confusión aumenta.

Mal: visible “Send”, nombre accesible “submit”
Bien: ambos son “Send”

4.2 Evita “botones con el mismo nombre” (“Details”, “Here”, “Open…”)

Si un usuario dice “Toca Details” y aparecen diez opciones, operar se vuelve difícil.
Arreglo: usa verbo + objeto.

“Details” → “Order details”
“Open” → “Open notification settings”
“Here” → “View pricing”

4.3 El espaciado entre botones adyacentes evita errores

Para entrada por voz y seguimiento ocular, los grupos densos aumentan los fallos.

Aumenta el espaciado
Separa acciones destructivas (no pongas “Delete” pegado a acciones comunes)

5. UI amigable para Switch: acorta el “viaje de foco”

Switch Control mueve el foco secuencialmente y el usuario selecciona en el momento correcto.
Así que si el foco tiene:

demasiadas paradas,
un orden extraño, o
no es visible,
la UI se vuelve inutilizable.

5.1 Reduce elementos enfocables (elimina paradas de Tab sin sentido)

Elimina:

enlaces decorativos
tabindex="0" innecesario
elementos enfocables pero no interactivos

5.2 Usa roving tabindex para separar “entre componentes” vs. “dentro del componente”

Para pestañas, menús, listboxes:

Tab: moverse entre componentes
Flechas: moverse dentro del componente
Esto reduce la carga para usuarios de switch.

5.3 Los modales deben atrapar el foco y restaurarlo

Al abrir: el foco entra en el modal
No permitir escapar al fondo
Al cerrar: devolver el foco al disparador
Esto es especialmente crucial para Switch Control.

6. Alternativas para arrastrar y soltar y gestos complejos (WCAG 2.5.x)

6.1 Proporciona siempre una alternativa sin arrastre

Ejemplo: reordenar

Proporciona botones “Subir” / “Bajar”
Proporciona atajos de teclado
Permite entrada numérica de posición

Fragmento conceptual

<button aria-label="Move up one">↑</button>
<button aria-label="Move down one">↓</button>

6.2 Evita que el pellizco/deslizamiento sea obligatorio

“Debes deslizar para cerrar” no es aceptable
Proporciona siempre una acción con botón (Cerrar, Atrás)

6.3 Ofrece extender/detener para tareas con límite de tiempo

Switch y voz a menudo toman más tiempo.

expiraciones de sesión
límites de tiempo en formularios
deberían incluir rutas claras para extender.

7. No dependas de tipos de eventos solo de ratón

7.1 No muestres contenido solo en `mouseover`

Si algo aparece con hover, también debe aparecer con foco:

tooltips
mega menús
texto de ayuda

7.2 No “confirmes” acciones en `pointerdown`

Esto incrementa activaciones accidentales. Usa click como evento de confirmación y asegura soporte de Enter/Espacio.

8. Checklist de 5 minutos: validación mínima para entrada alternativa

Las tareas principales se pueden completar usando solo Tab
El foco siempre es visible
Los nombres de botones son específicos (no solo “Details”)
Se evitan demasiados botones con nombres idénticos
Los objetivos son lo bastante grandes (~44px)
El arrastre tiene alternativa (botones arriba/abajo, etc.)
Los modales tienen trampa + Esc + restauración de foco
La UI de solo hover también funciona con foco
Los timeouts de formularios tienen opción de extensión (si aplica)

9. Caso de estudio: hacer que una UI de reordenamiento sea operable por todos

Antes

Reordenamiento solo por arrastre
La posición no es clara
Switch Control no puede operarlo

Después

Cada fila tiene botones “Subir” / “Bajar”
Mostrar texto de posición (p. ej., 3/10)
Usar role="status" para anunciar “Movido a la posición 3” tras cambios
Esto hace que funcione para solo teclado, entrada por voz y Switch Control.

10. Qué aporta esto (valor concreto por audiencia)

Personas que usan switches: pueden llegar a funciones clave con menos fatiga
Usuarios de voz: nombres claros hacen que los comandos sean fiables
Usuarios de seguimiento ocular: menos selecciones erróneas, operación más estable
Personas mayores: menos exigencia de motricidad fina y menos toques erróneos
Equipos de desarrollo: elementos nativos + patrones estándar reducen regresiones y protegen la calidad

11. Cobertura de nivel de accesibilidad (a qué apunta esta guía)

WCAG 2.1 AA (foco central)
- 2.1.1 Teclado: base para entrada alternativa
- 2.4.3 Orden del foco / 2.4.7 Foco visible
- 2.5.1 Gestos de puntero: evitar dependencia de gestos complejos
- 2.5.2 Cancelación de puntero: reducir activaciones accidentales
- 2.5.3 Etiqueta en el nombre: especialmente importante para entrada por voz
- 1.3.1 Información y relaciones: formularios/listas/estructura
- 3.3.x Asistencia de entrada: reducir la carga de entrada
- 4.1.2 Nombre, rol, valor: transmitir correctamente el significado de la UI
Dar soporte a entrada alternativa no es solo para discapacidades específicas: también ayuda en restricciones situacionales como manos ocupadas, caminar o lesión temporal.

12. Conclusión: diseña para que el “mismo objetivo” sea alcanzable sin ratón

HTML nativo + soporte completo de teclado es la base para entrada alternativa.
Usa etiquetas específicas para que la entrada por voz pueda invocar controles de forma fiable.
Asegura orden de foco y foco visible para que Switch Control sea utilizable.
Usa tamaño de objetivo y espaciado para reducir errores de operación.
Proporciona alternativas para arrastre y gestos complejos siempre.
Haz del checklist de 5 minutos un hábito para prevenir regresiones.

Los distintos métodos de entrada no deberían cambiar lo que los usuarios pueden lograr.
Eso no es una “adaptación especial”: es un estándar de calidad que hace los productos más seguros para todos.
Estoy animando a que tu producto se sienta natural en cualquier mano—y con cualquier voz.

Accesibilidad para entrada por voz, Switch Control y entrada alternativa: una guía práctica para crear interfaces que se puedan usar sin ratón (WCAG 2.1 AA)

1. Por qué el método de entrada cambia “posible vs. imposible”, incluso en la misma UI

2. Panorama de entrada alternativa: modalidades comunes y puntos típicos de fallo

2.1 Entrada por voz (p. ej., Voice Control)

2.2 Switch control (p. ej., Switch Control)

2.3 Seguimiento ocular / seguimiento de cabeza

2.4 Solo teclado

3. La estrategia básica: corrige esto y muchas entradas alternativas mejoran a la vez

3.1 Usa HTML nativo (lo más importante)

3.2 Mantén el orden de foco lógico (el orden del DOM es la base)

3.3 Haz el foco visible—contundente y siempre obvio

3.4 Asegura un tamaño de objetivo suficiente (reduce errores de operación)

4. UI amigable para voz: diseño de etiquetas y evitar duplicados

4.1 Haz coincidir etiquetas visibles con nombres accesibles

4.2 Evita “botones con el mismo nombre” (“Details”, “Here”, “Open…”)

4.3 El espaciado entre botones adyacentes evita errores

5. UI amigable para Switch: acorta el “viaje de foco”

5.1 Reduce elementos enfocables (elimina paradas de Tab sin sentido)

5.2 Usa roving tabindex para separar “entre componentes” vs. “dentro del componente”

5.3 Los modales deben atrapar el foco y restaurarlo

6. Alternativas para arrastrar y soltar y gestos complejos (WCAG 2.5.x)

6.1 Proporciona siempre una alternativa sin arrastre

6.2 Evita que el pellizco/deslizamiento sea obligatorio

6.3 Ofrece extender/detener para tareas con límite de tiempo

7. No dependas de tipos de eventos solo de ratón

7.1 No muestres contenido solo en mouseover

7.2 No “confirmes” acciones en pointerdown

8. Checklist de 5 minutos: validación mínima para entrada alternativa

9. Caso de estudio: hacer que una UI de reordenamiento sea operable por todos

10. Qué aporta esto (valor concreto por audiencia)

11. Cobertura de nivel de accesibilidad (a qué apunta esta guía)

12. Conclusión: diseña para que el “mismo objetivo” sea alcanzable sin ratón

Comparte esto:

7.1 No muestres contenido solo en `mouseover`

7.2 No “confirmes” acciones en `pointerdown`