Cómo conseguir accesibilidad web frente al daltonismo (3)

 

Cómo conseguir accesibilidad web frente al daltonismo (2)

 

Publicada una nueva versión de WCAG 3

El W3C ha publicado una nueva versión de WCAG 3: W3C Accessibility Guidelines (WCAG) 3.0 (W3C Working Draft 04 September 2025)

¿Y para cuándo la versión definitiva?

En WCAG 3 Introduction podemos leer:

Development

Timeline

WCAG 3 is not expected to be a completed W3C standard for a few more years.

WCAG 3 will not supersede WCAG 2 and WCAG 2 will not be deprecated for at least several years after WCAG 3 is finalized.

The Accessibility Guidelines Working Group (AG WG) previously created an initial set of guidelines and explored conformance models. In 2025, AG WG focused on progressing guidelines, requirements, assertions, and supporting material to Developing status. During the rest of 2025, the group will focus on completing the proposed guidelines and proposed conformance model for public review.

AG WG plans to develop a projected WCAG 3 timeline by December 2025.

We will update this section with more specific timeline information as it is available.

Consejos para formularios accesibles

En Accessible Forms: Tips and Techniques se proporcionan  buenas prácticas (consejos) interesantes para crear formularios accesibles:

Los formularios son fundamentales en la experiencia web (por ejemplo, para registros o compras), pero muchas veces presentan barreras para personas con discapacidad. Asegurar su accesibilidad es clave no solo para cumplir con normativas, sino también para garantizar una experiencia inclusiva.

1. Usa elementos semánticos de HTML

Utiliza etiquetas como <form>, <label>, <input>, <textarea> y <select> en lugar de <div> o <span>.

Relaciona cada <label> con su campo usando el atributo for.

2. Etiquetado e instrucciones claras

Todos los campos deben tener una etiqueta visible.

No sustituyas etiquetas con texto de marcador (placeholder), ya que este desaparece al escribir.

Proporciona instrucciones claras y mensajes de error descriptivos cerca del campo correspondiente.

3. Accesibilidad con teclado

Asegúrate de que el formulario pueda recorrerse con la tecla Tab en orden lógico.

Evita bloquear el enfoque (focus) en componentes personalizados.

Los botones deben ser operables con Enter o barra espaciadora.

4. Validación y retroalimentación clara

Usa atributos ARIA como aria-live y aria-describedby para comunicar errores o validaciones a los lectores de pantalla.

Realiza validaciones en tiempo real y mueve el foco al primer error detectado.

5. Agrupa campos relacionados

Usa <fieldset> y <legend> para agrupar controles relacionados (como botones de opción), lo cual mejora la comprensión para usuarios con lector de pantalla.

6. Mensajes de error accesibles

No uses solo el color para indicar errores; combina colores con mensajes textuales.

Asegura que los errores se lean en voz alta mediante ARIA y expliquen qué ocurrió y cómo solucionarlo.

7. Diseño para pantallas táctiles

Los botones deben ser lo suficientemente grandes (mínimo 44×44 px).

Asegura buena legibilidad de etiquetas en pantallas pequeñas.

Evita interacciones basadas en "hover", que no funcionan en dispositivos táctiles.

8. Prueba tus formularios

Evalúa con lectores de pantalla (NVDA, JAWS, VoiceOver).

Navega solo con el teclado.

Usa herramientas automáticas como Axe o WAVE, aunque no detectan todos los problemas.

Cómo conseguir accesibilidad web frente al daltonismo (1)

 

CAPTCHA: Análisis de su accesibilidad

Accesibilidad en el posicionamiento web

Animaciones accesibles en páginas web

Tablas de soporte de HTML en los lectores de pantalla

En Screen reader HTML support tables se pueden consultar tablas de soporte de HTML de los lectores de pantalla JAWS y NVDA.

Razones egoístas para desarrollar interfaces de usuario accesibles

En Selfish reasons for building accessible UIs:

• Debuggability
• Naming things
• Testability
• Power users

Focus priming

En Focus priming se explica algo que hacemos muchos de los que hacemos evaluaciones de sitios web. Cuando haces clic en algún lugar de una página web, puede parecer que no ocurra nada, pero en realidad estás determinando el punto de inicio del enfoque (focus) para la navegación con el teclado. Este detalle es importante al evaluar la accesibilidad.

¿Qué es el "focus priming"?

Es la acción de hacer clic en un punto específico de la página para establecer dónde comenzará el enfoque del teclado (por ejemplo, al presionar la tecla Tab). Aunque el enfoque inicial en la página no es visible (porque la página no es interactiva), existe y se puede modificar haciendo clic.

Ejemplos de cómo se mueve el enfoque:

• Al hacer clic en un campo de formulario o botón, el foco se mueve allí.
• Al hacer clic en un enlace, puede llevarte a otra parte de la página o del sitio.
• Al hacer clic en texto o imágenes no interactivas, simplemente se define un nuevo punto invisible de inicio del foco.

El término "focus priming" se refiere a esta técnica de establecer el foco antes de usar el teclado para realizar pruebas de accesibilidad.

Cómo la inteligencia artificial puede ayudar a las personas con discapacidad

 

Limitaciones de las herramientas automáticas de evaluación de la accesibilidad web

En Automated accessibility test tools find even less than expected se explica que, aunque muchas de las herramientas automáticas de evaluación de la accesibilidad web afirman cubrir entre el 30 % y el 50 % de los errores según WCAG, estudios y expertos como WebAIM, W3C, Karl Groves o Deque Systems confirman que esta cobertura es parcial y limitada.

El autor del artículo diseñó un conjunto de seis páginas HTML con 164 casos de prueba negativos (es decir, que deberían generar un error), centrados en el nombre accesible de los elementos interactivos (lo que lee un lector de pantalla cuando el foco llega a un botón, enlace, imagen, etc.).

El autor evaluó diferentes herramientas (gratuitas y comerciales) para ver cuántos errores detectaban, sobre elementos como <button>, <a>, <img>, <iframe>, formularios y elementos con roles ARIA.

Los resultados fueron:

• Ninguna herramienta superó el 40 % de cobertura, y muchas puntuaron por debajo.
• Algunas no reconocen elementos con role="button" u otros roles ARIA.
• Se observó gran variabilidad en el rendimiento dependiendo del tipo de contenido.
• No se evaluó el impacto del error (ej. falta de nombre en un botón de envío vs. en una imagen decorativa).

La conclusión del autor es que deberíamos matizar las cifras habituales de cobertura de herramientas automatizadas: cubren entre el 30 % y el 50 % de los problemas más comunes y fácilmente detectables, pero no todos. Además, el caso del nombre accesible indica que la cobertura real en casos prácticos puede ser incluso menor.

La accesibilidad de Samsung en los electrodomésticos

En [Interview] How Samsung Embeds Accessibility and User-Centered Values Into Its Home Appliances se explican algunas de las características de accesibilidad que incorporan los electrodomésticos de Samsung.

Todo lo que se cuenta está muy bien, pero ¿y las personas ciegas que no pueden ver y usar la pantalla táctil? Supongo que existirá la posibilidad de conectarse al electrodoméstico desde un teléfono móvil y emplear el lector de pantalla en el teléfono móvil, pero no se cuenta nada así en este artículo.

Herramientas de Windows para mejorar la accesibilidad

 

Índice de Confianza Digital 2025: El estado de la accesibilidad digital en Europa

Digital Trust Index 2025: The State of Digital Accessibility in Europe es un análisis del estado de la accesibilidad digital en Europa. Algunos de los datos que incluye son:

266,000 European homepages from 18 countries were tested for accessibility issues, slighty more than the 2024 study. 

The state of accessibility in Europe is poor:

• We found accessibility issues on 93% of tested pages (92.97%).
• That’s less than a 1% improvement compared to 2024 (-0.84%).

Herramientas automáticas para evaluar y mejorar la accesibilidad web

 

Nuevos criterios de accesibilidad para dispositivos móviles en WCAG 2.2

 

Sentencia judicial en lenguaje claro

En “Hemos estudiado tu caso y tienes toda la razón, Aureliano”: el voto particular de una jueza para que el niño a la que va dirigida la sentencia la entienda podemos leer:

“Nos dirigimos a ti, Aureliano. Formamos el equipo judicial elegido para decidir sobre lo que nos pides. Nos has contado que te cuesta un poco más que al resto de los niños y niñas atender en la clase, estudiar, obedecer a tu mamá y a tu papá, hacer caso a tu hermano, no enfadarte, de repente, sin saber por qué, y que también te es difícil seguir, en general, el ritmo de las actividades en casa, la calle o el cole. Hemos estudiado tu caso, y tienes toda la razón, Aureliano te vamos a apoyar porque ahora entendemos por qué te cuesta más hacer las cosas”.

Así comienza el voto particular que la jueza Gloria Poyatos, presidenta de la Sala Social del Tribunal Superior de Justicia de Canarias, ha introducido en una sentencia dirigida a un niño de diez años y que tenía que decidir sobre el recurso que la Consejería de Derechos Sociales, Igualdad, Diversidad y Juventud de Canarias había interpuesto porque no quería reconocer “la discapacidad del 45%”, probada y con un diagnóstico de TEA que tiene el niño.

Y, como es a él a quien se dirigía el fallo, Poyatos quiso que él también pudiera entender qué se decía en ese documento que tiene nueve páginas y que, en general y como en todas las sentencias, el lenguaje que utiliza es puramente jurídico, fácilmente comprensible para quienes trabajan en ese mundo pero no tanto para cualquier otra persona ―no solo menores― que no lo haga o que no esté relacionada o acostumbrada a tratar con esos textos judiciales.

La magistrada, que fue presidenta de la Asociación de Mujeres Juezas y que lleva años trabajando por hacer de la justicia no solo una justicia con perspectiva feminista sino un ámbito que sea siempre comprensible para la ciudadanía, emitió ese voto particular ―que tuvo que ser un voto particular porque el TSJC no quiso incluirlo en el fallo―, para cumplir, simplemente, con la ley.

Errores de accesibilidad en webs de transporte público: barreras para moverse por la ciudad