Una página puede parecer perfectamente normal y, aun así, resultar casi imposible de utilizar para alguien que navega sin ratón, necesita ampliar mucho el texto o utiliza un lector de pantalla.

También puede tener botones que apenas se distinguen del fondo, formularios que no explican por qué se ha producido un error o vídeos cuyo contenido solo se entiende si se escucha el audio. Son barreras que muchas veces pasan desapercibidas porque quien ha diseñado, programado o revisado la web no se encuentra con ellas.

La accesibilidad web consiste precisamente en evitar estas barreras. El objetivo es que cualquier persona pueda percibir el contenido, entenderlo, navegar por él e interactuar con la página, con independencia de sus capacidades o de la tecnología que utilice.

No se trata de crear una versión alternativa o «especial» de la web. Se trata de hacer bien la web principal.

¿A quién ayuda una web accesible?

Cuando hablamos de accesibilidad solemos pensar en una persona ciega utilizando un lector de pantalla. Es uno de los casos más claros, pero no el único.

Una web accesible ayuda, entre otras, a:

  • Personas ciegas o con baja visión que utilizan lectores de pantalla, ampliadores o configuraciones de alto contraste.
  • Personas con daltonismo o dificultades para distinguir determinados colores.
  • Personas sordas o con problemas de audición que necesitan subtítulos o transcripciones.
  • Personas con movilidad reducida que navegan con teclado, pulsadores, reconocimiento de voz u otros dispositivos.
  • Personas con dificultades cognitivas, de atención, comprensión o memoria.
  • Personas mayores que necesitan textos claros, elementos fáciles de reconocer y zonas de pulsación suficientemente grandes.

Además, muchas limitaciones son temporales o dependen del contexto. Alguien puede tener un brazo inmovilizado, intentar leer la pantalla bajo el sol, consultar un vídeo sin sonido o navegar desde un móvil pequeño. En todas estas situaciones, las mismas medidas de accesibilidad vuelven a ser útiles.

La accesibilidad es imprescindible para algunas personas y mejora la experiencia para prácticamente todas.

Los cuatro principios de la accesibilidad

Las Pautas de Accesibilidad para el Contenido Web (WCAG), publicadas por el W3C, organizan la accesibilidad alrededor de cuatro principios:

Perceptible

La información debe poder percibirse de distintas maneras. Por ejemplo, una imagen informativa necesita un texto alternativo y un vídeo hablado puede necesitar subtítulos.

También implica que el texto tenga contraste suficiente, que pueda ampliarse sin romper la página y que la información no dependa únicamente del color.

Operable

Todos los elementos deben poder utilizarse. Una persona que navega con teclado tiene que poder recorrer el menú, abrir un desplegable, completar un formulario y saber en todo momento qué elemento tiene el foco.

Aquí entran también cuestiones como evitar bloqueos de teclado, permitir detener movimientos que puedan molestar y utilizar botones suficientemente grandes y separados.

Comprensible

La navegación y el contenido deben resultar claros y previsibles. Los campos de un formulario tienen que estar bien identificados, los errores deben explicar qué ha pasado y los botones deben indicar qué acción realizan.

Un enlace que dice «descargar la guía de accesibilidad» aporta mucha más información que cinco enlaces seguidos con el texto «haz clic aquí».

Robusto

La página debe estar construida de forma que distintos navegadores y tecnologías de asistencia puedan interpretarla correctamente.

Esto se consigue utilizando HTML semántico, respetando la jerarquía de encabezados y empleando ARIA solo cuando es necesario y de forma correcta. Añadir atributos ARIA a lo loco no arregla una estructura HTML deficiente y, en algunos casos, puede empeorarla.

¿Qué necesita una web para ser accesible?

No existe un único botón que convierta una web en accesible. El resultado depende del diseño, el desarrollo, los contenidos y las funcionalidades.

Algunos de los puntos que revisamos con más frecuencia son:

  • Una estructura lógica de títulos y subtítulos.
  • HTML semántico para menús, botones, enlaces, tablas y formularios.
  • Navegación completa mediante teclado y un foco siempre visible.
  • Contraste suficiente entre texto, controles y fondos.
  • Textos alternativos adecuados para las imágenes informativas.
  • Imágenes decorativas ignoradas correctamente por los lectores de pantalla.
  • Etiquetas asociadas a los campos de formulario e instrucciones fáciles de entender.
  • Mensajes de error que no dependan únicamente del color.
  • Subtítulos, transcripciones y alternativas para el contenido multimedia.
  • Posibilidad de ampliar el texto y hacer zoom sin perder contenido ni funcionalidad.
  • Contenido que se adapte a móvil sin obligar a desplazarse en varias direcciones.
  • Enlaces, botones y zonas táctiles fáciles de identificar y pulsar.
  • Control sobre carruseles, animaciones o contenidos que se actualizan automáticamente.
  • Idioma de la página correctamente declarado.

Como referencia, WCAG 2.1 exige para el nivel AA una relación de contraste mínima de 4,5:1 en texto normal y de 3:1 en texto grande. WCAG 2.2 añade mejoras especialmente útiles para móvil, la autenticación y las personas con dificultades cognitivas o motoras. Aunque la referencia normativa más habitual en España sigue vinculada a WCAG 2.1 y a la norma EN 301 549, en un proyecto nuevo tiene sentido trabajar ya con WCAG 2.2 de nivel AA.

¿Un plugin puede hacer accesible una web WordPress?

Puede ayudar, pero no puede resolverlo todo.

Un plugin puede añadir alguna función útil o corregir un problema concreto. Lo que no puede hacer de manera fiable es reconstruir una jerarquía de contenidos incoherente, decidir si un texto alternativo explica bien una imagen, convertir en comprensible un formulario mal planteado o garantizar que un proceso de compra se pueda completar con lector de pantalla.

Lo mismo sucede con los widgets que prometen accesibilidad automática mediante una capa superpuesta. Cambiar colores, ampliar tipografías o añadir un botón flotante no corrige necesariamente el código ni las interacciones que hay debajo.

En WordPress intervienen el tema, los plugins, el maquetador y el contenido introducido desde el administrador. Incluso la etiqueta oficial accessibility-ready se refiere a unos requisitos mínimos del tema y no garantiza por sí sola que la web completa cumpla WCAG AA.

La accesibilidad debe formar parte del desarrollo y del mantenimiento, no instalarse al final como un parche.

¿Cómo puedo saber si mi web es accesible?

El primer paso es realizar una auditoría. Herramientas como Lighthouse, WAVE, axe DevTools o Accessibility Insights permiten encontrar bastantes errores técnicos y son muy útiles para obtener una primera fotografía.

Ahora bien, una puntuación de 100 en Lighthouse no certifica que una web sea accesible. El propio W3C advierte de que ninguna herramienta automática puede determinar por sí sola si un sitio cumple los estándares. Hay aspectos que necesitan criterio humano.

Una herramienta puede saber que una imagen tiene atributo alt, pero no si el texto incluido tiene sentido. Puede detectar que un campo no tiene etiqueta, pero no siempre si las instrucciones del formulario son comprensibles. Tampoco reproduce con fiabilidad la experiencia completa de alguien que utiliza un lector de pantalla.

Una revisión razonable debería combinar:

  1. Análisis automático de una muestra representativa de páginas.
  2. Navegación completa utilizando solo el teclado.
  3. Comprobación del orden y la visibilidad del foco.
  4. Pruebas con lectores de pantalla como NVDA o VoiceOver.
  5. Revisión manual de estructura, textos alternativos, formularios y mensajes.
  6. Pruebas de ampliación, contraste, adaptación a móvil y contenido multimedia.
  7. Revisión de los flujos importantes: contacto, registro, reserva, compra o pago.
  8. Documentación de los problemas, su gravedad y las correcciones necesarias.

No basta con analizar únicamente la portada. Una web puede tener una página de inicio impecable y un formulario de contacto, una reserva o un proceso de pago completamente inaccesible.

Accesibilidad web y SEO: se parecen, pero no son lo mismo

Muchas buenas prácticas de accesibilidad coinciden con las de SEO técnico:

  • Una estructura correcta de encabezados ayuda a entender el contenido.
  • Los textos alternativos aportan contexto a las imágenes.
  • Los enlaces descriptivos explican mejor su destino.
  • El HTML semántico aclara la función de cada elemento.
  • Los subtítulos y transcripciones convierten audio y vídeo en contenido textual.
  • Una navegación clara y una buena experiencia móvil reducen fricciones.

Google explica expresamente que el texto alternativo le ayuda a comprender las imágenes y su relación con la página. Sin embargo, sería exagerado afirmar que cumplir WCAG hace subir posiciones automáticamente. La accesibilidad no funciona como un interruptor directo de posicionamiento.

Lo correcto es decir que una web accesible suele estar mejor estructurada, ser más comprensible y ofrecer una experiencia más sólida. Todo ello facilita el rastreo y la interpretación del contenido y puede contribuir al SEO, pero no sustituye una estrategia de posicionamiento.

¿Y qué tiene que ver la accesibilidad con las inteligencias artificiales?

Los buscadores, asistentes y sistemas de IA necesitan extraer información de una página para poder interpretarla. Una estructura semántica clara, títulos bien ordenados, contenido textual, tablas correctamente construidas, descripciones de imágenes y transcripciones reducen la ambigüedad.

En otras palabras, muchas medidas pensadas para que una tecnología de asistencia entienda la web también facilitan que una máquina identifique qué es un título, qué contiene una imagen, qué relación existe entre varios datos o cuál es la acción de un botón.

Google indica que los requisitos técnicos que permiten acceder, rastrear e indexar una página también son la base para aparecer en sus resultados y formatos de búsqueda con IA.

Esto no significa que una web accesible vaya a ser citada automáticamente por ChatGPT, Gemini o cualquier otro asistente. No existe esa garantía. Significa que ofrecer contenido ordenado, explícito y disponible en formatos interpretables pone menos obstáculos tanto a las personas como a los sistemas que procesan la información.

¿Es obligatorio que mi web sea accesible?

Aquí viene la parte complicada: depende del titular, del servicio, del tamaño de la empresa, de la relación con la Administración, de la comunidad autónoma y, en algunos casos, de la normativa sectorial.

Decir que «desde junio de 2025 todas las webs deben ser accesibles» no es correcto. Tampoco lo es decir que las pequeñas empresas no tendrán nunca ninguna obligación.

La llamada Ley Europea de Accesibilidad no es una norma que apareciera de repente en 2025. La Directiva (UE) 2019/882 se aprobó en 2019, España la incorporó a su ordenamiento mediante la Ley 11/2023 y sus requisitos comenzaron a aplicarse a los productos y servicios incluidos en su ámbito el 28 de junio de 2025.

Sector público y webs vinculadas a servicios públicos

Los sitios web y aplicaciones móviles del sector público están sujetos al Real Decreto 1112/2018. También existen obligaciones para determinadas webs financiadas con fondos públicos o pertenecientes a entidades que gestionan servicios públicos.

En estos casos, la accesibilidad y los mecanismos de declaración, comunicación y revisión están regulados de forma específica.

Servicios incluidos en la Ley 11/2023

Desde el 28 de junio de 2025 se aplican los requisitos de la Ley 11/2023, que transpone el European Accessibility Act.

La ley no se aplica a cualquier web por el simple hecho de estar publicada. Su ámbito incluye determinados productos y servicios, como:

  • Servicios de comercio electrónico dirigidos a consumidores.
  • Servicios bancarios para consumidores.
  • Determinados servicios de transporte de viajeros y venta de billetes.
  • Servicios de comunicaciones electrónicas.
  • Acceso a servicios de comunicación audiovisual.
  • Libros electrónicos y sus programas especializados.
  • Determinados elementos digitales de suministros de agua, gas y electricidad.
  • Sitios y aplicaciones de agencias de viajes y turoperadores.
  • Redes sociales.

En el caso del comercio electrónico, la ley define el servicio como el prestado a distancia, por medios electrónicos y a petición de un consumidor, con el objetivo de celebrar un contrato. Por tanto, no es lo mismo una web corporativa que informa sobre una empresa que una web en la que un consumidor puede contratar o comprar.

La exención para microempresas

La Ley 11/2023 exime de sus requisitos de accesibilidad y de las obligaciones relacionadas a las microempresas que prestan servicios. No es solamente una ampliación de plazo ni una exención «parcial».

A estos efectos, una microempresa es la que:

  • Emplea a menos de 10 personas.
  • Y tiene un volumen de negocio anual que no supera los 2 millones de euros o un balance anual total que no supera esa cantidad.

Esta exención se refiere a los servicios dentro del ámbito de la Ley 11/2023. No debe interpretarse como una inmunidad frente a cualquier otra norma de accesibilidad, obligación contractual o requisito derivado de financiación pública.

Otras empresas privadas y las fechas de 2029 y 2030

El Real Decreto 193/2023 establece condiciones básicas de accesibilidad para bienes y servicios a disposición del público. Su artículo 14 incluye los sitios web y aplicaciones móviles privados cuyo contenido se refiera a esos bienes y servicios.

Para el resto de bienes y servicios privados nuevos, estas condiciones serán exigibles a partir del 1 de enero de 2029. Para los ya existentes que sean susceptibles de ajustes razonables, la fecha general es el 1 de enero de 2030. Las comunidades autónomas pueden establecer medidas adicionales dentro de sus competencias.

Por tanto, una microempresa puede estar exenta actualmente de los requisitos de la Ley 11/2023 y, aun así, tener que prepararse para el marco más amplio que llegará después.

La Ley 10/2025 y la atención a la clientela

La novedad estatal más reciente es la Ley 10/2025, de Servicios de Atención a la Clientela, publicada el 27 de diciembre de 2025 y en vigor desde el día siguiente.

Esta ley se aplica directamente a las empresas que prestan determinados servicios básicos de interés general —como agua, energía, transporte de viajeros, servicios postales, comunicaciones electrónicas o servicios financieros—, con independencia de su tamaño. También alcanza a otras empresas que venden bienes o prestan servicios a consumidores cuando tienen al menos 250 personas trabajadoras, más de 50 millones de euros de facturación anual o un balance superior a 43 millones.

Las empresas incluidas directamente en este ámbito deben tener un servicio de atención a la clientela diseñado con criterios de accesibilidad universal y ofrecer alternativas cuando un canal no pueda hacerse accesible. El plazo de adaptación previsto para ellas es de doce meses desde la entrada en vigor de la ley, es decir, hasta el 28 de diciembre de 2026.

Además, la Ley 10/2025 modificó la legislación general de consumidores. Desde el 28 de diciembre de 2025, cualquier empresa debe ofrecer medios y soportes universalmente accesibles en sus servicios de información y reclamación, facilitar medios alternativos y explicar cómo presentar una queja o reclamación por vía postal, telefónica y electrónica.

Este matiz es importante: la ley no convierte automáticamente toda la web de cualquier pyme o profesional en una web obligada a cumplir íntegramente WCAG AA. Sí obliga a revisar que los canales digitales de atención, contacto y reclamación puedan ser utilizados por personas con discapacidad.

¿Qué cambia en Cataluña?

En Cataluña existe una capa normativa propia que puede adelantar o ampliar las obligaciones estatales: el Decret 209/2023, por el que se aprueba el Codi d’accessibilitat de Catalunya, en vigor desde el 4 de marzo de 2024.

Para las webs y aplicaciones del sector público catalán, las corporaciones de derecho público, los sitios financiados públicamente y las entidades que prestan servicios públicos mediante concesión o contrato, el Código exige con carácter general WCAG 2.1 de nivel AA, junto con los requisitos adicionales de su anexo 5a.

También exige esos criterios a las webs y aplicaciones de entidades privadas que prestan servicios considerados esenciales o de interés general, como electricidad, agua, gas, telecomunicaciones, sanidad, servicios postales y banca. El Código contempla una posible excepción cuando cumplir suponga una carga desproporcionada, pero debe valorarse atendiendo al tamaño y los recursos de la entidad, el coste, el beneficio para las personas con discapacidad y la existencia de alternativas. No es una exención automática.

Además, establece obligaciones y plazos específicos para distintos sectores. Entre los casos más relevantes:

Actividad en CataluñaAlcance y calendario orientativo del Código
Entidades financieras y aseguradorasLas webs que permiten operaciones, contratación o consulta de cuentas o cuadros médicos tuvieron un plazo de un año; las aplicaciones, de dos años. Los plazos vencieron en marzo de 2025 y marzo de 2026, respectivamente.
Venta online de alimentaciónDeterminados supermercados y cadenas deben hacer accesible el proceso de compra en plazos de dos a cuatro años desde la entrada en vigor, según su número de establecimientos y tamaño: entre marzo de 2026 y marzo de 2028.
Venta de entradasLas plataformas de espectáculos, cines y determinadas instalaciones deportivas tienen plazos de dos a cuatro años, según su dimensión o aforo: entre marzo de 2026 y marzo de 2028.
Alojamientos turísticos con reserva onlineLos establecimientos y cadenas incluidos deben adaptar la reserva en plazos de dos a cuatro años, según el número de establecimientos o plazas: entre marzo de 2026 y marzo de 2028.
Centros educativosLas herramientas online de gestión de determinados centros tuvieron dos años; sus webs informativas disponen de tres años: marzo de 2026 y marzo de 2027.

La diferencia práctica es relevante. La Ley 11/2023 estatal contiene una exención expresa para las microempresas que prestan servicios. El Código catalán, en cambio, fija obligaciones propias para entidades y actividades concretas y permite alegar carga desproporcionada tras analizar el caso; no reproduce aquella exención general de forma automática. Una microempresa exenta de una obligación estatal puede, por tanto, estar sometida a una obligación catalana si su actividad encaja en alguno de los supuestos del Código.

Esto tampoco significa que, por estar en Cataluña, la web meramente informativa de cualquier pequeño profesional deba cumplir ya íntegramente WCAG AA. Hay que comprobar la actividad, los servicios ofrecidos, si permite contratar, comprar o reservar, el tamaño de la entidad, la financiación pública y el calendario concreto. En caso de concurrencia, prevalecen las condiciones sectoriales más exigentes.

Empresas de especial trascendencia económica

También existen obligaciones anteriores para determinadas empresas que prestan servicios al público de especial trascendencia económica. La Ley 56/2007 incluye empresas de ciertos sectores que superan los 100 trabajadores o los 6.010.121,04 euros de volumen anual de operaciones.

Entre esos sectores aparecen las telecomunicaciones, servicios financieros, suministros, agencias de viajes, transporte y determinadas actividades de comercio minorista.

¿Puede haber sanciones?

Sí. La Ley 11/2023 remite primero al régimen sancionador de cada sector y, de forma supletoria, a la Ley General de derechos de las personas con discapacidad. Esta última contempla multas desde 301 hasta 1.000.000 de euros.

Eso no significa que cualquier error de contraste provoque automáticamente una multa millonaria. La cuantía depende de la norma aplicable, la gravedad, el alcance, la intencionalidad, la reincidencia y otras circunstancias. Presentar únicamente la cifra máxima sin explicar este contexto puede generar una alarma innecesaria.

La obligación concreta no debería decidirse con un test online ni con una frase genérica. Hay que estudiar cada caso.

Nota: la información normativa de este artículo se ha comprobado con la legislación consolidada disponible en julio de 2026. No sustituye el asesoramiento jurídico aplicable a un caso concreto.

Preguntas habituales sobre accesibilidad web

¿Puedo hacer mi web accesible?

En la mayoría de los casos, sí.

Primero hay que revisar la web para saber qué barreras existen y de dónde vienen. Algunas pueden corregirse ajustando estilos, plantillas o contenidos. Otras requieren modificar componentes, formularios, menús o funcionalidades desarrolladas por terceros.

No se puede prometer un resultado sin conocer el proyecto, pero casi siempre es posible mejorar mucho la accesibilidad con un plan ordenado y prioridades claras.

¿Tengo que hacer una página web nueva?

No necesariamente.

Si la base técnica es buena, puede ser más eficiente adaptar la web actual. Cuando el tema, el maquetador o los plugins generan código difícil de corregir, o la página acumula problemas de estructura y mantenimiento, rehacerla puede resultar más razonable que encadenar parches.

La decisión debe tomarse después de una auditoría, comparando el coste de corregir con el de reconstruir. Dar por hecho que todo necesita una web nueva sería tan poco serio como asegurar que cualquier instalación puede arreglarse con un plugin.

¿Cómo puedo saber si mi web es accesible?

Una comprobación automática sirve como punto de partida, pero no como certificado. Para obtener una respuesta fiable hay que combinar herramientas, revisión manual, navegación con teclado y pruebas con tecnologías de asistencia.

En Departamento de Internet podemos revisar una muestra representativa de la web, localizar las barreras principales y preparar un informe con prioridades y soluciones. Así sabrás qué funciona, qué debe corregirse y qué implicación técnica tiene cada cambio.

¿Estoy obligado a que mi web sea accesible?

Depende. Una tienda online, una administración pública, una empresa grande de un sector regulado y la web informativa de un profesional autónomo no se encuentran necesariamente en la misma situación.

Para responder hay que comprobar:

  • Quién es el titular de la web.
  • Qué actividad realiza.
  • Si permite comprar, contratar, reservar o pagar.
  • Si se dirige a consumidores.
  • Cuántas personas emplea la empresa y cuál es su volumen de negocio o balance.
  • Si gestiona un servicio público, recibe financiación pública o trabaja mediante un contrato con la Administración.
  • Si sus canales de atención, contacto y reclamación cumplen la Ley 10/2025.
  • Si la actividad se desarrolla en Cataluña y está incluida en el Código de accesibilidad catalán.
  • Qué normativa sectorial y autonómica resulta aplicable.
  • Si hablamos de una obligación actual o de los plazos previstos para 2029 y 2030.

Podemos estudiar el caso y separar tres cosas que a menudo se mezclan: lo que ya es obligatorio, lo que será exigible más adelante y lo que conviene mejorar aunque todavía no exista una obligación directa.

Accesibilidad desde el principio o adaptación de una web existente

Incorporar la accesibilidad durante el diseño y el desarrollo suele ser más sencillo y económico que corregirla al final. Permite elegir bien los colores, preparar componentes accesibles, organizar el contenido y probar cada funcionalidad antes de publicarla.

Pero una web ya terminada también puede revisarse y mejorar. El proceso habitual consiste en:

  1. Analizar el tipo de web y sus posibles obligaciones estatales, autonómicas y sectoriales.
  2. Auditar una muestra representativa de páginas y procesos.
  3. Clasificar las barreras según su impacto.
  4. Corregir primero los problemas que impiden completar acciones.
  5. Volver a probar después de los cambios.
  6. Establecer unas pautas para que el contenido futuro no introduzca nuevas barreras.

En Departamento de Internet podemos ayudarte tanto a desarrollar una web accesible desde el inicio como a evaluar y adaptar una página existente. El objetivo no es conseguir una puntuación bonita en una herramienta, sino que la web pueda ser utilizada de verdad por el mayor número posible de personas.

Fuentes normativas y técnicas consultadas