Entradas

Congreso PyConES 2025 y accesibilidad para Python

Publicado el

Del 17 al 19 de octubre se celebrará en Sevilla una nueva edición de PyConES, la gran conferencia anual de la comunidad Python en España. Tres días intensos repletos de charlas técnicas, talleres, networking y, este año, también un espacio para la accesibilidad digital, un tema que debería ser parte esencial de cualquier evento tecnológico.
PyConES es mucho más que una conferencia técnica. Es un lugar de encuentro donde la comunidad se reúne para aprender, compartir experiencias y construir juntos el futuro del ecosistema Python.
Este año, la ciudad de Sevilla será el escenario perfecto para acoger a desarrolladores, empresas y entusiastas de todo el país (y más allá), en un ambiente abierto y colaborativo.

Accesibilidad en el evento

En el evento participaré con la charla titulada Accesibilidad e interfaces con Python, libres para codificar y libres para usar en la que mostraré técnicas básicas para crear interfaces de usuario con QT y WX que incorporen accesibilidad.

Código de programación más accesible con SIMAE

Publicado el

En el mundo de las tecnologías de apoyo para personas con discapacidad visual, pocas iniciativas resultan tan innovadoras y útiles como SIMAE, el Sistema de Marcado Estructural de Código Fuente para Programadores con Discapacidad Visual. Desarrollado en la UTN Facultad Regional Santa Fe, este proyecto de I+D está pensado para brindar contexto y estructura al código, aumentando la accesibilidad para quienes dependen de lectores de pantalla.

SIMAE nace en 2016, cuando un alumno ciego ingresó en Ingeniería en Sistemas. La necesidad de facilitar su experiencia de aprendizaje motivó a docentes e investigadores a diseñar una herramienta que transformara la forma de programar en algo más accesible.

Su función principal es insertar información contextual en el código fuente, para ello incorpora información extra en la semántica del código. Por ejemplo, se agregan marcadores para señalar el comienzo y fin de bloques buscando ayudar a ubicarse al programador dentro del código; una extensión para VSCode que permite detectar las marcas semánticas en los hints del código y utilizar atajos de teclado especiales para moverse por la estructura del código.

Soporta múltiples lenguajes (C++, Java, Python y también C#) y funciona en español e inglés.

Este proyecto demuestra que las tiflotecnologías pueden elevar significativamente la experiencia de programación para personas con discapacidad visual. Al convertir el código en algo estructurado y navegable —no solo visible—, la herramienta abre caminos hacia una programación más autónoma, inclusiva y eficiente. Su enfoque dual (standalone y extensión) ofrece flexibilidad según el entorno de trabajo del usuario.

Herramientas y Estrategias para Crear Apps Accesibles en Android e iOS

Publicado el

El desarrollo de aplicaciones móviles se ha convertido en una de las áreas más dinámicas e innovadoras de la industria del software. Este sector exige unos tiempos de actualización y publicación de nuevas aplicaciones muy elevado. Esto provoca que, en muchos casos, la accesibilidad sea una de las características perjudicadas en los productos publicados.
Una aplicación puede ser visualmente atractiva, contar con funciones avanzadas y ofrecer un rendimiento impecable, pero si no es usable para personas con discapacidad, estará dejando a un sector de la población fuera de la experiencia digital.

Accesibilidad desde la base del dispositivo

Los sistemas operativos para dispositivos móviles han dado pasos decisivos para que los desarrolladores tengan a su disposición herramientas de accesibilidad integradas desde el inicio. En el caso de Android, TalkBack es el lector de pantalla oficial que permite a los usuarios interactuar con la interfaz mediante gestos y mediante una comunicación por voz o braille, conocer qué aparece en la pantalla del dispositivo. En iOS, VoiceOver cumple esa función con un enfoque similar, basado en gestos multitáctiles y una navegación estructurada similar a la presentada en Android. Estos lectores no solo son esenciales para las personas ciegas, también se convierten en el punto de partida para que cualquier desarrollador entienda cómo se percibe su aplicación sin ver la pantalla.

El reto de desarrollar interfaces de usuario accesibles

Pensar en la interfaz no solo como un conjunto de imágenes y botones visibles, sino como una estructura semántica que se transforma en una experiencia navegable, coherente y predecible mediante voz o braille. Para lograrlo, es fundamental aprovechar correctamente los roles de accesibilidad que ofrecen los frameworks nativos. En SwiftUI, por ejemplo, existen modificadores que permiten etiquetar elementos y proporcionarles un texto descriptivo con accessibilityLabel, agrupar componentes o describir cambios dinámicos en la interfaz para que VoiceOver pueda transmitir toda la información de la pantalla al usuario ciego. En Android, el uso adecuado de contentDescription, AccessibilityNodeInfo y las API de Jetpack Compose garantizan que cada control comunique su función de manera clara a TalkBack.

Pero la accesibilidad no se limita a etiquetas de texto. También implica asegurar que la navegación por gestos sea lógica, que los botones tengan un tamaño adecuado para ser pulsados, que los contrastes de color cumplan los estándares y que las animaciones no generen barreras. Una interfaz sobrecargada de elementos visuales puede ser un obstáculo insuperable si no se acompaña de una estructura semántica que guíe al lector de pantalla.

Probar el producto

Las pruebas son otro aspecto crucial para la accesibilidad. Así como se prueban la usabilidad o el rendimiento, es necesario integrar pruebas de accesibilidad en el ciclo de desarrollo. Probar la aplicación con TalkBack y con VoiceOver no debe ser una tarea secundaria ni un “extra” antes de la publicación, sino un paso constante que permita detectar fallos antes de que lleguen a los usuarios. Existen además validadores automáticos, como Accessibility Scanner en Android o las auditorías de Xcode en iOS, que ayudan a identificar problemas comunes de forma temprana.

La accesibilidad en el equipo

Crear aplicaciones accesibles también implica cambiar la mentalidad del equipo de desarrollo y diseño. No se trata solo de cumplir con normativas como las WCAG, sino de pensar en la diversidad de personas que van a usar la aplicación. Una pantalla que puede parecer intuitiva para alguien que puede ver puede ser confusa si los elementos no están correctamente etiquetados o si el flujo de navegación es poco claro. Del mismo modo, un gesto complejo puede convertirse en una barrera para personas con movilidad reducida o que no puedan intuir el comportamiento necesario para utilizar la aplicación.

El equipo, además, tiene que comprender que la accesibilidad no es una carga, sino una oportunidad. Una app bien diseñada para ser inclusiva no solo beneficia a las personas con discapacidad visual, sino que también mejora la experiencia para otros colectivos: usuarios mayores, personas que utilizan el móvil en condiciones de baja visibilidad o incluso quienes prefieren interactuar con comandos de voz. La accesibilidad amplía el alcance del producto y refuerza la idea de que la tecnología debe estar al servicio de todos.

El reto del desarrollo de aplicaciones móviles accesibles es, en gran parte, un reto de empatía y de calidad. Quienes se enfrenten a él con seriedad descubrirán que las herramientas ya están disponibles y que, con buenas prácticas y compromiso, es posible construir experiencias digitales que no excluyan a nadie. Android y iOS ofrecen la base: depende de los desarrolladores aprovecharla para transformar sus proyectos en aplicaciones verdaderamente universales.

Cómo etiquetar imágenes y componentes visuales en Android con Content Description

Publicado el

En el desarrollo de aplicaciones para Android, la accesibilidad es un aspecto que no puede dejarse de lado. Uno de los errores más comunes en las interfaces de aplicaciones móviles es utilizar iconos o imágenes sin acompañarlos de una descripción accesible. Para los usuarios que dependen de TalkBack u otros lectores de pantalla, estos elementos pueden convertirse en barreras de accesibilidad muy severas si no cuentan con la información adecuada para identificar la funcionalidad de dichos botones o elementos visuales.

La propiedad contentDescription permite añadir una etiqueta textual a cualquier componente visual, de forma que TalkBack la anuncie en lugar de limitarse a leer un nombre técnico como “ic_send” o a ignorar la imagen por completo.

Ejemplo básico en XML

Un caso clásico es un botón con un icono de avión de papel que representa la acción de enviar un mensaje. Visualmente resulta evidente, pero sin descripción accesible no es comprensible para quien no puede ver la pantalla:

<ImageButton
  android:id="@+id/sendButton"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:src="@drawable/ic_send"
  android:contentDescription="Enviar mensaje" 
/>

En este ejemplo, TalkBack leerá “Enviar mensaje” al situarse sobre el botón, en lugar de un nombre de archivo técnico.

Ejemplo con Jetpack Compose

En Compose, la accesibilidad se maneja mediante modificadores de semántica. El equivalente a contentDescription sería:

IconButton(
  onClick = { /* Acción para enviar */ },
  modifier = Modifier.semantics { contentDescription = "Enviar mensaje" }
) {
  Icon(
    imageVector = Icons.Default.Send,
    contentDescription = null // Evitamos redundancia
  )
}

En este ejemplo el botón anuncia la etiqueta “Enviar mensaje” al interactuar con TalkBack. El icono interno no necesita contentDescription porque ya se ha definido en el contenedor.

Buenas prácticas

La propiedad contentDescription es sencilla de usar, pero conviene aplicarla con criterio:

  1. Priorizar la función: un icono de engranaje para un botón para ir a los ajustes de la app no debería describirse como “rueda dentada”, sino como “Ajustes”, que es la acción real.
  2. Ser breve y claro: descripciones cortas facilitan la navegación. Un botón que abre un chat debe decir “Abrir chat”, no “Icono de burbuja de diálogo para iniciar conversación”.
  3. Evitar redundancias: si un TextView ya tiene texto visible, no es necesario repetirlo en contentDescription. TalkBack lo leerá automáticamente.
  4. Ocultar lo decorativo: para imágenes que solo son decorativas, se debe establecer android:contentDescription=»@null» en XML o contentDescription = null en Compose. De esta forma TalkBack las ignora.

Etiquetar adecuadamente los componentes visuales no solo es una buena práctica de desarrollo, sino un compromiso con la inclusión digital. Al igual que ocurre con cualquier aspecto del diseño, dedicar unos segundos a escribir una descripción accesible marca la diferencia entre una app usable y otra que excluye a parte de sus usuarios. La propiedad contentDescription es una de las herramientas más simples y a la vez más poderosas que Android pone en manos de los desarrolladores para mejorar la accesibilidad. Añadir una descripción clara y precisa a imágenes e iconos garantiza que los usuarios con lectores de pantalla comprendan e interactúen con la interfaz en igualdad de condiciones.

Cómo etiquetar imágenes y componentes visuales en iOS y MacOS con SwiftUI

Publicado el

El desarrollo de interfaces con SwiftUI ofrece muchas ventajas en simplicidad y expresividad, pero también implica una responsabilidad clara: garantizar que todos los componentes sean accesibles. En este sentido, el modificador accessibilityLabel juega un papel fundamental, ya que permite proporcionar descripciones comprensibles para los usuarios que navegan mediante VoiceOver u otros productos de apoyo.

En una aplicación móvil, es habitual encontrar botones representados solo con iconos, imágenes decorativas o gráficos complejos que transmiten información de manera visual. Si estos elementos no cuentan con una etiqueta accesible, el lector de pantalla se limitará a leer su nombre interno —por ejemplo, “paperplane.fill”— o incluso no los anunciará, lo que genera una experiencia frustrante y excluyente.

El modificador accessibilityLabel resuelve este problema al ofrecer un texto alternativo que describe la función o el significado del elemento. La idea es que, al interactuar con el componente, VoiceOver verbalice la etiqueta definida en lugar del nombre interno o el contenido gráfico.

Ejemplo básico

Un caso típico es un botón con un icono de avión de papel para enviar un mensaje. Visualmente resulta evidente, pero sin una etiqueta accesible el usuario ciego no comprendería su propósito:

Button(action: {
// Acción para enviar
}) {
Image(systemName: "paperplane.fill")
.font(.largeTitle)
}
.accessibilityLabel("Enviar mensaje")

Al añadir .accessibilityLabel(«Enviar mensaje»), VoiceOver anuncia esa frase, y la acción del botón se vuelve comprensible y usable para todas las personas.

Además, no sólo se benefician los usuarios ciegos, también el sistema de Voice control para iOS y MacOS utilizará ese texto para localizar el botón y poderlo pulsar de forma más cómoda para el usuario.

Más allá de los iconos

El uso de accessibilityLabel no se limita a los botones. También puede aplicarse a imágenes que transmiten información importante. Una fotografía, un logotipo o un gráfico que refuerce la identidad de una app debería llevar una etiqueta adecuada.

Image("company_logo")
.resizable()
.frame(width: 120, height: 120)
.accessibilityLabel("Logotipo de la empresa Ejemplo")

En este caso, el lector de pantalla transmitirá la descripción de la imagen en lugar de identificar un elemento inaccesible o verbalizar el nombre del fichero del logotipo de la empresa.

Buenas prácticas

La potencia de accessibilityLabel reside en su sencillez, pero eso no significa que se deba aplicarlo sin reflexión. Es importante tener en cuenta algunas recomendaciones:

  1. Claridad antes que detalle: las etiquetas deben ser breves y concretas. No conviene describir minuciosamente una imagen si con dos palabras es suficiente para transmitir la idea.
  2. Función antes que forma: en un botón, es más importante describir la acción que detallar el icono. Por ejemplo, “Abrir ajustes” comunica más que “Engranaje”.
  3. Evitar redundancias: si un elemento ya tiene un texto visible, añadir un accessibilityLabel idéntico puede resultar repetitivo. En esos casos, lo mejor es dejar que VoiceOver lea directamente el texto.
  4. No etiquetar lo decorativo: si una imagen es meramente estética y no aporta información, lo correcto es marcarla como ignorada con .accessibilityHidden(true).

Etiquetar imágenes y componentes visuales no es un añadido opcional, sino un paso esencial para construir apps accesibles, usables y respetuosas con la diversidad de las personas que las utilizan. El modificador accessibilityLabel es un elemento sencillo y que ayuda a solucionar barreras severas de accesibilidad con un mínimo esfuerzo. Con unas pocas líneas de código, es posible transformar una interfaz visual en una experiencia inclusiva, asegurando que todos los usuarios, independientemente de cómo interactúen con su dispositivo, comprendan y disfruten la aplicación.

La inteligencia artificial como aliada para los programadores ciegos

Publicado el

La inteligencia artificial está transformando la forma en que se desarrolla el software. Desde hace unos años, el auge de los modelos de lenguaje y de las herramientas de autocompletado inteligente ha abierto nuevas posibilidades que van mucho más allá de la simple ayuda para escribir código más rápido.

Para una persona ciega que se dedica a programar, estas tecnologías representan no solo un aumento de productividad, sino un refuerzo de autonomía y acceso a recursos que antes resultaban más costosos de alcanzar.

Uno de los ámbitos donde la IA muestra mayor potencial es en la asistencia al escribir código. Los asistentes de programación, integrados ya en entornos como Visual Studio Code, Xcode o Android Studio, permiten recibir sugerencias de código completas que se adaptan al contexto de lo que se está escribiendo. Esto reduce el tiempo invertido en consultar la documentación del lenguaje y la plataforma así como el esfuerzo extra en la memorización de esta información.

La Inteligencia artificial también está entrando en el terreno de la depuración de código. Existen herramientas capaces de analizar un bloque de código y proponer explicaciones de por qué falla una prueba, dónde puede estar el error lógico o qué cambios podrían mejorar su rendimiento. Para un programador ciego, este acompañamiento supone un ahorro de tiempo, pero también un refuerzo pedagógico. Además, en muchos casos, las herramientas de depuración habituales resultan inaccesibles para las personas ciegas por problemas de accesibilidad en estas herramientas de depuración. Poder obtener una idea o una explicación de por qué está fallando algo puede ayudar al proceso de depuración de bloques de código.

La documentación es otro frente donde la inteligencia artificial está marcando la diferencia. Generar comentarios, crear documentación técnica a partir de funciones o clases, traducir explicaciones a varios idiomas o resumir artículos largos son tareas que, integradas en el flujo de desarrollo, facilitan la comunicación con otros equipos y el mantenimiento de los proyectos.

Falta de accesibilidad en la Inteligencia artificial

Aunque la aparición de estas herramientas, aparentemente, impliquen beneficios para todos los programadores, en realidad estas herramientas presentan un problema común para mucho del software utilizado para trabajar. Este problema es la falta de accesibilidad. En muchos casos estas herramientas integradas en los entornos de desarrollo utilizan componentes visuales o un lenguaje visual que resulta inaccesible para lectores de pantalla o, en otros casos, no existe la posibilidad de controlar las funciones de estas herramientas de autocompletado de código desde el teclado. Esto hará que el catálogo de entornos de desarrollo disponible para las personas ciegas se reduzca ya que, en un futuro, no sólo se tendrá que observar si el editor de código o los botones del entorno de desarrollo son accesibles, también se deberá observar si la forma en que el asistente de autocompletado de código es accesible.

En muchos casos, poco a poco, gracias al feedback de los programadores ciegos que notifican a los responsables de estos entornos de desarrollo de los problemas de accesibilidad, las herramientas de autocompletado van siendo un poco más accesible cada día. El problema es el de siempre: pocos programadores ciegos reportan y ayudan a hacer más accesibles los entornos de desarrollo y las herramientas que los acompañan.

La solución está en la personalización

La capacidad de muchas herramientas de poder personalizar distintos aspectos visuales y comportamientos permiten superar, en muchos casos, la falta de accesibilidad de estas herramientas. Poder asignar un atajo de teclado a una función de la herramienta de autocompletado o personalizar los colores de la pantalla de visualización para que las funciones de OCR del lector de pantallas puedan identificar cual es la zona del editor y cual es la zona de la recomendación facilita la identificación de estos elementos.

En cualquier caso estos son parches para la falta de una accesibilidad plena y completa en estas herramientas. Los programadores ciegos debemos seguir aportando feedback y reclamando accesibilidad para estos elementos del desarrollo de software.

El futuro para la programación

No debemos olvidar que la IA no sustituye la necesidad de criterio propio. La dependencia excesiva de las sugerencias puede llevar a errores invisibles, y la accesibilidad de estas herramientas aún tiene un largo camino por recorrer. Las interfaces gráficas, los atajos de teclado mal diseñados o la falta de descripciones adecuadas en los resultados pueden generar barreras nuevas. Por eso, la adopción de la IA debe ir acompañada de una mirada crítica y de una exigencia a los proveedores de que sus soluciones sean inclusivas desde el diseño.

Además, muchas de las soluciones propuestas para el código no incluyen atributos o elementos de accesibilidad. Sería muy irónico que un programador ciego desarrollase interfaces de usuario con problemas de accesibilidad por limitar su trabajo a copiar el código propuesto por una Inteligencia artificial sin prestar ni revisar el código propuesto por la herramienta.