El lunes por la mañana, una persona entra en una tienda online para comprar unas zapatillas. El filtro de talla parece sencillo, pero no responde al teclado. Después intenta pagar desde el móvil: el botón tiene un contraste tan pobre que parece estar jugando al escondite. Por último, abre un vídeo del producto y descubre que no hay subtítulos. No es una anécdota de laboratorio ni una rareza estadística: son barreras frecuentes que afectan a clientes reales, a la conversión y, desde junio de 2025, al cumplimiento de servicios digitales en la Unión Europea.
La Accesibilidad web ha dejado de ser una corrección estética que se añade cuando queda presupuesto o cuando alguien menciona un lector de pantalla en una reunión. En 2026 forma parte del producto, del diseño, de la arquitectura de la información y de la responsabilidad legal. Las WCAG 2.2 aportan criterios más precisos para las interacciones modernas, mientras que la Ley Europea de Accesibilidad ha elevado la exigencia para numerosos productos y servicios dirigidos al mercado europeo. La pregunta ya no es si una organización debería revisar sus interfaces, sino si puede demostrar que las revisa de forma continuada.
En breve
- La Ley Europea de Accesibilidad se aplica desde el 28 de junio de 2025 a servicios y productos incluidos en su ámbito.
- WCAG 2.2, publicada por el W3C en octubre de 2023, refuerza cuestiones como el foco visible, el tamaño de objetivos y las alternativas al arrastre.
- Una herramienta automática ayuda, pero no sustituye las pruebas manuales con teclado, lector de pantalla y personas usuarias.
- El Diseño inclusivo reduce fricción para todas las personas, no solo para quienes utilizan Tecnologías asistivas.
- La evidencia importa: auditorías, decisiones documentadas, componentes reutilizables y correcciones verificables forman parte del cumplimiento.
Accesibilidad web en 2026: por qué afecta a dirección, producto y negocio
La accesibilidad digital ya no vive en un cajón llamado “pendientes técnicos”. Ahora se cruza con ventas, reputación, contratación pública, calidad y soporte. Cuando un proceso de alta bloquea a quien navega con teclado, el problema no es únicamente técnico. También genera abandonos, llamadas al servicio de atención y pérdida de confianza. Por eso, una empresa que trata estas barreras como detalles menores suele descubrir demasiado tarde que los detalles habían montado una huelga.
La Directiva (UE) 2019/882, conocida como Ley Europea de Accesibilidad o European Accessibility Act, establece requisitos para determinados productos y servicios. Su aplicación comenzó el 28 de junio de 2025. Entre los ámbitos relevantes se encuentran, según el caso, el comercio electrónico, determinados servicios bancarios, transporte de viajeros, comunicaciones electrónicas, libros electrónicos y terminales de autoservicio. Cada Estado miembro incorpora la Directiva a su marco nacional, por lo que las compañías que operan en varios países deben revisar tanto el alcance europeo como las normas locales.
Esta realidad modifica la conversación dentro de las organizaciones. Antes, un equipo podía pedir una Auditoría web poco antes del lanzamiento y confiar en que un parche resolviera todo. Sin embargo, un portal de contratación, una aplicación de banca o un ecommerce contienen recorridos largos y dependencias complejas. Si el diseño de base es excluyente, arreglarlo al final cuesta más, tarda más y deja más margen para que aparezcan fallos nuevos.
| Área de negocio | Riesgo si existen barreras | Respuesta útil |
|---|---|---|
| Comercio electrónico | Abandono en búsqueda, filtros o pago | Probar el recorrido completo con teclado y móvil |
| Atención al cliente | Más incidencias y dependencia de canales alternativos | Etiquetar formularios, errores y estados de forma clara |
| Compras y licitaciones | Exclusión de procesos o solicitudes de evidencia | Documentar pruebas, componentes y plan de mejora |
| Marca | Desconfianza y percepción de servicio poco cuidado | Publicar información de accesibilidad verificable |
Además, las Normativas de accesibilidad no deben interpretarse como una invitación a instalar un complemento milagroso. Un widget que añade botones flotantes no arregla un diálogo que atrapa mal el foco, una etiqueta ausente o un formulario imposible de comprender. Es como colocar un timbre nuevo en una puerta que sigue sin rampa: puede hacer ruido, pero no resuelve el acceso.
La referencia técnica más extendida sigue siendo la familia WCAG del W3C. Sus cuatro principios —perceptible, operable, comprensible y robusto— permiten evaluar algo más importante que la estética: si una persona puede encontrar la información, entenderla, interactuar con ella y utilizarla con distintas tecnologías. En consecuencia, la accesibilidad se relaciona de forma directa con la Usabilidad. Una navegación coherente beneficia a quien usa un lector de pantalla, pero también a quien consulta una web con prisa, bajo el sol o con una conexión irregular.
Tomemos el caso de “Línea Norte”, una tienda ficticia de equipamiento deportivo. Su equipo detectó que el filtro de productos solo respondía al gesto de arrastrar un control deslizante. La solución no consistió en pintar el control con un color más intenso. Añadieron campos numéricos, botones para incrementar valores y un estado anunciado correctamente. Así, el filtro empezó a servir a más personas y dejó de exigir una destreza manual propia de un concurso de grúas recreativas.
La lección es sencilla: una experiencia accesible es una experiencia que conserva opciones. El siguiente paso consiste en entender qué aporta WCAG 2.2 a las interfaces que se diseñan hoy.
WCAG 2.2 en la práctica: los criterios que cambian menús, formularios y pagos
WCAG 2.2 no borra las pautas anteriores ni convierte el desarrollo web en un ritual misterioso con velas y atributos ARIA. Amplía WCAG 2.1 y presta especial atención a situaciones habituales en móviles, formularios y procesos autenticados. Su valor está en que traduce fricciones comunes en criterios revisables. Por lo tanto, ofrece a los equipos una base más concreta para detectar dónde una interfaz puede dejar fuera a parte de su audiencia.
Uno de los cambios más visibles afecta al foco. Cuando una persona navega con teclado, necesita saber en qué elemento se encuentra. Los criterios Focus Not Obscured exigen que ese indicador no quede oculto por elementos persistentes, como cabeceras pegajosas, banners de cookies o barras inferiores. Un foco tapado es una especie de GPS que funciona, pero coloca la flecha debajo de una manta. Técnicamente existe; en la práctica no orienta.
También importa el criterio Focus Appearance. Un indicador apenas perceptible no cumple su misión. El foco debe tener suficiente visibilidad, contraste y tamaño para distinguirse con claridad. Esto obliga a revisar decisiones que a veces se toman por estética, como eliminar el contorno predeterminado sin proporcionar una alternativa equivalente. La interfaz puede parecer más limpia en una captura, pero resulta mucho más confusa durante el uso real.
Los nueve criterios nuevos y la prioridad de los flujos críticos
WCAG 2.2 introduce nueve criterios de éxito. Algunos se sitúan en nivel A, otros en AA o AAA. No todos tendrán el mismo impacto para cada producto, aunque varios afectan directamente a patrones frecuentes. Los equipos deberían comenzar por las rutas donde existe una acción importante: iniciar sesión, buscar, elegir un producto, completar un formulario, pagar o pedir ayuda.
- Focus Not Obscured: el elemento enfocado debe seguir siendo visible.
- Focus Appearance: el foco debe mostrar un indicador perceptible y contrastado.
- Dragging Movements: una acción de arrastre debe tener alternativa sin arrastrar.
- Target Size: los controles táctiles necesitan un tamaño suficiente o un espaciado adecuado.
- Consistent Help: los mecanismos de ayuda deben aparecer en un orden coherente.
- Redundant Entry: no se debe pedir varias veces información ya facilitada, salvo necesidad justificada.
- Accessible Authentication: el acceso no debe depender de pruebas cognitivas innecesarias.
El criterio sobre movimientos de arrastre es muy relevante en interfaces móviles. Un mapa, un carrusel de productos o un selector de rango no deben depender exclusivamente de deslizar o arrastrar. Por ejemplo, un selector de precio puede incluir campos editables y botones para ajustar importes. De este modo, quien no pueda realizar el gesto con precisión conserva una vía alternativa. Además, quien tenga un dedo ocupado sujetando una bolsa también lo agradecerá, aunque la normativa no mencione bolsas de la compra.
El tamaño de los objetivos interactivos merece una revisión seria. En una pantalla pequeña, un icono diminuto con poco margen aumenta errores y frustración. WCAG 2.2 establece requisitos que ayudan a evitar estos puntos de toque minúsculos. No significa que todos los controles deban parecer botones de ascensor industrial. Significa que deben poder activarse sin una puntería de francotirador.
Los formularios representan otro campo de batalla. Deben ofrecer etiquetas asociadas, instrucciones comprensibles, mensajes de error concretos y un orden lógico de navegación. Si un campo falla, no basta con pintar un borde rojo. El mensaje debe explicar qué ocurrió y cómo solucionarlo. “Error” es una palabra honesta, pero tiene la utilidad práctica de un paraguas agujereado.
Las Tecnologías asistivas interpretan la estructura semántica de la página. Por eso, un botón debe ser un botón, un encabezado debe ser un encabezado y una lista debe conservar su estructura. ARIA puede complementar el HTML cuando hace falta, aunque no sustituye una base correcta. La primera regla sigue siendo humilde y eficaz: usar HTML nativo antes de inventar una pieza compleja.
Por último, WCAG 3 continúa en desarrollo dentro del W3C. No sustituye las obligaciones actuales vinculadas a WCAG 2.x. Sin embargo, su evolución apunta hacia evaluaciones más centradas en resultados y en experiencias reales. Mientras llega ese futuro, cumplir WCAG 2.2 empieza por hacer utilizables los recorridos que ya existen.
Diseño inclusivo desde el primer píxel: sistemas, contenido y arquitectura de la información
El Diseño inclusivo no consiste en crear una versión especial de la web para un grupo especial. Consiste en diseñar un servicio flexible desde el inicio. La diferencia parece pequeña, pero cambia todo el proceso. En lugar de preguntar al final “¿qué barreras hemos creado?”, el equipo pregunta al principio “¿qué condiciones de uso debemos contemplar?”. Esa segunda pregunta ahorra revisiones dolorosas y reduce decisiones impulsivas.
Una persona puede navegar sin ratón, con baja visión, con fatiga temporal, en un entorno ruidoso o con una pantalla rota. También puede utilizar una mano mientras sostiene a un bebé o consultar instrucciones bajo una luz intensa. La diversidad no es una lista cerrada de diagnósticos. Es el contexto normal de la vida digital. Por eso, diseñar con alternativas mejora el producto incluso para quienes jamás han abierto el menú de accesibilidad del sistema operativo.
Componentes accesibles que no obligan a reinventar la rueda
Los sistemas de diseño son uno de los lugares más eficaces para prevenir errores repetidos. Si un componente de botón ya incorpora contraste suficiente, foco visible, estados claros y un área táctil adecuada, cada equipo que lo reutiliza empieza con una ventaja. En cambio, si la biblioteca ofrece botones bonitos pero mudos, el problema se multiplica con una eficiencia digna de una fotocopiadora poseída.
Conviene definir tokens para colores, tipografía, espaciado, bordes y estados de interacción. El token de foco, por ejemplo, debe especificar color, grosor y separación respecto al elemento. Así, no queda sujeto a la inspiración del viernes por la tarde. Los componentes también deben documentar cuándo usar un enlace, cuándo un botón y cómo comunicar estados de carga, validación o éxito.
| Decisión de diseño | Riesgo habitual | Mejor práctica aplicable |
|---|---|---|
| Estado comunicado solo con color | La diferencia no se percibe en todos los contextos | Añadir texto, icono o patrón visual complementario |
| Icono sin etiqueta | Su significado resulta ambiguo | Incluir nombre accesible y, cuando convenga, texto visible |
| Animación automática | Distracción o malestar para algunas personas | Respetar reducción de movimiento y permitir pausarla |
| Modal personalizado | Foco perdido o contenido inaccesible | Gestionar foco, cierre y orden de lectura correctamente |
Los Contenidos accesibles también forman parte del diseño. Un texto alternativo útil no describe píxeles de forma mecánica; explica la información necesaria en su contexto. Si una imagen muestra tres acabados de una mochila, “persona sosteniendo objeto” no aporta casi nada. En cambio, “mochila modelo Atlas disponible en azul marino, arena y verde” ayuda a tomar una decisión.
El lenguaje claro mejora la comprensión. Los enlaces deben indicar su destino, los títulos deben organizar el contenido y las instrucciones deben evitar ambigüedades. En vez de “haz clic aquí”, resulta más útil “descargar la guía de tallas en PDF”. Asimismo, los mensajes de error deben orientar: “Introduce un código postal de cinco cifras” es mejor que “Formato inválido”.
La arquitectura de la información también decide quién encuentra algo y quién se pierde. Una navegación estable, categorías comprensibles y jerarquías consistentes reducen carga cognitiva. En “Línea Norte”, los artículos de ayuda estaban escondidos bajo el nombre creativo “Campamento base”. Sonaba aventurero, pero nadie asociaba esa etiqueta con devoluciones. Cambiarla por “Ayuda y devoluciones” redujo consultas y mejoró la localización de información.
Diseñar desde el principio incluye escribir criterios de aceptación accesibles en las historias de usuario. Por ejemplo: “El modal debe cerrarse con Escape, devolver el foco al activador y anunciar su título”. Esa frase evita que la accesibilidad quede reducida a una nota decorativa. La inclusión funciona mejor cuando se convierte en una propiedad verificable del componente.
Auditoría web y mejores prácticas: cómo probar accesibilidad sin depender de un botón mágico
Una Auditoría web útil no se limita a pasar una URL por un escáner y celebrar el número verde. Las herramientas automáticas detectan problemas valiosos: contrastes insuficientes, imágenes sin texto alternativo, nombres accesibles ausentes o errores de estructura. Sin embargo, no entienden por completo el propósito de una interfaz. Pueden comprobar que un enlace tiene texto, pero no saben si “más información” explica realmente a dónde lleva.
Por eso, las Mejores prácticas combinan automatización, revisión manual y pruebas con personas. La automatización debe entrar en el ciclo de desarrollo, idealmente desde las solicitudes de cambio y las pruebas de integración. Así, un error básico no llega a producción por accidente. No obstante, el equipo necesita complementar ese filtro con recorridos reales.
Un método de prueba que sigue el camino de las personas usuarias
El primer paso consiste en identificar las tareas prioritarias. Para una tienda online, suelen ser buscar un producto, filtrar, consultar detalles, añadir a la cesta, iniciar sesión, pagar y gestionar una devolución. Para una entidad financiera, pueden ser acceder a la cuenta, consultar movimientos, transferir dinero y recuperar credenciales. Revisar solo la página de inicio es como inspeccionar la puerta de un restaurante y declarar excelente la cocina.
- Inventariar páginas, aplicaciones, PDFs, vídeos, formularios y componentes compartidos.
- Priorizar recorridos por impacto de negocio y frecuencia de uso.
- Ejecutar validadores automáticos en local, integración continua y entornos previos.
- Probar con teclado sin utilizar el ratón.
- Revisar con lectores de pantalla, al menos en combinaciones relevantes de navegador y sistema.
- Validar contraste, zoom, reflujo, mensajes de estado y comportamiento en móvil.
- Registrar cada incidencia con severidad, criterio relacionado, evidencia y responsable.
- Repetir las pruebas después de corregir, porque los arreglos también pueden traer amigos indeseados.
La navegación por teclado merece una comprobación específica. Al pulsar Tab, el orden debe seguir una lógica visual y funcional. El foco nunca debe desaparecer. Los menús desplegables deben abrirse, recorrerse y cerrarse sin ratón. Los diálogos deben mantener el foco dentro mientras permanecen abiertos y devolverlo al elemento activador cuando se cierran. Estas reglas parecen básicas, aunque siguen fallando en muchos sitios donde el botón de cerrar funciona mejor como decoración que como control.
Las pruebas con lector de pantalla requieren escuchar, no solo mirar. Hay que comprobar si los encabezados dibujan una estructura comprensible, si las imágenes aportan información útil y si los controles anuncian su estado. Un acordeón debe informar de si está expandido o contraído. Un mensaje de éxito debe poder percibirse sin depender del cambio de color. Una validación correcta no debería obligar a adivinar qué acaba de pasar.
La documentación aporta continuidad. Conviene guardar informes de incidencias, capturas, resultados de pruebas, decisiones de componentes y fechas de corrección. Esta evidencia sirve para mejorar el producto y para responder ante solicitudes de clientes, organismos de vigilancia o procesos de contratación. Además, muestra que la accesibilidad forma parte de la gobernanza, no de un impulso puntual.
Las personas con discapacidad deben participar cuando sea posible en las pruebas de investigación y validación. Su experiencia revela barreras que ningún checklist detecta por completo. No se trata de pedir a una única persona que represente a toda la humanidad, algo agotador incluso para un superhéroe. Se trata de incorporar perspectivas diversas de forma recurrente y remunerada.
Una auditoría no es un certificado de inmortalidad. Cada nueva funcionalidad puede modificar el orden de foco, romper una etiqueta o esconder un mensaje. La calidad accesible se mantiene mediante hábitos de prueba, no mediante una captura de pantalla antigua.
IA, Ley Europea de Accesibilidad y gobernanza: automatizar sin perder el criterio humano
La inteligencia artificial ya participa en tareas de accesibilidad: genera subtítulos, propone descripciones de imágenes, detecta patrones de código, reescribe mensajes complejos y acelera revisiones repetitivas. Bien utilizada, reduce carga operativa y permite que los equipos encuentren fallos antes. Mal utilizada, produce una tranquilidad artificial: esa sensación de que una herramienta ha marcado “correcto” y, por tanto, la realidad se ha rendido.
Un generador de texto alternativo ilustra bien el límite. Puede reconocer que una imagen contiene una bicicleta, una persona y una calle. Sin embargo, quizá no entienda que la fotografía compara el sistema de suspensión de un modelo concreto. Para una persona que decide una compra, el contexto importa más que la etiqueta genérica. Por eso, las sugerencias automáticas deben revisarse en función del objetivo de la página.
Automatización responsable para equipos de producto
La IA puede ayudar a revisar grandes bibliotecas de contenido heredado. Por ejemplo, puede localizar imágenes sin descripción, identificar mensajes de error ambiguos o detectar componentes repetidos con patrones de foco inconsistentes. También puede proponer fragmentos de HTML semántico o explicar qué rol ARIA podría ser necesario. Aun así, el desarrollador debe validar el resultado. ARIA no es confeti: añadir más no siempre mejora la experiencia.
En los procesos de integración continua, conviene combinar reglas automáticas con umbrales de calidad. Si una modificación introduce controles sin nombre accesible o errores graves de contraste, la entrega debería avisar al equipo. Sin embargo, el proceso no debe bloquear cambios útiles por problemas irrelevantes ni permitir excepciones eternas. Cada excepción necesita motivo, responsable y fecha de revisión.
La Ley Europea de Accesibilidad tampoco equivale a una única plantilla aplicable a todos los países y servicios. La Directiva establece el marco, mientras que su ejecución se concreta mediante legislación nacional, autoridades competentes y mecanismos de vigilancia. Por ello, una empresa que opera en España, Francia, Alemania y otros mercados debe coordinar revisión legal, técnica y documental. Copiar una declaración de accesibilidad de otra compañía no es estrategia; es una forma bastante sofisticada de invitar al problema a tomar café.
Las microempresas de servicios pueden contar con determinadas excepciones previstas por la norma, pero esas excepciones no convierten la accesibilidad en irrelevante. Además, el ámbito legal no agota la exigencia comercial. Grandes clientes, plataformas de compra y organismos públicos solicitan cada vez más información sobre madurez accesible. Preguntan por políticas, auditorías, pruebas, formación y mecanismos para gestionar incidencias.
| Uso de IA | Aporta valor cuando | Revisión humana necesaria |
|---|---|---|
| Subtítulos automáticos | Se necesita una primera transcripción rápida | Corregir nombres, términos, tiempos y sentido |
| Texto alternativo sugerido | Se detectan imágenes sin descripción | Confirmar contexto, intención y datos relevantes |
| Análisis de código | Se buscan patrones repetitivos o errores técnicos | Comprobar semántica, interacción y compatibilidad real |
| Lenguaje claro | Se revisan mensajes largos o confusos | Validar tono, precisión jurídica y comprensión |
La gobernanza efectiva asigna responsabilidades claras. Producto define objetivos y prioridades. Diseño valida patrones y contenido. Desarrollo aplica bases semánticas y comportamiento. QA prueba recorridos. Legal interpreta el alcance regulatorio. Dirección aporta recursos y supervisa indicadores. Cuando todos esperan que otra persona resuelva el asunto, la accesibilidad termina en el mismo sitio que los calcetines perdidos: nadie sabe dónde está, pero todos aseguran haberla visto.
Un buen indicador no es solo el número de errores abiertos. También cuenta el porcentaje de componentes validados, el tiempo medio de corrección, la cobertura de recorridos críticos y la participación de personas usuarias en pruebas. De este modo, la organización mide prevención, no únicamente daños.
La tecnología acelera la detección; el criterio humano decide si una persona puede completar su tarea con dignidad y autonomía.
¿WCAG 2.2 es una ley aplicable automáticamente en toda la Unión Europea?
No. WCAG 2.2 es una recomendación técnica del W3C. La obligación legal procede de normas como la Ley Europea de Accesibilidad y de su aplicación nacional. En la práctica, WCAG se utiliza como referencia técnica esencial para demostrar accesibilidad.
¿Una herramienta automática puede certificar que una web es accesible?
No por sí sola. Los validadores detectan incidencias técnicas frecuentes, pero no evalúan completamente el orden de lectura, la claridad de los textos, el propósito de los controles o la facilidad para completar una tarea. Hace falta revisión manual.
¿Qué debe revisar primero una empresa con poco tiempo?
Debe auditar los recorridos de mayor impacto: acceso, recuperación de contraseña, búsqueda, formularios, páginas de producto, pago y atención al cliente. Corregir esas rutas reduce antes el riesgo y la fricción.
¿Qué papel tienen las personas usuarias de Tecnologías asistivas?
Aportan evidencia directa sobre barreras que una herramienta o un equipo interno puede pasar por alto. Las pruebas con personas usuarias deben planificarse de forma recurrente, con objetivos claros y remuneración adecuada.
Soy Ferran, tengo 29 años y me especializo en diseño de producto digital y arquitectura de la información. Me apasiona crear experiencias digitales intuitivas y centradas en el usuario.