Cómo mejorar la operación con teclado y los indicadores de foco｜Accesibilidad web práctica para reducir problemas de usabilidad difíciles de ver

Cuando se piensa en mejorar la accesibilidad web, a menudo se presta atención a problemas que son fáciles de notar visualmente. Sin embargo, en la práctica, hay problemas que son difíciles de detectar a primera vista, pero que crean una gran carga para los usuarios. Ejemplos típicos son la operación con teclado y los indicadores de foco. Una página puede parecer natural cuando se usa con el ratón, pero cuando alguien intenta usarla solo con el teclado, los problemas aparecen de repente: no puede entrar en el menú, no puede llegar a un botón o no puede saber dónde se encuentra. En la Parte 4, nos centraremos en estos “problemas de usabilidad difíciles de ver” y explicaremos la perspectiva de WCAG 2.2 y los métodos prácticos de mejora de la forma más concreta posible.

Lo que aprenderás en este artículo

• Por qué es importante la operación con teclado
• Qué ocurre cuando los indicadores de foco no son visibles
• Criterios de éxito de WCAG 2.2 relacionados con el foco que conviene comprender
• Problemas prácticos comunes y direcciones de mejora
• Cómo pensar en la división de roles con UUU Web Accessibility Service

En primer lugar, la operación con teclado no es necesaria solo para un pequeño grupo de usuarios de escritorio. Muchos usuarios dependen de la navegación con teclado, incluidas personas que tienen dificultad para usar un ratón, personas a quienes les resultan difíciles los movimientos precisos de manos o dedos, personas que utilizan tecnologías de asistencia y personas que usan atajos para operar de manera eficiente. También hay muchas situaciones en las que la usabilidad con teclado importa incluso sin un entorno asistivo especial, como usar un portátil fuera de casa o manejar temporalmente el dispositivo con una sola mano. En otras palabras, la operabilidad con teclado no es un requisito solo para algunos usuarios; es un asunto de calidad relacionado con la usabilidad web básica.

Aquí, la operación con teclado significa principalmente moverse con la tecla Tab y Shift + Tab, activar elementos con Enter o Espacio, y desplazarse por la página usando las teclas de flecha cuando sea necesario. Los usuarios deben poder llegar, en orden y sin usar el ratón, a enlaces, botones, formularios, menús, modales, pestañas, acordeones y elementos similares. Sin embargo, en la práctica, este comportamiento básico a menudo se rompe por interfaces personalizadas o implementaciones de JavaScript que priorizan la apariencia. Por ejemplo, algo parece un botón, pero en realidad es un elemento div con solo un evento de clic, por lo que no responde a la entrada del teclado. Un menú desplegable depende del hover del ratón, por lo que los usuarios no pueden entrar en sus elementos mediante navegación con Tab. Después de abrir un modal, el foco no se mueve al lugar correcto y, en cambio, se escapa al fondo. Estas situaciones hacen que la página sea casi “inutilizable” para algunos usuarios.

Junto con la operación con teclado, los indicadores de foco también son importantes. El foco se refiere al elemento que actualmente está seleccionado mediante la operación con teclado. Con el ratón, los usuarios pueden seguir visualmente la posición del cursor. Con el teclado, el indicador de foco les dice “dónde están ahora”. Por lo tanto, cuando los usuarios se mueven a un enlace o botón, la posición actual debe mostrarse claramente mediante un contorno, un cambio de color de fondo, un subrayado, una sombra o una señal visual similar. Si no hay indicador de foco, o si es extremadamente tenue o se mezcla con el fondo, los usuarios no pueden entender qué elemento están a punto de operar. Esto no es simplemente un problema de diseño visual; afecta a si la operación puede completarse o no.

En WCAG 2.2, los requisitos relacionados con el foco se han reforzado en comparación con versiones anteriores. En la práctica, los criterios especialmente importantes son 2.4.11 “Foco no oculto (mínimo)”, 2.4.12 “Foco no oculto (mejorado)” y 2.4.13 “Apariencia del foco”. Estos requieren que el elemento enfocado no quede oculto cuando los usuarios se desplazan con el teclado, y que el propio indicador de foco sea suficientemente visible. WCAG ya exigía que el foco fuera visible en 2.4.7 “Foco visible”, pero WCAG 2.2 va más allá y aborda problemas prácticos como “técnicamente es visible, pero difícil de reconocer” o “queda oculto detrás de un elemento fijo”. Este es uno de los aspectos más prácticos de la actualización.

Por ejemplo, muchos sitios web modernos usan una cabecera fija en la parte superior de la pantalla. Como los menús y botones de contacto permanecen visibles al hacer scroll, esto puede resultar cómodo para usuarios de ratón. Sin embargo, cuando alguien navega por la página con teclado, el enlace o campo de entrada que recibe el foco puede quedar oculto detrás de esa cabecera fija. El usuario sigue presionando Tab, pero visualmente parece que no ocurre nada y no puede saber a dónde se ha movido. Este es exactamente el tipo de situación que aborda 2.4.11. Una interfaz que parece cómoda durante el diseño puede revelar una cara completamente diferente cuando se revisa con navegación por teclado.

Otro problema común es que el propio indicador de foco es extremadamente débil. Para preservar la coherencia visual, algunos sitios eliminan el contorno predeterminado del navegador y lo reemplazan por un borde gris muy pálido o una sombra apenas perceptible. Los creadores pueden pensar “lo estamos mostrando”, pero si el contraste con el fondo es bajo o el cambio es demasiado pequeño en relación con el tamaño del elemento, los usuarios pueden no notarlo en la práctica. En áreas de navegación con muchos enlaces, datos en formato de tabla, listas de tarjetas y diseños similares, los indicadores de foco poco claros aumentan mucho la dificultad de operación. Los indicadores de foco no son decoración; son pistas de navegación. En lugar de preocuparnos por que destaquen demasiado, debemos priorizar que los usuarios no pierdan su ubicación.

La primera comprobación práctica es si los usuarios pueden moverse desde el inicio hasta el final de una página usando solo la tecla Tab. Verifica si los principales elementos interactivos pueden alcanzarse en orden: cabecera, navegación global, migas de pan, contenido principal, barra lateral, formularios y pie de página. En ese momento, también es importante comprobar si el orden de navegación se desvía mucho del flujo visual, si el foco desaparece a mitad de camino, si los elementos que deberían recibir foco realmente lo hacen y si los elementos decorativos sin significado reciben foco con demasiada frecuencia. Una gran ventaja de las pruebas con teclado es que pueden iniciarse sin ningún entorno de prueba especial. Simplemente dejando el ratón a un lado y usando el sitio con la tecla Tab se pueden revelar muchos problemas.

Un punto que debe vigilarse con cuidado es el orden del foco. Aunque todos los elementos puedan recibir foco, la operación se vuelve difícil si el orden no es natural. Por ejemplo, antes de pasar del menú superior al texto del cuerpo, el foco puede saltar a enlaces en áreas invisibles o a elementos detallados de la barra lateral. O dentro de una interfaz de tarjetas, el foco puede moverse en un orden como título, imagen, enlace de detalle y espacio en blanco, dificultando entender qué información forma un grupo. Este tipo de alteración del orden puede ocurrir fácilmente por la estructura HTML, la presentación CSS o el control con JavaScript. Es importante comprobar que el orden visual y la estructura fuente o el orden de operación no estén demasiado alejados.

Los enlaces de salto también afectan la comodidad de la operación con teclado. En sitios con cabeceras grandes o muchos enlaces de navegación, los usuarios pueden tener que pasar por muchos enlaces pequeños desde el inicio de la página cada vez antes de llegar al contenido principal. Por eso, resulta muy efectivo proporcionar un enlace de salto como “Saltar al contenido principal”, que permita a los usuarios de teclado moverse directamente al contenido principal. Los enlaces de salto no necesitan destacar normalmente, pero deben ser claramente visibles cuando reciben foco. Aunque se instale un enlace de salto, no funcionará si permanece fuera de la pantalla al enfocarse o se mezcla con el fondo. Aquí también es importante el diseño del indicador de foco.

Los componentes que implican JavaScript, como modales, menús laterales y pestañas, requieren especial cuidado. Cuando se abre un modal, ¿el foco se mueve al encabezado o al botón de cierre dentro del modal? Cuando se cierra, ¿el foco vuelve al botón que lo activó originalmente? Cuando un menú lateral está abierto, ¿el foco se escapa al contenido del fondo? En una interfaz de pestañas, ¿los usuarios pueden saber qué pestaña está seleccionada actualmente y se admiten operaciones esperadas como el movimiento con teclas de flecha? La pulcritud visual por sí sola no basta. La pregunta clave es si el flujo de operación se siente natural para los usuarios de teclado. Los sitios modernos usan cada vez más interfaces animadas y dinámicas, pero mantener el contexto operativo del usuario es aún más importante.

Incluso en diseños centrados en smartphones, la perspectiva de operación con teclado no es irrelevante. Al considerar tabletas con teclados externos, algunas tecnologías de asistencia, navegadores de televisión y dispositivos de entrada especiales, la operabilidad mediante teclado o navegación secuencial similar al teclado sigue siendo importante. Los indicadores de foco claros también ayudan no solo a los usuarios de teclado, sino a cualquiera que pueda perder fácilmente de vista el objetivo actual de operación. En otras palabras, reforzar los indicadores de foco no es una corrección de nicho; mejora la calidad general de operación.

Estos son algunos ejemplos comunes de “casi bien, pero no del todo” en la práctica. Primero, los usuarios pueden moverse a los enlaces de navegación global con Tab, pero los submenús no se abren con el teclado. Segundo, los botones pueden recibir foco, pero la posición actual se muestra solo mediante una diferencia mínima de color de fondo y es casi invisible. Tercero, antes de llegar al formulario de consulta, los usuarios deben tabular a través de muchos enlaces de redes sociales y banners, haciendo que el contenido principal parezca lejano. Cuarto, las cabeceras fijas ocultan campos de formulario o mensajes de error, dificultando entender la posición del foco. Quinto, en interfaces complejas como carruseles y acordeones, los elementos parecen seleccionables pero no pueden alcanzarse con el teclado. Todos estos problemas son difíciles de notar con el ratón, pero causan mucho estrés al operar con teclado.

En cuanto a la mejora, la base es usar correctamente los elementos HTML nativos. Usa elementos a para enlaces, elementos button para botones y elementos de entrada apropiados para controles de formulario. Solo con esto mejora mucho la compatibilidad con la operación con teclado y las tecnologías de asistencia. Además, no elimines casualmente el indicador de foco predeterminado del navegador; si lo eliminas, diseña una alternativa aún más visible. Ajusta las posiciones de scroll para que las cabeceras fijas y los elementos sticky no oculten los elementos enfocados. Proporciona enlaces de salto. Para modales, pestañas y componentes similares, alinea el comportamiento con los conceptos de WAI-ARIA. Más que añadir funciones nuevas y llamativas, preservar la operación básica tiene mucho más valor.

Aquí también conviene organizar la compatibilidad con UUU Web Accessibility Service. Servicios como UUU, que ofrecen funciones de apoyo a la visualización como cambios de tamaño de fuente, ajuste de contraste, ajuste de altura de línea, detención de animaciones, lectura en voz alta, traducción y visualización de furigana, tienen gran valor para ayudar a los usuarios a ajustar las páginas a un estado más visible y comprensible. Por ejemplo, si un indicador de foco es difícil de ver por una pequeña diferencia de color, el ajuste de contraste puede ayudar como medida complementaria. El apoyo de lectura en voz alta y los ajustes de visualización también pueden mejorar la comprensibilidad general.

Sin embargo, si la operación con teclado funciona realmente, si el orden del foco es adecuado, si el foco no queda oculto y si los usuarios pueden moverse correctamente dentro de los modales son cuestiones que no pueden resolverse de forma fundamental solo con funciones de apoyo a la visualización. Esas áreas requieren mejorar la estructura HTML original, el diseño CSS y la implementación de JavaScript. En otras palabras, servicios como UUU son muy compatibles con el rol de “apoyar la visibilidad y la legibilidad”, mientras que la calidad de la operación con teclado y la gestión del foco sigue siendo un área que los creadores deben implementar con responsabilidad. Comprender esta diferencia de roles ayuda a evitar malentendidos como “instalamos una herramienta, pero el sitio sigue siendo difícil de operar”.

Este tema no es solo para ingenieros. Los directores pueden incluir comprobaciones como “¿se puede llegar a las rutas principales usando solo el teclado?” y “¿el foco es suficientemente visible?” durante la definición de requisitos y las pruebas de aceptación. Los diseñadores pueden tratar los indicadores de foco como objetivos de diseño desde el principio, igual que los estados predeterminados y hover. Los editores y el personal de relaciones públicas también pueden notar problemas como enlaces de salto, organización de la navegación y exceso de enlaces innecesarios. En otras palabras, la operación con teclado y los indicadores de foco son detalles de implementación, pero también revelan la filosofía de diseño de todo el sitio.

Con esto concluye la Parte 4. La operación con teclado y los indicadores de foco son difíciles de notar visualmente, pero son elementos extremadamente importantes que determinan si los usuarios pueden usar realmente un sitio web. WCAG 2.2 pone mayor énfasis no solo en que el foco sea visible, sino también en que sea suficientemente reconocible y no quede oculto por elementos fijos o interfaces similares. En la práctica, el primer paso es operar la página usando solo la tecla Tab y comprobar el orden, la alcanzabilidad, la visibilidad y el comportamiento de modales y menús. Servicios como UUU Web Accessibility Service son valiosos para el apoyo a la visualización, pero la calidad de la operación con teclado y la gestión del foco aún debe mejorarse mediante el diseño y la implementación del propio contenido web. La próxima vez, veremos cómo mejorar textos difíciles de leer, centrándonos en encabezados, resúmenes y japonés claro.

Enlaces de referencia

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI: Understanding WCAG 2.2
• W3C WAI: Keyboard Accessible
• W3C WAI: Understanding Success Criterion 2.1.1 Keyboard
• W3C WAI: Understanding Success Criterion 2.4.7 Focus Visible
• W3C WAI: Understanding Success Criterion 2.4.11 Focus Not Obscured (Minimum)
• W3C WAI: Understanding Success Criterion 2.4.13 Focus Appearance
• W3C WAI-ARIA Authoring Practices Guide
• WAIC: Japanese translation of Web Content Accessibility Guidelines (WCAG) 2.2
• WAIC: Understanding Success Criterion 2.4.7 Focus Visible