Caso práctico, ejercicios y lista de comprobación

Esta lección aplica todo el curso a un encargo realista. Primero verás un caso resuelto paso a paso, desde la configuración de las herramientas hasta la lista de hallazgos; después, cinco ejercicios para comprobar lo aprendido, una lista de comprobación para tu próximo análisis automático y recursos oficiales para seguir profundizando.

Caso práctico: la sede electrónica del Ayuntamiento de Valdeloma

El Ayuntamiento de Valdeloma (ficticio, unos 40.000 habitantes) debe revisar su declaración de accesibilidad conforme al RD 1112/2018 (PDF, se abre en una ventana nueva) y encarga una auditoría de su portal y su sede electrónica frente a WCAG 2.2 AA, con correspondencia con la EN 301 549 v3.2.1 (PDF, se abre en una ventana nueva). El portal tiene unas 3.200 páginas; la sede ofrece cita previa, instancia general y pago de tributos, y se accede con Cl@ve.

Paso 1: preparar y configurar

• Herramientas: axe DevTools como principal e IBM Equal Access como segunda opinión, ambas con WCAG 2.2 AA y buenas prácticas en sección aparte; pa11y-ci con axe como motor para el rastreo; Colour Contrast Analyser para medir; inspectores del navegador y Accessibility Insights para la parte asistida.
• Fichas de ejecución: versiones de extensiones, motor y navegador fijadas el primer día, ventana de 1.280 px y repetición a 320 px CSS.
• Acuerdos con el cliente: rastreo nocturno con concurrencia baja; entorno de preproducción de la sede con una identidad de prueba facilitada por el ayuntamiento; prohibido enviar instancias o pagos en producción.

Paso 2: rastreo y agrupación

El rastreo devuelve 41.300 incidencias. Agrupadas por regla y selector, seis patrones de plantilla suman más de 37.000:

• link-name en los cuatro iconos de redes sociales del pie: 12.800 instancias (cuatro por página).
• color-contrast en el texto del pie, #8A8A8A sobre #F2F2F2: 3,1:1 en todas las páginas.
• label en el campo del buscador de la cabecera, que no tiene etiqueta asociada ni ningún otro nombre accesible.
• region y heading-order (buenas prácticas) en la plantilla de noticias.
• aria-allowed-attr en el menú principal (aria-selected sobre enlaces, donde no está permitido).

El resto son sobre todo fallos de contenido, como 640 imágenes de noticias sin alt repartidas en 210 páginas, que se corrigen con formación de las personas editoras y no con un cambio de plantilla.

Paso 3: análisis de la muestra y de sus estados

En cada página y estado de la muestra se ejecutan axe e IBM. Resultados relevantes: en la página de cita previa, el calendario abierto tiene botones de día sin nombre (button-name); el texto blanco del titular de portada sobre una fotografía aparece como «necesita revisión» y CCA mide 2,9:1 en el punto peor; y el formulario de instancia general, enviado vacío, muestra mensajes de error con contraste 3,6:1. IBM marca además un posible problema de aria-labelledby en el selector de trámite que axe no marca: al revisarlo en el panel Accessibility, el nombre se calcula bien y se descarta como falso positivo, anotando el motivo.

Paso 4: revisión asistida y manual

Con Tab stops se ve que el banner de cookies queda fijo abajo y tapa el foco del botón «Siguiente» (2.4.11 Foco no oculto (mínimo)). El calendario no se maneja con teclado (2.1.1 Teclado). Los errores del formulario aparecen sin anunciarse (4.1.3 Mensajes de estado) y no sugieren cómo corregirlos (3.3.3). La sesión caduca a los diez minutos sin aviso (2.2.1 Tiempo ajustable). Ninguno había salido en las herramientas.

Paso 5: hallazgos para el informe

De los 14 hallazgos finales del informe, 6 tienen origen automático verificado y 8 proceden solo de la revisión asistida o manual. Las 41.300 incidencias se reducen a hallazgos con instancias contadas, y las buenas prácticas van a un anexo de recomendaciones.

Ejercicios de autoevaluación

1. En el caso, ¿por qué el rastreo no encontró el problema del calendario de cita previa?

2. axe marca heading-order en 300 noticias. ¿Lo cuentas como incumplimiento de 1.3.1?

3. Configuras axe-core por script solo con la etiqueta wcag22aa y no aparece ningún problema de contraste. ¿Qué ha pasado?

4. Un botón muestra el texto «Pagar» y tiene aria-label="Continuar". Ninguna herramienta lo marca. ¿Qué criterio revisas y con qué herramienta lo confirmas?

5. En la reauditoría de seis meses después, las incidencias automáticas han bajado un 50 %. ¿Qué compruebas antes de comunicar la mejora?

Lista de comprobación

• Norma configurada de forma explícita (WCAG 2.2 AA) en cada herramienta.
• Versiones de herramientas, motor y navegador fijadas y anotadas.
• Ficha de ejecución y salida en bruto guardadas para cada análisis.
• Rastreo acordado con el cliente: horario, concurrencia y cuentas de prueba.
• Ningún envío real de formularios, pagos o registros en producción.
• Resultados agrupados por regla y selector; plantilla separada de contenido.
• Cada página de la muestra analizada en todos sus estados y a 320 px.
• Iframes, Shadow DOM, canvas y multimedia revisados a mano.
• Todo lo marcado como «necesita revisión» resuelto manualmente.
• Cada violación reproducida y mapeada a criterio WCAG y cláusula EN.
• Buenas prácticas en una sección de recomendaciones aparte.
• Falsos positivos descartados documentados con su motivo.
• Criterios sin regla automática evaluados uno a uno.

Para seguir aprendiendo

• Reglas ACT del W3C: cada regla con su aplicabilidad, expectativas y casos de prueba.
• Lista de herramientas de evaluación del W3C, filtrable por normativa y tipo.
• WCAG-EM, la metodología de evaluación en la que encajan las herramientas.
• Understanding WCAG 2.2, con las técnicas y fallos documentados de cada criterio.
• Accesibilidad en el portal de Administración Electrónica, con el Observatorio de Accesibilidad Web (se abre en una ventana nueva) y su metodología de seguimiento.