La accesibilidad móvil es un caos (y no es culpa de los desarrolladores)

Si has pedido un informe de accesibilidad para una app, probablemente hayas visto esto: dos auditores distintos, la misma app, dos notas distintas. No porque uno sea mejor que el otro, sino porque el sistema les permite llegar a conclusiones diferentes.

Una norma de web aplicada a algo que no es web

WCAG nació para documentos HTML. Hablan de enlaces, encabezados, formularios, foco de teclado, DOM. Cuando llegó la era móvil, en lugar de crear un estándar específico, se optó por extender la interpretación: W3C publicó guías sobre cómo aplicar WCAG a móvil, y en Europa la EN 301 549 trasladó esos criterios a software y apps.

El resultado es una norma que funciona por analogía. ¿Qué es un “encabezado” en SwiftUI? ¿Y un “landmark”? ¿Cómo se aplica el criterio de “reflow” en una app que gira entre orientaciones? ¿Qué significa “navegación por teclado” cuando el usuario usa VoiceOver con gestos, Switch Control o Voice Control? Cada criterio requiere que alguien lo traduzca, y esa traducción es donde empieza la subjetividad.

Sin metodología objetiva, el resultado depende del auditor

En web existe al menos WCAG-EM, herramientas como axe o Lighthouse, y una base común de técnicas suficientes. En móvil:

• No hay una metodología de muestreo ampliamente aceptada. ¿Qué pantallas se auditan? ¿Qué flujos? ¿Qué dispositivos y versiones de sistema?
• Las herramientas automáticas cubren muy poco. El Accessibility Inspector y Android Scanner detectan lo básico, pero casi todo lo relevante (orden de lectura, etiquetas con sentido, gestos alternativos) es manual.
• El comportamiento depende de la plataforma. Lo que VoiceOver anuncia de una forma, TalkBack lo anuncia de otra. ¿Cuál es “el correcto”?
• Criterios ambiguos de conformidad. ¿Un elemento con etiqueta técnicamente presente pero poco útil cumple o no? Depende de a quién preguntes.

Y como la conformidad suele medirse como pasa/no pasa por criterio, una sola interpretación distinta puede mover la nota de una app de “conforme parcialmente” a “no conforme”.

Las guías de plataforma no son una norma

Apple y Google publican guías excelentes (HIG, Material). Pero son recomendaciones de diseño, no requisitos verificables, y no tienen valor normativo. Un auditor puede usarlas como referencia o ignorarlas, y ambas decisiones son defendibles.

Por qué esto importa

Porque los informes de accesibilidad tienen consecuencias: contratos públicos, sanciones, reputación, y sobre todo usuarios que no pueden usar tu producto. Si el mismo trabajo da resultados distintos según quién lo revise:

1. El desarrollador no sabe qué arreglar, porque no sabe qué criterio aplicará el siguiente auditor.
2. El incentivo se pervierte. Se acaba optimizando para pasar la auditoría, no para que la app sea usable con VoiceOver.
3. El usuario con discapacidad pierde, porque la nota no refleja su experiencia real.

Qué haría falta

• Una guía de aplicación específica para apps nativas, con criterios de éxito interpretados para móvil, no por analogía con el DOM.
• Una metodología de evaluación estándar: qué se muestrea, en qué dispositivos, con qué tecnologías de asistencia y con qué criterio de aprobado.
• Pruebas de referencia: casos concretos de “esto cumple, esto no” para componentes habituales (listas, modales, gestos personalizados, controles adaptables).
• Que las auditorías documenten sus decisiones de interpretación, para que sean reproducibles y discutibles.

Hasta entonces, la accesibilidad móvil seguirá dependiendo más de quién te audite que de lo que hayas construido. Y eso, para algo que se supone que es una cuestión de derechos, es inaceptable.