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

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

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

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

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 asociación CINTAC

La Asociación CINTAC (Centro de Innovación de Tecnologías Accesibles) es una entidad sin ánimo de lucro de ámbito nacional fundada en 2020 que tiene el propósito de impulsar la tecnología social y promover tecnologías accesibles e inclusivas.

Misión

Su objetivo principal es generar un beneficio social y económico sostenible facilitando el acceso a productos, servicios y entornos tecnológicos a todas las personas.

Visión

Esta asociación aspira a ser un referente nacional en la creación y adaptación de tecnologías inclusivas para personas con discapacidad o limitaciones funcionales.

Ámbitos de actuación

CINTAC trabaja en diversos frentes para alcanzar sus metas:

A través de contenidos, eventos y colaboraciones, promueve la importancia de la accesibilidad tecnológica.

También organiza jornadas, congresos y talleres sobre accesibilidad TIC, usabilidad e innovación social.

Estudia e impulsa la implementación de herramientas accesibles, generando conocimiento aplicado.

Ha establecido alianzas con entidades y grupos empresariales para mejorar la accesibilidad en todos los ámbitos de la empresa.

Miembros de la asociación

CINTAC es claramente multisectorial y multidisciplinar, integrada por ingenieros, programadores, diseñadores y expertos en comunicación, ciberseguridad, Big Data y accesibilidad.

Cuenta también con asociados corporativos y corporativo plus, lo que permite a empresas y profesionales unirse bajo diferentes categorías.

La asociación ofrece una plataforma para apoyar a la sociedad mediante proyectos adecuados a personas con discapacidad, integrar la accesibilidad como valor diferencial competitivo, estar al día en normativas, buenas prácticas y tecnología accesible. Esta plataforma está enfocada en profesionales o empresas del sector TI, RRHH o diseño de servicios

Para usuarios u organizaciones interesadas en accesibilidad, CINTAC es un centro de referencia, recursos y comunidad comprometida.

Cómo asociarse

La asociación ofrece distintas categorías de membresía, adaptadas tanto a profesionales individuales como a empresas.

Ser socio brinda acceso a formación especializada, eventos, grupos de trabajo y una red de contactos en el área de la accesibilidad tecnológica.

Puedes asociarte a CINTAC a través de su portal web.

Nueva generación de herramientas automáticas de validación de la accesibilidad gracias a la inteligencia artificial

Las herramientas automáticas para la validación de barreras de accesibilidad, aunque conocidas sus limitaciones, son indispensables para las personas que diseñan y desarrollan interfaces digitales. Es conocido que la mayoría de estas barreras sólo pueden evaluar menos del 40% de los criterios de éxito de WCAG y que, en su evaluación, tampoco hay una precisión demasiado elevada.

La Inteligencia Artificial al rescate

Gracias a los últimos avances en la creación de modelos expertos con IA hay empresas como Evinced, que apuestan por el desarrollo de mejores herramientas, hoy podemos decir que tenemos a nuestra disposición la siguiente generación de las herramientas automáticas para la validación de la accesibilidad.

En algunos casos la mejora parece bastante evidente como sucede con Site scanner, una herramienta para analizar las barreras de accesibilidad en un sitio web de forma global ofreciendo resultados agrupados por componentes o incluso zonas que requieran de un usuario y contraseña. Lo interesante de esta herramienta es que, según sus creadores, pueden validar el 80% de los criterios de éxito y los resultados son más fiables. Por ejemplo, que una imagen tenga una cadena de texto ya no es suficiente para validar ese criterio de éxito, la descripción también debe ser algo comprensible y no el nombre del fichero del archivo de imagen.

Otra diferencia importante es que pueden analizar el contenido y la funcionalidad del renderizado del DOM (Document Object Model) por lo que algunos problemas de accesibilidad no visibles para Wave o AXE debido al uso de ReactJS o Angular si son detectados por esta nueva generación de herramientas.

La accesibilidad no sólo es Web

Las Web Content Accessibility Guidelines (WCAG) también se aplican a las aplicaciones de los smartphones pero las herramientas de automatización de experiencias son pocas y casi ninguna incluye alguna herramienta de validación de la accesibilidad de forma fiable ya que, en muchos casos, el acceso al dispositivo móvil se realiza mediante capturas de pantalla, perdiendo el acceso a la capa semántica de las aplicaciones móviles.

  El Automation SDK de Evinced se integra con los tests automatizados de Selenium, Cypress, Playwright, XCUITest o Appium para dar ese extra para poder evaluar las posibles barreras de accesibilidad en una web o una app móvil.

Accesibilidad desde el diseño

Los diseñadores de contenidos o de experiencia de usuario, en muchos casos, utilizan aplicaciones como Figma para hacer ese diseño de experiencia de una web o una app móvil. Aunque este tipo de herramienta ofrecen algunos plugins relacionados con la accesibilidad, todos ellos son de ejecución manual y, cuando el frame de diseño de un proyecto es demasiado grande, hay muchas posibilidades de que haya componentes o flujos que se hayan quedado sin evaluar.

Con el plugin de Design Assistant para Figma se promete una evaluación automatizada de todos los elementos del proyecto y aplicando los evaluadores mejorados con IA se ofrece la detección y corrección de problemas de contraste de color, problemas de foco y zonas táctiles, flujos ARIA y otras validaciones de criterios de éxito de WCAG.

Además este plugin ofrece la posibilidad de incluir notas para los desarrolladores para que durante la implementación del diseño se incluyan las soluciones a las barreras de accesibilidad y ejemplos para diseñar tests unitarios.

Los desarrolladores también tienen más herramientas

Las herramientas de desarrollo de Google Chrome pueden mejorarse gracias a Debugger, una extensión para este navegador que usando IA mejora la detección de errores de contraste de color o de navegación por teclado y también mejora la detección de problemas con etiquetas de accesibilidad. Además proporciona ejemplos para solucionar los problemas detectados.

En el apartado para el CI/CD (Integración continua y distribución continua) Evinced ofrece Unit Tester, una herramienta automática para crear tests para la validación de criterios de éxito WCAG 2.1 nivel AA para problemas de roles, teclado y lectores de pantalla.

Se puede integrar de forma sencilla en los pipelines de Jenkins, Travis o CircleCI.

Conclusiones y realidades

Esta empresa ofrece otras herramientas para el apoyo de diseñadores, testers, desarrolladores y analistas. Todo enfocado en la detección y solución de barreras de accesibilidad.

Como con cualquier solución automática, no reemplaza la evaluación manual ni pruebas con usuarios reales con discapacidad. La experiencia final de un usuario es la única prueba que validará la accesibilidad al 100%. Estas herramientas ayudan a los profesionales a poder mejorar su trabajo y, de forma voluntaria o involuntaria, hacer que todo sea más accesible.

El desconocimiento de la accesibilidad es el primer problema que tiene el mundo de la accesibilidad digital. Muchos profesionales del diseño o el desarrollo usan sus herramientas de trabajo sin molestarse en comprender que hay elementos técnicos que se salen de su tecnología de trabajo. Gracias a estas herramientas esos profesionales tienen un contacto con la accesibilidad de forma más cómoda, guiada y no les exige un esfuerzo inicial de aprendizaje. Lo toman como algo a solucionar en su trabajo y siguen los consejos e indicaciones de la IA para solucionar ese problema de accesibilidad.

Estas herramientas siguen en desarrollo y están abiertas a mejora ya que todavía hay casos complejos de accesibilidad que la IA no sabe resolver. Además, por ahora, sólo se da soporte para contenidos en inglés.

Lo interesante de este conjunto de herramientas es que el enfoque se aplica a todos los sectores relacionados con un proyecto web o una app móvil. La responsabilidad de la accesibilidad no recae en un único profesional. Con estas herramientas todos los profesionales, desde el diseñador al desarrollador y el tester tienen contacto con la accesibilidad. Esto maximiza la posibilidad de que la mayor cantidad posible de barreras de accesibilidad sean detectadas y solucionadas antes de que el producto sea puesto a disposición de los usuarios. Un enfoque interesante y muy alineado con el concepto de que la accesibilidad debe aplicarse a todas las etapas de un proyecto.

Esperemos que pronto veamos que este tipo de herramientas automáticas mejoran el trabajo de muchos profesionales y facilitan que la accesibilidad sea parte real de los proyectos.