Accesibilidad — fundamentos, VoiceOver y TalkBack para usuarios ciegos

¿Qué es la Accesibilidad (a11y) en aplicaciones móviles?

Accessibility (abreviado a11y — 11 letras entre «a» e «y») — la práctica de desarrollar aplicaciones utilizables por personas con discapacidades visuales, auditivas, motoras y cognitivas. En el desarrollo móvil, la accesibilidad cubre cuatro escenarios principales: usuarios ciegos (lectores de pantalla), usuarios con baja visión (escalado, contraste), usuarios sordos o con dificultades auditivas (subtítulos, alternativas visuales al sonido) y usuarios con movilidad reducida (control por voz, Switch Control, áreas táctiles grandes).

Requisitos legales — en muchos países, la accesibilidad es obligatoria por ley. EE.UU.: Section 508 y ADA. UE: European Accessibility Act (2025). Reino Unido: Equality Act 2010. Sin soporte de accesibilidad, una aplicación puede ser objeto de demandas judiciales — en EE.UU. en 2023 se presentaron más de 4000 demandas por productos digitales inaccesibles. Apple y Google verifican la accesibilidad durante la moderación de aplicaciones: App Store Review Guidelines (4.2) y Google Play Store exigen soporte mínimo de accesibilidad.

Argumento comercial — la accesibilidad amplía la audiencia. Según Return on Disability (2021), las personas con discapacidad controlan 13 billones de dólares en ingresos disponibles al año. Las aplicaciones accesibles también se posicionan mejor en los buscadores (HTML semántico, textos alternativos), tienen una calificación de usuario más alta y menos reseñas sobre problemas de UX. En IT Sectr, incluimos la accesibilidad en la definición de hecho de todos los proyectos — es un estándar de calidad, no una mejora opcional.

Accesibilidad en iOS: VoiceOver y UIAccessibility

VoiceOver — el lector de pantalla de Apple integrado en iOS, iPadOS y macOS. El usuario desliza el dedo por la pantalla y VoiceOver lee el nombre del elemento bajo su dedo. Un doble toque activa el elemento. VoiceOver admite más de 40 gestos: deslizamiento con tres dedos (desplazamiento), doble toque con dos dedos (detener), gesto en Z (volver). Los desarrolladores controlan qué y cómo lee VoiceOver a través del protocolo UIAccessibility y las propiedades accessibilityLabel, accessibilityTraits y accessibilityHint.

class CustomButton: UIButton {

    override var isAccessibilityElement: Bool {
        get { return true }
        set {}
    }

    // anular accessibilityLabel
    override var accessibilityLabel: String? {
        get { return "Botón de envío del formulario" }
        set {}
    }

    // anular accessibilityHint
    override var accessibilityHint: String? {
        get { return "Toque dos veces para enviar datos" }
        set {}
    }

    // anular accessibilityTraits
    override var accessibilityTraits: UIAccessibilityTraits {
        get { return .button }
        set {}
    }
}

// Dynamic Type — escalado de texto
titleLabel.font = UIFontMetrics.default.scaledFont(
    for: UIFont.systemFont(ofSize: 16)
)
titleLabel.adjustsFontForContentSizeCategory = true

Tipografía dinámica — Dynamic Type en iOS permite al usuario elegir el tamaño del texto (de XS a XXXL). Los desarrolladores usan UIFontMetrics.scaledFont para el escalado automático. El texto debe mostrarse correctamente en todos los tamaños: las líneas no deben recortarse, los botones deben crecer proporcionalmente al texto. UITableView actualiza automáticamente la altura de las celdas al cambiar el tamaño del texto. Ignorar Dynamic Type significa hacer que la aplicación sea inaccesible para usuarios con baja visión.

Accesibilidad en SwiftUI

SwiftUI proporciona modificadores de accesibilidad: .accessibilityLabel(), .accessibilityHint(), .accessibilityAddTraits(), .accessibilitySortPriority(). Por defecto, todos los elementos estándar de SwiftUI (Text, Button, Image) ya son elementos de accesibilidad con etiquetas automáticas. Para vistas personalizadas, use .accessibilityElement(children: .combine) para combinar elementos secundarios en uno solo. SwiftUI admite automáticamente Dynamic Type y VoiceOver.

VStack {
    Image(systemName: "trash")
        .accessibilityLabel(Text("Eliminar elemento"))
    Text("Papelera")
        .font(.body)
}
.accessibilityElement(children: .combine)
.accessibilityAddTraits(.isButton)
.accessibilityHint(Text("Elimina el elemento seleccionado permanentemente"))

Accesibilidad en Android: TalkBack y contentDescription

TalkBack — el lector de pantalla de Google, preinstalado en la mayoría de dispositivos Android (disponible en Google Play para todas las versiones de Android 5+). TalkBack usa los mismos gestos que VoiceOver: deslizar para navegar, doble toque para activar. Los desarrolladores definen las descripciones de los elementos mediante el atributo android:contentDescription en XML o mediante setContentDescription() en código. Para ImageView, contentDescription es obligatorio — sin él, TalkBack dirá «sin etiqueta» o leerá el nombre del archivo.

// XML: contentDescription para ImageView
<ImageView
    android:id="@+id/iconDelete"
    android:src="@drawable/ic_delete"
    android:contentDescription="@string/delete_button_desc"
    android:focusable="true"
    android:clickable="true" />

// Kotlin: asignación programática
iconDelete.contentDescription = getString(R.string.delete_button_desc)

// Accessibility Delegate (personalizado)
iconDelete.accessibilityDelegate = object : View.AccessibilityDelegate() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View, info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.text = "Botón de eliminar"
        info.contentDescription = "Eliminar elemento seleccionado"
        info.className = Button::class.java.name
    }
}

// Live Regions para actualizaciones dinámicas
textView.accessibilityLiveRegion = View.ACCESSIBILITY_LIVE_REGION_POLITE

Live Regions — el mecanismo de Android para notificar a TalkBack sobre cambios de contenido sin necesidad de foco. El atributo android:accessibilityLiveRegion acepta tres valores: none (sin notificaciones), polite (anunciar después de lo actual), assertive (anunciar inmediatamente). Use polite para actualizaciones de estado de carga, assertive para errores críticos. El uso excesivo de assertive creará caos para el usuario — TalkBack interrumpirá constantemente la acción actual.

Accessibility Scanner

Accessibility Scanner — una aplicación gratuita de Google para probar la accesibilidad de aplicaciones Android sin acceso al código fuente. El escáner verifica: contraste del texto, tamaño de las áreas táctiles (mínimo 48×48dp según las Android Accessibility Guidelines), contentDescription para ImageView y jerarquía correcta de elementos. Para pruebas automatizadas, use AccessibilityChecks de Espresso — se integran en CI/CD y verifican la accesibilidad en cada compilación.

WCAG 2.1: contraste, tamaño y áreas táctiles

WCAG 2.1 (Web Content Accessibility Guidelines) — el estándar internacional de accesibilidad desarrollado por W3C. La versión 2.1 (2018) incluye 13 criterios adicionales para aplicaciones móviles. Niveles de conformidad: A (mínimo), AA (obligatorio para la mayoría de organizaciones), AAA (máximo). Apple y Google recomiendan el nivel AA como mínimo para publicar aplicaciones. WCAG 2.2 se publicó en 2023 con mejoras para el foco y la entrada de datos.

Criterios clave para el desarrollo móvil: contraste de texto de al menos 4.5:1 (AA) o 7:1 (AAA), tamaño de las áreas táctiles de al menos 44×44pt (iOS) o 48×48dp (Android), compatibilidad con orientación horizontal y vertical sin pérdida de funcionalidad, posibilidad de desactivar animaciones (prefers-reduced-motion), subtítulos para contenido multimedia y compatibilidad con control por voz (Voice Control en iOS, Voice Access en Android).

Herramientas de verificación de contraste — Colour Contrast Analyser (TPGI), WebAIM Contrast Checker, Stark (Figma), Accessibility Inspector (Xcode). En IT Sectr, verificamos el contraste en la etapa de diseño (Figma + Stark) y nuevamente en la etapa de desarrollo (Accessibility Inspector / Accessibility Scanner). El requisito mínimo es 4.5:1 para todo texto menor de 18pt (14pt bold). Los logotipos y elementos decorativos no requieren contraste.

Pruebas de accesibilidad: herramientas y lista de verificación

Pruebas en iOS — Accessibility Inspector en Xcode (Xcode → Open Developer Tool → Accessibility Inspector) verifica la etiqueta, los traits y la pista para cada elemento. VoiceOver se puede activar en Configuración o mediante el Atajo de Accesibilidad (triple clic en el botón). Para pruebas automatizadas, use XCUITest con XCTAssertTrue(app.staticTexts["etiqueta"].isAccessibilityElement). Apple recomienda probar todas las pantallas de la aplicación con VoiceOver activado.

Pruebas en Android — Accessibility Scanner (Play Store) verifica el contraste, el tamaño de las áreas táctiles y contentDescription. Para automatización: Espresso AccessibilityChecks (importación: androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.5.1'). Google recomienda la siguiente lista de verificación: cada ImageView tiene contentDescription, las áreas táctiles miden al menos 48×48dp, el texto se escala al 200% sin recortarse y todos los elementos son alcanzables mediante el deslizamiento de TalkBack.

Lista de verificación de IT Sectr — antes del lanzamiento, verificamos: (1) VoiceOver/TalkBack lee correctamente todos los elementos, (2) el texto se escala al tamaño máximo sin pérdida de funcionalidad, (3) todos los ImageView tienen contentDescription, (4) el contraste del texto es ≥4.5:1 en todos los temas, (5) las áreas táctiles miden ≥44pt/48dp, (6) no hay menús contextuales accesibles solo mediante pulsación larga, (7) compatibilidad con Reduce Motion / Remove Animations en la configuración del sistema. Esta lista forma parte de la definición de hecho de cada sprint.