Categoría: Desarrollo accesible

Artículos sobre desarrollo y programación accesible

Qué es el Inspector de accesibilidad de Firefox Developer Tools

Publicado el

El Firefox Accessibility Inspector es un panel especializado dentro de las herramientas de desarrollo del navegador que expone el llamado árbol de accesibilidad una estructura que representa cómo se presenta el contenido web a los agentes de asistencia, mostrando para cada nodo información como el rol, el nombre accesible, los estados, las relaciones y otros atributos ligados a la accesibilidad.

El  Accessibility Inspector está integrado en el navegador Mozilla Firefox y permite a los desarrolladores web examinar la forma en que las tecnologías de asistencia, como los lectores de pantalla, interpretan la estructura de una página web. Esta funcionalidad está disponible desde la versión 61 de Firefox.

Mediante este inspector, el desarrollador puede activar el motor de accesibilidad del navegador y desplazar un foco de inspección que muestra cómo un lector de pantalla “vería” o interpretaría un elemento concreto del sitio, o incluso la página en su conjunto.

Una de las funciones fundamentales del inspector es ofrecer una vista jerárquica del árbol de accesibilidad (accessibility tree), que difiere del árbol DOM en cuanto incluye únicamente los elementos expuestos a las tecnologías de asistencia. En esa vista, cada nodo presenta al menos dos propiedades clave: un rol (por ejemplo button, link, heading) y un nombre (que para los controles suele venir del texto de su etiqueta).

Además, cuando se selecciona un nodo, se muestra un panel con detalles más extensos: nombre, rol, acciones disponibles (por ejemplo “Press” para un botón), valor (en caso de un campo de entrada), DOM Node asociado, descripción, atajo de teclado, índices en el padre, conteo de hijos, estados (como focusable, enabled, selected), relaciones con otros nodos (por ejemplo “labelled by”), y atributos de accesibilidad relevantes o relacionados con ARIA (por ejemplo aria-label, aria-hidden, role, etc.).

La herramienta incluye utilidades de diagnóstico automatizado: permite activar un análisis de “Check for issues” (verificar problemas) que scaneará toda la página en busca de diferentes tipos de fallos contraste de color insuficiente, problemas de navegación mediante teclado, etiquetas de texto faltantes y resaltará únicamente los nodos que presentan esos problemas. Además, el inspector permite simular deficiencias de visión de color (simulación de daltonismo) o mostrar la orden de tabulación de los elementos. Todo ello ayuda al desarrollador a comprender y corregir cómo una página estaría siendo percibida por personas que utilizan lectores de pantalla u otros dispositivos de asistencia, lo cual es esencial para asegurar que el HTML semántico, el uso de ARIA y la estructura del contenido soporten una experiencia inclusiva.

Google Lighthouse como herramienta de evaluación de la accesibilidad

Publicado el

Google Lighthouse es una herramienta automatizada de auditoría integrada en el navegador Google Chrome, diseñada para evaluar diversos aspectos de calidad en cualquier página web, desde el rendimiento y la optimización para motores de búsqueda hasta ciertos criterios fundamentales de accesibilidad.
Lighthouse forma parte del ecosistema de herramientas de Google orientadas al análisis y diagnóstico web.
Esta herramienta se ejecuta desde las DevTools de Chrome, desde la línea de comandos o mediante su versión en línea, y proporciona informes detallados que permiten comprender el estado técnico de un sitio web.
El funcionamiento de Lighthouse se basa en la recopilación estructurada de métricas relacionadas con la carga, la estabilidad visual, el procesamiento del contenido y los metadatos de la página. En el ámbito del rendimiento, la herramienta mide el tiempo de interacción, de renderizado y la eficiencia en el uso de recursos; en el ámbito del SEO, analiza la correcta estructuración de elementos fundamentales para la indexación, como etiquetas meta, atributos descriptivos o la accesibilidad del contenido para los robots de búsqueda.
Además, la sección de accesibilidad realiza una serie de comprobaciones técnicas que identifican ciertos problemas habituales como la falta de texto alternativo, la insuficiente estructura semántica o la ausencia de etiquetas asociadas a controles interactivos.

Es importante señalar que, aunque Lighthouse incorpora una auditoría de accesibilidad basada en reglas automatizadas, su fiabilidad es limitada cuando se interpreta como un verificador exhaustivo de barreras de accesibilidad. La herramienta detecta únicamente una parte de las barreras existentes, aquellas que pueden evaluarse de forma automática sin intervención humana. Aspectos esenciales como la claridad de las descripciones alternativas, la adecuación de la estructura lógica del contenido, la comprensibilidad de los textos, la calidad de la interacción mediante teclado o la experiencia global de usuarios con diversas discapacidades requieren un análisis manual basado en las pautas WCAG. Por esta razón, Lighthouse no puede considerarse una herramienta específica para la mejora integral de la accesibilidad web, sino un complemento orientado a la detección preliminar de problemas comunes y al apoyo en procesos de auditoría más amplios.

A pesar de estas limitaciones, los resultados proporcionados por Lighthouse ofrecen valor en procesos de diseño y desarrollo, ya que permiten identificar rápidamente fallos críticos que afectan a la experiencia de usuario, al posicionamiento en buscadores y al rendimiento general del sitio. La interpretación de sus métricas debe realizarse de manera contextualizada, entendiendo que sus diagnósticos no sustituyen a una revisión profesional de accesibilidad ni a pruebas con usuarios reales, pero sí constituyen una base inicial para orientar esfuerzos de optimización y asegurar un nivel mínimo de calidad técnica.

Color Asset Creator

Publicado el

La gestión de colores en proyectos para iOS, iPadOS, macOS o visionOS ha evolucionado mucho en los últimos años. Apple introdujo los color assets como parte de los catálogos de recursos de Xcode, ofreciendo una forma estructurada y escalable de definir la paleta de una aplicación. Sin embargo, la interfaz gráfica actual de Xcode para crear y editar estos recursos presenta graves problemas de accesibilidad para desarrolladores ciegos.

La gestión de colores desde la interfaz gráfica de XCode implica interactuar con controles visuales complejos, selectores de color, paneles flotantes y zonas de arrastre que no siempre exponen correctamente su información a las APIs de accesibilidad. Esto provoca dificultades a la hora de crear o modificar conjuntos de colores o de definir comportamientos en los conjuntos creados.

Con el proyecto Color Asset Creator se propone una solución concreta: una extensión de Xcode diseñada específicamente para crear color assets de forma accesible, aprovechando una interfaz basada en código y controles estándar que sí son compatibles con tecnologías de apoyo.

En lugar de depender del panel visual de Xcode, la extensión ofrece una interfaz basada en formularios y controles estándar que se integran con VoiceOver y con el resto de tecnologías de apoyo. De este modo, un desarrollador ciego puede definir un nuevo color con nombre de forma estructurada, introducir los valores de sus componentes de color mediante campos de texto y controles accesibles y generar los ficheros y entradas necesarias en el catálogo de recursos del proyecto.

Qué son los color assets en Xcode

En XCode, los catálogos de recursos (asset catalogs) permiten agrupar imágenes, colores, símbolos y otros elementos bajo una estructura común, normalmente en ficheros Assets.xcassets. Dentro de estos catálogos, los color assets son definiciones de color con nombre que pueden utilizarse en cualquier parte de la app, tanto en código como en interfaces visuales.

En lugar de definir colores “al vuelo” con valores RGB o hexadecimales dispersos por el código, los color assets permiten centralizar la paleta en un único lugar. Cada entrada de color se guarda como un conjunto (.colorset) con su correspondiente definición interna, tal y como describe la documentación oficial de Apple sobre los tipos de color.

Estos color assets pueden adaptarse a diferentes condiciones: por ejemplo, ofrecer variantes específicas para modo claro y modo oscuro, o para distintos espacios de color. De este modo, el mismo nombre de color se ajusta automáticamente según el contexto visual del sistema, lo que facilita la creación de interfaces coherentes, accesibles y visualmente consistentes.

Participación en A11yConf 2025 sobre Accesibilidad práctica en SwiftUI

Publicado el

El próximo 29 de noviembre se celebrará una nueva edición de A11yConf, la conferencia de referencia en el mundo hispanohablante dedicada íntegramente a la accesibilidad digital.
El evento reunirá a profesionales del diseño, el desarrollo, la investigación y la comunicación comprometidos con la creación de experiencias digitales inclusivas.
A11yConf es un punto de encuentro fundamental para quienes creemos que la accesibilidad no es un añadido, sino una parte esencial del diseño y desarrollo responsable. Asistir al evento es una oportunidad para aprender de referentes del sector, descubrir nuevas perspectivas y reforzar el compromiso colectivo con la inclusión digital.

Toda la información sobre el programa, los ponentes y las inscripciones están disponible en la web oficial del evento.

Accesibilidad y SwiftUI

En esta edición participaré con una charla práctica sobre la resolución de barreras de accesibilidad en interfaces desarrolladas con SwiftUI. Durante la sesión se mostrarán ejemplos reales y técnicas concretas para la detección y solución de problemas de accesibilidad en aplicaciones para iPhone, iPad, Mac y otros dispositivos del ecosistema Apple.

La ponencia abordará desde los errores más comunes que aparecen en componentes visuales y gestuales hasta estrategias avanzadas para ofrecer una experiencia completa a personas usuarias de VoiceOver, braille y tecnologías de asistencia.

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 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.