Accesibilidad Web en Joomla: cómo adaptar las webs de tus clientes a la normativa europea

La accesibilidad web ha dejado de ser ese apartado que aparece al final de un proyecto, justo después de "ya que estamos, ponemos también el favicon".

Hoy tiene implicaciones legales, técnicas, comerciales y, sobre todo, humanas.

Desde el 28 de junio de 2025 es aplicable la Directiva Europea de Accesibilidad a determinados productos y servicios. Entre ellos se encuentran, por ejemplo, los servicios de comercio electrónico, determinados servicios bancarios y algunos servicios relacionados con el transporte y las comunicaciones. En España, la Directiva fue transpuesta mediante la Ley 11/2023.

Eso no significa que absolutamente cualquier página web europea esté automáticamente sometida a las mismas obligaciones. El ámbito depende del tipo de servicio, del proveedor y de otras circunstancias previstas en la normativa.

Pero hay algo que sí debería preocupar a cualquier agencia Joomla:

entregar una web accesible ya no es simplemente una cuestión de buenas prácticas. En muchos proyectos forma parte de los requisitos que hay que considerar desde el principio.

Y aquí aparece una buena noticia.

Joomla lleva años incorporando accesibilidad en su núcleo. Su plantilla predeterminada, sus funciones de navegación y su sistema de comprobación de contenido ofrecen una base muy interesante para trabajar con WCAG. Joomla señala actualmente su objetivo de alcanzar y mantener la conformidad con WCAG 2.2 AA.

La clave está en entender que Joomla puede darte una buena base, pero no puede convertir automáticamente una web en accesible.

La plantilla, las extensiones, los overrides, el contenido y, especialmente, las decisiones del desarrollador siguen teniendo mucho que decir.

Qué es realmente la accesibilidad web y qué tiene que ver WCAG 2.2

Cuando hablamos de accesibilidad web estamos hablando de conseguir que una persona pueda percibir, comprender, navegar e interactuar con un sitio web independientemente de sus capacidades y de la tecnología de asistencia que emplee.

Las WCAG, las Web Content Accessibility Guidelines del W3C, organizan sus recomendaciones alrededor de cuatro principios:

• Perceptible.
• Operable.
• Comprensible.
• Robusto.

WCAG 2.2 fue publicada como recomendación del W3C en octubre de 2023 y añadió nueve criterios de éxito respecto a WCAG 2.1. Entre ellos encontramos cuestiones especialmente interesantes para los desarrolladores, como el foco no oculto, el tamaño mínimo de los objetivos táctiles y la autenticación accesible.

Para una agencia Joomla, esto tiene una consecuencia práctica:

no basta con pasar una herramienta automática y conseguir una bonita puntuación de 95 o 100.

La accesibilidad requiere comprobar cómo funciona realmente la interfaz.

Una herramienta puede detectar que una imagen no tiene alt.

No puede decidir por ti si ese alt describe correctamente la información que aporta la imagen.

Y ahí empieza la parte divertida.

Bueno, divertida para quienes disfrutan revisando interfaces con teclado.

¿La Ley Europea de Accesibilidad obliga a todas las webs?

Esta es probablemente la primera pregunta que te hará un cliente.

Y conviene responderla correctamente.

No todas las páginas web están sujetas automáticamente a la misma obligación derivada del Acta Europea de Accesibilidad.

La Directiva 2019/882 se aplica a determinados productos y servicios. Entre los servicios incluidos están el comercio electrónico, determinados servicios de transporte, banca para consumidores, servicios de comunicaciones electrónicas y determinados servicios de acceso a contenidos audiovisuales.

La legislación española que transpone la Directiva, la Ley 11/2023, establece también excepciones. Por ejemplo, las microempresas que prestan servicios quedan exentas de determinadas obligaciones de accesibilidad contempladas en ese título.

Por otra parte, España cuenta con otras normas relacionadas con la accesibilidad de bienes, servicios, sitios web y aplicaciones. El Real Decreto 193/2023 establece condiciones básicas de accesibilidad y no discriminación para bienes y servicios a disposición del público y contempla requisitos específicos para sitios web y aplicaciones relacionados con bienes y servicios.

Por eso, antes de decirle a un cliente "tu web tiene que cumplir la EAA", conviene hacer algo mucho más profesional:

determinar qué normativa le resulta aplicable.

Esto evita dos problemas bastante desagradables.

• El primero es prometer una obligación que jurídicamente quizá no corresponda.
• El segundo es pensar que una web está fuera de cualquier obligación cuando sí existen otras normas aplicables.

Para proyectos con implicaciones legales concretas, la validación final debe hacerla un profesional jurídico especializado.

Joomla como base para crear webs accesibles

Joomla no parte de cero.

El proyecto Joomla lleva años trabajando en accesibilidad y su propia documentación explica que el CMS busca proporcionar una base accesible para crear sitios web.

Joomla 5 (y 6) mantiene esa filosofía y sus plantillas predeterminadas incorporan características orientadas a la accesibilidad, como navegación rápida y enlaces para saltar contenido. Joomla también incluye herramientas específicas para revisar problemas de accesibilidad en el contenido.

Una de las piezas más interesantes es Jooa11y, el Joomla Accessibility Checker.

Está integrado en Joomla y permite detectar visualmente numerosos problemas habituales relacionados con el contenido. Comprueba cuestiones como textos alternativos, enlaces genéricos, encabezados, contraste, etiquetas de formularios y declaración del idioma.

Y esto es importante:

Jooa11y no sustituye una auditoría completa de accesibilidad.

Su propia documentación deja claro que está orientado a problemas de contenido y no pretende ser un analizador completo del código.

Es decir, tenemos una excelente primera línea de defensa.

Pero todavía necesitamos más.

Jooa11y: el pequeño gran aliado de los redactores

Imagina que entregas una web a un cliente.

El diseño es perfecto.

La programación está revisada.

La plantilla funciona.

Y tres meses después el cliente empieza a publicar imágenes con nombres como:

foto-final-definitiva-2.jpg

Sin texto alternativo.

Aquí es donde Jooa11y puede convertirse en un aliado fantástico.

El comprobador puede señalar, entre otros problemas:

• Imágenes sin texto alternativo.
• Enlaces vacíos.
• Enlaces con textos demasiado genéricos.
• Encabezados que saltan niveles.
• Formularios sin etiquetas.
• Contraste insuficiente.
• Ausencia de idioma declarado.
• Problemas relacionados con tablas.

También incorpora avisos que requieren revisión humana, por ejemplo en vídeos sin subtítulos o determinados casos de contraste.

Esto permite introducir una idea muy importante en los proyectos Joomla:

la accesibilidad no termina cuando la agencia pulsa el botón de publicar.

El cliente seguirá creando contenido.

Por eso merece la pena formar al equipo que gestionará la web y dejar activadas herramientas que faciliten la detección de errores.

La accesibilidad es un proceso.

No una casilla que se marca una vez.

Navegación por teclado: la prueba que casi nadie debería saltarse

Si quieres hacer una primera prueba rápida de accesibilidad, cierra el ratón.

Sí.

Déjalo ahí.

Ahora intenta utilizar la web únicamente con el teclado.

Pulsa Tab.

Otra vez.

Y otra.

Comprueba qué elemento recibe el foco.

¿Puedes llegar al menú?

¿Puedes abrirlo?

¿Puedes cerrar un desplegable?

¿Puedes acceder a todos los controles?

¿Puedes llegar al contenido principal?

¿Te quedas atrapado en algún componente?

WCAG 2.2 establece que toda funcionalidad debe poder operarse mediante teclado, salvo las excepciones previstas por el propio criterio, y también exige evitar las llamadas "trampas de teclado".

Y hay otro detalle fundamental:

El foco debe ser visible

Un usuario que utiliza el teclado necesita saber dónde está.

WCAG 2.2 incluye el criterio 2.4.7, Focus Visible, de nivel AA. El indicador de foco debe poder verse cuando un componente recibe el foco.

Eliminar el outline porque "queda feo" puede ser una de esas pequeñas decisiones de diseño que luego generan un problema enorme.

Por ejemplo:

:focus { outline: none; }

Si haces esto, necesitas proporcionar otro indicador de foco visible y adecuado.

Una opción habitual es trabajar con :focus-visible y diseñar un indicador claramente perceptible.

WCAG 2.2 también incorpora el criterio 2.4.11, Focus Not Obscured (Minimum), que exige que el elemento que recibe el foco no quede completamente oculto por contenido creado por el autor. Esto es especialmente relevante cuando tenemos cabeceras fijas, barras inferiores, banners o elementos flotantes.

El típico menú fijo que tapa justo el botón que necesita pulsar el usuario tiene bastante menos gracia cuando lo miras desde aquí.

HTML semántico antes que ARIA

Aquí hay una regla que merece ser grabada a fuego:

primero HTML semántico, después ARIA cuando realmente haga falta.

Un botón debería ser un <button>.

Un enlace debería ser un <a>.

Un encabezado debería ser un <h2>, <h3> o el nivel que corresponda.

No conviertas un <div> en un botón simplemente porque puedes añadirle:

role="button"

ARIA tiene una función importantísima, especialmente en componentes dinámicos y aplicaciones complejas. Pero W3C recomienda no cambiar las semánticas nativas salvo que exista una razón para hacerlo. También establece que los controles ARIA interactivos deben poder utilizarse con teclado.

Para Joomla esto es especialmente relevante cuando trabajamos con:

• Overrides.
• Módulos personalizados.
• Menús.
• Formularios.
• Ventanas modales.
• Componentes de terceros.
• JavaScript personalizado.

Un override mal planteado puede convertir una estructura HTML razonablemente accesible en un pequeño campo de minas.

Cómo ayudan los overrides de Joomla a la accesibilidad

Los overrides son una de las grandes ventajas de Joomla para una agencia.

Permiten modificar la salida HTML de componentes y módulos sin tocar directamente el código original de Joomla. De esta manera podemos adaptar la estructura y mantener los cambios separados del núcleo.

Eso resulta especialmente útil cuando necesitamos:

• Corregir una estructura de encabezados.
• Añadir información semántica.
• Mejorar etiquetas accesibles.
• Revisar atributos de formularios.
• Modificar el marcado de determinados módulos.
• Corregir una salida generada por una extensión.

Pero hay una advertencia.

Un override no arregla mágicamente una extensión inaccesible.

Si el JavaScript depende de un div que actúa como botón, si el foco no se gestiona correctamente o si un modal no devuelve el foco al lugar adecuado, cambiar cuatro etiquetas HTML no solucionará el problema.

La accesibilidad hay que verla como un sistema completo:

HTML + CSS + JavaScript + contenido + interacción.

Cassiopeia: una buena base, pero no una garantía

Cassiopeia es la plantilla predeterminada de Joomla y está diseñada como una plantilla generalista, responsive y accesible. Joomla documenta también cómo personalizarla mediante sus opciones y user.css.

Esto permite realizar bastantes ajustes sin empezar desde una hoja en blanco.

Por ejemplo, puedes trabajar sobre:

• Contrastes.
• Tamaños de texto.
• Espaciado.
• Estados de foco.
• Diseño responsive.
• Jerarquía visual.
• Elementos de navegación.

Pero cuidado con una frase peligrosa:

"Como Cassiopeia es accesible, la web ya cumple."

No.

Una plantilla accesible es una base.

Después entran en juego tus modificaciones, los plugins, las extensiones, los módulos, los contenidos y los componentes externos.

La propia documentación de Joomla señala la importancia del contraste suficiente para cumplir los estándares de accesibilidad.

Por tanto, si una agencia sustituye Cassiopeia por una plantilla comercial, debe revisar qué ocurre con toda esa base de accesibilidad.

El diseño bonito puede seguir siendo bonito.

Pero tiene que seguir siendo utilizable.

Contraste de colores: el clásico problema que aparece cuando llega el diseñador

Hay una conversación que muchas agencias conocen:

"Ese gris queda mucho más elegante".

Y luego llega el contraste.

WCAG no entiende de elegancia.

Entiende de contraste suficiente.

Hay que revisar especialmente:

• Texto sobre fondos de color.
• Botones.
• Enlaces.
• Estados hover y focus.
• Elementos deshabilitados cuando corresponda.
• Iconos que transmiten información.
• Texto colocado sobre imágenes.
• Componentes dinámicos.

Jooa11y puede detectar determinados problemas de contraste, mientras que herramientas como WAVE ofrecen comprobaciones visuales y de contraste.

Pero los fondos con imágenes, degradados o transparencias pueden requerir una revisión adicional.

Por eso una herramienta que dice "todo bien" no significa necesariamente "todo bien".

Significa:

la herramienta no ha encontrado aquello que sabe detectar.

Es una diferencia enorme.

Formularios accesibles en Joomla

Los formularios son uno de los puntos donde una web puede romperse rápidamente.

Un formulario accesible necesita, entre otras cosas, que los campos tengan nombres y etiquetas comprensibles y que los errores puedan identificarse y entenderse.

No sirve demasiado tener:

• Nombre
• Email
• Mensaje

si el lector de pantalla no puede relacionar correctamente esas etiquetas con sus campos.

También debemos revisar:

• Campos obligatorios.
• Mensajes de error.
• Orden del foco.
• Instrucciones.
• Autocompletado cuando corresponda.
• Botones.
• Validación.
• Mensajes dinámicos.

Y aquí las extensiones Joomla merecen una revisión específica.

El núcleo puede estar perfectamente planteado y, sin embargo, una extensión de formularios introducir problemas.

Por eso la auditoría debe hacerse sobre la web renderizada, no únicamente sobre Joomla en abstracto.

Imágenes: el atributo alt no es un cajón para meter palabras clave

Este error sigue apareciendo muchísimo.

Tenemos una imagen de una oficina y alguien escribe:

alt="oficina empresa abogados Madrid despacho abogados"

Eso no es accesibilidad.

Es SEO con esteroides y bastante poca paciencia para quien utiliza un lector de pantalla.

El texto alternativo debe transmitir el propósito o la información relevante de la imagen.

Si la imagen es decorativa, la solución puede ser distinta.

Si contiene información imprescindible, esa información debe estar disponible de una manera accesible.

Jooa11y ayuda a detectar imágenes sin texto alternativo y otros problemas relacionados con los alt.

Pero, de nuevo, el criterio humano manda.

Una herramienta puede decirte:

Hay texto alternativo.

No puede decidir si ese texto es realmente útil para la persona que no puede ver la imagen.

Encabezados y arquitectura de contenidos

La jerarquía de encabezados también tiene una importancia enorme.

Una página debería tener una estructura lógica.

No deberíamos elegir un <h2> porque "se ve más pequeño".

Para eso está CSS.

Los encabezados deben reflejar la estructura del contenido.

Por ejemplo:

• H1 Accesibilidad web en Jooml
  • H2 Por qué importa la accesibilidad
  • H2 Cómo preparar Joomla
    • H3 Navegación por teclado
    • H3 Formularios accesibles
    • H3 Imágenes y textos alternativos
  • H2 Cómo auditar la web

Jooa11y detecta, entre otros problemas, saltos de nivel y determinados problemas relacionados con la estructura de encabezados.

Esto ayuda tanto a las personas que utilizan tecnologías de asistencia como a la propia comprensión de la página.

Y sí, también ayuda a SEO.

La accesibilidad y el SEO tienen bastantes puntos de encuentro.

Pero no son lo mismo.

Las extensiones Joomla son parte de la auditoría

Este punto debería aparecer en rojo en cualquier checklist de una agencia.

Joomla puede ser accesible y tu web no.

¿Por qué?

Porque puedes instalar una extensión que genere:

• HTML incorrecto.
• Botones sin nombre accesible.
• Modales inaccesibles.
• Carruseles imposibles de manejar con teclado.
• Formularios problemáticos.
• Menús con una gestión deficiente del foco.
• Controles que solo funcionan con ratón.

Por eso, antes de instalar una extensión en un proyecto donde la accesibilidad sea crítica, merece la pena revisar su comportamiento.

No te quedes únicamente con:

"Compatible con Joomla 5".

Eso habla de compatibilidad.

No necesariamente de accesibilidad.

Cómo auditar una web Joomla paso a paso

Aquí tienes un proceso que puedes convertir directamente en checklist interno de agencia.

Paso 1. Define el alcance legal

Antes de tocar código, determina qué normativa es aplicable al cliente.

Revisa el tipo de servicio, el mercado, el país, el tamaño del proveedor y las posibles excepciones.

No confundas "WCAG 2.2 AA es nuestro objetivo técnico" con "la ley exige exactamente esto en todos los casos".

Son conversaciones distintas.

Paso 2. Haz inventario de la web

Lista:

• Plantilla.
• Overrides.
• Componentes.
• Módulos.
• Plugins.
• Formularios.
• Elementos JavaScript.
• Contenido multimedia.
• Documentos descargables.
• Servicios externos.

Este inventario te permitirá saber dónde buscar problemas.

Paso 3. Ejecuta Jooa11y

Empieza por el propio Joomla.

Comprueba los contenidos y corrige errores relacionados con imágenes, enlaces, encabezados, contraste, formularios y otros avisos detectados.

Paso 4. Pasa Lighthouse

Lighthouse incluye auditorías específicas de accesibilidad y genera un informe con los problemas detectados y referencias para corregirlos.

Es rápido y muy útil para detectar problemas básicos.

Pero no conviertas la puntuación en el objetivo.

Un 100 no significa que una persona con discapacidad pueda completar correctamente todas las tareas.

Paso 5. Utiliza WAVE

WAVE ofrece una representación visual de los problemas y elementos relacionados con accesibilidad, estructura, contraste y ARIA.

Su extensión permite trabajar también con páginas locales, protegidas mediante contraseña o generadas dinámicamente.

Es especialmente útil para entender visualmente qué está pasando.

Paso 6. Comprueba con axe

axe DevTools permite realizar pruebas automatizadas y también dispone de mecanismos de comprobación manual guiada. Soporta criterios WCAG 2.0, 2.1 y 2.2.

Es una buena pieza para incorporar a un flujo de desarrollo más técnico.

Paso 7. Haz la prueba con teclado

Aquí no hay atajos.

Coge el teclado y recorre la web.

Comprueba el orden del foco.

Comprueba menús.

Comprueba formularios.

Comprueba modales.

Comprueba botones.

Comprueba elementos dinámicos.

Y comprueba que puedes salir de todo aquello en lo que has entrado.

Paso 8. Prueba con lector de pantalla

Una auditoría seria debe incluir tecnología de asistencia cuando el alcance del proyecto lo requiera.

Los tests automatizados no detectan todos los problemas y no sustituyen las pruebas manuales con lectores de pantalla.

Aquí puedes trabajar con tecnologías como NVDA, VoiceOver, TalkBack u otras según el entorno y el alcance del proyecto.

Paso 9. Revisa móvil

WCAG no es solamente "la web de escritorio".

Hay que comprobar:

• Zoom.
• Tamaño de objetivos.
• Orientación.
• Teclado virtual.
• Menús.
• Modales.
• Formularios.
• Elementos que aparecen o desaparecen.
• Foco y navegación.

WCAG 2.2 incorpora precisamente un criterio específico sobre el tamaño mínimo de los objetivos táctiles.

Paso 10. Repite después de corregir

La primera auditoría genera errores.

Los corriges.

Vuelves a auditar.

Y descubres otros.

Bienvenido al desarrollo web.

La accesibilidad es iterativa.

Una matriz sencilla para entregar webs Joomla con accesibilidad

Una agencia puede convertir todo este proceso en una matriz de control:

El valor de esta tabla no está en tener muchos checks.

Está en convertir la accesibilidad en parte del proceso de entrega.

¿Hay que rehacer una plantilla Joomla desde cero?

En muchos casos, no.

Y esta es probablemente una de las mejores noticias para una agencia.

Si tienes una plantilla razonablemente bien construida, puedes comenzar por una auditoría y corregir los problemas existentes.

Dependiendo del caso, puede ser suficiente trabajar sobre:

• CSS.
• Estados de foco.
• Estructura HTML.
• Overrides.
• JavaScript.
• Componentes.
• Formularios.
• Contenido.
• Extensiones.

Joomla permite realizar overrides para modificar la salida de componentes y módulos sin modificar directamente el código original.

Eso facilita aplicar correcciones sin convertir cada actualización del CMS en una aventura.

Pero si la plantilla tiene una arquitectura deficiente, depende de JavaScript inaccesible o utiliza componentes incompatibles, entonces puede ser más rentable sustituir determinadas partes.

La pregunta correcta no es:

"¿Podemos mantener esta plantilla?"

La pregunta es:

"¿Qué cambios necesitamos para que la experiencia completa sea accesible?"

Lo que una agencia debería incluir en su propuesta de accesibilidad

Aquí hay una oportunidad comercial interesante.

La accesibilidad no tiene por qué venderse como una reparación de última hora.

Puedes integrarla desde el principio en tu metodología.

Por ejemplo:

Auditoría inicial

Analizar la web actual y localizar los principales problemas.

Plan de corrección

Clasificar los problemas por gravedad, impacto y esfuerzo.

Desarrollo

Corregir plantilla, overrides, extensiones y componentes propios.

Contenido

Revisar imágenes, enlaces, encabezados, documentos y multimedia.

Validación

Ejecutar pruebas automáticas y manuales.

Documentación

Entregar al cliente un informe de lo realizado y de las recomendaciones para mantener la accesibilidad.

Formación

Explicar al equipo editorial cómo publicar contenido sin introducir nuevos problemas.

Esta última parte suele olvidarse.

Y puede ser la diferencia entre entregar una web accesible y entregar una web que empieza siendo accesible.

No prometas "100 % accesible" porque una herramienta marque 100

Este consejo merece su propio apartado.

Las herramientas automáticas son fantásticas.

Pero ninguna herramienta automática puede determinar por sí sola que una web es completamente accesible.

WAVE lo explica expresamente: los resultados automáticos ayudan a la evaluación humana, pero no pueden determinar por sí mismos si una página es accesible.

axe también señala que las pruebas automatizadas complementan las pruebas manuales y que determinados problemas requieren revisión humana y, cuando corresponde, tecnología de asistencia.

Por eso, como agencia, es mucho más profesional decir:

"Hemos realizado una auditoría de accesibilidad basada en WCAG 2.2 AA, hemos corregido los problemas detectados y hemos realizado pruebas automáticas y manuales dentro del alcance definido".

Eso es bastante más serio que:

"Lighthouse nos da 100".

La accesibilidad también es una oportunidad de negocio

Aquí aparece la parte que muchas agencias están pasando por alto.

La accesibilidad puede convertirse en una ventaja competitiva.

Una agencia que sabe desarrollar Joomla accesible puede ofrecer algo más que diseño y programación.

Puede ofrecer:

una metodología de desarrollo digital responsable y preparada para los requisitos de accesibilidad.

Y eso tiene valor.

Especialmente en proyectos de comercio electrónico, servicios financieros, transporte, administraciones, organizaciones grandes y empresas que necesitan demostrar que han incorporado la accesibilidad a sus procesos.

La propia normativa española establece obligaciones de accesibilidad para los servicios incluidos en su ámbito y contempla, entre otras cuestiones, la formación del personal de los prestadores de servicios.

Por tanto, formar al cliente también puede convertirse en parte del servicio.

Checklist final de accesibilidad Joomla

Antes de entregar una web, comprueba al menos:

• La web puede utilizarse con teclado.
• El foco siempre es visible.
• El foco no queda oculto detrás de elementos fijos.
• No existen trampas de teclado.
• Los encabezados tienen una jerarquía lógica.
• Los enlaces describen correctamente su destino.
• Las imágenes tienen alternativas adecuadas.
• Los formularios tienen etiquetas correctamente asociadas.
• Los mensajes de error son comprensibles.
• El contraste ha sido revisado.
• Los controles interactivos tienen nombres accesibles.
• ARIA se emplea cuando realmente aporta valor.
• Los menús funcionan sin ratón.
• Los modales gestionan correctamente el foco.
• El contenido funciona con zoom.
• Se ha probado la versión móvil.
• Se han revisado las extensiones de terceros.
• Jooa11y ha sido ejecutado.
• Se han realizado pruebas con Lighthouse, WAVE o axe.
• Se han hecho pruebas manuales.
• Se ha definido cómo se mantendrá la accesibilidad después de la entrega.

Y hay una última casilla que no debería faltar:

• El cliente sabe cómo publicar contenido accesible.

Joomla puede poner la primera piedra, pero la accesibilidad depende del proyecto completo

La accesibilidad web en Joomla no consiste en instalar un plugin, pulsar un botón y esperar que aparezca una medalla.

Joomla proporciona una base muy buena. Jooa11y ayuda a detectar errores habituales de contenido. Cassiopeia ofrece una referencia accesible. Los overrides permiten adaptar la salida HTML. Y herramientas como Lighthouse, WAVE y axe ayudan a encontrar problemas que de otra forma podrían pasar desapercibidos.

Pero la última palabra la tiene el proceso.

Diseño.

Código.

Contenido.

Extensiones.

Interacción.

Pruebas.

Y personas reales.

Porque el objetivo final de WCAG no es conseguir una puntuación bonita en un informe.

Es conseguir que una persona pueda entrar en una web, encontrar lo que busca y completar su tarea sin que su discapacidad se convierta en una barrera.

Y eso, legalmente importante o no, debería ser suficiente motivo para hacerlo bien.