Más allá del texto: contraste, movimiento y ajustes del sistema

Hay un sesgo cómodo en la forma en que los equipos abordan la accesibilidad: se identifica con la ceguera, se resuelve con etiquetas y se da por cerrada. Pero la inmensa mayoría de las personas afectadas por decisiones de interfaz no usa lector de pantalla. Usa la vista, con menos contraste del que tú tienes, con una percepción del color distinta de la tuya, o con un sistema vestibular que reacciona con náusea a una transición que a ti te parece elegante. Estas personas no aparecen en ninguna auditoría de etiquetas porque no fallan al navegar: fallan al percibir, y el fallo es silencioso. Nadie escribe una reseña diciendo que no distingue el estado activo de un interruptor; simplemente deja de usar la app.

Contraste: un umbral, no una opinión

El contraste entre dos colores se define como el cociente entre sus luminancias relativas más un desplazamiento, y produce un número entre uno y veintiuno. Los criterios de las WCAG fijan los mínimos con precisión: 4.5 a 1 para el texto normal, 3 a 1 para el texto grande —a partir de dieciocho puntos, o catorce en negrita— y 3 a 1 para los componentes de interfaz y los objetos gráficos que transmiten información, como el borde de un campo, el trazo de una gráfica o el estado de un interruptor. El nivel triple A eleva el texto normal a 7 a 1, y las directrices de diseño de Apple recomiendan tomarlo como aspiración cuando el diseño lo permita.

La consecuencia práctica es que el contraste deja de ser materia de gusto. Un gris claro sobre blanco no es discutiblemente elegante: es medible, y si da 2.9 no cumple. Ese carácter aritmético es también una buena noticia, porque permite automatizar la comprobación en la fase de diseño y en integración continua sobre la paleta, en lugar de descubrirla en revisión.

La plataforma ayuda si se la deja. Los colores semánticos del sistema —etiqueta primaria, secundaria, terciaria, fondos agrupados, separadores— ya están calibrados para cumplir en claro, en oscuro y con el contraste aumentado. Y para la paleta propia, el catálogo de recursos admite variantes por apariencia y por contraste alto, de modo que un mismo nombre resuelve al color adecuado sin condicionales en el código.

Text("Pendiente")
    .foregroundStyle(.secondary)         // semantico: calibrado por el sistema
    .background(Color("Aviso"))          // del catalogo, con variante de alto contraste

El color no puede ir solo

El daltonismo afecta a cerca del ocho por ciento de los hombres de ascendencia europea, y sus formas más comunes comprometen justo el eje rojo verde que la industria del software usa sin descanso para codificar error y éxito. Una lista donde el estado se distingue por un punto rojo o verde no comunica nada a esas personas, y tampoco a quien mira la pantalla bajo el sol o con un filtro nocturno agresivo. El principio es antiguo y sigue vigente: el color puede reforzar la información, nunca portarla en exclusiva.

SwiftUI expone el ajuste del sistema mediante accessibilityDifferentiateWithoutColor, pensado exactamente para reforzar la codificación cuando la persona lo ha pedido. La forma madura de usarlo es no depender de él: diseñar con redundancia desde el principio y reservar el ajuste para intensificar, no para introducir la única alternativa.

@Environment(\.accessibilityDifferentiateWithoutColor) private var sinColor

HStack {
    Image(systemName: estado.simbolo)      // forma distinta por estado
        .foregroundStyle(estado.tinte)     // el color solo refuerza
    Text(estado.titulo)                    // y el texto lo dice
    if sinColor { Text(estado.abreviatura).bold() }
}

Movimiento, transparencia y compañía

El movimiento a gran escala —desplazamientos amplios, zoom, paralaje, rebotes— desencadena en algunas personas mareo, náusea y desorientación por conflicto vestibular. No es una molestia estética: es una respuesta fisiológica que puede durar horas. El ajuste de reducir movimiento existe para eso, y responder a él no significa eliminar toda animación sino sustituir la traslación por una atenuación. Una transición que aparece con un fundido cruzado sigue comunicando el cambio de estado sin desplazar el campo visual.

@Environment(\.accessibilityReduceMotion) private var menosMovimiento

var body: some View {
    Panel()
        .transition(menosMovimiento ? .opacity : .slide)
        .animation(menosMovimiento ? .none : .spring(duration: 0.4), value: visible)
}

Conviene precisar qué se considera movimiento problemático, porque la reacción excesiva también es un fallo. Lo que desencadena el conflicto vestibular es el desplazamiento de grandes superficies, el escalado brusco, el paralaje y las trayectorias curvas rápidas. Un cambio de opacidad, un color que transiciona o un indicador que gira en un espacio pequeño no entran en esa categoría y no hace falta suprimirlos. Eliminar toda animación cuando el ajuste está activo suele empeorar la comprensión, porque desaparecen las señales de continuidad que explican de dónde viene cada cosa.

Los demás ajustes siguen el mismo patrón: el sistema los publica en el entorno y tú decides qué significan en tu interfaz. Reducir transparencia debe sustituir los materiales translúcidos por fondos sólidos, porque un material sobre contenido variable produce contrastes impredecibles. El contraste aumentado, disponible como colorSchemeContrast, debe intensificar bordes y separadores. El texto en negrita del sistema llega como legibilityWeight y afecta también a los símbolos. Y mostrar formas de botón exige que lo pulsable se vea pulsable sin depender del color del rótulo.

flowchart TB
a[Ajustes de accesibilidad del sistema] --> b[Valores en el Environment de SwiftUI]
b --> c[reduceMotion: fundido en vez de desplazamiento]
b --> d[reduceTransparency: fondo solido]
b --> e[colorSchemeContrast: bordes marcados]
b --> f[legibilityWeight: tipografia mas gruesa]
b --> g[differentiateWithoutColor: forma y texto]
c --> h[La interfaz responde sin preguntar]
d --> h
e --> h
f --> h
g --> h

Queda una dimensión que rara vez se cuenta junto a las anteriores y pertenece al mismo capítulo: el tamaño de los objetivos táctiles. Las directrices de Apple fijan cuarenta y cuatro puntos como mínimo para cualquier elemento accionable, y ese número no protege solo a quien tiene temblor o movilidad reducida: protege a cualquiera que use la app caminando, con guantes o con prisa. Un icono de veinticuatro puntos puede seguir midiendo veinticuatro visualmente si se le añade área táctil con relleno o con un marco mayor y un fondo transparente que responda al tacto.

Button(action: cerrar) {
    Image(systemName: "xmark")
        .frame(width: 44, height: 44)     // area tactil, no tamano visual
        .contentShape(Rectangle())        // toda el area responde, no solo el glifo
}

contentShape es la pieza que casi siempre falta: sin ella, la zona sensible se limita al trazo dibujado del símbolo, de modo que el marco ampliado engaña al desarrollador —que ve el espacio— sin ayudar a la persona, que sigue teniendo que acertar en un glifo de doce puntos. Conviene revisar además que dos objetivos ampliados no acaben solapándose, porque un toque ambiguo es peor que un toque difícil.

Probar que la app responde

Todo lo anterior es inútil si nadie comprueba que ocurre. La ventaja de estos ajustes frente a otras dimensiones de la accesibilidad es que su verificación se automatiza con facilidad, porque son valores del entorno y el entorno se puede fijar en una previsualización o en un test. La práctica que mejor rinde consiste en no crear previsualizaciones nuevas por cada combinación, sino declarar un conjunto pequeño de escenarios representativos y aplicarlos a las vistas críticas.

#Preview("Contraste y movimiento reducidos") {
    Panel()
        .environment(\.accessibilityReduceMotion, true)
        .environment(\.accessibilityReduceTransparency, true)
        .environment(\.colorSchemeContrast, .increased)
        .preferredColorScheme(.dark)
}

Hay un matiz técnico que conviene conocer para no perder tiempo: fijar estos valores en el entorno de una previsualización afecta a cómo tu código reacciona, pero no reproduce exactamente lo que hace el sistema operativo con sus propios materiales y efectos. Para eso hacen falta los interruptores reales, y ahí el Accessibility Inspector permite activarlos sobre la app en ejecución en un dispositivo físico, que es donde aparecen las sorpresas con materiales, sombras y símbolos.

La comprobación de contraste, por su parte, no debería vivir en la app sino en la paleta. Si los colores están definidos en un catálogo de recursos o en un paquete de sistema de diseño, el cálculo del cociente de luminancias entre las combinaciones permitidas se puede ejecutar como prueba unitaria sobre esa fuente única y fallar en integración continua cuando alguien introduzca un par que no cumple. Es una prueba de veinte líneas que impide una clase entera de defectos antes de que llegue a una pantalla.