La respuesta corta
Si la app es de una administración pública española, la accesibilidad no es una buena práctica: es una obligación con norma técnica, con declaración pública y con un procedimiento de reclamación por el que cualquier ciudadano puede exigirte cuentas.
Lo regula el Real Decreto 1112/2018, que se aplica a los sitios web y aplicaciones para dispositivos móviles del sector público en todos sus niveles: Administración General del Estado, comunidades autónomas, entidades locales, organismos públicos y órganos judiciales.
Y hay una frase en el artículo 7 que conviene leer antes de plantear cualquier excepción: «la falta de prioridad, de tiempo o de conocimiento no puede justificar la excepción».
La norma técnica
El decreto remite a la norma EN 301 549 como referencia para presumir la conformidad: el contenido que cumple sus disposiciones aplicables se considera conforme. En el texto se cita la versión V1.1.2 (2015-04); como toda norma armonizada se actualiza, hay que trabajar siempre contra la versión vigente aplicable en el momento del proyecto, y confirmarlo con el organismo.
En lo que afecta al día a día del equipo, esa norma incorpora los criterios de las pautas WCAG, y en móvil se traduce en cosas concretas:
- Etiquetas de accesibilidad en todos los elementos interactivos, con texto que diga qué hacen y no cómo se llaman internamente.
- Orden de foco lógico y navegación completa sin depender del gesto.
- Contraste verificado, no aproximado a ojo.
- Áreas táctiles suficientes.
- Textos que escalan cuando el usuario aumenta el tamaño de letra del sistema, sin que la pantalla se rompa.
- Alternativas para el contenido no textual.
- Lectores de pantalla reales: VoiceOver y TalkBack, probados en dispositivo, no en simulador.
La declaración de accesibilidad
No es un párrafo en el pie de página. El artículo 15 exige que la entidad responsable de la web o la aplicación facilite una declaración «detallada, exhaustiva y clara» sobre la conformidad, en formato accesible, y anual.
Y tiene que incluir dos cosas que obligan a hacer los deberes de verdad:
- El contenido no accesible, explicado. Es decir: hay que saber qué no cumple y por qué, lo que implica haberlo auditado.
- Los mecanismos de contacto para reclamar.
Para el equipo de desarrollo, la consecuencia práctica es que el material de la declaración es un entregable del proyecto. Si no está en el alcance, alguien lo va a escribir a última hora sin datos.
El mecanismo de reclamación
El artículo 10 establece dos vías, y conviene distinguirlas porque tienen consecuencias distintas:
- Comunicaciones sobre requisitos de accesibilidad, por correo electrónico, teléfono u oficina.
- Solicitudes de información y quejas, que se tramitan por el procedimiento administrativo, con un plazo de respuesta de veinte días hábiles.
Ese plazo es lo que convierte la accesibilidad en un asunto operativo y no solo técnico: alguien del organismo tiene que poder responder en veinte días hábiles, y para eso necesita saber qué falla y cuándo se va a arreglar. Si el proveedor no le ha dejado esa información, no puede.
Revisión y seguimiento
Las entidades tienen que revisar la accesibilidad antes de la puesta en marcha y después periódicamente. Y hay seguimiento nacional: el ministerio competente coordina la supervisión e informa a la Comisión Europea cada tres años.
Traducido al proyecto: la revisión previa al lanzamiento es una fase, con su tiempo y su responsable. Descubrir los incumplimientos en esa revisión, con la fecha de publicación encima, es el escenario caro.
Cómo se hace sin que duela
- Desde el diseño. Contraste, tamaños y jerarquía se deciden en Figma, no se parchean en código.
- Componentes accesibles por defecto. Si el sistema de diseño ya trae la semántica puesta, el equipo no tiene que acordarse en cada pantalla.
- Comprobaciones automáticas en el pipeline, que cazan contraste, etiquetas ausentes y áreas táctiles pequeñas. No lo detectan todo, pero evitan regresiones silenciosas.
- Pruebas manuales con lector de pantalla en cada entrega, sobre los flujos principales.
- Y con personas usuarias reales cuando el proyecto lo permite. Es lo que distingue cumplir de servir.
El orden importa: incorporar accesibilidad desde el primer sprint cuesta una fracción de reconstruirla sobre una app terminada.
Los errores más repetidos
- Etiquetas heredadas del código: un botón que el lector anuncia como «button_submit_2».
- Imágenes decorativas anunciadas como si tuvieran contenido, llenando de ruido la navegación.
- Foco perdido al abrir un diálogo, dejando al usuario de lector de pantalla en ninguna parte.
- Colores como único portador de información: un estado que solo se distingue por rojo o verde.
- Texto dentro de imágenes, que no escala ni se lee.
Antes de estimar
- ¿Qué versión de la norma exige el organismo?
- ¿Quién audita, y con qué metodología?
- ¿Está en el alcance el material de la declaración?
- ¿Hay sistema de diseño previo, y es accesible?
- ¿Quién responderá las reclamaciones y con qué información?
La tercera y la quinta son las que nadie presupuesta y las que siempre acaban haciendo falta.
Es parte del trabajo estándar en apps para el sector público: la accesibilidad no es una capa que se añade, es una restricción de diseño desde la primera pantalla.
Fuente primaria, consultada el 14 de agosto de 2026: Real Decreto 1112/2018, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público.
