Axively

WCAG 2.2 AA

Auditoría WCAG para sitios web modernos

Una auditoría WCAG comprueba si las personas pueden percibir, comprender, navegar y manejar su sitio web. Para la mayoría de los proyectos web comerciales, el objetivo práctico es WCAG 2.2 nivel AA: el nivel al que remiten muchas leyes, normas de contratación pública y políticas de accesibilidad.

Axively prueba las páginas públicas con los conjuntos de reglas de axe-core para WCAG 2.1/2.2 niveles A y AA, explica el impacto de cada infracción y genera sugerencias de corrección pensadas para desarrolladores.

Audit checklist

  • Confirme que cada control interactivo tiene un nombre accesible.
  • Revise la estructura de encabezados, las regiones (landmarks) y el HTML semántico.
  • Verifique el acceso por teclado y los indicadores de foco visibles.
  • Localice fallos de contraste en texto y componentes de la interfaz.
  • Compruebe etiquetas, errores e instrucciones de los formularios.
  • Revise imágenes, iconos y SVG en busca de alternativas útiles.
  • Vuelva a probar las plantillas corregidas y las páginas de mayor valor.

Por qué WCAG 2.2 AA es el objetivo práctico

Las WCAG se organizan en criterios de éxito de niveles A, AA y AAA. El nivel A cubre las barreras más básicas; el nivel AA añade requisitos ampliamente esperados en sitios públicos y comerciales. WCAG 2.2 mantiene los criterios conocidos de WCAG 2.1 y añade requisitos más recientes, como la apariencia del foco y el tamaño del objetivo.

Para el contenido web en la UE, la norma EN 301 549 remite a los criterios WCAG. Por ello, una auditoría WCAG es una base práctica para la preparación ante la EAA, las declaraciones de accesibilidad y los cuestionarios de contratación pública.

Fallos WCAG habituales que perjudican las conversiones

Los problemas de accesibilidad no son solo riesgo legal; son problemas de conversión. Las etiquetas ausentes dificultan completar formularios. El contraste bajo oculta precios y llamadas a la acción. Las trampas de teclado bloquean a quienes usan tecnología de asistencia y a los usuarios avanzados. Los mensajes de error confusos hacen que el proceso de compra parezca roto.

Las mejoras más rápidas suelen venir del sistema de diseño: botones, campos de formulario, diálogos modales, navegación y componentes de aviso accesibles. Corregir esos patrones mejora todas las páginas que los usan.

  • Botones y enlaces sin nombre descriptivo
  • Campos de formulario sin etiquetas o con errores inaccesibles
  • Diálogos modales que no gestionan el foco
  • Fallos de contraste en llamadas a la acción y estados deshabilitados
  • Iconos que se anuncian como nombres de archivo sin significado

Un flujo de corrección realista

Empiece por las infracciones críticas y graves en las páginas que generan ingresos. Después corrija las plantillas reutilizables. Tras cada sprint, ejecute un escaneo de verificación para que el equipo vea si la misma regla sigue apareciendo. Guarde las evidencias de antes y después junto a las notas de versión; serán útiles cuando los clientes pidan documentación de accesibilidad.

FAQ

¿WCAG 2.2 sustituye a WCAG 2.1?

WCAG 2.2 se basa en WCAG 2.1. Una auditoría WCAG 2.2 AA sigue comprobando los criterios A/AA anteriores y añade los nuevos requisitos de la versión 2.2.

¿Puede axe-core encontrar todos los problemas WCAG?

Ningún motor automático encuentra todos los problemas WCAG. Las pruebas automatizadas son excelentes para muchos fallos detectables en el código; la calidad del contenido, la lógica de las tareas y algunos requisitos multimedia necesitan revisión humana.

¿Las correcciones WCAG son de los desarrolladores o del equipo legal?

Los desarrolladores corrigen el código, pero producto, diseño y legal deben acordar el alcance, la redacción de la declaración y las prioridades de riesgo. La accesibilidad es un proceso de calidad del producto, no la lista de una sola persona.