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: delimitar el alcance de una evaluación conforme a la EN 301 549 (PDF, se abre en una ventana nueva) para un ayuntamiento con web, documentos, app, vídeo, soporte y un quiosco. Después, cinco ejercicios con solución, una lista de comprobación reutilizable y recursos oficiales para seguir aprendiendo.

Caso práctico: el Ayuntamiento de Sierra Alta

El Ayuntamiento de Sierra Alta (municipio ficticio, unos 40.000 habitantes) encarga en octubre de 2026 una evaluación de conformidad de sus servicios digitales para actualizar su declaración de accesibilidad. Su ecosistema es este:

• Portal municipal y sede electrónica (sede.sierraalta.example), con un proceso de solicitud que genera un justificante en PDF.
• Unos 300 PDF descargables: bases de convocatorias, ordenanzas y formularios rellenables.
• La app «Sierra Alta Cita» para iOS y Android, con acceso por PIN o huella.
• Un reproductor propio para los plenos, en directo y en diferido.
• Una plataforma de participación en la que el vecindario publica propuestas con texto e imágenes.
• Atención por el teléfono 010 y un chat escrito en la web.
• Un quiosco de turnos en la oficina de atención ciudadana.

Paso 1: referencia y versión

La evaluación se hace contra la EN 301 549 v3.2.1, única versión armonizada en la fecha del encargo. Como requisito adicional, separado del veredicto legal, se evalúan los criterios A y AA de las WCAG 2.2. El informe advertirá de que la v4.1.1 está publicada y pendiente de citarse en el DOUE.

Paso 2: inventario y capítulos

El quiosco no es una web ni una app, así que no figura en las tablas A.1 ni A.2. El Ayuntamiento decide evaluarlo igualmente con la norma como referencia técnica, y así se dice en el alcance.

Paso 3: plan de pruebas

Para cada requisito aplicable se toma la entrada del anexo C, se anota la precondición y se fija la técnica concreta. La muestra de la web sigue WCAG-EM (se abre en una ventana nueva): 14 páginas estructuradas, 2 aleatorias, el proceso de solicitud completo, 6 PDF de tipos distintos y el justificante. La línea base es NVDA con Firefox, JAWS con Chrome, VoiceOver en iOS, TalkBack en Android y zoom al 200 % y al 400 %.

Paso 4: hallazgos que no habría encontrado una evaluación «solo WCAG»

• 5.4, no cumple: el justificante PDF se genera sin etiquetas ni idioma, aunque el formulario de origen está bien estructurado.
• 7.3, no cumple: los subtítulos de los plenos están dentro del menú «Ajustes», mientras el volumen está en la barra principal.
• 11.8.2, no cumple: la plataforma de participación no permite añadir texto alternativo a las imágenes de las propuestas.
• 12.1.1, no cumple: la ayuda de la app no describe la compatibilidad con VoiceOver y TalkBack.
• 5.3, cumple: la app ofrece PIN como alternativa a la huella.
• 12.2.3, cumple: el chat ofrece un canal que no depende de la voz, aunque el propio componente de chat tiene incumplimientos de 9.4.1.2 que se registran aparte.

Paso 5: informe y declaración

El informe usa los identificadores de la norma (9.1.4.3, 10.1.3.1, 11.5.2.5), el vocabulario del anexo C con cada «no aplicable» justificado por su condición y una sección separada para los seis criterios WCAG 2.2. La fila 9.4.1.1 se mantiene, con la nota del W3C explicada en la metodología. La declaración resultante indica «parcialmente conforme» con el RD 1112/2018 (PDF, se abre en una ventana nueva) y lista el contenido no accesible por componente.

Ejercicios

1. La web de un museo público incluye vídeos con guía en lengua de signos y un botón «Habla con nosotros por videollamada». ¿Qué capítulos se añaden al 9 en la tabla A.1?

2. Un informe declarado «conforme a la EN 301 549 v3.2.1» incluye la fila «9.2.5.8 Tamaño del objetivo (mínimo): no cumple». ¿Qué está mal?

3. La app de cita previa de un hospital público solo permite iniciar sesión con reconocimiento facial. ¿Qué requisito se incumple y cómo lo comprueba el anexo C?

4. El auditor marca «no aplicable» el requisito 7.1.1 en una sede electrónica sin escribir nada más. ¿Cómo debería redactarlo?

5. En noviembre de 2026, una consejería quiere que el pliego de su nuevo portal exija «exclusivamente la EN 301 549 v4.1.1 (PDF, se abre en una ventana nueva)». ¿Qué le aconsejarías?

Lista de comprobación

• Cito la versión exacta de la norma y compruebo en EUR-Lex cuál está armonizada.
• Inventario todos los componentes: web, documentos, app, vídeo, soporte y terminales.
• Asigno a cada componente su tabla del anexo A o explico por qué no tiene.
• Recorro cada fila condicional y anoto si su condición se da.
• Incluyo 9.6: página completa y procesos completos.
• Reviso 5.2, 5.3 y 5.4 en webs y apps.
• Evalúo el reproductor con el capítulo 7, además del contenido.
• Aplico 11.8 a toda plataforma que sirva para crear contenido.
• Evalúo siempre el capítulo 12: ayuda y canales de soporte.
• Uso la entrada del anexo C de cada requisito y registro evidencias reproducibles.
• Justifico cada «no aplicable» con su condición.
• Separo el veredicto legal de los requisitos adicionales WCAG 2.2.

Para seguir aprendiendo

• EN 301 549 v3.2.1 (ETSI, PDF): texto oficial con los anexos A, B y C.
• Decisión de Ejecución (UE) 2021/1339: referencia armonizada vigente.
• Directiva (UE) 2016/2102: artículos 4 y 6 sobre requisitos y presunción de conformidad.
• Real Decreto 1112/2018: transposición española.
• WCAG2ICT (W3C): cómo se aplican las WCAG a documentos y software.