Qué falla al navegar solo con teclado
El error más común al navegar solo con teclado es que los componentes interactivos son visibles, pero no se pueden alcanzar con la tecla Tab. Piense en un menú que solo se abre con un clic del ratón, un botón que no recibe el foco, o una ventana emergente que no se puede cerrar sin ratón. Para las personas que no pueden usar ratón debido a limitaciones motrices, o que utilizan un lector de pantalla que funciona mediante navegación por teclado, esto significa que parte del sitio web simplemente no es utilizable.
La causa casi siempre está en componentes personalizados: un desarrollador construye un elegante menú desplegable, un selector de fecha personalizado o un filtro desplegable con HTML y JavaScript propios, pero olvida la compatibilidad con teclado que un botón o enlace HTML estándar proporciona de forma gratuita. El componente se ve bien y funciona con el ratón, así que nadie se da cuenta durante las pruebas de que la tecla Tab simplemente lo salta.
Por qué esto a menudo pasa desapercibido
Este error es persistente porque no es evidente a simple vista. Cualquiera que navegue por una tienda en línea con un ratón no verá ningún problema. Solo cuando olvida el ratón y se mueve por la página solo con Tab, Mayús+Tab, Intro y las teclas de flecha, se hace evidente dónde falla la navegación. Dado que estas pruebas rara vez forman parte estándar de un proceso de entrega, el problema a menudo pasa desapercibido durante años, hasta que un visitante o una autoridad de supervisión se enfrenta a él.
Una segunda razón es que muchos de estos defectos ocurren precisamente en los lugares más destacados cuando se usa el sitio: el proceso de compra, la pantalla de inicio de sesión, un filtro de búsqueda. Estos son exactamente los componentes que a menudo se construyen por separado del resto del sitio, con componentes propios que no siempre reciben la misma atención que la navegación principal.
Cómo identificar esto usted mismo
Una primera comprobación sencilla es soltar el ratón y recorrer un flujo de página solo con el teclado. Preste atención a tres cosas: cada elemento interactivo es accesible mediante Tab, en cada momento es claramente visible qué elemento tiene el foco, y cada componente que se abre (un menú, un filtro, una ventana emergente) también se puede cerrar sin ratón. Si el foco se queda atrapado en una ventana emergente, salta a un lugar inesperado o desaparece completamente de la pantalla, es una señal de que hay trabajo por hacer.
Un análisis automatizado puede detectar algunos de estos problemas, por ejemplo, indicadores de foco faltantes o componentes sin acceso por teclado que son identificables técnicamente en el código fuente. Sin embargo, si un menú desplegable se puede operar de forma lógica y predecible es algo que un análisis no puede evaluar completamente: en esencia, sigue siendo una prueba humana. Esto es válido para más requisitos de WCAG, y siempre lo mencionamos en el informe. inicie el análisis rápido gratuito de sus páginas más importantes para ver qué parte de este tipo de problemas ya se detecta automáticamente.
Cómo evitar esto
La solución generalmente no está en tecnología adicional en el sitio web, sino en el uso correcto de los componentes existentes. Un botón o enlace HTML estándar es naturalmente accesible con Tab y se puede operar con Intro; quien en su lugar hace clic en un texto o imagen con JavaScript debe añadir esa compatibilidad con teclado él mismo. Para componentes personalizados como menús, filtros y ventanas emergentes, debe haber un acuerdo claro con el desarrollador: cada componente debe poder abrirse, operarse y cerrarse con el teclado, y el foco debe permanecer visible y predecible.
Lo que no ayuda aquí es un widget de accesibilidad que afirma solucionar este tipo de deficiencias con un script independiente. Una superposición de ese tipo no cambia el código subyacente y, por lo tanto, no cambia la usabilidad real; la ley requiere un sitio web accesible, no una capa superpuesta. Deliberadamente no vendemos ese tipo de widgets.
¿Desea saber qué partes de su sitio web o aplicación contienen este tipo de problemas estructurales y cuánto peso tienen en la lista de prioridades de su plan de mejora? En la base de conocimientos organizada por tema lee qué está en juego para cada tipo de deficiencia, y en cómo se lleva a cabo exactamente nuestro análisis ve qué parte se analiza automáticamente y qué parte requiere atención manual.
¿Tiene preguntas sobre qué cae y qué no cae bajo este requisito, o sobre el resto del marco de análisis? Las respuestas a las preguntas más frecuentes ya dan respuesta a la mayoría de ellas.
El análisis rápido gratuito de axessia.eu le da una indicación inmediata de si este tipo de problemas de teclado ocurren en su sitio, sin que necesite una cuenta para ello.