Buscador

miércoles, 17 de junio de 2026

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.

martes, 16 de junio de 2026

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.

miércoles, 10 de junio de 2026

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.