Material de consulta. Cómo se usa una app con lector de pantalla, por qué tu diseño se rompe con la letra grande, y qué arreglar primero.
Etiquetas
📚 Material de consulta. No ocupa sesión de clase. Está aquí para cuando tu proyecto lo necesite.
Por qué esto sí importa
Tres razones, y ninguna es "para ser buena persona":
- Son usuarios reales. Cerca del 15% de la población vive con alguna discapacidad. En una app con mil usuarios, son ciento cincuenta personas.
- Es requisito legal en un número creciente de países y sectores — y en varios contratos de gobierno y banca es condición para entregar.
- Mejora la app para todos. Los objetivos táctiles grandes ayudan a quien va en el camión; el buen contraste ayuda a quien usa el teléfono bajo el sol; las etiquetas claras ayudan a cualquiera con prisa.
Ese tercer punto es el que conviene interiorizar: casi ninguna corrección de accesibilidad beneficia solo a las personas con discapacidad. Son mejoras generales de calidad que además incluyen.
La única forma de encontrar los problemas
No se ven en una captura de pantalla. Ni en el emulador. Ni revisando el código.
Enciende TalkBack o VoiceOver e intenta usar tu propia app sin mirarla. Diez minutos te van a enseñar más sobre accesibilidad que cualquier lista de recomendaciones.
Vas a escuchar "botón", "imagen", "sin etiqueta" y silencios largos donde debería haber información. Cada uno es un lugar donde tu app es inutilizable para alguien. Es una experiencia incómoda la primera vez, y es exactamente el punto.
La segunda prueba, igual de reveladora y más rápida: sube el tamaño de letra del sistema al máximo y recorre tus pantallas. Prepárate para ver texto cortado.
Las cuatro props
El primer snippet las tiene todas y cubren la enorme mayoría de los casos:
accessibilityRole— qué tipo de elemento es. El lector anuncia "botón", "enlace", "encabezado", y eso le dice al usuario qué puede hacer con él.accessibilityLabel— qué es. Describe el elemento, no la acción física: "Eliminar el pedido 4321", nunca "toca aquí" ni "ícono de basura".accessibilityHint— qué va a pasar si lo activa. Opcional, útil cuando la consecuencia no es obvia.accessibilityState— en qué estado está: seleccionado, deshabilitado, ocupado, expandido.
El que más se olvida es el estado, y es el que más frustra: sin él, el usuario no puede saber si ya marcó ese favorito, si el interruptor está encendido o si el botón está deshabilitado. Está navegando a ciegas dentro de tu app, literalmente.
Los tres errores que verás siempre
Áreas táctiles pequeñas. Un ícono de 24×24 es difícil de atinar para cualquiera. Los mínimos son 44×44 en iOS y 48×48 dp en Android, y hitSlop te deja cumplirlos sin cambiar el diseño visual.
Contraste insuficiente. El gris claro sobre gris claro se ve elegante en la pantalla del diseñador y desaparece bajo el sol. El mínimo recomendado es 4.5:1 para texto normal; el verificador de WebAIM te lo calcula en segundos.
Texto que no escala. Cuando el usuario sube la letra del sistema, los contenedores con altura fija cortan el texto. Y la tentación de "arreglarlo" con allowFontScaling={false} es justamente lo contrario de arreglarlo: es silenciar a la persona que necesita letra grande — y en iOS puede costarte el rechazo de la tienda.
Agrupar: que el lector cuente una historia
El último snippet resuelve un problema sutil. Una tarjeta de producto tiene foto, nombre, precio y disponibilidad; visualmente el usuario la percibe como una cosa. Sin agrupar, el lector la anuncia como cuatro fragmentos sueltos, y navegar una lista de veinte tarjetas se vuelve una tortura de ochenta elementos.
El criterio es directo: si el usuario lo percibe como un elemento, anúncialo como un elemento.
Por dónde empezar en tu proyecto
Si solo puedes dedicarle una hora, en este orden de impacto:
- Etiquetas en todo lo tocable que no tenga texto visible (íconos, botones de imagen).
- Estados en lo que se pueda activar o seleccionar.
- Áreas táctiles de al menos 44/48.
- Contraste del texto secundario, que suele ser el culpable.
- Prueba con letra grande y arregla lo que se corte.
Con eso tu app pasa de inutilizable a usable para un usuario con lector de pantalla. Y de paso mejora para todos los demás.
Ejemplos de Código
4 ejemplos
Las cuatro props que resuelven casi todo
Rol, etiqueta, pista y estado.
1<Pressable
2 onPress={onGuardar}
3 accessible // trátalo como UN elemento
4 accessibilityRole="button" // el lector dice "botón"
5 accessibilityLabel="Guardar cambios" // QUÉ es (no "toca aquí")
6 accessibilityHint="Guarda el formulario y vuelve a la lista" // QUÉ PASA
7 accessibilityState={{ disabled: enviando, busy: enviando }}
8>
9 <Text>Guardar</Text>
10</Pressable>
11
12Roles más usados:
13 button · link · header · image · search · checkbox · switch · alert
14
15Regla de la etiqueta: describe el ELEMENTO, no la acción física.
16 ❌ "Toca aquí" ❌ "Ícono de basura"
17 ✅ "Eliminar el pedido 4321"Área táctil mínima
44×44 en iOS, 48×48 dp en Android. Sin excepciones.
1// ❌ Ícono de 24×24: difícil de atinar para cualquiera
2<Pressable style={{ width: 24, height: 24 }}>
3 <Icono />
4</Pressable>
5
6// ✅ Opción A — el contenedor crece
7<Pressable style={{ width: 48, height: 48, alignItems: "center", justifyContent: "center" }}>
8 <Icono /> {/* el ícono sigue viéndose de 24 */}
9</Pressable>
10
11// ✅ Opción B — hitSlop expande el área SIN cambiar el diseño
12<Pressable hitSlop={12} style={{ width: 24, height: 24 }}>
13 <Icono />
14</Pressable>
15
16Esto no es solo accesibilidad: es usabilidad para todos.
17Nadie atina cómodamente a 24 px yendo en el camión.El tamaño de fuente del sistema
El problema de accesibilidad más común y el menos revisado.
1// El usuario sube la letra en Ajustes del sistema.
2// Tu fontSize: 14 puede convertirse en el equivalente a 28.
3
4// ❌ Contenedor con altura fija: el texto se corta
5<View style={{ height: 60 }}>
6 <Text style={{ fontSize: 16 }}>{titulo}</Text>
7</View>
8
9// ✅ Deja crecer al contenedor
10<View style={{ minHeight: 60, paddingVertical: 8 }}>
11 <Text style={{ fontSize: 16 }}>{titulo}</Text>
12</View>
13
14// ⚠️ Esto NO es la solución:
15<Text allowFontScaling={false}> // silencia a quien necesita letra grande
16// Úsalo solo en casos muy puntuales (un logo, un número de versión).
17
18Cómo probar: Ajustes → Pantalla → Tamaño de fuente → máximo.
19Luego recorre TODAS tus pantallas.Agrupar para que el lector no lea basura
Sin agrupación, el usuario escucha cada fragmento por separado.
1// ❌ El lector lee cuatro elementos sueltos:
2// "Camisa azul" ... "$450" ... "En existencia" ... "imagen"
3<View style={styles.tarjeta}>
4 <Image source={{ uri: foto }} />
5 <Text>{nombre}</Text>
6 <Text>${precio}</Text>
7 <Text>{disponible ? "En existencia" : "Agotado"}</Text>
8</View>
9
10// ✅ Un solo elemento con una frase que tiene sentido:
11<View
12 accessible
13 accessibilityRole="button"
14 accessibilityLabel={`${nombre}, $${precio}, ${disponible ? "en existencia" : "agotado"}`}
15 style={styles.tarjeta}
16>
17 {/* los hijos ya no se anuncian por separado */}
18</View>
19
20Criterio: si el usuario percibe la tarjeta como UNA cosa,
21el lector también debe anunciarla como una.Recursos
3 recursos disponibles
¡Hora de Practicar!
Práctica Guiada — Usa tu app a ciegas
Diez minutos con el lector de pantalla encendido cambian cómo diseñas para siempre.
No es un ejercicio teórico. Hazlo con tu proyecto:
- Activa el lector de pantalla — Android: Ajustes → Accesibilidad → TalkBack. iOS: Ajustes → Accesibilidad → VoiceOver.
- Apaga la pantalla mentalmente: intenta completar el flujo principal de tu app sin mirarla, solo escuchando y deslizando.
- Anota cada vez que escuches: "botón", "imagen", "sin etiqueta" o simplemente silencio. Cada uno es un elemento que un usuario ciego no puede usar.
- Sube el tamaño de letra del sistema al máximo (Ajustes → Pantalla → Tamaño de fuente) y vuelve a abrir tu app. Anota qué se corta, qué se encima y qué desaparece.
- Corrige los cinco problemas más graves.
Entrega: la lista de lo que encontraste y los commits de las correcciones.
Reto de Lectura
Reto de Lectura — La pantalla que el lector no puede leer
Esta pantalla se ve impecable y es inutilizable con TalkBack. Cinco elementos que el lector anuncia mal o no anuncia.
Esta tarjeta de producto se ve perfecta. Con el lector de pantalla encendido es inservible. Encuentra los 5 problemas y di exactamente qué escucha (o no escucha) el usuario.
jsx1function TarjetaProducto({ producto, esFavorito, onFavorito, onComprar }) { 2 return ( 3 <View style={styles.tarjeta}> 4 <Image source={{ uri: producto.foto }} style={styles.foto} /> 5 6 <Text style={{ fontSize: 18 }}>{producto.nombre}</Text> 7 <Text style={{ fontSize: 14 }}>${producto.precio}</Text> 8 9 <Pressable onPress={onFavorito} style={styles.iconoChico}> 10 <Text>{esFavorito ? "★" : "☆"}</Text> 11 </Pressable> 12 13 <Pressable onPress={onComprar} style={styles.boton}> 14 <Text style={{ color: "#9ca3af" }}>Comprar</Text> 15 </Pressable> 16 </View> 17 ); 18} 19 20const styles = StyleSheet.create({ 21 tarjeta: { padding: 12, backgroundColor: "#ffffff" }, 22 foto: { width: 100, height: 100 }, 23 iconoChico: { width: 24, height: 24 }, 24 boton: { backgroundColor: "#e5e7eb", padding: 10 }, 25});
Preguntas:
- ¿Qué anuncia el lector al llegar a la imagen?
- El botón de favorito muestra ★ o ☆. ¿Qué escucha el usuario y cómo sabe si ya es favorito?
- El área táctil del favorito mide 24×24. ¿Qué problema tiene, y no solo para usuarios con discapacidad?
- El texto "Comprar" es gris
#9ca3afsobre fondo#e5e7eb. ¿Cuál es el problema? - El usuario sube el tamaño de fuente del sistema al máximo. ¿Qué le pasa a esta tarjeta?
Documentación Oficial
Documentación de apoyo
Guías oficiales y herramientas de verificación.
Clase 31 de 31 en la ruta Desarrollo movil