WCAG 2.1 AA explicado para lectores no técnicos

Qué significa WCAG 2.1 AA en la práctica

WCAG 2.1 AA es un conjunto de requisitos de accesibilidad para sitios web, aplicaciones y documentos digitales. WCAG significa Pautas de Accesibilidad al Contenido en la Web (Web Content Accessibility Guidelines). Las normas están diseñadas para ayudar a que los servicios digitales sean utilizables por personas con discapacidad, incluidas las personas ciegas o con baja visión, sordas o con pérdida auditiva, con movilidad reducida, con discapacidades cognitivas, dificultades de aprendizaje o limitaciones temporales, como un brazo roto o fatiga visual.

Para quienes no tienen perfil técnico, la forma más sencilla de entender WCAG 2.1 AA es esta: se trata de un estándar reconocido para hacer que el contenido digital funcione para más personas. Cubre aspectos como si el texto se puede leer con facilidad, si un sitio web se puede usar con el teclado, si los lectores de pantalla pueden comprender la estructura de la página y si los formularios son claros y utilizables.

La parte 2.1 se refiere a la versión del estándar. La parte AA se refiere al nivel de conformidad. WCAG tiene tres niveles: A, AA y AAA. El nivel A es el mínimo básico. El nivel AA es el nivel al que aspiran la mayoría de las organizaciones y el que con más frecuencia exigen la ley o las políticas internas. El nivel AAA es más exigente y, por lo general, no se requiere en todo un sitio web.

Cuando se dice que un sitio cumple con “WCAG 2.1 AA”, normalmente se quiere decir que el sitio se ha diseñado y probado para cumplir los criterios de éxito de los niveles A y AA de WCAG 2.1. En realidad, la accesibilidad no es una acreditación puntual. Es un proceso continuo de diseño, gestión de contenidos, pruebas y mejora.

Por qué importa WCAG

La accesibilidad suele abordarse como un requisito legal, pero también es una cuestión básica de usabilidad y de servicio público. Si una persona no puede completar un formulario, leer un documento de política, reservar una cita o entender información importante por barreras evitables, el servicio no está funcionando correctamente.

WCAG ayuda a las organizaciones a identificar y reducir esas barreras. Proporciona un marco común que diseñadores, desarrolladores, equipos de contenido, equipos de contratación y responsables de decisión pueden utilizar. Esto es especialmente importante en el sector público, donde los servicios digitales deben funcionar para el mayor público posible.

Las mejoras de accesibilidad suelen beneficiar a todo el mundo, no solo a las personas con discapacidad. Los encabezados claros facilitan el escaneo de las páginas. Un buen contraste de color ayuda en pantallas móviles bajo la luz solar intensa. Los subtítulos ayudan a quienes están en lugares ruidosos. Los formularios compatibles con el teclado ayudan a usuarios avanzados. El lenguaje claro ayuda a todas las personas a entender qué deben hacer a continuación.

Los cuatro principios de WCAG

WCAG se basa en cuatro principios fundamentales. El contenido debe ser perceptible, operable, comprensible y robusto. A menudo se resumen con el acrónimo POUR.

Perceptible

Las personas deben poder percibir la información presentada. Esto significa que el contenido no debe depender únicamente de un sentido, como la vista o el oído. Algunos ejemplos son proporcionar alternativas textuales para las imágenes, subtítulos para los vídeos y suficiente contraste de color entre el texto y el fondo.

Operable

Las personas deben poder manejar la interfaz. Un sitio no debe requerir movimientos precisos del ratón ni gestos que algunas personas no puedan realizar. Muchas personas dependen del teclado, de dispositivos de conmutación o del control por voz. Por tanto, la navegación y los formularios deben funcionar sin ratón.

Comprensible

Las personas deben poder comprender tanto la información como el funcionamiento de la interfaz. Las páginas deben ser predecibles, las instrucciones deben ser claras y los formularios deben explicar los errores de una forma útil. Un lenguaje complicado puede ser, por sí mismo, un problema de accesibilidad.

Robusto

El contenido debe funcionar de forma fiable con distintos navegadores, dispositivos y tecnologías de apoyo, como los lectores de pantalla. Esto depende de utilizar una estructura y una codificación adecuadas para que la tecnología pueda interpretar correctamente el contenido.

Qué suele cubrir WCAG 2.1 AA

Aunque el estándar es detallado, muchos de sus requisitos pueden entenderse en términos sencillos. En el nivel WCAG 2.1 AA, normalmente se espera que las organizaciones aborden cuestiones como las siguientes:

  • Alternativas textuales: las imágenes con significado deben tener texto alternativo para que las personas usuarias de lectores de pantalla puedan comprender su finalidad.
  • Subtítulos y transcripciones: el vídeo pregrabado debe incluir subtítulos, y el contenido de audio debe contar con transcripciones cuando proceda.
  • Contraste de color: el texto y los elementos clave de la interfaz deben distinguirse claramente del fondo.
  • Acceso mediante teclado: las personas usuarias deben poder navegar por menús, enlaces, botones y formularios utilizando solo el teclado.
  • Foco visible: debe existir un indicador visual claro que muestre qué elemento está seleccionado en cada momento al navegar con el teclado.
  • Encabezados y estructura claros: las páginas deben usar correctamente encabezados, listas y etiquetas para que el contenido sea fácil de seguir.
  • Accesibilidad de formularios: los campos deben tener etiquetas, las instrucciones deben ser claras y los errores deben explicarse de forma que las personas puedan entenderlos y corregirlos.
  • Texto redimensionable y diseño adaptable: el contenido debe seguir siendo utilizable cuando las personas amplían el zoom o lo visualizan en pantallas más pequeñas.
  • Finalidad de los enlaces: los enlaces deben tener sentido, especialmente fuera de contexto. “Leer más” por sí solo suele no ser suficiente.
  • Navegación coherente: los elementos repetidos deben comportarse de forma predecible en todo el sitio.
  • Compatibilidad con lectores de pantalla: el código y la estructura subyacentes deben permitir que las tecnologías de apoyo interpreten correctamente el contenido.
  • Sin barreras innecesarias: el contenido no debe parpadear de formas que puedan provocar crisis, y las interacciones no deben depender únicamente de gestos complejos.

WCAG 2.1 añadió requisitos adicionales especialmente relevantes para el uso móvil y para personas con baja visión o discapacidades cognitivas. Entre ellos se incluyen la orientación, el reflujo, los métodos de entrada y la identificación de la finalidad de la entrada.

Quién debe cumplir WCAG 2.1 AA

La respuesta depende del país, del sector y del marco jurídico, pero en términos generales los organismos del sector público suelen estar obligados a cumplir WCAG 2.1 AA en sitios web y aplicaciones móviles. En toda la UE, los organismos públicos han estado sujetos a requisitos de accesibilidad en virtud de la Directiva de Accesibilidad de los Sitios Web, lo que llevó a muchas organizaciones a adoptar WCAG 2.1 AA como referencia práctica.

Esto suele incluir la administración central, las autoridades locales, el NHS y los organismos sanitarios, las universidades, las escuelas, los organismos reguladores y otras instituciones públicas, aunque el alcance exacto y las excepciones varían según el país.

Las organizaciones del sector privado también pueden tener que cumplir, especialmente cuando prestan servicios esenciales a consumidores o operan en sectores regulados. Incluso cuando no existe una obligación legal directa, WCAG 2.1 AA se utiliza ampliamente en contratación pública, contratos, políticas internas y gestión de riesgos.

También es habitual que las organizaciones exijan a sus proveedores cumplir WCAG 2.1 AA al contratar sitios web, intranets, portales, sistemas de reservas o plataformas documentales. En la práctica, esto significa que la accesibilidad no es solo una cuestión legal para la organización que publica el contenido, sino también para las agencias y los proveedores de software que la apoyan.

La relación con la Ley Europea de Accesibilidad

La Ley Europea de Accesibilidad, o EAA, es independiente de la Directiva de Accesibilidad de los Sitios Web, pero ambas están estrechamente relacionadas en su finalidad. Las dos buscan mejorar la accesibilidad, pero se aplican a ámbitos distintos.

La Directiva de Accesibilidad de los Sitios Web se centra principalmente en los sitios web y las aplicaciones móviles de los organismos del sector público. La EAA amplía los requisitos de accesibilidad a partes del sector privado al abarcar determinados productos y servicios comercializados en la UE, como los servicios de comercio electrónico, los servicios bancarios, los libros electrónicos, los terminales de venta de billetes, los terminales bancarios de consumo y algunos servicios digitales relacionados con el transporte.

Para quienes no tienen perfil técnico, lo importante es esto: la EAA aumenta la presión para que las organizaciones se tomen en serio la accesibilidad digital. Aunque un equipo solo esté familiarizado con las normas del sector público, la dirección general en Europa es clara. La accesibilidad se está convirtiendo en una expectativa estándar en cada vez más servicios digitales, no en un requisito de nicho.

WCAG suele utilizarse como referencia práctica para el contenido web y las interfaces digitales al demostrar accesibilidad, aunque los textos legales puedan referirse a normas más amplias o a normas europeas armonizadas. En otras palabras, si una organización se prepara para obligaciones relacionadas con la EAA, comprender WCAG 2.1 AA es un punto de partida sensato.

¿Cumplir significa que cada página es perfecta?

No necesariamente. Las grandes organizaciones suelen tener sistemas heredados, PDFs antiguos, herramientas de terceros y contenido archivado que plantean dificultades. Por lo general, el cumplimiento se evalúa en función de los requisitos concretos aplicables, y muchos organismos públicos publican una declaración de accesibilidad en la que explican qué cumple, qué no cumple y qué están haciendo para mejorar.

Dicho esto, las declaraciones de accesibilidad no sustituyen a la acción. Su finalidad es aportar transparencia, no servir de excusa para problemas evitables. Un programa de accesibilidad realista incluye gobernanza, pruebas, priorización y revisión periódica.

Cómo probar WCAG 2.1 AA

Probar la accesibilidad correctamente implica algo más que ejecutar un comprobador automático. Las herramientas automáticas son útiles, pero solo pueden identificar algunos problemas. Muchos problemas importantes de accesibilidad requieren revisión humana.

1. Empezar con comprobaciones automáticas

Las herramientas automáticas pueden detectar rápidamente problemas comunes como la ausencia de texto alternativo, un contraste de color deficiente, botones vacíos, etiquetas de formulario ausentes o problemas en la estructura de encabezados. Son útiles para localizar errores evidentes a gran escala, especialmente durante el desarrollo y la publicación de contenidos.

Sin embargo, las herramientas automáticas no pueden valorar de forma fiable si el texto alternativo es significativo, si las instrucciones son claras, si el orden del teclado tiene sentido o si una persona puede completar una tarea sin confusión.

2. Probar con el teclado

Una prueba sencilla pero muy eficaz consiste en dejar a un lado el ratón e intentar usar el sitio solo con el teclado. ¿Puede desplazarse por menús, enlaces, botones y formularios? ¿Puede ver dónde está el foco? ¿Puede abrir y cerrar elementos interactivos? ¿Puede enviar un formulario y corregir un error?

Si el uso del teclado resulta difícil, es probable que el sitio plantee barreras importantes para muchas personas.

3. Revisar manualmente el contenido y el diseño

La revisión manual debe abarcar los encabezados, el texto de los enlaces, las instrucciones, los mensajes de error, los títulos de página, el uso del color, la estructura de los documentos y la claridad general. Una página puede superar un análisis automático y, aun así, ser difícil de entender o imposible de usar en la práctica.

4. Probar con tecnología de apoyo

Siempre que sea posible, pruebe con lectores de pantalla y otras tecnologías de apoyo. Esto ayuda a comprobar si la estructura de la página se anuncia correctamente, si los controles tienen los nombres adecuados y si las actualizaciones dinámicas del contenido se comunican correctamente.

Esto no significa que todos los equipos de proyecto deban convertirse en usuarios expertos de todas las tecnologías de apoyo, pero sí que es importante realizar algunas pruebas prácticas, especialmente en los recorridos clave de las personas usuarias.

5. Incluir a personas con discapacidad en las pruebas

La información más valiosa suele proceder de pruebas con personas que realmente usan tecnologías de apoyo o encuentran barreras de accesibilidad en su vida diaria. Las pruebas con usuarios pueden mostrar dónde un servicio cumple técnicamente algunos criterios, pero aun así genera fricción, confusión o exclusión.

6. Probar también los documentos y los sistemas integrados

Las pruebas de accesibilidad no deben limitarse al sitio web principal. Los PDF, los documentos de Word, los formularios en línea, los mapas, los sistemas de reservas, las herramientas de pago y los widgets de terceros también pueden crear barreras. Si forman parte del recorrido de la persona usuaria, deben tenerse en cuenta.

Errores de concepto habituales sobre WCAG

  • “La accesibilidad es solo para personas ciegas.” En realidad, la accesibilidad abarca una amplia variedad de necesidades, incluidas diferencias auditivas, de movilidad, cognitivas y neurológicas.
  • “Un overlay o widget soluciona la accesibilidad.” No es así. La accesibilidad debe integrarse en el diseño, el código y el contenido.
  • “Si una herramienta automática dice que todo está bien, cumplimos.” Las pruebas automáticas son útiles, pero solo son una parte del proceso.
  • “La accesibilidad hace que los sitios web se vean simples.” Una buena accesibilidad favorece un diseño claro y usable. No impide una identidad visual sólida.
  • “Esto solo importa para las organizaciones grandes.” Las organizaciones pequeñas también prestan servicios a personas con discapacidad y pueden seguir afrontando riesgos legales, contractuales o reputacionales.

Qué deberían hacer las organizaciones a continuación

Para los equipos que no tienen un perfil muy técnico, el enfoque más práctico es tratar WCAG 2.1 AA como un estándar operativo y no como un tema especializado. Eso significa incorporarlo a la contratación, a los pliegos de diseño, a los flujos de trabajo de contenido, al aseguramiento de la calidad y a la gobernanza.

Un punto de partida sensato sería:

  • auditar los sitios web, aplicaciones y documentos actuales
  • identificar los recorridos prioritarios de las personas usuarias, como formularios, pagos, reservas y procesos de contacto
  • corregir primero las barreras más graves
  • formar a los editores de contenido y a los equipos de proyecto
  • establecer requisitos de accesibilidad para los proveedores
  • introducir pruebas periódicas en lugar de revisiones puntuales
  • mantener una declaración de accesibilidad precisa cuando sea obligatoria

La accesibilidad es más fácil y económica cuando se considera desde el principio. Adaptarla posteriormente suele ser más lento, más caro y menos eficaz.

En resumen

WCAG 2.1 AA es el estándar ampliamente reconocido que se utiliza para hacer que los sitios web y los servicios digitales sean más accesibles. Para quienes no tienen perfil técnico, conviene entenderlo como una lista práctica y un marco para eliminar barreras que impiden a las personas utilizar el contenido digital.

Es importante porque los servicios digitales deben funcionar para todas las personas, incluidas las personas con discapacidad. Los organismos del sector público suelen estar obligados a cumplirlo, y el contexto jurídico más amplio en Europa, incluida la Ley Europea de Accesibilidad, hace que las expectativas de accesibilidad se amplíen más allá del sector público.

El cumplimiento no consiste solo en superar un análisis o publicar una declaración. Requiere pruebas adecuadas, responsabilidades claras, prácticas de contenido accesibles y mejora continua. Las organizaciones que entienden esto están en mucha mejor posición para ofrecer servicios digitales legales, utilizables y justos.

🇱🇹 🇬🇧 🇩🇪 🇬🇷 🇫🇷 🇪🇸 🇵🇹 🇹🇷