Accesibilidad ≠ Overlay: la Comisión Europea recomienda corregir la accesibilidad en origen
La Comisión Europea lo formula de manera muy práctica: si una herramienta no consigue que la propia web cumpla los criterios de accesibilidad aplicables, no es una solución adecuada. Lo recomendable es corregir los problemas en su origen.
La Comisión Europea entra en el debate sobre los overlays
En su información oficial sobre accesibilidad web, la Comisión Europea dedica un apartado específico a las accessibility overlays. No se limita a explicar qué son: también aclara qué papel pueden desempeñar frente a los requisitos técnicos de accesibilidad en la Unión Europea.
La Comisión recuerda que los requisitos legales de accesibilidad vinculados a la Directiva de Accesibilidad Web se apoyan en criterios técnicos de la norma europea armonizada EN 301 549 v3.2.1. A partir de ahí establece una diferencia esencial entre añadir una herramienta y conseguir que el sitio web cumpla realmente esos criterios.
Añadir una herramienta no equivale a cumplir los criterios
Un overlay puede incorporar controles, modificar determinados estilos o intentar reparar algunos problemas durante la ejecución de la página. Pero la pregunta relevante no es cuántas funciones añade el panel, sino si la web resultante satisface los requisitos de accesibilidad que le corresponden.
La Comisión indica que los overlays —o cualquier otra herramienta— que no garanticen que la propia web cumple los criterios detallados de la norma no constituyen una solución adecuada. Este matiz evita confundir la presencia de tecnología de accesibilidad con la accesibilidad del producto digital.
Corregir la accesibilidad en origen
La recomendación de la Comisión es directa: es mejor corregir los problemas de accesibilidad en su origen.
En desarrollo web, esto significa trabajar sobre la causa de la barrera. Si un campo de formulario carece de una etiqueta accesible, se corrige el formulario. Si un menú no funciona con teclado, se corrige su interacción. Si un componente personalizado no comunica correctamente su nombre, función o estado, se modifica su implementación. Si el foco se desplaza de forma incorrecta, se corrige la gestión del foco.
El objetivo no es conseguir que una capa externa parezca compensar el problema, sino conseguir que el componente original sea accesible.
¿Qué papel tiene EN 301 549?
La norma EN 301 549 establece requisitos de accesibilidad para productos y servicios TIC. Para la Directiva de Accesibilidad Web, la Comisión identifica la versión armonizada 3.2.1 como referencia técnica y explica que se basa ampliamente en WCAG 2.1, aunque contiene también requisitos adicionales relevantes.
Por eso, hablar de cumplimiento no puede reducirse a instalar un widget ni siquiera a obtener un buen resultado en una herramienta automática. Deben evaluarse los requisitos aplicables al producto y comprobarse en la experiencia real.
Una web accesible no necesita un modo accesible separado
Corregir en origen cambia la filosofía del proyecto. En lugar de crear una versión especial para determinados usuarios, diseñamos la misma interfaz para que pueda utilizarse de distintas maneras: con ratón, teclado, lector de pantalla, ampliación, reconocimiento de voz u otras tecnologías de apoyo.
Esto también facilita el mantenimiento. Cuando se corrige el componente original, la mejora forma parte del producto. Cuando se depende de una reparación posterior, cada cambio en la web puede generar nuevas incompatibilidades entre el código original y la capa que intenta modificarlo.
Las pruebas con personas con discapacidad siguen siendo necesarias
La Comisión añade otra recomendación importante: para garantizar que los sitios sean realmente accesibles, es importante involucrar siempre a personas con discapacidad en las pruebas.
Las herramientas automáticas son útiles para detectar determinados errores, pero no reproducen toda la experiencia de una persona que navega con teclado, lector de pantalla, ampliación u otras tecnologías. Una estrategia sólida combina requisitos técnicos, evaluación experta y pruebas de uso.
No es una cuestión de estar contra la tecnología
La posición de la Comisión no implica que cualquier herramienta adicional sea inútil. Una herramienta puede aportar funciones, ayudar en el proceso o mejorar aspectos concretos. El criterio es otro: no debe sustituir la corrección de los requisitos que la propia web debe satisfacer.
La automatización tiene valor cuando ayuda a localizar y solucionar barreras. El problema aparece cuando se utiliza como argumento para no modificar una implementación inaccesible.
Qué significa esto para quienes gestionamos una web
Si una auditoría detecta una barrera, conviene identificar dónde se origina y corregirla en el tema, plantilla, componente, contenido o proceso que la genera. Esto puede requerir trabajo de diseño y desarrollo, pero ofrece una mejora estable y verificable.
También evita trasladar al usuario la responsabilidad de encontrar un botón de accesibilidad, activar un perfil o confiar en que una herramienta interprete correctamente una interfaz que nació con barreras.
Accesibilidad ≠ Overlay
Después de analizar ACB, NFB y la declaración conjunta de EDF e IAAP, esta cuarta entrega incorpora la posición publicada por la propia Comisión Europea: una herramienta añadida sobre una web no es una solución adecuada si la web continúa sin cumplir los criterios de accesibilidad.
La recomendación práctica es corregir la accesibilidad en origen. Diseñar correctamente. Desarrollar correctamente. Evaluar. Probar con tecnologías de apoyo y con personas con discapacidad. Y mantener la accesibilidad cuando el producto evoluciona.
Fuentes oficiales
Comisión Europea — Shaping Europe’s Digital Future
Accesibilidad a la Web — apartado sobre superposiciones de accesibilidad
Directiva sobre accesibilidad de los sitios web — normas y armonización
Este artículo forma parte de la serie «Accesibilidad ≠ Overlay». Entrega 04 — Comisión Europea.