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

Esta lección aplica todo el curso a un trámite completo de sede electrónica. Primero verás un caso resuelto paso a paso; después, cinco ejercicios con su solución, una lista de comprobación para tus próximas auditorías y recursos oficiales para seguir profundizando.

Caso práctico: solicitud de plaza en una escuela infantil municipal

El Ayuntamiento de Villanueva del Campo (ficticio) encarga la evaluación WCAG 2.2 AA del trámite «Solicitud de plaza en escuela infantil» de su sede electrónica, disponible en castellano y en valenciano. El proceso tiene seis pasos: acceso (Cl@ve o usuario y contraseña municipales), datos de la persona solicitante, datos del menor, documentación, revisión y presentación, y justificante. La sede incluye un teléfono de ayuda en la cabecera y un chat con personal municipal.

Paso 1: delimitar conjuntos y proceso

Las versiones en castellano y en valenciano son conjuntos de páginas distintos (lección 2): la coherencia se compara dentro de cada versión, no entre ellas. El trámite es un proceso y entra completo, incluidas las páginas de la pasarela de identificación, que se documentan como contenido de terceros.

Paso 2: idioma y comportamiento predecible

• La versión en valenciano declara <html lang="es">. 3.1.1 no se cumple en esa versión: debe declarar lang="ca" (o la variante ca-valencia).
• El selector de idioma muestra «Valencià» sin lang. 3.1.2 no se cumple en la versión en castellano.
• El teléfono de ayuda está en la cabecera en todas las páginas, salvo en el paso de documentación, donde pasa al pie. 3.2.6 no se cumple.
• El desplegable «Tipo de jornada» muestra u oculta el horario ampliado sin mover el foco: cambio de contenido, 3.2.2 se cumple.

Paso 3: autenticación

El acceso con usuario y contraseña municipales bloquea el pegado y el gestor de contraseñas no rellena el campo. En el mismo paso se ofrece Cl@ve; en la prueba, su código de un solo uso admitía pegado. Hay una alternativa sin bloqueo, así que 3.3.8 se cumple, con la recomendación de retirar el bloqueo del acceso municipal (lección 5).

Paso 4: formulario

• En «Datos del menor» se vuelve a pedir el domicilio introducido dos pantallas antes, sin opción de reutilizarlo. 3.3.7 no se cumple.
• El formato de «Fecha de nacimiento» (dd/mm/aaaa) solo aparece tras el error. 3.3.2 no se cumple.
• Los errores en línea aparecen al salir del campo y el foco sigue avanzando; NVDA no anuncia nada. 4.1.3 no se cumple. Los mensajes indican cómo corregir: 3.3.1 y 3.3.3 se cumplen.
• El selector «Escuela preferida» es un cuadro combinado personalizado: el campo no tiene rol combobox ni aria-expanded y las opciones son div sin rol. 4.1.2 no se cumple (lección 7).

Paso 5: documentación, revisión y presentación

Tras subir un archivo aparece «Documento añadido» sin anuncio: se agrega al hallazgo de 4.1.3. La pantalla de revisión muestra todos los datos con enlaces «Modificar» antes de presentar: 3.3.4 se cumple. El justificante se ofrece en PDF, que se evalúa con su propia metodología (nivel 6).

Paso 6: consolidar

Criterio	Nivel	Resultado	Hallazgo
3.1.1 Idioma de la página	A	No cumple	lang="es" en la versión en valenciano
3.1.2 Idioma de las partes	AA	No cumple	Selector de idioma sin lang
3.2.6 Ayuda coherente	A	No cumple	Teléfono en el pie en un paso
3.3.2 Etiquetas o instrucciones	A	No cumple	Formato de fecha solo tras el error
3.3.7 Entrada redundante	A	No cumple	Domicilio pedido dos veces
3.3.8 Autenticación accesible	AA	Cumple	Cl@ve como alternativa; recomendación
4.1.2 Nombre, función, valor	A	No cumple	Cuadro combinado sin rol ni estados
4.1.3 Mensajes de estado	AA	No cumple	Errores en línea y subida de archivos

Como el proceso contiene páginas no conformes, el proceso completo no es conforme con el nivel AA.

Ejercicios de autoevaluación

1. El chat automatizado aparece como botón flotante al final del contenido en todas las páginas de una tienda, pero en la página de pago está dentro del menú de la cabecera. ¿Qué criterio evalúas y con qué resultado?

Ver solución

3.2.6 Ayuda coherente: un mecanismo de contacto totalmente automatizado cambia su orden relativo en una página del conjunto. No se cumple, salvo que el cambio lo haya provocado el usuario.

2. El segundo factor de un banco pide el código en seis casillas de un dígito; al pegar el código completo solo se rellena la primera. No hay otro método. ¿Veredicto?

Ver solución

3.3.8 no se cumple: obliga a transcribir el código sin mecanismo de ayuda ni alternativa. La solución es un único campo con autocomplete="one-time-code" o repartir el valor pegado entre las casillas.

3. Al marcar un filtro, el listado se actualiza, el foco sigue en la casilla y aparece «18 resultados» sin anuncio. ¿3.2.2 o 4.1.3?

Ver solución

4.1.3. No hay cambio de contexto, porque el foco no se mueve y la página conserva su propósito, así que 3.2.2 se cumple; el recuento es un mensaje de estado que debe poder determinarse programáticamente, por ejemplo con role="status".

4. En una auditoría AA, un compañero registra como incumplimiento 3.3.9 porque el login usa un CAPTCHA de selección de imágenes de objetos comunes. ¿Qué corriges?

Ver solución

3.3.9 es AAA y queda fuera del alcance: pasa a recomendaciones. A nivel AA, 3.3.8 se cumple por la excepción de reconocimiento de objetos. Revisa aparte 1.1.1 (alternativa textual y otra modalidad sensorial).

5. Un botón «Me gusta» cambia de icono vacío a relleno al pulsarlo; en el árbol de accesibilidad es un botón llamado «Me gusta» sin más información. ¿Qué falta y qué criterio incumple?

Ver solución

Falta el estado: 4.1.2 exige que el estado pueda determinarse y que se notifique su cambio. Se resuelve con aria-pressed="true" o "false" en el botón, actualizado en cada pulsación.

Lista de comprobación

• Define los conjuntos de páginas (versiones lingüísticas, sede, área privada) antes de comparar.
• Verifica lang en cada versión y en selectores de idioma y pasajes en otro idioma.
• Cambia valores de controles con teclado y comprueba que no hay cambios de contexto sin aviso.
• Compara navegación, identificación de componentes y ubicación de la ayuda entre páginas.
• Envía cada formulario vacío, con errores y completo.
• Comprueba instrucciones visibles, errores en texto y sugerencias de corrección.
• Anota los datos pedidos dos veces en cada proceso.
• Prueba cada acceso con gestor de contraseñas, pegado y segundo factor, incluida la recuperación.
• Clasifica cada CAPTCHA y busca una alternativa sin prueba cognitiva.
• Revisa nombre, rol, estados y valores de cada componente personalizado en el árbol de accesibilidad.
• Verifica cada mensaje de estado con el Visor de voz de NVDA u otro lector de la línea base.
• Asigna cada hallazgo al criterio específico y comprueba su nivel.
• Separa los criterios AAA como recomendaciones y no cites 4.1.1.

Para seguir aprendiendo

• Web Content Accessibility Guidelines (WCAG) 2.2, recomendación del W3C, con su glosario normativo.
• What's New in WCAG 2.2, resumen oficial de los criterios nuevos.
• Understanding 3.3.8 Accessible Authentication (Minimum), con ejemplos de métodos conformes.
• ARIA Authoring Practices Guide: patrones, referencia de roles y estados por componente.
• Real Decreto 1112/2018, sobre accesibilidad de sitios web y aplicaciones para dispositivos móviles del sector público.