Más allá de las WCAG: requisitos que se olvidan en webs y apps

Una web que cumple las WCAG 2.1 AA de principio a fin puede no cumplir la EN 301 549 (PDF, se abre en una ventana nueva). La razón está en las tablas del anexo A que estudiaste en la lección sobre la presunción de conformidad: además del capítulo 9, recogen requisitos de los capítulos 5, 6, 7, 11 y 12 que ninguna lista de criterios WCAG contiene. Esta lección se centra en esa diferencia desde el punto de vista de quien audita o encarga una web o una app: qué requisitos «no WCAG» aparecen de verdad en los proyectos, con qué ejemplos y cómo se comprueban.

El mapa de la diferencia

La tabla resume los requisitos que con más frecuencia faltan en los informes. Todos figuran en las tablas A.1 o A.2 de la v3.2.1, con la condición indicada.

Requisitos genéricos en webs y apps

5.2: activar sin necesitar lo que se suple

Si la web ofrece su propio botón de «alto contraste» o «aumentar texto», ese mecanismo es una función de accesibilidad documentada y debe poder activarse sin depender de la capacidad que suple. Un conmutador de alto contraste con un icono gris claro sobre blanco, sin nombre accesible y sin acceso por teclado incumple 5.2 aunque el resto de la página sea impecable. Comprobación: localiza el control, actívalo solo con teclado y con lector de pantalla, y mide su contraste.

5.3: siempre más de un medio

El procedimiento del anexo C es directo: comprobar que existe más de un medio de identificación o de control. Una app de banca que solo permite entrar con reconocimiento facial deja fuera a quien no puede usarlo; si ofrece también PIN o contraseña, cumple. Comprobación: desactiva la biometría en el dispositivo y verifica que el acceso sigue siendo posible.

5.4: la conversión no puede perder la accesibilidad

Muchas webs públicas convierten información: el formulario se transforma en un justificante PDF, un expediente se exporta a un documento, un chat se descarga como transcripción. Si el formato de destino admite información de accesibilidad (un PDF admite etiquetas, idioma y título) y la conversión la descarta, se incumple 5.4. Comprobación: genera el documento convertido y revísalo con el capítulo 10; si el origen tenía estructura y el resultado es un PDF sin etiquetas, tienes el incumplimiento.

Comunicación en tiempo real y vídeo

Cuando una web o una app ofrece voz en los dos sentidos, entra el capítulo 6. Los puntos que más se comprueban en auditoría son:

• Texto en tiempo real (6.2): si hay voz bidireccional, debe existir un modo de texto en tiempo real, que se muestra mientras se escribe, salvo que añadirlo exija cambiar el hardware.
• Calidad del vídeo (6.5): para que la lengua de signos y la lectura labial sean viables, la norma exige al menos resolución QVGA y 12 imágenes por segundo, recomienda VGA y 20 imágenes por segundo, y limita el desfase entre voz y vídeo a 100 milisegundos.
• Indicadores e identificación (6.2.2 y 6.5.5-6.5.6): indicador visual de actividad de audio e identificación de quién habla.
• Alternativas a la voz (6.4): si hay contestador o sistema de respuesta de voz interactiva, debe poder usarse sin oír ni hablar.

El capítulo 7, por su parte, evalúa el reproductor, no el vídeo. Aunque cada vídeo tenga subtítulos perfectos (criterio 1.2.2, requisito 9.1.2.2), el reproductor incumple si no permite mostrarlos (7.1.1), si no deja ajustar su presentación (7.1.4) o si esconde el botón de subtítulos o de audiodescripción en un submenú mientras el volumen está en la barra principal (7.3). Comprobación: reproduce un vídeo con teclado y con lector de pantalla, activa los subtítulos y la audiodescripción y busca las opciones de personalización.

Preferencias de usuario y herramientas de autor

El apartado 11.7 pide que el software respete la configuración de la plataforma en color, contraste, tipo y tamaño de letra y cursor de foco. En una app nativa se comprueba subiendo el tamaño de texto del sistema (Texto dinámico en iOS, tamaño de fuente en Android) y activando el contraste aumentado: la app debe reflejarlo, salvo que el usuario elija otra cosa dentro de ella.

El apartado 11.8 es el más olvidado en el sector público, pese a que muchas webs son herramientas de autor: aulas virtuales, gestores de contenidos que usan los departamentos, plataformas de participación ciudadana o portales de empleo donde se redacta el currículo. Si la web permite crear contenido para otros, debe:

• producir contenido en un formato que admita la accesibilidad (11.8.1);
• permitir crearlo accesible, por ejemplo añadir texto alternativo a una imagen o marcar encabezados (11.8.2);
• conservar la información de accesibilidad al transformar el contenido (11.8.3);
• ofrecer ayuda para reparar problemas, como un comprobador (11.8.4);
• si ofrece plantillas, que existan plantillas accesibles (11.8.5).

Documentación y soporte: el capítulo 12 siempre cuenta

En las dos tablas del anexo A, los requisitos 12.1.1, 12.1.2, 12.2.2, 12.2.3 y 12.2.4 son incondicionales. En una auditoría de web o app eso se traduce en preguntas concretas: ¿la ayuda explica las funciones de accesibilidad y la compatibilidad con lectores de pantalla?, ¿esa ayuda es accesible?, ¿el personal de atención sabe informar sobre ellas?, ¿hay un canal que no dependa de la voz o del oído, como chat, correo o videointerpretación en lengua de signos?

Resumen

• Cumplir las WCAG 2.1 AA no basta: las tablas A.1 y A.2 añaden requisitos de los capítulos 5, 6, 7, 11 y 12.
• 5.2, 5.3 y 5.4 aparecen a menudo en webs y apps: activación de funciones propias, alternativa a la biometría y conversiones que no pierdan la accesibilidad.
• El capítulo 6 entra con cualquier voz bidireccional (videoconsulta, videollamada) y el 7 evalúa el reproductor, no el vídeo.
• 11.7 exige respetar las preferencias de la plataforma y 11.8 se aplica a toda web que sirva para crear contenido.
• Los requisitos del capítulo 12 son incondicionales: ayuda accesible y canales de soporte adecuados en todo proyecto.