Accesibilidad web: quién está obligado y cuánto cuesta

La accesibilidad web es la práctica de ingeniería y diseño UX/UI que cumple con WCAG 2.2 Nivel AA y el Acta Europea de Accesibilidad mediante HTML semántico, navegación por teclado y contraste mínimo de 4,5:1 en webs corporativas de €4.500 a €9.000.

La mayoría de empresas llega al tema como un susto normativo justo antes de una revisión. Ese orden produce el peor resultado posible: un montón de parches sobre una web terminada. Pensado desde el primer boceto, el mismo requisito no cuesta casi nada y de paso mejora la web para todo el mundo.

Esta guía trata las decisiones de diseño y no la norma: qué seis fallos aparecen en casi toda auditoría, cómo probar tu web en diez minutos, cuánto cuesta el trabajo, y quién está realmente obligado desde el 28 de junio de 2025.

La accesibilidad no es un estilo visual, y conviene aclararlo primero. Las webs que cumplen se ven como cualquier otra web bien hecha. Lo que cambia es un conjunto de decisiones que normalmente se toman sin pensarlas: cuánto contraste tiene el texto, qué pasa al pulsar el tabulador, si un campo sigue entendiéndose cuando desaparece el texto de ayuda.

Según la Iniciativa de Accesibilidad Web del W3C, las pautas se apoyan en cuatro principios: el contenido debe ser perceptible, operable, comprensible y robusto. Esas cuatro palabras sirven más en una reunión con una agencia que los criterios numerados, porque de ellas salen preguntas que cualquiera puede hacerle a un diseño.

El argumento comercial es más simple que el moral. Alrededor de una de cada seis personas en el mundo vive con una discapacidad significativa, y la proporción sube claramente con la edad, lo que importa en cualquier producto dirigido a mayores de cincuenta.

Desde el 28 de junio de 2025 se aplica en España la Ley 11/2023, que traspone la Directiva europea de accesibilidad (Directiva UE 2019/882, conocida como European Accessibility Act). No alcanza a todas las webs por igual, y la idea extendida de que «ahora toda web debe ser accesible por ley» es incorrecta.

La normativa cubre los productos y servicios digitales dirigidos a consumidores (B2C): comercio electrónico, servicios bancarios para particulares, libros electrónicos, telecomunicaciones y transporte de viajeros. Una web corporativa industrial o informativa entre empresas (B2B), sin función de venta al consumidor ni área privada de autoservicio para clientes, no entra automáticamente en el ámbito de aplicación de la ley.

Existe además una exención legal explícita para microempresas: quienes presten servicios con menos de diez personas empleadas y un volumen de negocio anual o balance general que no supere los dos millones de euros quedan exentos de las obligaciones relativas a servicios. Para productos comercializados esa exención no aplica.

El sector público se rige por el Real Decreto 1112/2018, que traspone la Directiva 2016/2102 y remite a la norma europea EN 301 549. Esa misma norma es la referencia técnica de la Ley 11/2023: la versión citada en el Diario Oficial de la UE apunta a WCAG 2.1 AA, y la versión 4.1.1 publicada en septiembre de 2026 pasa a WCAG 2.2, aunque todavía no se ha citado. Construir según WCAG 2.2 AA cubre las dos.

Sobre las sanciones, la Ley 11/2023 no fija una tabla propia de multas: remite al régimen sancionador de la normativa sectorial que corresponda a cada producto o servicio. El texto refundido de la Ley General de derechos de las personas con discapacidad (Real Decreto Legislativo 1/2013) prevé multas de €301 a €1.000.000 según la gravedad. Las cifras redondas que circulan por internet sin cita legal no merecen crédito. Para una empresa privada, cumplir WCAG 2.2 AA desde el código elimina casi toda la incertidumbre.

Seis fallos concentran la mayor parte de lo que aparece en auditorías reales, y todos son decisiones de diseño y no errores de programación. El análisis anual WebAIM Million encuentra incumplimientos detectables de forma automática en más del 95 % de las portadas más visitadas. Corregidos en el boceto no cuestan nada; después del lanzamiento significan tocar plantillas terminadas.

• Contraste insuficiente, casi siempre gris sobre blanco porque en el diseño quedaba más sobrio.
• Textos alternativos ausentes, o que repiten el nombre del archivo.
• Enlaces que dicen «leer más», que un lector de pantalla anuncia fuera de contexto como una lista de entradas idénticas.
• Formularios cuya única etiqueta es el texto de ayuda, que desaparece con la primera tecla.
• Controles construidos con divs, invisibles para la tecnología de apoyo porque no llevan rol.
• Vídeo sin subtítulos, que excluye a personas sordas y a todo el que mira sin sonido.

Cada uno se arregla en minutos en un archivo de diseño y en horas en código de producción. Esa proporción es todo el argumento para tratar la accesibilidad como restricción de diseño y no como tarea de desarrollo.

El contraste es el fallo más frecuente y el más fácil de evitar, porque se comprueba antes de que exista una línea de código. Se pide una relación mínima de 4,5 a 1 entre texto y fondo en texto normal, y de 3 a 1 en texto grande y en los bordes visibles de los controles.

La trampa está en que las paletas de marca se eligen en monitores calibrados y salas en penumbra. Un gris medio que allí parece elegante deja de leerse en el móvil a plena luz. Comprobar la paleta al definir la marca, y no al montar las páginas, evita toda una categoría de rehacer trabajo.

El color tampoco puede ser lo único que transmite significado. Un formulario que marca los errores solo en rojo resulta inservible para la parte considerable de hombres con daltonismo. Añadir un icono y una frase cuesta una línea.

Queda el indicador de foco. Es habitual que se elimine el contorno que trae el navegador porque desentona con el diseño, y no se reemplace por nada. Esa sola decisión deja toda la web inutilizable con teclado, y es el fallo grave que más encontramos en trabajos por lo demás cuidados.

La navegación con teclado es la forma más rápida de juzgar una web y no necesita herramientas. Aparta el ratón, pulsa el tabulador repetidamente y observa. Si llegas a todos los controles, siempre ves dónde estás y nunca te quedas atrapado, la web está en un estado razonable.

Tres cosas fallan en la práctica. El orden salta porque los elementos se colocaron visualmente en vez de ordenarse en el marcado. Se abre una ventana modal y el tabulador sigue recorriendo la página de detrás, así que no se alcanza el botón de cerrar. Y un desplegable que solo se abre al pasar el cursor sencillamente no es alcanzable.

Hace falta además una manera de saltar los bloques repetidos. En una web con cabecera grande y menú largo, una persona pulsa si no veinte veces el tabulador en cada página antes de llegar al contenido. Un enlace de salto son unas pocas líneas y está entre las correcciones más rentables que existen.

Nada de esto exige un lector de pantalla. Tabulador, Enter, Escape y las flechas sacan a la luz la mayoría de los problemas serios en menos de diez minutos.

Los formularios son el punto donde las barreras cuestan dinero directamente, porque el formulario suele ser la conversión. Los requisitos son poco vistosos y breves, y casi toda web comercial incumple al menos uno.

Cada campo necesita una etiqueta visible que siga visible. El texto de ayuda dentro del campo no es una etiqueta: desaparece con la primera tecla y deja adivinando a quien se distrajo. Los campos relacionados necesitan agrupación para que un lector de pantalla los anuncie como conjunto.

Los errores tienen que decir qué hacer, no qué pasó. «Campo no válido» no sirve de nada; «introduce la fecha como DD/MM/AAAA» sí. El error además debe anunciarse, asociarse al campo y ser alcanzable, y ahí es donde falla a menudo un resumen de errores visualmente bonito al principio de la página.

Los límites de tiempo merecen mención porque son invisibles hasta que hacen daño. Una reserva que cierra la sesión a los diez minutos excluye a quien lee despacio o usa lector de pantalla, y ese grupo tarda bastante más en el mismo recorrido.

Los widgets superpuestos como AccessiBe o UserWay, esos botones flotantes de accesibilidad que prometen cumplimiento normativo inmediato por una cuota mensual, merecen una respuesta directa. Desde mediados de 2025 se comercializan de forma insistente ante empresas que temen inspecciones.

No hacen accesible una web. Un overlay se coloca mediante JavaScript encima del marcado existente y pretende adivinar un significado que no puede ver en el DOM: no sabe qué muestra una imagen sin describir, no puede deducir una jerarquía coherente de encabezados ni reparar componentes interactivos programados con divs sin rol ARIA. Ajustar el tamaño de la letra o los colores del contraste es algo que la persona ya puede hacer directamente en las opciones de su propio navegador.

Las comprobaciones automáticas, que es todo lo que un overlay puede ejecutar, solo detectan una parte de los problemas: incluso la cifra más generosa publicada, el estudio de cobertura de la propia Deque, se queda en torno al 57 %. Trampas de teclado, órdenes de foco ilógicos o modales inaccesibles quedan completamente fuera de su alcance. Además, un overlay no aporta protección jurídica alguna. Usuarios de lectores de pantalla llevan años denunciando que estos widgets interfieren con sus tecnologías de asistencia, y más de 800 especialistas han firmado el Overlay Fact Sheet desaconsejándolos. Lo que evalúan los tribunales y los organismos reguladores es exclusivamente el código HTML semántico subyacente.

Auditar una web existente funciona en tres pasadas, y el orden importa porque cada una es más cara que la anterior. Contratar primero una auditoría externa, antes de las pasadas gratuitas, gasta la mayor parte del presupuesto en hallazgos que podrías haber reunido tú.

La primera pasada es automática. Una extensión de navegador o un comprobador de línea de comandos encuentra contrastes, alternativos ausentes y campos sin etiqueta en minutos. Las herramientas automáticas detectan solo una parte de los problemas reales (alrededor del 57 % en el estudio de Deque, menos según otras estimaciones), así que un informe limpio es el principio y no el final.

La segunda pasada es manual y gratuita: el recorrido con teclado descrito arriba, más revisar la página con las imágenes desactivadas y con el zoom al 200 %. Aquí salen los problemas estructurales que ningún escáner ve.

La tercera es la revisión experta con tecnología de apoyo, y es la que merece pagarse. Cubre lo que ninguna herramienta detecta: si el orden de lectura tiene sentido, si los anuncios sirven de algo y si la tarea se puede completar. Contrátala después de las dos primeras, no antes.

Integrada en una web nueva desde el diseño inicial, la accesibilidad supone €0 extra en la inversión. La verificación de paleta, los estados de foco en teclado, los formularios etiquetados y la estructura semántica son decisiones de ingeniería y no trabajo añadido. En nuestros precios publicados, una landing page parte de €1.500 y una web corporativa completa de €4.500, incluyendo la accesibilidad de serie en cada bloque.

Adaptar una web corporativa ya publicada plantea un escenario diferente. Arreglos de contenido como textos alternativos y relaciones de contraste suelen situarse de €500 a €1.500. Sin embargo, la remediación estructural de plantillas, como reconstruir componentes hechos con divs, solucionar trampas de foco o reordenar el DOM para que coincida con el orden visual, suele situarse de €1.500 a €4.500 en una web corporativa consolidada.

Una auditoría experta con tecnología de apoyo sobre una web mediana es por sí sola un encargo de cuatro cifras, y por eso conviene realizar antes las comprobaciones manuales gratuitas. La métrica decisiva es la tasa de retrabajo: solucionar un contraste en Figma cuesta cinco minutos, mientras que corregirlo tras el lanzamiento obliga a modificar todas las plantillas y repetir pruebas de regresión. Precios sin IVA del 21 %.

Los centros sanitarios afrontan requisitos especialmente estrictos de accesibilidad y privacidad, como detallamos en nuestra guía de diseño web para clínicas y consultas médicas.

Utilice nuestra lista de verificación de accesibilidad EAA 2027 y WCAG 2.2 AA para auditar sus plantillas e integrar tokens accesibles en su sistema de diseño.