En Telefónica creemos que la accesibilidad es una responsabilidad compartida. Nuestro accessibility catalog es una iniciativa open source diseñada para ayudar a los desarrolladores a crear aplicaciones Android más accesibles.
En una publicación anterior, «Mejora la accesibilidad de Android con conmutables personalizados exploramos cómo hacer más accesibles los componentes personalizados que cambian de estado (como Switches y Checkboxes). Desde entonces, el catálogo ha incorporado interesantes novedades, especialmente en torno a las descripciones de contenido (content descriptions) y las descripciones de estado (state descriptions), dos pilares fundamentales para construir interfaces accesibles.
Cómo usar correctamente las descripciones de contenido
Las interfaces modernas incluyen ilustraciones, iconos, gráficos y elementos visuales ricos. Sin embargo, si no se tiene en cuenta la accesibilidad, muchos de estos elementos se vuelven invisibles o confusos para usuarios de lectores de pantalla como TalkBack.
En este artículo abordaremos cómo utilizar correctamente las descripciones de contenido (contentDescription en Android), explicando cuándo proporcionarlas, cuándo no hacerlo y cómo adaptarlas al contexto. Utilizaremos ejemplos reales implementados en el Accessibility Catalog para que puedas aplicar directamente estas ideas en tus propias aplicaciones.
Antes de empezar
Todas las pruebas de accesibilidad que se muestran aquí se han realizado utilizando TalkBack, el lector de pantalla más común en Android.
Los conceptos y las APIs descritas son a nivel de framework, por lo que aplican a cualquier servicio de accesibilidad en Android.
¿Qué es una content description?
Una descripción de contenido es una información textual alternativa que describe un elemento de la interfaz para tecnologías de asistencia.
Permite:
- Que los usuarios que utilizan lectores de pantalla entiendan qué representa un elemento
- Que los lectores de pantalla transmitan propósito, contexto o acción, no solo lo visual
En Android:
- Las Views utilizan android:contentDescription
- Compose utiliza contentDescription o Modifier.semantics {}
Pero simplemente añadir descripciones en todas partes no es suficiente — e incluso puede perjudicar la experiencia si se hace incorrectamente.
Empecemos
Imagina que tenemos una pantalla que contiene:
- Ilustraciones meteorológicas
- Iconos de acción
- Elementos decorativos
- Gráficos complejos
- Indicadores de estado
- Números de teléfono
Visualmente, todo parece claro. Pero, ¿cómo experimenta TalkBack esta pantalla?
Sin descripciones de contenido bien pensadas:
- Los iconos pueden anunciarse como “Imagen”
- Puede perderse información importante
- La información redundante puede leerse varias veces
- Los elementos decorativos pueden añadir ruido innecesario
1. Descripciones significativas para imágenes informativas
Si una imagen transmite información, debe tener una descripción significativa.
Ejemplo:
Resultado en TalkBack:
“Tiempo soleado con una temperatura de 30 grados”
Esto explica qué significa la imagen, no solo cómo se ve.
Evita descripciones genéricas como “Icono del tiempo” o “Imagen”.
Describe el valor informativo.
2. Los iconos accionables deben describir la acción
Los iconos que se usan como botones deben describir qué ocurre al activarlos, no el icono en sí.
Ejemplo:
Anuncio de TalkBack:
“Eliminar elemento. Botón.”
Regla:
Describe la acción, no lo visual.
Un aspa en el “Icono de cerrar”
Un check en “Eliminar elemento”
3. Las imágenes decorativas deben ignorarse
Si una imagen es puramente decorativa, no debe anunciarse en absoluto.
Ejemplo:
Resultado: TalkBack la ignora completamente.
Los elementos decorativos aportan estética, no información — así que mantén la experiencia accesible limpia.
4. Los gráficos complejos necesitan descripciones con contexto
Los gráficos e infografías a menudo no pueden entenderse visualmente con lectores de pantalla.
En lugar de describir formas o colores, resume el significado.
TalkBack:
“Gráfico de barras que muestra las ventas por trimestre”
Para datos muy complejos, considera:
- Una descripción resumida
- O una alternativa textual accesible cercana
5. Evita la redundancia con el texto visible
Uno de los errores más comunes es duplicar anuncios.
Evita:
[Icono: Eliminar] [Texto: Eliminar elemento]
Ambos elementos exponen la misma descripción de contenido → TalkBack lee “Eliminar elemento” dos veces.
Enfoque correcto: Agrupa la semántica
En Compose, es recomendable agrupar la semántica en el contenedor padre para evitar duplicidades o ruido en los anuncios de accesibilidad.
Existen dos enfoques según el nivel de control necesario:
Opción 1: Control explícito de la semántica
Cuando se necesita un control total sobre el resultado final (por ejemplo, para evitar duplicidades o redefinir completamente el mensaje), se puede limpiar la semántica de los hijos y definirla en el contenedor padre.
Resultado:
“Eliminar elemento”
Se anuncia una sola vez, de forma clara.
Opción 2: Uso de mergeDescendants
En casos más sencillos donde la semántica de los elementos hijos ya es correcta, se puede utilizar mergeDescendants = true para combinar automáticamente la información en un único nodo accesible.
Este enfoque es más conciso, pero depende de que la semántica de los hijos no genere duplicidades ni información innecesaria.
6. Descripciones adaptadas al contexto
Las descripciones deben adaptarse al estado o contexto.
Ejemplo: indicador de estado
TalkBack:
“Estado: en línea”
Sin contexto, un “punto verde” no significa nada para un lector de pantalla.
Nota: Aunque el contenido represente un “estado”, en este caso se usa contentDescription porque el elemento es una imagen sin semántica propia.
Veremos más adelante las stateDescription que se utilizan cuando el estado forma parte de un componente interactivo o con rol (por ejemplo, switches, checkboxes o elementos agrupados con texto).
7. Números de teléfono: mejora su lectura
Por defecto, TalkBack puede leer los números de teléfono como un único número largo.
Comportamiento por defecto
“Seiscientos cincuenta y seis millones setecientos…”
Mejora con contentDescription
TalkBack:
“6… 5… 6… 7… 8… 7… 4… 3… 4”
Mucho más claro y fácil de seguir.
Ideas clave
- Usa descripciones significativas y con contexto
- Describe qué hace un elemento, no cómo se ve
- No describas elementos decorativos
- Evita la redundancia con el texto visible
- Adapta las descripciones al estado y contexto
Para cerrar
Las content descriptions son un pequeño detalle con un impacto enorme en la accesibilidad.
Cuando se usan bien, convierten una interfaz visualmente rica pero inaccesible en una experiencia que todos pueden entender y disfrutar.
Este artículo se basa en una contribución real al Accessibility Catalog, donde puedes encontrar ejemplos completos en Compose y comparativas lado a lado de patrones correctos e incorrectos.
