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

Esta lección reúne el curso en un caso resuelto paso a paso, cinco ejercicios con su solución y una lista de comprobación para tus proyectos. El caso combina las situaciones que más encontrarás como especialista: un trámite con formulario y autenticación, una página informativa, una versión «en lectura fácil» generada con IA y un asistente virtual.

Caso práctico: la ayuda al transporte joven de un ayuntamiento

Un ayuntamiento de tamaño medio (ficticio) publica en su sede electrónica la ayuda «Bono Joven de Transporte». El servicio incluye una página informativa, un formulario de solicitud de 35 campos en una sola pantalla, acceso con Cl@ve o con un código de 6 dígitos enviado por SMS que caduca a los 60 segundos, una «versión en lectura fácil» redactada con un modelo de lenguaje y publicada con el logotipo europeo, y un asistente virtual que se abre solo a los 5 segundos. La concejalía pide un diagnóstico de accesibilidad cognitiva y un plan de mejora.

Paso 1. Marco y alcance

Es una administración local: se aplica el RD 1112/2018 (PDF, se abre en una ventana nueva) y, por él, la EN 301 549 v3.2.1 (PDF, se abre en una ventana nueva) (WCAG 2.1 AA). Se evalúan además los criterios nuevos de WCAG 2.2 como buena práctica y se identifican como tales. Tareas críticas: (1) saber si se cumplen los requisitos, (2) presentar la solicitud y (3) consultar su estado.

Paso 2. Conformidad WCAG

• El código SMS no se puede pegar ni rellenar automáticamente y solo dura 60 segundos sin opción de ampliar: 2.2.1 Tiempo ajustable y, como buena práctica 2.2, 3.3.8 Autenticación accesible (mínimo).
• La sesión caduca a los 15 minutos sin aviso y se pierde lo escrito: 2.2.1.
• El DNI se pide en el paso de datos personales y otra vez en la declaración responsable: 3.3.7 Entrada redundante (2.2).
• Los errores se muestran como «Formulario incorrecto» arriba, sin decir qué campo falla: 3.3.1 Identificación de errores y 3.3.3 Sugerencias ante errores.
• El teléfono de ayuda aparece en el pie de unas páginas y no de otras: 3.2.6 Ayuda coherente (2.2).
• El asistente se abre solo y roba el foco a mitad del formulario: cambio de contexto no solicitado (3.2.5 Cambios a petición, AAA) que además rompe 2.4.3 Orden del foco; su anuncio en bucle de «escribiendo…» es un mal uso de las regiones vivas.

Paso 3. Revisión experta y diseño engañoso

El recorrido cognitivo detecta que la página informativa pide «empadronamiento con una antigüedad mínima de seis meses a contar desde la fecha de devengo» y un plazo de «20 días hábiles desde la publicación en el boletín oficial»: hay que calcular dos fechas y saber qué es el devengo. En el último paso del formulario, una casilla ya marcada dice «No deseo que mis datos no se cedan a entidades colaboradoras»: preselección y doble negación, con riesgo además frente al RGPD.

Paso 4. Textos e IA

Con el método de unidades críticas se compara la versión «en lectura fácil» con la convocatoria: ha desaparecido el requisito de no superar un nivel de ingresos, «deberá aportar» se ha convertido en «puede aportar» y el plazo aparece como «20 días». No consta validación por personas con discapacidad intelectual, así que el logotipo europeo no puede usarse. Se retira la versión, se encarga una adaptación según la UNE 153101 EX y su validación según la UNE 153102 EX, y se reescribe la página informativa en lenguaje claro con fechas concretas.

Paso 5. Pruebas con personas y plan

Con una entidad de Plena inclusión y una asociación juvenil se organizan sesiones con seis participantes. Solo dos completan la solicitud sin ayuda; cuatro se bloquean en el código SMS y tres no saben decir hasta cuándo pueden presentarla. El plan resultante:

Prioridad	Acción	Referencia
1	Código pegable con autocomplete="one-time-code", 5 minutos de validez y opción de reenviar	2.2.1; 3.3.8
1	Aviso 2 minutos antes de caducar la sesión, con ampliación y guardado de borrador	2.2.1; 2.2.6 (AAA)
2	Formulario en 5 pasos con indicador, DNI pedido una sola vez y errores junto a cada campo	3.3.1; 3.3.3; 3.3.7
2	Asistente que solo se abre a petición, con «Hablar con una persona» y ayuda en el mismo lugar	2.4.3; 3.2.6
3	Página en lenguaje claro con fechas concretas; casilla desmarcada y en positivo	Lenguaje claro; COGA; RGPD
3	Versión en lectura fácil adaptada y validada, con fecha y entidad validadora	UNE 153101 EX y 153102 EX

Tras las correcciones, una segunda ronda con otras seis personas: cinco completan la solicitud sin ayuda y todas responden bien a la pregunta del plazo.

Ejercicios

Ejercicio 1. Un portal supera una auditoría WCAG 2.1 AA. ¿Puedes afirmar que es cognitivamente accesible?

Ver solución

No. El nivel AA cubre solo una parte de las necesidades cognitivas: el nivel de lectura, las palabras inusuales, las interrupciones o la ayuda contextual están en AAA o fuera de las WCAG. Hacen falta la revisión experta con patrones COGA y las pruebas con personas.

Ejercicio 2. Un aviso «Producto añadido a la cesta» aparece y desaparece a los 3 segundos. Además, se anuncia con role="alert". ¿Qué cambiarías?

Ver solución

Usar role="status", porque no es urgente, y mantener el aviso visible hasta que la persona lo cierre o siga navegando, o dejar la confirmación también en la propia cesta. Un mensaje que desaparece tan rápido funciona como un límite de tiempo (2.2.1) y exige atención y velocidad de lectura.

Ejercicio 3. Un modelo de lenguaje resume una resolución: «Te han dado la ayuda. Puedes recurrir si no estás de acuerdo». El original concede la ayuda «parcialmente» y fija un mes para recurrir. ¿Qué método aplicas y qué encuentras?

Ver solución

El de unidades críticas. Se han perdido dos: el carácter parcial de la concesión, que cambia el sentido, y el plazo de recurso. Ambos son errores críticos: la pieza se rechaza y se corrige comparando con el original.

Ejercicio 4. En una prueba con usuarios, el moderador pregunta a una participante con discapacidad intelectual «¿Has entendido la página?» y ella responde que sí. ¿Es una evidencia válida?

Ver solución

No. La pregunta favorece la respuesta complaciente. Hay que formular preguntas de comprensión que exijan haber entendido («¿Qué documento tienes que llevar?») y observar si completa la tarea.

Ejercicio 5. Para darse de alta en un servicio basta un clic; para darse de baja hay que llamar por teléfono en horario de oficina. ¿Cómo lo reflejas en un informe de accesibilidad?

Ver solución

Como recomendación, separada de los incumplimientos WCAG: patrón de obstrucción que exige función ejecutiva y memoria y excluye a quien no puede usar el teléfono. Se propone baja por el mismo canal y con el mismo esfuerzo, y se sugiere que la asesoría jurídica valore la práctica.

Lista de comprobación

• Las tareas críticas se han evaluado completas, de principio a fin.
• Nada exige recordar ni transcribir códigos o datos de un paso anterior.
• Los plazos se dan como fechas y los importes, ya calculados.
• Todo límite de tiempo avisa antes y se puede ampliar.
• No aparece nada que la persona no haya pedido: sonido, movimiento, ventanas o chats.
• Rechazar o darse de baja cuesta lo mismo que aceptar o darse de alta.
• No hay casillas premarcadas ni preguntas con doble negación.
• Los errores dicen qué ha pasado y cómo arreglarlo, junto al campo.
• La ayuda humana está en el mismo lugar en todas las páginas.
• Los textos clave están en lenguaje claro y los derechos y trámites, en lectura fácil validada.
• Todo contenido generado con IA se ha revisado con un criterio escrito y queda registrado.
• El asistente virtual se abre a petición, se identifica como automático y ofrece una persona.
• Se ha probado con personas con discapacidad cognitiva y se ha repetido la prueba tras corregir.

Para seguir aprendiendo

• Making Content Usable for People with Cognitive and Learning Disabilities (W3C)
• Comprender las WCAG 2.2 (Understanding WCAG 2.2, W3C)
• Involving Users in Evaluating Web Accessibility (W3C)
• Texto consolidado del RDL 1/2013, con la reforma de la Ley 6/2022 (BOE)
• Reglamento (UE) 2024/1689 de Inteligencia Artificial (EUR-Lex)