Novedades de ARIA 1.3

En el artículo Cool new stuff coming in ARIA 1.3, escrito por Karl Groves, uno de los guruses de la accesibilidad web, se exploran las novedades de Accessible Rich Internet Applications (WAI-ARIA) 1.3 (borrador del 4 de junio de 2026).

El borrador de WAI-ARIA 1.3 introduce nuevas capacidades orientadas principalmente a mejorar la accesibilidad de aplicaciones web complejas, especialmente editores colaborativos, sistemas de anotación, flujos de revisión documental y formularios avanzados. A diferencia de versiones anteriores, no se centra en crear nuevos widgets, sino en representar mejor el significado de contenidos complejos para las tecnologías de asistencia.

No obstante, hay que recordar que ARIA no sustituye a HTML y que siempre deben utilizarse primero los elementos semánticos nativos cuando existan equivalentes adecuados.

Entre las principales novedades destacan:

• role="suggestion": permite identificar cambios propuestos en documentos (inserciones, eliminaciones o modificaciones), facilitando que los usuarios de tecnologías de asistencia comprendan que se trata de sugerencias y no de contenido definitivo.
• role="comment": identifica comentarios, anotaciones o revisiones asociados a una parte concreta del contenido.
• role="mark": representa contenido resaltado con significado semántico, similar al elemento HTML <mark>.

También se incorporan nuevos atributos:

• aria-description: proporciona una descripción accesible directamente mediante texto, sin necesidad de referenciar otro elemento del DOM. Debe utilizarse solo cuando no exista texto visible adecuado para emplear aria-describedby.
• aria-braillelabel: permite definir una etiqueta específica para dispositivos braille, optimizada para sus limitaciones de espacio.
• aria-brailleroledescription: ofrece una descripción del rol adaptada a la salida braille.

Además, ARIA 1.3 introduce mejoras en atributos existentes:

• aria-details podrá referenciar múltiples elementos, permitiendo asociar varias explicaciones o detalles estructurados a un mismo componente.
• aria-errormessage también admitirá múltiples referencias, facilitando mostrar simultáneamente varios errores de validación asociados a un campo.
• Se aclara que aria-haspopup="false" no debe exponerse a las tecnologías de asistencia, ya que aporta información redundante.
• Se refuerza la recomendación de utilizar niveles de encabezado coherentes mediante aria-level, preferiblemente recurriendo a los elementos HTML <h1>–<h6>.

El borrador también incorpora nuevos roles relacionados con la semántica documental, como code, deletion, insertion, strong, emphasis, subscript, superscript y time, especialmente útiles en editores personalizados donde no es posible emplear HTML nativo.

Dado que ARIA 1.3 aún se encuentra en desarrollo, el artículo recomienda no adoptar estas funcionalidades en entornos de producción sin realizar pruebas exhaustivas, ya que tanto la especificación como su soporte por navegadores y tecnologías de asistencia pueden cambiar. En cualquier caso, ARIA 1.3 representa un avance hacia una representación más precisa de documentos complejos, revisiones, anotaciones y contenidos enriquecidos en aplicaciones web modernas.

Taller sobre cómo auditar la accesibilidad de diseños UX

Que haya algún curso sobre usabilidad, accesibilidad o experiencia de usuario en Madrid o Barcelona no es una novedad. Lo que sí que es una novedad es un curso sobre esos temas fuera de los dos polos económicos de España.

El próximo 27/6/2026 en Valencia se organiza el Accessibility Lab Workshop - Aprende a auditar tus diseños, un taller de dos horas y media sobre cómo aprender a identificar y corregir las barreras de accesibilidad antes de enviar los diseños a desarrollo.

Estudio de la accesibilidad de un sitio web creado mediante inteligencia artificial

En Lovable’s AI built a 100% accessible site – or did it? se explica que un sitio web construido con inteligencia artificial (usando la herramienta Lovable) obtuvo una puntuación perfecta del 100% en una prueba automática de accesibilidad. Sin embargo, al ser probado por un usuario real de lector de pantalla (VoiceOver en iPhone), mostró múltiples problemas graves.

Los principales problemas encontrados fueron:

• El lector de pantalla leía contenido oculto detrás de menús o ventanas modales.
• Un componente de seguridad (Cloudflare) se repetía sin control, interrumpiendo la navegación.
• Al ser una aplicación de una sola página (SPA), el foco no se movía correctamente al cambiar de sección.
• El botón de menú no indicaba si estaba expandido o colapsado (falta de aria-expanded).
• Se saltaban niveles de encabezados (de H1 a H3, sin H2).
• Etiqueta aria-label diferente al texto visible del botón, dificultando el control por voz.
• El selector de idiomas no permitía saber cuál estaba activo.

No obstante, un experto en accesibilidad corrigió muchos de estos problemas en solo 10 minutos desde su teléfono móvil. Según los autores de este artículo, esto demuestra que la IA puede funcionar bien si un humano especialista supervisa el proceso. Pero la mayoría de los sitios creados con estas herramientas no tendrán esa supervisión, por lo que aún están lejos de ser realmente accesibles por defecto.

La sesión ha caducado (session timeout)

El artículo Session Timeouts: The Overlooked Accessibility Barrier In Authentication Design es un excelente análisis de los problemas de accesibilidad que plantea la gestión de la sesión en una aplicación web.

El artículo analiza la gestión de sesiones en la web desde la perspectiva de la accesibilidad, destacando que los tiempos de expiración (session timeouts) no solo afectan a la experiencia de usuario y la seguridad, sino que constituyen una barrera significativa para las personas con discapacidad.

Se señala que una gran parte de la población (incluyendo las personas con discapacidades motoras, cognitivas o visuales, así como usuarios neurodivergentes) se ve desproporcionadamente afectada por límites de tiempo estrictos. Estos usuarios pueden necesitar más tiempo para interactuar con formularios, procesar información o navegar mediante productos de apoyo, lo que provoca que los sistemas interpreten erróneamente su actividad como inactividad.

El texto muestra varias situaciones en las que las personas con discapacidad experimentan problemas de accesibilidad:

• Las personas con discapacidades motoras pueden introducir datos más lentamente.
• Las personas con dificultades cognitivas requieren más tiempo para comprender o procesar información.
• Los usuarios con discapacidad visual dependen de lectores de pantalla, lo que incrementa el tiempo de navegación.

Además, el artículo critica prácticas habituales poco accesibles, como cierres de sesión sin aviso, avisos insuficientes, imposibilidad de extender la sesión y pérdida de datos al expirar. Como soluciones, se proponen buenas prácticas alineadas con las WCAG, como son:

• Proporcionar avisos previos claros y suficientes.
• Permitir extender el tiempo de sesión.
• Implementar guardado automático del progreso.
• Diseñar tiempos de expiración coherentes (preferiblemente basados en actividad).
• Informar desde el inicio sobre los límites de tiempo.

Finalmente, se subraya que mejorar la accesibilidad de los tiempos de sesión no solo beneficia a personas con discapacidad, sino a todos los usuarios, y constituye tanto una buena práctica técnica como un compromiso ético en el desarrollo web.

Las WCAG proporcionan recursos adicionales que los desarrolladores web pueden consultar para comprender mejor la accesibilidad de la gestión de sesiones:

• WCAG SC 2.2.1 Timing Adjustable
• WCAG SC 2.2.5 Re-authenticating
• WCAG SC 2.2.6 Timeouts

Día Mundial para Promover la Concienciación sobre la Accesibilidad Web (Global Accessibility Awareness Day)

El tercer jueves del mes de mayo se celebra el Global Accessibility Awareness Day (GAAD), Día Mundial para Promover la Concienciación sobre la Accesibilidad Web.

En la página principal podemos leer:

Thursday, May 21, 2026, help us celebrate the 15th Global Accessibility Awareness Day (GAAD)! The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than One Billion people with disabilities/impairments.

Celebración del GAAD en varias universidades españolas

Cada año, el tercer jueves de mayo se celebra el Día Mundial para Promover la Concienciación sobre la Accesibilidad Web (Global Accessibility Awareness Day, GAAD). Este año se celebra el próximo jueves 21 de mayo.

Varias universidades españolas han organizado algunos eventos para ese año. Por ejemplo, la Universidad de Alicante organiza el 21 de mayo el Día de la Accesibilidad Digital en la UA 2026. En la descripción del evento se indica:

Este año, como novedad, contaremos con la participación de varios expertos en accesibilidad que se desplazarán hasta la UA para compartir sus conocimientos y experiencias. Su perspectiva enriquecerá el debate y ayudará a sensibilizar a todos los asistentes sobre la relevancia de la accesibilidad digital en nuestra sociedad.

Y la Universitat de Lleida organiza el 28 de mayo la Primera Jornada de Accesibilidad Digital, con la siguiente descripción:

Jornada para aprender sobre personas, diseño, desarrollo web, documentos, evaluación e inteligencia artificial en el ámbito de la accesibilidad digital.

La accesibilidad y la usabilidad se deben trabajar de forma conjunta

En Sometimes the Best Accessibility Fix is a Usability Fix se explica que la accesibilidad no debe considerarse un añadido separado de la experiencia de usuario (UX), sino una parte esencial del buen diseño. Muchas barreras de accesibilidad surgen de problemas de usabilidad que ya resultan molestos para usuarios sin discapacidad, aunque afectan de manera mucho más grave a personas con discapacidades visuales, motoras, cognitivas o neurodivergentes.

Se presentan varios ejemplos comunes para entender la relación entre accesibilidad y usabilidad:

• Errores prematuros en formularios: mostrar mensajes de error antes de que el usuario termine de escribir genera confusión y distracción. Retrasar la validación mejora tanto la usabilidad como la accesibilidad.
• Listas desplegables mal diseñadas: menús largos sin búsqueda por escritura (“typeahead”) o que se abren en posiciones arbitrarias dificultan enormemente la navegación con teclado o lectores de pantalla.
• Mensajes de confirmación que desaparecen rápido: los avisos temporales impiden que muchas personas terminen de leerlos. Mantenerlos visibles más tiempo o permitir cerrarlos manualmente mejora el control temporal.
• Campos que solo se pueden borrar con retroceso: obligar a eliminar texto carácter por carácter añade esfuerzo innecesario, especialmente para usuarios con limitaciones motoras o lectores de pantalla.
• Pérdida de posición en galerías de productos: volver al inicio de una lista tras consultar un producto crea frustración y obliga a repetir navegación.
• Mostrar contraseñas mediante “mantener pulsado”: este patrón exige precisión motora y temporal; un interruptor permanente resulta más accesible y usable.
• Fuentes de información duplicadas: repetir la misma información en varios formatos incrementa la carga cognitiva y genera redundancia para usuarios de tecnologías asistivas.
• Borrado de datos tras errores: eliminar información introducida, como números de tarjeta de crédito, obliga a repetir tareas complejas y aumenta la probabilidad de errores.

El artículo concluye que las organizaciones que realmente se preocupan por la accesibilidad también deben preocuparse por la usabilidad. Cuando las mejoras de accesibilidad se presentan como correcciones de usabilidad, suelen encontrar menos resistencia organizativa y benefician a todos los usuarios. Además de reducir riesgos legales, estas mejoras disminuyen la fricción, las quejas y las llamadas de soporte, aumentando la satisfacción del cliente mediante interacciones más estables y predecibles.

Extendidos los plazos de ADA Title II en EE UU

ADA Title II Rule on Web Content and Mobile App Accessibility estaba previsto que inicialmente entrase en vigor en 2026. Sin embargo, en DOJ Delays the Title II Web Accessibility Deadline - Don't Sit Back se explica que el 20 de abril de 2026 el Departamento de Justicia de EE. UU. publicó una norma provisional que retrasa un año los plazos de cumplimiento de la regla de accesibilidad web del Título II (2024). Las entidades públicas con más de 50.000 habitantes pasan a tener como fecha límite abril de 2027, mientras que las más pequeñas disponen hasta abril de 2028. Además, se abre un periodo de 60 días para comentarios públicos.

La norma justifica el retraso con varios argumentos. El más sólido es la limitación de recursos (personal y presupuesto) de muchas entidades, especialmente en educación. Sin embargo, el texto critica duramente otros razonamientos: la supuesta sobreestimación del papel de la inteligencia artificial (que no figuraba en la norma original), las dudas sobre la aplicabilidad de WCAG 2.1 (consideradas jurídicamente arriesgadas) y la idea de posibles demandas impulsadas por actores extranjeros, calificada como poco creíble. También se señala que el Departamento de Justicia estaría “premiando la ignorancia” al conceder más tiempo a instituciones que no comprendieron correctamente la normativa previa.

Aunque la medida solo modifica los plazos y no los requisitos, se anticipa una posible revisión futura de la norma que podría afectar aspectos clave como el uso de WCAG. En cualquier caso, se subraya que la obligación de garantizar la accesibilidad web sigue vigente y que las entidades deben continuar avanzando en su cumplimiento pese a la incertidumbre regulatoria.

ADA Title II Rule on Web Content and Mobile App Accessibility en Estados Unidos

ADA Title II Rule on Web Content and Mobile App Accessibility es una regulación publicada en abril de 2024 por el Departamento de Justicia de EE. UU. que concreta, por primera vez de forma explícita, cómo deben cumplir las administraciones públicas con las obligaciones de accesibilidad digital establecidas en la Americans with Disabilities Act (ADA).

La norma establece que:

• Ámbito de aplicación: Se aplica a todas las entidades públicas estatales y locales (incluyendo universidades públicas), así como a los servicios digitales que ofrecen, tanto directamente como a través de terceros.
• Obligación principal: Todos los sitios web, aplicaciones móviles y contenidos digitales públicos deben ser accesibles para las personas con discapacidad, garantizando el principio de “comunicación efectiva” y acceso equitativo a los servicios públicos.
• Estándar técnico exigido: Se adopta como referencia obligatoria WCAG 2.1 nivel AA, lo que implica cumplir criterios sobre estructura, navegación, alternativas textuales, subtitulado, etc.
• Alcance del contenido: Incluye prácticamente todo el contenido digital público: páginas web, documentos, plataformas educativas, aplicaciones móviles y servicios online, incluso cuando son proporcionados por terceros contratados.
• Excepciones limitadas: Existen algunas excepciones específicas (por ejemplo, contenido archivado o ciertos contenidos de terceros no controlados), pero son restringidas y no eliminan la obligación general de accesibilidad.
• Plazos de cumplimiento: Inicialmente fijados para 2026, han sido extendidos en 2026 mediante una norma intermedia:
• Entidades grandes (≥50.000 habitantes): hasta abril de 2027
• Entidades pequeñas: hasta abril de 2028

ADA Title II Rule on Web Content and Mobile App Accessibility transforma la accesibilidad web en el sector público estadounidense de una obligación genérica a un requisito técnico concreto y exigible, alineado con WCAG 2.1 AA, reforzando la rendición de cuentas y la inclusión digital.

Texto alternativo para el contenido generado desde CSS

A través de Tests for CSS generated content alternative text he aprendido que se puede definir un texto alternativo para el contenido generado desde CSS. Este artículo analiza el uso de la propiedad content en CSS para generar contenido visual (como texto o iconos) y su implicación en la accesibilidad. Cuando este contenido es relevante, debería contar con una alternativa accesible para personas que utilizan productos de apoyo como los lectores de pantalla. Para ello, la especificación de CSS permite incluir un texto alternativo mediante una barra (/) dentro de la propiedad content, donde lo anterior a la barra se muestra visualmente y lo posterior se destina a los productos de apoyo.

Según la especificación, este texto alternativo debe sustituir al contenido visual en lectores de pantalla y puede ser expuesto en el árbol de accesibilidad en navegadores compatibles.

Pero como suele ocurrir muchas veces, una cosa es la teoría (la especificación) y otra la práctica (lo que realmente funciona al combinar un navegador con un lector de pantalla en un sistema operativo específico). Se presentan cuatro casos de prueba: (1) solo contenido generado, que generalmente se anuncia correctamente; (2) solo texto alternativo, con resultados inconsistentes según navegador y lector de pantalla; (3) texto alternativo vacío, donde no debe anunciarse nada; y (4) combinación de contenido visual y texto alternativo, donde este último debería reemplazar al primero, aunque también con inconsistencias en algunos entornos.

En conjunto, los resultados muestran que el soporte de esta funcionalidad aún no es completamente fiable entre diferentes combinaciones de navegadores y lectores de pantalla. Por ello, se recomienda tratar esta técnica como experimental y, para información importante, seguir utilizando HTML semántico y atributos ARIA en lugar de depender únicamente del contenido generado por CSS para garantizar la accesibilidad.