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

Esta lección aplica el curso completo a un encargo realista. Primero verás un caso resuelto paso a paso: la revisión manual de un trámite de una sede electrónica con teclado, lectores de pantalla y el inspector del navegador. Después tendrás cinco ejercicios con su solución, una lista de comprobación para tu próxima sesión de pruebas y recursos oficiales para seguir aprendiendo.

Caso práctico: el volante de empadronamiento de una sede electrónica

El Ayuntamiento de Villaserena (municipio ficticio) está obligado por el RD 1112/2018 (PDF, se abre en una ventana nueva) y ha encargado la revisión de su sede electrónica, sede.villaserena.example. La muestra, definida con WCAG-EM (se abre en una ventana nueva), incluye el proceso completo «Solicitar volante de empadronamiento»: ficha del trámite, formulario de datos con buscador de calles, guardado de borrador, revisión, envío y descarga del justificante. Tu tarea es la revisión manual con tecnologías de apoyo.

Paso 1: preparar el puesto y la matriz

Partiendo de la línea base acordada, fijas la matriz: NVDA con Firefox y Chrome en todas las páginas del proceso; JAWS con Chrome en el proceso completo; VoiceOver con Safari en iOS y TalkBack con Chrome en Android para el proceso completo; y solo teclado, zoom al 200 % y al 400 %, espaciado de texto y tema de contraste en todas las páginas. Anotas versiones el primer día, usas un perfil de navegador sin extensiones y pides al ayuntamiento un entorno de preproducción con el tiempo de sesión reducido a dos minutos.

Paso 2: pasada con teclado y zoom

El proceso se completa con teclado: el foco es visible y el orden es lógico. Al 400 %, el formulario se reajusta bien. Primera señal de alarma: en el buscador de calles, las flechas mueven un resaltado sobre las sugerencias, pero nada indica qué ocurre por debajo. Lo anotas para la pasada con lector.

Paso 3: pasada con NVDA y el visor de voz

• Buscador de calles. Al escribir «May» y pulsar Flecha abajo, el visor de voz no muestra nada. En la pestaña Accesibilidad de Chrome, el campo tiene rol de cuadro de texto, sin role="combobox", sin aria-expanded y sin aria-activedescendant; las sugerencias son li sin rol. Se reproduce igual con Firefox, JAWS y VoiceOver. Fallo del sitio: H-01, 4.1.2 Nombre, función, valor (A).
• Guardar borrador. Aparece un mensaje emergente «Borrador guardado» durante tres segundos. Nada en el visor de voz; en el DOM, el mensaje se crea en cada guardado sin rol ni aria-live. H-02, 4.1.3 Mensajes de estado (AA).
• Enviar con errores. Con el DNI vacío, el foco se queda en el botón «Continuar» y no se anuncia nada. Al volver al campo, NVDA dice «DNI, editable, en blanco», sin el texto de error que se ve debajo: no está asociado con aria-describedby. H-03, 1.3.1 Información y relaciones (A) y 4.1.3 Mensajes de estado (AA).
• Aviso de sesión. A los dos minutos aparece un banner «Su sesión caducará en 60 segundos» con el botón «Ampliar», insertado al final del DOM, sin rol ni movimiento del foco. Con lector, no se percibe y la sesión expira. H-04, 2.2.1 Tiempo ajustable (A), con 4.1.3 como secundario.

Paso 4: móvil y criterio del auditor

Con VoiceOver en iOS, el indicador «Paso 2 de 4» es una lista con list-style: none y Safari no la anuncia como lista. El texto «Paso 2 de 4, Datos personales» sí se lee completo. Aplicas las preguntas de la lección de soporte: la información llega y la tarea no se ve afectada. Descartado como hallazgo; se anota como observación, con la mejora opcional role="list". Con TalkBack se confirman H-01 a H-04 sin diferencias relevantes.

Paso 5: registrar H-01 de forma reproducible

• Página y estado: /tramites/volante-empadronamiento, paso 2, lista de sugerencias abierta.
• Pasos: 1. Tab hasta «Calle». 2. Escribir «May». 3. Pulsar Flecha abajo dos veces. 4. Pulsar Enter.
• Esperado: se anuncian el rol de cuadro combinado, el estado expandido y cada sugerencia activa; Enter confirma el valor.
• Observado: no se anuncia nada al moverse por las sugerencias; el valor se rellena sin confirmación.
• Combinaciones: todas las de la línea base.
• Evidencia: H-01_calles_nvda.txt (visor de voz), H-01_calles_arbol.png (panel Accesibilidad), H-01_calles.mp4 (15 s).
• Recomendación: patrón de combo con lista de la APG (se abre en una ventana nueva): role="combobox", aria-expanded, aria-controls, role="listbox", role="option" y aria-activedescendant.

Ejercicios de autoevaluación

1. En un listado de productos, NVDA anuncia «clicable» en cada tarjeta. ¿Qué haces?

2. Tras pulsar «Aplicar filtros», NVDA empieza a leer desde el título de la página. ¿Qué compruebas y qué criterios pueden fallar?

3. El árbol de accesibilidad de un combo es correcto y NVDA con Firefox anuncia bien las opciones, pero JAWS con Chrome, que está en la línea base, no anuncia la opción activa. ¿Cómo procedes?

4. Un botón muestra «Descargar» y el panel de Chrome indica que su nombre es «Botón de obtención del justificante», procedente de aria-label. ¿Qué criterio falla y cómo se corrige?

5. Tras cerrar un modal, NVDA no lee nada con las flechas en modo navegación y el inspector muestra el contenido principal como ignorado. ¿Cuál es la causa probable?

Lista de comprobación

• Matriz de combinaciones fijada y versiones anotadas.
• Perfil de navegador limpio y ajustes de Tab configurados en macOS.
• Visor de voz de NVDA o historial de JAWS abiertos durante la prueba.
• Cada componente comparado con su patrón de la APG.
• Componentes probados con Tab y en modo navegación.
• Opción activa de combos y listas anunciada en cada pulsación.
• Diálogos: rol, título, fondo inerte y retorno del foco.
• Cada acción dinámica revisada: foco, anuncio y contenido nuevo.
• Estados de error, borrador, espera y caducidad de sesión provocados.
• Nodo del árbol inspeccionado en cada hallazgo de nombre, rol o estado.
• Fallo confirmado en una segunda combinación o en un caso mínimo.
• Diferencias de presentación descartadas y documentadas.
• Pruebas en iOS y Android hechas en dispositivos reales.
• Cada hallazgo con pasos, esperado, observado, combinación y evidencia.

Para seguir aprendiendo

• Web Content Accessibility Guidelines (WCAG) 2.2, recomendación del W3C.
• ARIA Authoring Practices Guide (APG): patrones y ejemplos de componentes.
• Accessible Name and Description Computation 1.2: cómo se calcula el nombre accesible.
• Understanding 4.1.3 Status Messages: mensajes de estado explicados con ejemplos.
• WCAG-EM (versión 2.0 de 2026, basada en la 1.0): la metodología de evaluación en la que se integra la revisión manual.