Informe y declaración de accesibilidad para apps móviles (RD 1112/2018)

Una evaluación termina en dos documentos distintos: el informe de auditoría, dirigido al equipo que debe corregir, y la declaración de accesibilidad, dirigida a la ciudadanía y exigida por el RD 1112/2018 (PDF, se abre en una ventana nueva) a las apps del sector público (y, en el sector privado, una buena práctica alineada con la Ley 11/2023 (PDF, se abre en una ventana nueva)). Esta lección detalla qué debe contener cada uno para una app móvil y dónde publicarlos.

El informe de auditoría de una app

Sigue la estructura general del Nivel 4 con las adaptaciones propias del software:

1. Resumen ejecutivo: estado de conformidad respecto a la EN 301 549 v3.2.1 (PDF, se abre en una ventana nueva) capítulo 11 (conforme / parcialmente conforme / no conforme), número de hallazgos por severidad, los tres problemas que más impacto tienen y si los flujos críticos son completables con cada tecnología de apoyo.
2. Alcance: nombre y versión de la app (compilación), plataformas y versiones de sistema, dispositivos (modelo y fabricante), tecnologías de apoyo y versiones (VoiceOver de iOS 18.x, TalkBack 15.x), configuraciones probadas, muestra de pantallas y flujos, fecha de las pruebas y entorno (producción o preproducción).
3. Metodología: referencia a WCAG-EM (se abre en una ventana nueva) adaptada con WCAG2ICT, herramientas automáticas usadas (Inspector, Scanner, Lint, auditorías de pruebas) y protocolo manual.
4. Resultados por requisito: tabla con cada cláusula aplicable del capítulo 11 (y de 5, 6, 7 y 12 si procede) y su estado: cumple / no cumple / no aplica / no evaluado, con enlace a los hallazgos. Indica expresamente los criterios vacíos como «no aplicable (void en EN 301 549)».
5. Hallazgos detallados: identificador, pantalla, plataforma(s), pasos, observado, esperado, cláusula, severidad, evidencia y recomendación técnica. En apps, la recomendación debe ser concreta para la pila tecnológica: «añadir accessibilityLabel("Buscar") al botón de la barra», «sustituir el GestureDetector por un Semantics(button: true)», «usar Modifier.semantics(mergeDescendants = true) en la fila». Un fragmento de código correcto ahorra una iteración.
6. Plan de corrección: priorizado por impacto (flujos críticos primero), agrupado por componente (corregir el componente de tarjeta arregla 30 pantallas), con estimación relativa de esfuerzo.
7. Anexos: vídeos y capturas, informes de Scanner e Inspector, lista de comprobación completa.

Qué exige el RD 1112/2018 a las apps móviles

El Real Decreto 1112/2018 transpone la Directiva (UE) 2016/2102 (PDF, se abre en una ventana nueva) y se aplica a los sitios web y a las aplicaciones para dispositivos móviles de las administraciones públicas y del resto de entidades de su ámbito (art. 2). Para las apps, las obligaciones de accesibilidad son exigibles desde el 23 de junio de 2021. Las aplicaciones deben cumplir los requisitos de la norma armonizada (EN 301 549), y el organismo debe:

• Publicar y mantener una declaración de accesibilidad para cada app (art. 15).
• Ofrecer un mecanismo de comunicación para que cualquier persona informe de incumplimientos o solicite información accesible, y responder en el plazo previsto (art. 10 y 12). Las solicitudes de información accesible y las quejas tienen plazo de respuesta de 20 días hábiles, y existe un procedimiento de reclamación posterior si no se atienden.
• Designar una unidad responsable de accesibilidad que coordine y revise periódicamente.
• Someterse a los informes de revisión y al seguimiento del Observatorio de Accesibilidad Web (se abre en una ventana nueva), que aplica una metodología específica para apps móviles derivada de la Decisión de Ejecución (UE) 2018/1524 (PDF, se abre en una ventana nueva).

Contenido de la declaración de accesibilidad de una app

El modelo de declaración (Decisión de Ejecución (UE) 2018/1523 (PDF, se abre en una ventana nueva) y modelo publicado por el Observatorio en administracionelectronica.gob.es) es el mismo para webs y apps, con adaptaciones:

1. Identificación: nombre de la app, organismo responsable, plataformas (iOS/Android) y versión a la que se refiere la declaración.
2. Compromiso con la accesibilidad conforme al RD 1112/2018.
3. Situación de cumplimiento: plenamente conforme / parcialmente conforme / no conforme, con la EN 301 549 v3.2.1 como referencia.
4. Contenido no accesible, en tres apartados: (a) falta de conformidad con el RD, describiendo cada incumplimiento y, si procede, los requisitos afectados; (b) carga desproporcionada, con la justificación; (c) contenido fuera del ámbito de aplicación (por ejemplo, mapas sin fin de navegación o contenido de terceros no financiado).
5. Preparación de la declaración: fecha, método (autoevaluación o evaluación externa, indicando quién) y fecha de la última revisión.
6. Observaciones y datos de contacto: cómo comunicar incidencias, solicitar información accesible o presentar quejas (correo, formulario, teléfono), y la unidad responsable.
7. Procedimiento de aplicación: cómo reclamar si la respuesta no es satisfactoria (reclamación ante la unidad responsable y, en su caso, el recurso administrativo que corresponda).
8. Contenido opcional: funciones de accesibilidad de la app (compatibilidad con VoiceOver/TalkBack, Dynamic Type, modo oscuro), que además cubre la cláusula 12.1.1 de la EN.

Dónde se publica

Para los sitios web, la declaración está en la propia web. Para las apps, el art. 15 del RD y el art. 7 de la Directiva prevén que la declaración esté disponible en el sitio web del organismo que ha desarrollado la aplicación, o junto con la información disponible al descargar la aplicación (la ficha de la tienda). En la práctica, la recomendación es triple: enlace a la declaración desde la ficha de App Store y Google Play, acceso desde la propia app (menú «Accesibilidad» o «Acerca de») y publicación en la web del organismo en el mismo apartado donde está la declaración del sitio. La declaración debe ser accesible y estar en un formato que se pueda leer con las tecnologías de apoyo; publicarla solo como imagen o como PDF sin etiquetar contradice su propósito.

Mantener la declaración viva y el sector privado

Las apps se actualizan cada pocas semanas. El RD exige revisar la declaración al menos anualmente y cuando haya cambios sustanciales: revisión completa anual con auditoría, revisión ligera en cada versión mayor (incumplimientos corregidos o nuevos), fecha actualizada e integración del canal de comunicación con el sistema de incidencias del equipo. En el sector privado, la Ley 11/2023 (que transpone la Directiva (UE) 2019/882 (PDF, se abre en una ventana nueva), conocida como Acta Europea de Accesibilidad) aplica desde el 28 de junio de 2025 a servicios como banca, comercio electrónico o transporte, incluidas sus apps; no impone este modelo de declaración, pero sí información accesible sobre el cumplimiento, y el informe con referencia a la EN 301 549 es la mejor evidencia ante la vigilancia del mercado.

Resumen

• El informe de app incluye alcance detallado (versiones, dispositivos, tecnologías de apoyo), resultados por cláusula del capítulo 11, hallazgos con pasos y evidencias, severidad por impacto en tareas y recomendaciones en el lenguaje de la pila técnica.
• El RD 1112/2018 obliga a las apps del sector público desde el 23 de junio de 2021: cumplimiento de la EN 301 549, declaración, mecanismo de comunicación, unidad responsable y seguimiento del Observatorio.
• La declaración sigue el modelo de la Decisión 2018/1523: situación de cumplimiento, contenido no accesible en tres apartados, preparación, contacto y procedimiento de aplicación.
• Se publica en la web del organismo o junto a la información de descarga; lo recomendable es tienda, app y web.
• Revisión anual y en cada versión mayor; en el sector privado, la Ley 11/2023 exige información de conformidad y el informe EN 301 549 es la evidencia.