Qué son los puntos activos de VoiceOver en macOS

VoiceOver, el lector de pantallas de Apple, ofrece distintas formas de explorar la interfaz gráfica de usuario. Pero, principalmente, la forma de exploración consiste en mover el foco de VoiceOver por la pantalla o hacer que ese foco siga al foco del teclado, del ratón o del sistema.

Pero a veces podemos querer observar una zona de la pantalla o volver a esa zona aunque estemos trabajando en otra zona de la pantalla. VoiceOver también nos permite hacer esto gracias a los puntos activos.

Un punto activo permite marcar un elemento de la pantalla para volver a él directamente más tarde. En lugar de recorrer toda una ventana hasta llegar a un botón, una tabla, una barra de herramientas o una zona concreta de una aplicación, se puede asignar ese elemento a un número y después saltar a él con un comando de teclado. Apple indica, por ejemplo, que se puede asignar un punto activo al botón de mensaje nuevo en Mail para acceder directamente a ese botón siempre que la aplicación esté abierta.

Qué es un punto activo

Un punto activo de VoiceOver es una referencia rápida a un elemento de la interfaz. No modifica la aplicación, no crea un acceso directo del sistema ni cambia la estructura de la ventana. Simplemente permite que VoiceOver recuerde un elemento para poder volver a él cuando lo necesitemos.

La idea se parece a colocar un marcador en una página. Cuando navegamos por una aplicación compleja, hay elementos a los que volvemos una y otra vez. Puede ser un botón, una lista de resultados, una zona de mensajes, un campo de búsqueda o un control cuyo valor cambia. Si ese elemento queda asociado a un punto activo, VoiceOver puede ofrecer nuevos mecanismos de navegación para consultar o saltar a ese marcador.

El uso más evidente de un punto activo es volver rápidamente a un elemento. Si una persona trabaja con una aplicación durante mucho tiempo y necesita acceder de forma constante a una zona concreta, puede marcarla y regresar a ella con una pulsación.

Pero la función no se limita a la navegación. Apple también indica que, si el punto activo se asigna a un elemento cuyo estado o valor puede cambiar, VoiceOver puede utilizarlo para controlar ese elemento sin necesidad de que el foco esté situado en él.

Esto permite vigilar determinados cambios mientras se trabaja en otra parte de la pantalla. Por ejemplo, puede ser útil en zonas donde aparece información de progreso, estados de conexión, contadores, resultados o valores que se actualizan. No todos los elementos serán igual de útiles para este uso, pero la posibilidad existe y conviene conocerla.

También hay un detalle importante en tablas, listas y áreas web. Cuando se va a un punto activo situado en uno de esos elementos, VoiceOver permite interactuar inmediatamente con él, sin necesidad de introducir un comando adicional para iniciar la interacción.

Cuántos puntos activos se pueden configurar

VoiceOver permite configurar hasta diez puntos activos. Cada punto se identifica mediante un número. Por tanto, se pueden tener puntos activos del 0 al 9 o del 1 al 10 según la disposición del teclado y la forma en la que se introduzcan los comandos.

Si se utilizan actividades de VoiceOver, se pueden configurar hasta diez puntos activos para cada actividad. Esto es relevante porque las actividades permiten tener configuraciones diferentes según la aplicación o el contexto de uso. En la práctica, una persona podría tener un conjunto de puntos activos para navegar por una aplicación concreta y otro conjunto distinto para otra actividad.

Esta separación evita que una configuración tenga que servir para todo. Una misma tecla puede llevar a un punto activo distinto dependiendo del contexto en el que se esté trabajando, siempre que se haya organizado mediante actividades.

Cómo crear un punto activo

Para crear un punto activo, primero hay que situar el cursor de VoiceOver sobre el elemento que se quiere marcar. Después se pulsa VO + Mayúsculas + número de punto activo. Por ejemplo, si queremos asignar el punto activo 1 al elemento actual, se coloca VoiceOver sobre ese elemento y se pulsa VO + Mayúsculas + 1.

Si ese número ya estaba asignado a otro elemento, la nueva asignación sustituye a la anterior. VoiceOver no pregunta para conservar el punto anterior.

Cómo ir a un punto activo

Una vez creado el punto activo, se puede volver a él pulsando VO + número de punto activo. Por ejemplo, si el punto activo 1 está asociado a una lista de mensajes, VO + 1 llevará el cursor de VoiceOver a esa lista.

También existe un selector de punto activo. Se abre con VO + Mayúsculas + X y permite seleccionar uno de los puntos activos configurados. Esta opción puede ser muy útil cuando no podemos recordar qué número se asignó a cada elemento o cuando se prefiere explorar los puntos disponibles antes de saltar a uno de ellos.

Cómo saber qué hay en un punto activo

VoiceOver permite escuchar una descripción de un punto activo pulsando VO + Comando + número de punto activo. Este comando no sirve para ir al punto, sino para obtener información sobre él.

Cuando se utilizan varios puntos activos conviene poder comprobar qué contiene cada uno sin cambiar inmediatamente de posición. De esta forma podemos consultar la información de la barra de estado de una aplicación, el mensaje de procesamiento o estado de la barra de tareas sin necesidad de mover el foco de VoiceOver del punto donde estemos trabajando.

Cómo escuchar cambios en un punto activo

Una de las funciones más interesantes de los puntos activos es la posibilidad de escuchar cambios de valor. Para activar o desactivar esta vigilancia se utiliza VO + Comando + Mayúsculas + número de punto activo. Apple lo describe como el comando para escuchar cambios de valor en un punto activo y señala que, para dejar de escuchar esos avisos, se vuelve a pulsar el mismo comando.

Este comportamiento puede ser útil cuando una parte de la interfaz cambia mientras estamos trabajando en otra. Por ejemplo, una zona de estado puede informar de un progreso, una lista puede actualizarse, o un control puede cambiar de valor. En lugar de volver constantemente a comprobarlo, VoiceOver puede avisar cuando detecte cambios en ese punto activo.

Cómo eliminar un punto activo

Para eliminar un punto activo, primero se va a ese punto con VO + número de punto activo. Después se pulsa VO + Mayúsculas + ese mismo número.

Si un punto activo deja de tener utilidad, es mejor eliminarlo o reasignarlo. Mantener puntos antiguos puede hacer que la navegación sea menos predecible, sobre todo si pertenecen a ventanas, controles o estados que ya no se utilizan.

Encuesta europea sobre accesibilidad audiovisual 2026

La accesibilidad audiovisual sigue siendo una asignatura pendiente en muchos servicios digitales y medios de comunicación.

Aunque en los últimos años se han producido avances importantes, la experiencia real de las personas con discapacidad y las personas mayores sigue siendo no del todo satisfactoria ya que siguen encontrando demasiadas barreras en la televisión, las plataformas de vídeo, los servicios de streaming, las redes sociales o los sitios de noticias online.

Por este motivo se ha puesto en marcha la Encuesta sobre accesibilidad audiovisual 2026, una iniciativa europea orientada a recoger información directa sobre cómo las personas acceden, o intentan acceder, a los contenidos audiovisuales en su vida diaria.

Una encuesta para conocer la experiencia real

El objetivo de esta encuesta es que organizaciones europeas como la Unión Europea de Ciegos, la Federación Europea de Personas con Discapacidad Auditiva, la Unión Europea de Sordos, Inclusion Europe y el Foro Europeo de la Discapacidad puedan recopilar información sobre la accesibilidad audiovisual desde la perspectiva de quienes utilizan estos servicios.

La encuesta pregunta por la experiencia de uso en distintos entornos como la televisión tradicional, servicios de streaming de video, plataformas de noticias y redes sociales.

Este enfoque resulta especialmente importante porque la accesibilidad no puede evaluarse únicamente desde el cumplimiento técnico o normativo. También debe tenerse en cuenta si una persona puede encontrar, activar, comprender y utilizar los recursos de accesibilidad cuando realmente los necesita.

Subtítulos, audiodescripción y mucho más

Cuando hablamos de accesibilidad audiovisual solemos pensar en subtítulos, audiodescripción o interpretación en lengua de signos. Pero el problema va más allá de que estos recursos existan.

También importa si están disponibles en todos los contenidos, si se pueden activar fácilmente, si funcionan correctamente en las aplicaciones, si son compatibles con productos de apoyo y si la interfaz permite encontrarlos sin convertir una acción sencilla en una pequeña aventura tecnológica.

La accesibilidad audiovisual no debería depender de la plataforma, del dispositivo, del país o de la buena voluntad de una empresa concreta. El acceso a la información, la cultura, el entretenimiento y la actualidad debe ser posible para todas las personas.

Apoyar mejoras en la normativa europea

Las aportaciones recogidas en esta encuesta contribuirán a reforzar los esfuerzos dirigidos a mejorar los requisitos de accesibilidad establecidos en la Directiva de Servicios de Comunicación Audiovisual.

Esta directiva europea regula aspectos relacionados con los servicios audiovisuales, y la información aportada por los usuarios puede ayudar a identificar carencias, barreras frecuentes y necesidades que todavía no están suficientemente cubiertas.

La participación de las personas con discapacidad y de quienes utilizan recursos de accesibilidad es esencial para que las normas no se queden en una declaración de intenciones. La experiencia de uso aporta contexto, ejemplos y evidencia sobre lo que funciona y lo que sigue fallando.

La participación en la encuesta es voluntaria y, de forma opcional, las personas participantes pueden facilitar sus datos de contacto. Según la información proporcionada, estos datos serán utilizados exclusivamente por las organizaciones responsables de la iniciativa y tratados conforme al Reglamento General de Protección de Datos.

La fecha límite para completar la encuesta es el 12 de julio de 2026.

Este tipo de iniciativas son una buena oportunidad para trasladar problemas reales que muchas veces quedan invisibles: contenidos sin audiodescripción, subtítulos incompletos, controles inaccesibles, aplicaciones que no funcionan correctamente con lectores de pantalla o servicios donde la accesibilidad depende demasiado del azar.

Cuantas más personas participen, más completa será la imagen de la accesibilidad audiovisual en Europa y más argumentos habrá para exigir servicios realmente inclusivos.

Puedes participar en la encuesta completando el formulario.

Atributo Tabindex y su efecto en la accesibilidad

El atributo tabindex forma parte de HTML y permite modificar la forma en la que un elemento recibe el foco del teclado. Su uso puede mejorar la accesibilidad de una interfaz, pero también puede empeorarla si se utiliza para corregir problemas que deberían resolverse con una estructura HTML adecuada.
La navegación con teclado es una parte esencial de la accesibilidad web. Muchas personas no utilizan ratón, bien porque trabajan con lector de pantalla, porque emplean otros productos de apoyo o porque simplemente prefieren desplazarse por la interfaz mediante la tecla de tabulación y otros comandos del teclado. En esos casos el foco indica en qué elemento se encuentra la interacción en cada momento.
Los elementos de HTML ya forman parte del orden de tabulación por defecto. Un enlace con href, un botón, un campo de formulario o un control nativo pueden recibir el foco sin necesidad de añadir atributos adicionales. Esto es importante porque HTML ya incorpora mucho comportamiento accesible cuando se utiliza correctamente.
El problema aparece cuando se intenta forzar el comportamiento de una página mediante tabindex sin tener en cuenta las expectativas de las personas que navegan con teclado.

Qué hace tabindex

El atributo tabindex permite alterar el orden natural del foco. Puede hacer que un elemento no interactivo pueda recibir el foco, puede retirar un elemento interactivo del orden de tabulación y también puede reorganizar el orden en el que se recorren los elementos de la página.
Su valor es numérico. Cuando se utiliza tabindex=»-1″, el elemento puede recibir el foco mediante JavaScript, pero no queda incluido en la navegación secuencial con la tecla Tab. Cuando se utiliza tabindex=»0″, el elemento entra en el orden de tabulación respetando la posición que ocupa en el código HTML. Cuando se utiliza un valor positivo, como tabindex=»1″ o tabindex=»2″, se fuerza un orden de navegación distinto al orden natural del documento.
En la práctica, los valores positivos suelen ser una mala señal. Si el orden de foco no coincide con el orden visual o lógico de la página, lo correcto normalmente no es añadir números para reconstruir artificialmente la navegación. Lo adecuado es revisar la estructura del HTML y utilizar CSS para ajustar la presentación visual cuando sea necesario.

<a href="/inicio">Inicio</a>
<div tabindex="0">Contenido desplazable</div>
<a href="/contacto">Contacto</a>

En este ejemplo, el div entra en el orden de tabulación en el lugar que ocupa dentro del documento. Esto puede ser correcto si ese contenedor tiene algún comportamiento interactivo real. Pero si se trata solo de un bloque de texto, añadirlo al foco puede introducir ruido innecesario en la navegación.

El foco no debe sustituir a la semántica

Una regla sencilla para evaluar el uso de tabindex consiste en preguntarse si el elemento debería ser interactivo. Si se necesita un botón, se debe utilizar un elemento button. Si se necesita un enlace, se debe utilizar un enlace. Si se necesita un campo de formulario, se debe utilizar el control correspondiente.

Crear un botón con un div y añadirle tabindex=»0″ no convierte ese elemento en un botón completo. Puede recibir el foco, pero no incorpora automáticamente el comportamiento esperado con teclado, la semántica adecuada ni la comunicación correcta con los productos de apoyo. En muchos casos, ese tipo de solución obliga a reproducir manualmente características que HTML ya ofrece de forma nativa.

La accesibilidad no consiste solo en que algo pueda recibir el foco. También importa qué anuncia el lector de pantalla, qué teclas activan el componente, cómo se informa del estado, cómo se integra en el flujo del documento y si la interacción coincide con lo que la persona usuaria espera.

Cuándo puede ser útil tabindex=”-1”

El valor -1 resulta útil cuando un elemento no debe aparecer en la navegación normal con Tab, pero necesita recibir el foco en una situación concreta. Un caso habitual es un mensaje de error después de enviar un formulario.

Si una persona envía un formulario y existen errores, mover el foco al resumen de errores puede ayudar a comprender qué ha ocurrido. Para una persona que navega con teclado, evita tener que volver a recorrer toda la página hasta localizar el problema. Para una persona que utiliza lector de pantalla, permite que el mensaje sea anunciado en el momento adecuado.

<div id="errores" tabindex="-1">
Hay errores en el formulario. Revisa los campos indicados.
</div>

Después, mediante JavaScript, se puede enviar el foco a ese elemento cuando se detecten errores.

document.getElementById('errores').focus();

Este patrón también puede ser útil en ventanas modales, paneles que se abren dinámicamente o zonas de la interfaz que aparecen como consecuencia de una acción de la persona usuaria. El objetivo no es añadir más paradas al teclado, sino colocar el foco en un punto lógico cuando cambia el contexto de interacción.

Cuándo puede ser útil tabindex=“0”

El valor 0 debe utilizarse con más cuidado. Su función es incorporar un elemento al orden natural de tabulación. Esto puede tener sentido cuando existe una zona que debe poder recibir interacción con teclado, pero que por defecto no forma parte del orden de foco.

Un ejemplo frecuente son los contenedores con desplazamiento interno creados con CSS mediante overflow.

Si un bloque tiene contenido desplazable y una persona solo utiliza el teclado, necesita poder situar el foco en esa región para desplazarse por ella. En ese caso, tabindex=»0″ puede hacer que el contenedor sea alcanzable saltando con la tecla de tabulador.

<section aria-labelledby="condiciones" tabindex="0" style="overflow: auto; max-height: 12rem;">
<h2 id="condiciones">Condiciones de uso</h2>
<p>Texto de las condiciones de uso...</p>
</section>

En este tipo de componentes no es suficiente con hacer que el contenedor reciba el foco. También conviene proporcionar una etiqueta accesible y una estructura semántica clara. Una persona que usa lector de pantalla debe poder entender qué contiene esa región y por qué ha llegado hasta ella.

Los valores positivos rompen expectativas

Los valores positivos de tabindex permiten definir un orden de tabulación independiente del orden del documento.

Esta práctica debe realizarse con mucho cuidado ya que es muy sencillo romper el orden coherente y comprensible del orden de tabulación.

Cuando el foco salta de una parte a otra de la página en un orden inesperado, la interfaz se vuelve más difícil de comprender. La persona que navega con teclado puede perder la relación entre la posición visual, la estructura del contenido y el punto real de interacción. Para quien utiliza lector de pantalla, esa separación entre orden del código, orden visual y orden de foco puede resultar especialmente confusa.

<div tabindex="3">Tercer elemento</div>
<div tabindex="1">Primer elemento</div>
<div tabindex="2">Segundo elemento</div>

Este código fuerza una secuencia que no coincide con el orden del documento. Si el diseño necesita mostrar visualmente los elementos de otra manera, CSS debería encargarse de la presentación. El HTML debe conservar un orden lógico, comprensible y coherente.

Componentes personalizados

Existen componentes interactivos que no tienen una equivalencia directa en HTML nativo. Un sistema de pestañas, determinados widgets complejos o algunos controles de aplicación pueden requerir una gestión específica del foco.

En estos casos, tabindex puede formar parte de la solución, pero no debe utilizarse de forma aislada. Un patrón de pestañas accesible, por ejemplo, puede necesitar que la pestaña activa tenga tabindex=»0″ y que las pestañas inactivas tengan tabindex=»-1″ para permitir una navegación controlada con flechas y una gestión correcta del foco.

Revisar el uso de tabindex

Una revisión de accesibilidad debería incluir la búsqueda de usos de tabindex en el código. Cada aparición merece una comprobación concreta. Si un elemento nativo interactivo tiene tabindex=»0″, probablemente no lo necesita. Si un elemento no interactivo tiene tabindex=»0″, conviene revisar si realmente debe recibir el foco. Si aparece un valor positivo, normalmente debería corregirse el orden del documento en lugar de mantener ese valor.

También es importante revisar los casos con tabindex=»-1″. No son necesariamente incorrectos, pero deben estar asociados a una gestión del foco clara. Si ningún script envía el foco a ese elemento, puede que el atributo no esté cumpliendo ninguna función.

Las herramientas automáticas pueden localizar estos casos, pero la decisión final requiere criterio humano. Una herramienta puede indicar que existe un tabindex, pero no siempre puede determinar si su uso responde a una necesidad real de interacción.

Una herramienta que debe usarse con criterio

tabindex no es un atributo prohibido. Es una herramienta potente para gestionar el foco en situaciones concretas. Pero precisamente por afectar directamente a la navegación con teclado, debe utilizarse con prudencia.

En una página bien estructurada, la mayor parte del orden de tabulación debería venir dado por el propio HTML. Los enlaces, botones y campos de formulario ya tienen comportamiento accesible cuando se usan correctamente. Añadir tabindex sin una razón clara puede introducir barreras donde antes no las había.

The Color Contrast Checker

El proyecto The Color Contrast Checker es una herramienta web orientada a revisar el contraste entre colores y facilitar el cumplimiento de las pautas de accesibilidad relacionadas con la legibilidad visual. Su objetivo principal es permitir que diseñadores, desarrolladores y responsables de contenido comprueben si una combinación de color de texto y fondo alcanza los niveles exigidos por WCAG para los criterios AA y AAA.

La propia herramienta se presenta como un comprobador gratuito de contraste WCAG con sugerencias para encontrar combinaciones de color accesibles.

El contraste de color es uno de esos aspectos de la accesibilidad que puede parecer sencillo hasta que se analiza con cierta atención. No es suficiente con que dos colores parezcan diferentes en una pantalla concreta, con un brillo concreto y en unas condiciones de iluminación concretas. Una combinación que para una persona resulta aceptable puede ser insuficiente para otra con baja visión, daltonismo, fatiga visual o simplemente utilizando el dispositivo en un entorno poco favorable.

La accesibilidad visual no depende únicamente del tamaño de la letra ni de la calidad tipográfica. También depende de la relación entre el color del primer plano y el color del fondo. Cuando esa relación de contraste de color es baja, el contenido puede seguir estando técnicamente presente, pero deja de ser cómodo, eficiente o incluso posible de leer para gran parte de los usuarios. En esa situación el problema deja de ser estético para convertirse en un problema funcional.

Herramientas como The Color Contrast Checker ayudan a convertir una percepción subjetiva en un dato verificable. El diseñador puede introducir los colores, comprobar la relación de contraste y conocer si la combinación cumple o no los umbrales establecidos. Esta verificación resulta especialmente útil porque evita depender únicamente de la intuición, de la vista del diseñador o de la apariencia en una única pantalla.

WCAG utiliza ratios de contraste para determinar si un texto resulta suficientemente distinguible respecto a su fondo. En el modelo tradicional de WCAG 2, la escala va de 1:1, cuando no hay contraste, hasta 21:1, que corresponde al contraste máximo entre negro y blanco. Otras herramientas actuales también incorporan APCA, un modelo perceptual propuesto en el contexto de WCAG 3, que expresa el contraste mediante valores de luminancia percibida en lugar de utilizar el ratio clásico.

La revisión del contraste no debería considerarse una fase final del proyecto. Debería formar parte del diseño desde el principio. Si una paleta no permite combinaciones suficientes para texto normal, texto grande, componentes interactivos y estados de interfaz, el problema no está en la herramienta que lo detecta. El problema está en la definición de la propia paleta.

También conviene recordar que una buena puntuación de contraste no resuelve por sí sola toda la accesibilidad visual. Un texto puede tener contraste suficiente y seguir siendo difícil de leer por usar un tamaño demasiado pequeño, una fuente poco clara, demasiado espaciado negativo, bloques extensos sin estructura o información transmitida solamente mediante color.

365 Days iOS Accessibility

El proyecto 365 Days iOS Accessibility es una iniciativa orientada a compartir conocimiento práctico sobre accesibilidad en aplicaciones iOS. El proyecto consiste en publicar, durante un año, pequeñas piezas de contenido relacionadas con técnicas, recomendaciones y detalles que pueden ayudar a crear aplicaciones más accesibles.

La accesibilidad en iOS suele asociarse de forma inmediata con VoiceOver, pero el proyecto muestra que el campo es mucho más amplio. En sus publicaciones aparecen temas relacionados con SwiftUI, UIKit, visionOS, accesibilidad en Apple Watch, atajos de teclado, Voice Control, Full Keyboard Access, orientación de pantalla, texto alternativo, prioridades de orden de lectura o adaptación de interfaces a tamaños grandes de texto.

Este enfoque resulta especialmente interesante porque reduce la distancia entre la teoría y la práctica. Muchas veces la accesibilidad se presenta como una obligación general, como una fase de revisión o como una lista de comprobaciones al final del desarrollo. Sin embargo, en el trabajo diario de una aplicación móvil, las barreras suelen aparecer en decisiones pequeñas como un botón sin etiqueta clara, un orden de navegación incorrecto, un gesto sin alternativa, una pantalla que no soporta orientación horizontal, un texto que no crece correctamente o una imagen compartida sin descripción.

El valor de este proyecto está precisamente en señalar esos detalles. No sólo explica que una aplicación debe ser accesible, sino de mostrar cómo se puede mejorar una parte concreta de la interfaz, una interacción concreta o un componente concreto. En una publicación se recuerda, por ejemplo, la importancia de permitir que las imágenes compartidas por los usuarios incluyan texto alternativo para que pueda utilizarse como etiqueta de accesibilidad. En otra se habla de la necesidad de soportar ambas orientaciones cuando sea posible y de evitar obligar al usuario a girar el dispositivo.

Otro aspecto importante es la relación entre distintas herramientas de apoyo. Una aplicación con buen soporte para VoiceOver suele tener una base más sólida para otras formas de interacción, pero eso no significa que todo quede resuelto automáticamente. El proyecto recuerda, por ejemplo, que en Apple Watch puede ser útil implementar acciones rápidas para AssistiveTouch cuando existe una acción principal clara. Este tipo de observaciones ayudan a entender que la accesibilidad no depende de una única tecnología, sino de la capacidad de la interfaz para ofrecer caminos alternativos para la persona usuaria.

GAAD 2026

El próximo 21 de mayo de 2026 se celebrará una nueva edición del Global Accessibility Awareness Day, más conocido como GAAD. Será la decimoquinta edición de una jornada internacional dedicada a hablar, pensar y aprender sobre accesibilidad digital e inclusión. Su objetivo es conseguir que la tecnología digital pueda ser utilizada por todas las personas, incluidas las personas con discapacidad.

La accesibilidad digital afecta a páginas web, aplicaciones móviles, software, documentos, plataformas educativas, servicios públicos, comercio electrónico y cualquier entorno en el que una persona necesite interactuar con tecnología. No es un asunto reservado a especialistas. También involucra a quienes diseñan, desarrollan, prueban, compran, financian, legislan o toman decisiones sobre productos digitales.

El GAAD nació precisamente para reducir esa distancia entre la intención y la práctica. Muchas personas están de acuerdo con la idea de hacer tecnología más accesible, pero no siempre saben por dónde empezar. La propia web del GAAD recuerda que el conocimiento sobre accesibilidad web es un primer paso necesario para que los equipos técnicos puedan revisar, corregir y mejorar sus productos.

Una jornada con muchos eventos

Aunque el día oficial será el 21 de mayo, durante estas semanas se están anunciando diversos eventos, webinars y talleres relacionados con la accesibilidad digital. La página oficial del GAAD mantiene una sección de eventos donde se recogen actividades en distintos países y formatos.

Entre las citas previstas está la Primera Jornada de Accesibilidad Digital de la Universitat de Lleida, que se celebrará el 28 de mayo de 2026 en formato online, con inscripción gratuita y sesiones sobre personas, diseño, desarrollo web, documentos, evaluación e inteligencia artificial.

También se ha anunciado el evento Global Accessibility Awareness Day with Deque, previsto para el 21 de mayo, con actividades virtuales gratuitas orientadas a la sensibilización y al aprendizaje sobre accesibilidad digital.

Otra propuesta internacional es la jornada de Disability:IN para el GAAD, centrada en cómo las organizaciones están incorporando la accesibilidad en el desarrollo de productos, la experiencia de cliente, la tecnología y la innovación. El evento contempla sesiones para distintas regiones, incluyendo EMEA, APAC, LATAM y NORAM.

En el ámbito universitario también se celebrará el UC Global Accessibility Awareness Day 2026 Webinar, bajo el lema From Policy to Practice, con contenidos sobre implementación de políticas de accesibilidad, inteligencia artificial, problemas habituales en PDF y audiodescripción.

Estas actividades muestran que el GAAD ya no es solo una fecha simbólica. Es una oportunidad para compartir experiencias, contrastar criterios, revisar procesos y acercar la accesibilidad a personas que quizá no trabajan directamente en este ámbito, pero cuyas decisiones influyen en la vida diaria de muchas personas.

Plexus Tech y la accesibilidad digital real

Este año participaré como moderador en una mesa dentro del evento de Plexus Tech dedicado al GAAD. Plexus ya celebró en 2025 un encuentro en streaming bajo el lema de seguir trabajando por una accesibilidad digital real, con profesionales de distintos sectores, expertos en normativa, diseño UX/UI y accesibilidad digital.

En la edición de 2025 se abordaron cuestiones como la evolución normativa, la aplicación de estándares, el papel de las administraciones y la necesidad de introducir la accesibilidad desde la base de los proyectos. También se compartieron casos reales de organizaciones como Renfe, Santander, Govern de les Illes Balears y B100.

Ese enfoque resulta especialmente importante. La accesibilidad no puede aparecer al final de un proyecto como una fase de revisión o como una corrección de emergencia. Cuando llega tarde, suele llegar peor. Obliga a rehacer interfaces, reescribir contenidos, corregir componentes, revisar documentos y justificar decisiones que podrían haberse tomado correctamente desde el principio.

Hablar de accesibilidad digital real implica asumir que el cumplimiento normativo es necesario, pero no suficiente. Una interfaz puede superar determinadas comprobaciones automáticas y seguir siendo incómoda, confusa o poco usable. También puede cumplir formalmente con un criterio técnico y, aun así, no ofrecer una experiencia razonable a una persona que navega con lector de pantalla, que usa teclado, que necesita más tiempo para completar una tarea o que requiere contenidos más claros.

Accesibilidad como práctica continua

El GAAD sirve para recordar que la accesibilidad no es una campaña anual. Es una práctica continua. Cada nueva funcionalidad, cada actualización de una aplicación, cada cambio de diseño y cada documento publicado puede abrir o cerrar una puerta.

En los últimos años se ha hablado mucho de inteligencia artificial, automatización y nuevas interfaces. Estas tecnologías pueden ayudar a reducir barreras, pero también pueden crear otras nuevas si no se diseñan con criterios inclusivos. Por eso es importante que los eventos del GAAD no se limiten a explicar qué es la accesibilidad, sino que entren en cómo se aplica, cómo se evalúa, cómo se mantiene y cómo se integra en los equipos.

La accesibilidad digital no pertenece únicamente al departamento de desarrollo. Empieza en la definición del producto, continúa en el diseño, se concreta en el código, se valida en las pruebas, se comunica en los contenidos y se mantiene durante toda la vida del servicio.

El 21 de mayo es una buena excusa para revisar lo que hacemos. Pero la accesibilidad no debería depender de una fecha concreta. El valor del GAAD está en recordarnos que cada barrera digital tiene consecuencias reales y que cada mejora también las tiene.