Por qué importa: personas reales, ley y calidad

Existe una forma cómoda de contar la accesibilidad, y es falsa: presentarla como un apéndice, un impuesto que el equipo paga al final para complacer a alguien. La forma exacta es otra. Una interfaz no es un dibujo: es una estructura semántica —elementos con nombre, valor, estado y relaciones— que el sistema presenta por un canal concreto. El canal visual es solo uno de los posibles. Cuando tu app únicamente funciona por ese canal, no es que resulte más incómoda para ciertas personas: es que sencillamente no existe para ellas, igual que un servidor que solo habla un protocolo no existe para un cliente que habla otro. Desde ese único hecho se deducen las tres razones que la industria suele enumerar como si fueran independientes: la humana, la legal y la técnica.

Quién hay realmente al otro lado

Antes de mirar las cifras conviene fijar el vocabulario, porque el modelo mental que se use determina dónde se busca la solución. El modelo médico entiende la discapacidad como un déficit de la persona que hay que compensar; el modelo social la entiende como la fricción que aparece entre una persona y un entorno que no la contempló. La diferencia no es filosófica sino operativa: bajo el primero, el problema está en el usuario y la app no tiene nada que arreglar; bajo el segundo, la discapacidad la produce el diseño, y por tanto el diseño puede eliminarla. Todo lo que sigue asume el segundo modelo, que además es el que sostienen las normas vigentes.

La Organización Mundial de la Salud estima que alrededor de mil trescientos millones de personas viven con una discapacidad significativa: en torno al dieciséis por ciento de la población mundial. Desglosado por canales, la cifra deja de ser abstracta. Más de dos mil millones de personas conviven con alguna forma de deficiencia visual de cerca o de lejos; unos cuarenta millones son ciegas. Cerca del ocho por ciento de los hombres de ascendencia europea tiene alguna forma de daltonismo. Mil quinientos millones de personas presentan pérdida auditiva en algún grado. Y a partir de los cuarenta años la presbicia es prácticamente universal: no es una discapacidad, pero produce exactamente la misma conducta —subir el tamaño del texto del sistema— que la baja visión.

Esas cifras globales, sin embargo, dicen poco sobre una app concreta, y el argumento gana fuerza cuando se traduce a la escala del producto. Una aplicación con cien mil usuarios activos al mes tiene, según esas proporciones, en torno a dieciséis mil personas con alguna discapacidad significativa, varios miles con una forma de daltonismo y una fracción difícil de estimar pero nunca despreciable que navega con lector de pantalla. No son categorías de un informe: son sesiones que ocurren hoy, en tu app, y que terminan antes de lo que deberían.

El error de cálculo habitual consiste en tratar la discapacidad como un atributo permanente y binario de una minoría estable. No lo es. El modelo del espectro de la persona que popularizó la práctica de diseño inclusivo distingue tres formas de la misma limitación funcional: permanente, temporal y situacional. Quien ha perdido un brazo, quien lo lleva escayolado seis semanas y quien lleva un bebé en brazos comparten, mientras dura, la misma restricción de interacción con una sola mano. Quien es sordo, quien tiene una otitis y quien va en un vagón ruidoso comparten la necesidad de subtítulos. Bajo esa lente, el porcentaje de sesiones de tu app afectadas por alguna limitación no es el dieciséis por ciento: se aproxima al cien.

Hay un dato de negocio que suele cerrar la discusión antes que cualquier apelación moral: en la práctica, un usuario con discapacidad rara vez decide solo. Los estudios de mercado del sector estiman que el gasto discrecional que controlan directa o indirectamente las personas con discapacidad y sus círculos familiares se cuenta en billones de euros a escala global. Una app inaccesible no pierde a un usuario: pierde a la unidad de decisión completa que lo rodea.

Hay además un factor demográfico que hace que este cálculo empeore con el tiempo y que ningún equipo debería ignorar al planificar a tres años vista. La población de los mercados donde se monetizan las apps envejece con rapidez, y el envejecimiento no produce discapacidades exóticas: produce exactamente las que castiga una interfaz descuidada. Presbicia, reducción del contraste percibido, pérdida auditiva en las frecuencias altas, temblor leve, tiempos de reacción más largos. La base de usuarios que hoy tolera tu texto de once puntos con gris claro sobre blanco es la misma que dentro de una década no lo verá, y para entonces habrá encontrado otra app.

Conviene también desactivar una intuición falsa sobre los datos propios. Es habitual que alguien argumente que la analítica no muestra usuarios con tecnologías de asistencia, y que por tanto no los hay. La inferencia está mal hecha: si la app no es usable con lector de pantalla, esas personas la abandonan en los primeros segundos y no llegan a generar los eventos que la analítica cuenta. La ausencia en las métricas no es evidencia de ausencia de demanda, es la consecuencia esperable del problema que se quiere medir. Lo que sí se puede medir sin sesgo es la distribución del tamaño de texto y de los ajustes activos entre las sesiones existentes, y ese dato sorprende a casi todos los equipos la primera vez que lo miran.

La obligación ya no es una hipótesis

Vale la pena añadir que el catálogo de limitaciones no se agota en la vista y el oído, aunque sean las que más atención reciben. La discapacidad motriz condiciona el tamaño y la separación de los objetivos táctiles y hace impracticables los gestos que exigen precisión o simultaneidad. Las diferencias cognitivas y de atención penalizan las interfaces con demasiada información simultánea, los temporizadores que expiran y los mensajes de error escritos en jerga. La dislexia castiga los bloques largos sin jerarquía y las tipografías estrechas. Cada una de esas familias tiene su contrapartida en decisiones concretas de diseño, y ninguna requiere tecnología de asistencia para manifestarse.

Durante dos décadas la accesibilidad digital vivió en la zona gris de la recomendación. Esa etapa se acabó. En la Unión Europea, la Directiva 2019/882, conocida como Acta Europea de Accesibilidad, es aplicable desde el 28 de junio de 2025 y alcanza de forma explícita al comercio electrónico, los servicios bancarios de consumo, el transporte de viajeros, los libros electrónicos y las comunicaciones electrónicas, con las apps móviles nombradas como parte del servicio. En España se transpuso mediante la Ley 11/2023, mientras que el sector público ya estaba cubierto desde antes por el Real Decreto 1112/2018. El criterio técnico de cumplimiento no se inventa caso por caso: la norma armonizada EN 301 549 remite a los criterios de las WCAG en su nivel doble A, que es el listón operativo que un auditor va a aplicar.

Fuera de Europa el panorama es análogo aunque llegue por otras vías. En Estados Unidos, la jurisprudencia acumulada bajo el Título III de la ADA ha consolidado que una app vinculada a un establecimiento comercial es un lugar de acomodación pública; el caso Robles contra Domino's, cuyo recurso el Tribunal Supremo declinó revisar en 2019, dejó firme esa lectura. La Sección 508 de la Rehabilitation Act añade el filtro de la compra pública: sin conformidad, no hay contrato federal. Canadá tiene la Accessible Canada Act y Ontario su AODA; Australia, Japón, Corea, Israel y Brasil sostienen regímenes comparables.

Merece la pena entender por qué el legislador eligió apoyarse en un estándar técnico externo en lugar de redactar requisitos propios. Una norma que dijera que las apps deben ser accesibles sería inaplicable, porque no define umbral ni método de verificación. Al remitir a las WCAG a través de EN 301 549, el marco jurídico importa criterios comprobables, con condiciones de éxito redactadas para poder ser evaluadas por un tercero. Eso tiene una consecuencia excelente para un equipo de ingeniería: la obligación legal se traduce, sin ambigüedad, en una lista de comprobaciones que se pueden automatizar en parte y auditar el resto. Deja de ser un asunto de abogados y pasa a ser un asunto de definición de terminado.

Un matiz importante para no exagerar en la dirección contraria: las WCAG se redactaron pensando en la web y algunos de sus criterios no tienen traducción literal a una app nativa. EN 301 549 incluye por eso un capítulo específico para software no web, y las plataformas móviles cuentan con guías complementarias. En la práctica, un equipo de iOS que cumple con lo que exige el ecosistema de Apple —control accesible, texto escalable, contraste suficiente, respeto a los ajustes del sistema— cubre la mayor parte del terreno sin necesidad de traducir criterio a criterio.

El efecto rampa

Queda por señalar un actor que muchos equipos descubren tarde: la propia plataforma. Apple lleva más de una década invirtiendo en tecnologías de asistencia y las presenta como una característica distintiva del ecosistema, con secciones editoriales dedicadas en la tienda y premios anuales que destacan apps por su diseño inclusivo. Ser accesible no solo evita un riesgo: abre una vía de visibilidad que no depende de comprar publicidad.

El argumento de calidad tiene un nombre tomado del urbanismo. Las rampas en los bordillos de las aceras se legislaron pensando en sillas de ruedas; en cuanto se instalaron, resultó que las usaban carritos de bebé, maletas con ruedas, repartidores con carretillas, bicicletas y cualquiera con las rodillas cansadas. La medida diseñada para un grupo pequeño acabó beneficiando a la mayoría, y ese fenómeno —el efecto rampa— se repite con una regularidad casi mecánica en el software. Los subtítulos se crearon para personas sordas y hoy los consume media plataforma de vídeo con el sonido apagado. La lectura por voz nació para personas ciegas y se usa mientras se conduce. El contraste alto se pensó para baja visión y se agradece bajo el sol.

El fenómeno tiene además una lectura estadística que explica por qué ocurre siempre y no por casualidad. Diseñar para el caso medio optimiza una interfaz para un usuario que no existe: nadie tiene simultáneamente visión perfecta, atención plena, ambas manos libres, un entorno silencioso y buena iluminación. Diseñar para los extremos, en cambio, obliga a eliminar suposiciones en lugar de a añadir casos particulares, y una interfaz con menos suposiciones cubre más situaciones reales por construcción. El efecto rampa no es generosidad recompensada: es el resultado previsible de sustituir una constante por una variable.

En una app de Apple ese efecto tiene además una traducción técnica muy concreta, y es el argumento que suele convencer a un equipo de ingeniería que no se ha movido con los anteriores. La jerarquía de accesibilidad no es una estructura paralela ni decorativa: es la misma que consume XCUITest para localizar elementos. Un botón sin identidad accesible no solo es invisible para VoiceOver; es inalcanzable para tu suite de pruebas de interfaz.

Image(systemName: "trash")
    .accessibilityLabel("Eliminar tarea")
    .accessibilityIdentifier("boton.eliminar")   // estable para XCUITest

// En el test, el mismo arbol que usa VoiceOver:
let app = XCUIApplication()
app.buttons["boton.eliminar"].tap()

La consecuencia es más profunda de lo que parece. Etiquetar exige nombrar, y nombrar exige haber decidido qué es cada cosa. Un equipo que no logra escribir la etiqueta de un control suele descubrir, al intentarlo, que ese control tenía un significado ambiguo o dos responsabilidades mezcladas. La accesibilidad funciona así como un detector de deuda semántica: cada elemento que se resiste a ser nombrado señala un punto donde la interfaz aún no sabe lo que quiere decir. Y sistemas como Siri, los atajos, App Intents, la traducción automática de pantalla o los futuros agentes que operen la interfaz por ti se alimentan exactamente de esa misma información estructural.

El efecto rampa tiene además una manifestación de layout que conviene nombrar porque ahorra trabajo futuro. Una vista construida para sobrevivir al tamaño de texto máximo es, por construcción, una vista sin alturas fijas, sin truncamientos silenciosos y con su eje de crecimiento libre. Esa misma vista es la que aguanta después el alemán, cuyas palabras compuestas miden el doble que en español; la que funciona en una ventana redimensionable de macOS; la que se comporta en pantalla dividida de iPad; la que no explota en el modo de pantalla ampliada. Nadie diseñó para esos casos: salieron gratis por haber eliminado una suposición.

Dónde encaja en el proceso

Hay una objeción que aparece siempre en este punto y que merece una respuesta directa en lugar de un rodeo: si el equipo va justo de plazo, ¿no es razonable aplazarlo? La respuesta honesta es que aplazarlo no ahorra tiempo, lo traslada con intereses. Un control declarado como botón desde el principio no cuesta nada; convertirlo en botón seis meses después implica rehacer su estilo, revisar su animación, ajustar su layout y volver a probar la pantalla. El trabajo de accesibilidad hecho a tiempo es en su mayor parte una elección entre dos formas de escribir lo mismo, y solo se convierte en trabajo adicional cuando se eligió mal y hay que deshacerlo.

La pregunta operativa no es si hacerlo, sino en qué punto del ciclo se paga. La respuesta es que se paga en todos, en dosis pequeñas, y nunca en una fase final llamada auditoría. En diseño se decide el contraste, el tamaño mínimo de los objetivos táctiles y si el color es el único portador de significado. En implementación se etiquetan los controles no textuales, se agrupan los elementos que se leen juntos y se usan estilos de fuente semánticos. En revisión de código se comprueba lo anterior con la misma naturalidad con que se comprueba el manejo de errores. Y en las pruebas se automatiza lo automatizable y se reserva una navegación manual para lo que ninguna herramienta detecta.

flowchart LR
a[Diseno: contraste, tamanos, no solo color] --> b[Implementacion: etiquetas, agrupacion, tipos semanticos]
b --> c[Revision de codigo: checklist en la PR]
c --> d[Pruebas: auditoria automatica mas navegacion manual]
d --> e[Lanzamiento]
e --> f[Telemetria de ajustes de accesibilidad]
f --> a

El bucle del diagrama se cierra en un punto que suele faltar: la telemetría. Registrar de forma agregada qué ajustes de accesibilidad tienen activos las sesiones reales convierte una discusión de intuiciones en una de datos, y sirve además para priorizar. Si el diez por ciento de las sesiones llega con un tamaño de accesibilidad, arreglar el layout en ese rango deja de ser una tarea de conciencia y pasa a ser una tarea de conversión con un tamaño de mercado adjunto.

Merece la pena decir con claridad qué parte de esto es gratis. En SwiftUI, un Button con texto, un Toggle, un NavigationLink o un List ya llegan al árbol de accesibilidad con nombre, rasgo y valor correctos, y el texto declarado con estilos semánticos ya escala con Dynamic Type sin que escribas una línea. El trabajo real se concentra en lo que tú inventas: iconos sin texto, controles dibujados a mano, gestos personalizados, jerarquías visuales que el sistema no puede deducir. Ese resto es pequeño, y es exactamente el material de las cuatro lecciones siguientes.

De ahí se sigue una regla de decisión que ahorra discusiones y que conviene adoptar antes de escribir código: usa el control estándar y cámbiale el aspecto, en lugar de dibujar un control nuevo y añadirle accesibilidad después. Un Button con un estilo personalizado, un Toggle con una apariencia propia o un Slider con su pista redibujada conservan todos sus rasgos, gestos, comportamiento con el rotor, respuesta al teclado y compatibilidad con Voice Control. Un rectángulo con un gesto encima no conserva nada y obliga a reconstruir a mano cada una de esas propiedades, casi siempre de forma incompleta.

Conviene además fijar un criterio de arranque para un producto que ya existe y arrastra deuda, porque el error clásico es intentar arreglarlo todo a la vez y abandonar en la segunda semana. La secuencia que funciona ordena por impacto: primero los recorridos críticos —alta, autenticación, compra, la tarea principal—, después las pantallas más visitadas según la analítica, y solo al final la cola larga. Dentro de cada pantalla, el orden también es fijo: etiquetas ausentes, contraste, texto que se rompe al crecer, agrupación y orden de lectura, y por último los refinamientos. Una app con los tres primeros puntos resueltos en sus cinco pantallas principales ya es utilizable; una con refinamientos exquisitos en una pantalla secundaria no lo es.

Por último, una advertencia sobre la organización del trabajo. Nombrar a una persona responsable de accesibilidad suele producir el efecto contrario al buscado: el resto del equipo delega y deja de mirar. El papel que sí funciona es el de referente, alguien que conoce las herramientas, resuelve dudas y revisa los casos difíciles, mientras la responsabilidad de que cada cambio cumpla sigue siendo de quien lo escribe. Es la misma distinción que existe entre tener un experto en seguridad y tener un departamento al que se le echa la culpa después.