Accesibilidad de teclado y ARIA: la obligación legal que se convierte en ventaja comercial

Desde junio de 2025, la European Accessibility Act exige accesibilidad digital para la mayoría de los servicios en línea. El test #35 detecta los problemas de navegación por teclado que ponen en riesgo a los sitios.

La accesibilidad de teclado es uno de esos temas que la mayoría de los profesionales web reconocen como importantes — y luego ignoran de inmediato. El razonamiento siempre es el mismo: «nuestros usuarios usan ratón.» Pero esa suposición es incorrecta, y desde junio de 2025, también es ilegal para un número creciente de empresas en la Unión Europea.

La European Accessibility Act (EAA, Directiva 2019/882) exige que los productos y servicios vendidos a consumidores — incluyendo sitios web y aplicaciones móviles — sean accesibles para personas con discapacidades. La navegación por teclado es uno de los pilares fundamentales de la accesibilidad web. Si un usuario no puede tabular por la interfaz, activar botones o navegar menús sin ratón, el sitio falla el criterio de accesibilidad más básico.

El test #35 de Orilyt analiza señales HTML estáticas para detectar los problemas de accesibilidad de teclado más comunes: valores tabindex negativos que eliminan elementos del orden de tabulación, estilos de foco desactivados por CSS, skip links ausentes y atributos ARIA en conflicto con elementos enfocables. No es una auditoría WCAG completa — pero detecta los problemas que más importan.

Test #35: ¿Qué verifica Orilyt?

El test #35 realiza un análisis estático del HTML y CSS inline de la página para detectar señales de accesibilidad de teclado. Verifica seis indicadores específicos:

1. Tabindex negativo — los elementos con tabindex="-1" se eliminan del orden natural de tabulación. Esto a veces es intencional (modales, elementos fuera de pantalla), pero el abuso crea barreras invisibles. Cualquier ocurrencia baja la puntuación a 60
2. Tabindex positivo — valores como tabindex="5" fuerzan un orden de tabulación personalizado que casi siempre rompe el flujo lógico de lectura. El test señala estos casos como advertencia
3. Outline de foco desactivado — si el CSS contiene outline: none sin una regla :focus o :focus-visible correspondiente que proporcione un estilo alternativo, los usuarios de teclado no pueden ver dónde están en la página. La puntuación cae a 60
4. Detección de skip link — un enlace «Ir al contenido» (apuntando a #main, #content o anclas similares) permite a los usuarios de teclado saltar la navegación. Su presencia es una señal positiva que aumenta la confianza
5. Conflictos ARIA-hidden — elementos marcados con aria-hidden="true" que contienen hijos enfocables (enlaces, botones, inputs) crean una trampa peligrosa: los lectores de pantalla ocultan el elemento, pero el foco del teclado puede aterrizar en él
6. Presencia de CSS de foco — el test verifica si la página incluye reglas CSS :focus o :focus-visible, indicando que el desarrollador ha considerado los estilos de navegación por teclado

Una página sin problemas evidentes obtiene 80. El test no puede superar 80 porque el análisis HTML estático solo no puede validar completamente la navegación por teclado — aún se necesitan pruebas reales de tabulación. Si se encuentran problemas, la puntuación baja a 60 o 55 según la gravedad.

La European Accessibility Act: qué cambió en junio de 2025

La EAA fue adoptada en 2019, pero los estados miembros tenían hasta el 28 de junio de 2025 para transponerla a la legislación nacional. Desde esa fecha, las empresas que prestan servicios a consumidores en la UE deben cumplir requisitos de accesibilidad alineados con el WCAG 2.1 Nivel AA.

El alcance es amplio: sitios de comercio electrónico, servicios bancarios, venta de billetes de transporte, libros electrónicos y cualquier servicio digital vendido a consumidores. Las microempresas (menos de 10 empleados y menos de 2 millones de euros de facturación) están exentas, pero el umbral es bajo — la mayoría de los clientes de las agencias están dentro del alcance.

Las sanciones varían según el estado miembro, pero incluyen multas, medidas cautelares y acciones correctivas obligatorias. Más importante aún, la regulación crea un mercado de cumplimiento: las empresas necesitan auditorías, planes de remediación y monitoreo continuo — servicios que las agencias pueden vender.

La navegación por teclado no es el único criterio WCAG, pero es el que falla más espectacularmente. Un usuario que no puede tabular más allá de la navegación, o que queda atrapado en un modal sin manejador de tecla Escape, experimenta un colapso total de la interfaz. Es lo primero que verifican los auditores.

Los 5 fallos de accesibilidad de teclado más comunes

En la práctica, la mayoría de los problemas de accesibilidad de teclado se agrupan en cinco categorías. Cada uno es detectable y corregible:

1. Componentes personalizados sin soporte de teclado — menús desplegables, acordeones, carruseles y modales construidos con <div> y JavaScript pero sin manejadores de eventos de teclado. Funcionan con clic de ratón pero son completamente invisibles para la navegación Tab. Corrección: usar HTML semántico (<button>, <details>) o añadir manejadores keydown y roles ARIA apropiados
2. Indicadores de foco ausentes — resets CSS o design systems que incluyen outline: none globalmente sin proporcionar un estilo alternativo :focus-visible. Los usuarios de teclado literalmente no pueden ver dónde están. Corrección: definir un anillo de foco visible en el CSS — un outline solid de 2px en un color contrastante funciona para la mayoría de los diseños
3. Trampas de tabulación — modales o widgets embebidos que capturan el foco sin ofrecer forma de escapar con el teclado. El usuario queda atrapado. Corrección: implementar trampa de foco que cicle dentro del modal y libere el foco con Escape
4. Orden de tabulación incorrecto — valores tabindex positivos (tabindex="1", tabindex="99") que anulan el orden natural del DOM. La secuencia de tabulación se vuelve impredecible. Corrección: eliminar todos los valores tabindex positivos y confiar en el orden del DOM
5. Skip links ausentes — en páginas con navegación compleja, los usuarios de teclado deben tabular por cada enlace del encabezado antes de llegar al contenido principal. Un enlace «Ir al contenido» al inicio de la página resuelve esto en una línea de HTML

Cómo corregir problemas de accesibilidad de teclado

La buena noticia: la mayoría de las correcciones de accesibilidad de teclado son sencillas y no requieren un rediseño. Se agrupan en tres categorías:

1. Usar HTML semántico — reemplazar <div onclick="..."> por <button>, usar <a> para navegación, usar <details>/<summary> para secciones desplegables. Los elementos semánticos son accesibles por teclado por defecto
2. Añadir estilos de foco — definir una regla :focus-visible en el CSS. Un simple outline: 2px solid #2563EB con offset proporciona visibilidad sin afectar a los usuarios de ratón. Nunca usar outline: none sin alternativa
3. Probar con la tecla Tab — la prueba de accesibilidad más efectiva no cuesta nada: desconecta el ratón y navega por tu sitio con Tab, Shift+Tab, Enter y Escape. Si te quedas atascado, tus usuarios también

Para sitios WordPress en particular, el culpable más frecuente es el tema. Los temas premium a menudo priorizan el diseño visual sobre la accesibilidad. Revisa los menús de navegación del tema, los formularios de contacto y cualquier componente con JavaScript (sliders, lightboxes, mega menús).

La accesibilidad como oportunidad de negocio para las agencias

Para freelances y agencias, la EAA ha creado un mercado de cumplimiento que no existía antes de junio de 2025. El caso de negocio es convincente:

1. Obligación legal = demanda garantizada — cada cliente con un sitio de comercio electrónico o servicio para consumidores en la UE necesita una auditoría de accesibilidad. No es opcional. Es la ley
2. Ingresos recurrentes — la accesibilidad no es una corrección puntual. Los sitios cambian, se publican nuevas páginas, los plugins se actualizan. El monitoreo continuo y las re-auditorías periódicas son necesarios para mantener el cumplimiento
3. Baja competencia — la mayoría de las agencias web aún no ofrecen servicios de accesibilidad. Ser temprano crea ventaja de posicionamiento. Las agencias que se mueven ahora dominarán este segmento de mercado

En el informe Orilyt, el test #35 genera una recomendación FIA clara cuando se encuentran problemas. Una puntuación de 55 o 60 en accesibilidad de teclado es un iniciador de conversación con cualquier cliente. La recomendación explica qué se encontró (ej.: «Outline de foco desactivado sin alternativa»), dónde ocurre y qué hacer al respecto.

De la obligación legal a la ventaja competitiva

La accesibilidad de teclado no es un tema de nicho. Afecta a usuarios con discapacidad motora, usuarios avanzados de teclado, usuarios de lectores de pantalla, y cualquiera con un trackpad roto un martes por la tarde. La EAA la ha convertido en un requisito legal para millones de empresas europeas.

El test #35 no reemplaza una auditoría WCAG completa — pero detecta las señales que indican si la accesibilidad de teclado ha sido considerada en absoluto. Estilos de foco ausentes, abuso del tabindex negativo y conflictos ARIA-hidden son las señales de alerta que predicen problemas más profundos.

Para las agencias, es una oportunidad de mercado con un argumento de venta integrado: «Su sitio está legalmente obligado a ser accesible. Esto es lo que encontró nuestra auditoría. Así es como lo corregimos.» La ley hizo la venta por usted.