La EAA ya obliga a tu app iOS: qué decidir antes de que sea tarde

La accesibilidad de tu app iOS dejó de ser un asunto de experiencia de usuario: desde junio de 2025 es una obligación legal con sanciones. Y, como pasó con el RGPD, las empresas que llegan tarde lo pagan más caro que las que se adelantan.

Si gestionas el producto digital de una empresa con una app iOS en producción, saber cómo cumplir la EAA en tu app iOS ya no es opcional, y probablemente la urgencia es mayor de la que tu equipo te ha trasladado. Esta guía explica, sin tecnicismos innecesarios, qué te exige de verdad la European Accessibility Act, qué riesgo asumes si no haces nada y cómo abordarlo sin frenar tu roadmap.

Llevo más de 25 años en desarrollo de software y 11 en iOS nativo. Como Arquitecto iOS Senior he pasado auditorías de calidad y seguridad en banca y seguros —algunas que puedo nombrar, como Santander y AXA, y otras que no por confidencialidad—, y trabajé en accesibilidad para Juegos ONCE, donde la accesibilidad no es una casilla que marcar: es la razón de ser del producto. Desde esa experiencia te cuento lo que necesitas para tomar decisiones, no para escribir código.

Qué es la EAA y por qué te afecta

La European Accessibility Act —Directiva (UE) 2019/882— es la primera ley europea que obliga a que los productos y servicios digitales sean accesibles para personas con discapacidad. No es una recomendación ni un sello voluntario: es legislación vinculante, ya transpuesta a la ley española y de aplicación desde junio de 2025.

La parte que te interesa: las aplicaciones móviles entran de lleno cuando dan soporte a un servicio cubierto por la directiva. En la práctica, si tu app encaja en alguna de estas categorías, te obliga:

• Banca y servicios financieros para consumidores.
• Comercio electrónico (cualquier app que permita comprar online).
• Transporte de pasajeros (billetes, información de viaje, check-in).
• Comunicaciones electrónicas y servicios de mensajería.
• Medios audiovisuales y acceso a libros electrónicos.

Es decir: prácticamente cualquier app B2C que genere negocio. Si tu app es una herramienta puramente interna el encaje es distinto, pero no des por hecho que estás fuera. Hay una exención para microempresas, pero conviene leerla con cuidado: solo aplica a las que prestan servicios —no a las que fabrican o distribuyen productos— y el listón es bajo (menos de 10 personas y un volumen de negocio o balance anual que no supere los 2 millones de euros). Si superas ese umbral, no eres microempresa a efectos de la ley, así que la exención no te cubre y la EAA te obliga igual. Ante la duda, confírmalo con asesoría legal antes de relajarte.

En términos de negocio, la idea es simple: la accesibilidad ha dejado de ser "experiencia de usuario" para convertirse en un requisito de conformidad legal, al mismo nivel que la protección de datos. Y el paralelismo con el RGPD no es retórico: el mismo patrón de empresas que esperaron a la última fila y acabaron remediando con prisas y mala prensa se va a repetir aquí.

Fechas límite y sanciones: el reloj que ya corre

La EAA es de aplicación general desde junio de 2025. En España se ha transpuesto mediante la Ley 11/2023, de 8 de mayo, cuyo Título I regula los requisitos de accesibilidad de productos y servicios e incluye expresamente las aplicaciones para dispositivos móviles entre los servicios cubiertos.

Hay dos fechas que debes tener en tu calendario:

• Servicios y productos nuevos: deben nacer ya conformes. Si vas a lanzar app o un rediseño grande, la accesibilidad ya es un requisito de salida, no un fast follow.
• Servicios ya en el mercado: tienen un periodo transitorio hasta el 28 de junio de 2030. Parece lejano, pero es engañoso: en una app con años de historia, hacerla accesible no se resuelve en un sprint. Es trabajo de meses repartido pantalla por pantalla.

Sobre las consecuencias de no cumplir: la Ley 11/2023 no fija un cuadro de multas propio para accesibilidad, sino que remite a la legislación sectorial y, en su defecto, al régimen sancionador en materia de derechos de las personas con discapacidad (el Real Decreto Legislativo 1/2013), donde los incumplimientos graves pueden alcanzar sanciones de cifras muy serias. La conclusión práctica no cambia: hay multa, y para los casos graves es relevante.

Pero seamos honestos: para una empresa que vive de su app, la multa rara vez es lo más caro. El coste real es otro:

• Remediación en caliente. Una denuncia o una resolución de incumplimiento te obliga a arreglarlo con prisas, desviando al equipo de la roadmap, en lugar de planificarlo con cabeza.
• Daño reputacional. Aparecer como una empresa que excluye a personas con discapacidad es un titular que ninguna marca quiere.
• Pérdida de mercado. En España hay 4,3 millones de personas con algún tipo de discapacidad (según la Encuesta EDAD 2020 del INE, recogida en el propio preámbulo de la Ley 11/2023). Una app inaccesible es, literalmente, clientes que no pueden comprarte.

Mi recomendación, como quien ha estado al otro lado de muchas auditorías: trátalo como deuda con vencimiento legal. Cuanto antes sepas dónde estás, más barato y más ordenado te sale.

Qué significa "accesible" en una app iOS (en cristiano)

Cuando se habla de cumplir la EAA en iOS, la referencia técnica concreta es la norma europea EN 301 549, que para apps móviles se apoya en las pautas internacionales WCAG 2.1 (nivel AA). No necesitas conocerlas al detalle; sí entender que iOS trae casi todo lo necesario de fábrica, pero tu equipo tiene que activarlo e implementarlo bien. No pasa solo.

En la práctica, el 90% de los problemas que encuentro al auditar una app caen en cuatro frentes. Estos son, traducidos a lo que significan para tu producto:

1. Lectura por voz (VoiceOver). Es el lector de pantalla con el que una persona ciega usa la app: oye lo que hay en pantalla. Si los botones e iconos no están bien etiquetados, esa persona oye "botón, botón, botón" sin saber qué hace ninguno. Es el fallo más común y el que deja la app directamente inutilizable para ese usuario.

2. Texto que crece (Dynamic Type). Muchos usuarios navegan con la letra ampliada, y no es un capricho: la norma que exige la EAA (WCAG 2.1, criterio 1.4.4) obliga a que el texto pueda ampliarse hasta el 200% sin perder contenido ni funcionalidad. En iOS el listón es aún más alto: el mayor tamaño de accesibilidad (AX5) llega al 310%. Si tu diseño usa tamaños de fuente fijos, a esos tamaños el texto se corta o el layout se rompe, y dejas fuera a una base de usuarios enorme: no solo personas con baja visión, también gente mayor. Un detalle que se cuela a menudo: si tu marca usa una tipografía propia, el escalado no es automático; el equipo tiene que mapearla a los estilos de texto del sistema para que crezca igual. Es de los primeros sitios donde se recorta por las prisas, y de los más fáciles por los que suspender una auditoría.

3. Contraste y color. El gris de marca elegante suele no tener suficiente contraste para leerse con comodidad. Y si la app comunica algo solo con color (el campo "en rojo" cuando hay error), una persona daltónica no se entera. Hay que reforzarlo con texto o iconos.

4. Orden y foco. La app tiene que "tener sentido" cuando se navega por voz: que los elementos se lean en el orden lógico y que, cuando salta un error o un aviso, el usuario se entere. Cuando esto falla, la experiencia es un caos aunque cada elemento esté bien etiquetado.

La conclusión de negocio: ninguno de estos cuatro frentes es un gran proyecto aislado. Son docenas de ajustes pequeños repartidos por toda la app. Eso es bueno (no hay que reescribir nada) y malo a la vez (hay que tocar muchas pantallas con criterio). Por eso el orden importa: primero saber dónde estás, luego priorizar.

Qué deberías exigir en una auditoría de accesibilidad

Si vas a encargar este trabajo —interno o a un especialista—, esto es lo que una auditoría de accesibilidad iOS seria debe entregarte. Úsalo como criterio de calidad:

• Un inventario priorizado, no una lista de 400 incidencias en bruto. Qué es bloqueante para cumplir, qué es importante y qué es menor.
• Estimación de esfuerzo por bloque, para que puedas meterlo en tu planificación.
• Cobertura de los cuatro frentes anteriores, pantalla por pantalla en los flujos críticos (login, compra, pago, alta).
• Revisión manual real con VoiceOver, no solo un informe automático. Las herramientas detectan lo evidente; lo que de verdad rompe la experiencia (etiquetas que existen pero no tienen sentido al oírlas) solo lo pilla una persona probando.
• Una red de seguridad para que no vuelva a romperse. Esto es clave y casi nadie lo cuenta: la accesibilidad no es un proyecto que se termina, es un estado que se mantiene. Cada pantalla nueva puede reintroducir fallos. Lo correcto es dejar comprobaciones automáticas integradas en el proceso de desarrollo de tu equipo, de modo que un cambio inaccesible se detecte antes de llegar a producción.

Si te entregan solo un PDF con incidencias y nadie te habla de mantenimiento, te falta la mitad del trabajo.

Los errores que más caro salen

Estos son los que más me encuentro en producción, incluso en apps de equipos muy buenos. Te los doy en clave de riesgo, no de código:

1. Iconos sin etiqueta. Los botones de "compartir", "más opciones", "favorito"… que para un lector de pantalla no dicen nada. Es el fallo masivo número uno.
2. Texto metido dentro de imágenes. No se puede leer por voz ni ampliar. Suele venir de banners y promociones que diseño entrega como imagen.
3. El foco se pierde tras una acción. El usuario envía un formulario, salta un error, y por voz no se entera de que algo ha fallado. Pierdes conversión y cumplimiento a la vez.
4. Contraste suspendido por decisión de diseño. El problema aquí no es técnico, es de proceso: hay que validar el contraste antes de cerrar la guía de estilo, no después.
5. Contenido web embebido a medias. Si tu app incrusta páginas web, su accesibilidad también cuenta para la EAA, y suele ser el agujero más grande y el más olvidado.

El patrón común: casi ninguno es un fallo "grave" por separado. Lo grave es la acumulación. Una app con cientos de estos pequeños fallos es, a efectos legales, una app no conforme.

Cómo abordarlo sin frenar tu roadmap

La objeción que siempre escucho del lado de producto es razonable: "no puedo parar el desarrollo de features para esto". No hace falta. Así es como lo planteo cuando me integro en un equipo:

1. Auditoría primero. Saber exactamente dónde estás. Sin esto, cualquier estimación es a ojo.
2. Priorización por flujos de negocio. Empezar por donde está tu dinero y tu mayor exposición legal: login, compra, pago. Lo accesorio puede esperar.
3. Corrección en paralelo. Un arquitecto iOS senior que se integra en tu equipo puede ir resolviendo accesibilidad mientras vosotros seguís entregando features. No es una cosa o la otra.
4. Automatizar para no recaer. Dejar montadas las comprobaciones para que la app no vuelva a romperse con cada release futura.

Hecho así, la accesibilidad deja de ser un freno y se convierte en una línea de trabajo controlada, con fecha y coste conocidos.

Preguntas frecuentes

¿La EAA obliga a las aplicaciones móviles iOS?

Sí. La European Accessibility Act obliga a las apps móviles cuando dan soporte a un servicio cubierto por la directiva: banca y servicios financieros para consumidores, comercio electrónico, transporte de pasajeros, comunicaciones electrónicas y medios audiovisuales. En la práctica, casi cualquier app B2C que genere negocio queda incluida.

¿Desde cuándo es obligatoria la EAA en España?

Es de aplicación general desde junio de 2025, transpuesta en España mediante la Ley 11/2023. Los servicios y productos nuevos deben nacer ya conformes; los servicios ya en el mercado disponen de un periodo transitorio hasta el 28 de junio de 2030.

¿Qué significa que una app iOS sea accesible según la EAA?

La referencia técnica es la norma EN 301 549, que para apps móviles se apoya en las pautas WCAG 2.1 nivel AA. En la práctica, el grueso de los problemas se concentra en cuatro frentes: etiquetado para VoiceOver, soporte de Dynamic Type (texto ampliable), contraste y uso del color, y orden y gestión del foco.

¿Hay exención para pequeñas empresas?

Existe una exención para microempresas, pero es restrictiva: solo aplica a las que prestan servicios (no a las que fabrican o distribuyen productos) y por debajo de un umbral bajo. Ante la duda, conviene confirmarlo con asesoría legal antes de asumir que se está fuera del alcance.

¿Necesitas saber si tu app cumple la EAA?

Hacer accesible una app con años de historia no es activar una opción: es auditar pantalla por pantalla, priorizar por impacto legal y de negocio, corregir sin parar tu roadmap y dejar montada la red para que no recaiga. Es exactamente el trabajo que he hecho en apps de banca, seguros y en Juegos ONCE, con millones de usuarios detrás.

Si tienes una app iOS en producción y no sabes a qué distancia estás de cumplir, el primer paso es medirlo. En AtalayaSoft te hacemos una Auditoría de accesibilidad iOS orientada a la EAA: revisamos tu app contra la norma (EN 301 549 / WCAG 2.1 AA), te entregamos un informe priorizado y accionable —con esfuerzo estimado, listo para tu planificación— y, si lo necesitas, nos integramos en tu equipo para implementar las correcciones.

Solicita tu Auditoría de accesibilidad iOS para la EAA →

---

Servicios relacionados

• iOS Accessibility (EAA) — auditoría e implementación de accesibilidad para cumplir la EAA.
• Vibe Code Audit iOS — radiografía del estado real de tu código iOS, accesibilidad incluida.
• Senior iOS Engineer — integración de un arquitecto iOS senior en tu equipo (staff augmentation).