Cuatro razones por las que las capas de accesibilidad no funcionan

En 4 Reasons Why Accessibility Overlays Don’t Work se explican cuatro razones por las que las capas de accesibilidad no funcionan:

1. Accessibility overlays need to be found and activated
   For an accessibility overlay to even begin to be effective, the user must first be able to activate it. Occasionally, the activation and deactivation methods for accessibility overlays are not keyboard accessible, meaning only a mouse can turn them on and off. This design leaves mobile and keyboard-only users unable to access the overlay at all.
   
   Some overlays also can’t be found by screen readers and other assistive technologies. As a result, users relying on those technologies will not be able to find the overlay, rendering it useless.
2. Accessibility overlays may not be compatible with the user’s preferred settings
   People with disabilities usually have their own preferred assistive technologies to help them perform tasks. For example, a user with low vision who uses a screen magnifier probably uses that same screen magnifier when browsing any website and can turn it on and off easily.
   
   Accessibility overlays, however, have their own predefined actions and functions. They do not conform to the user’s preferred technologies and settings. In the example of the user with low vision, this user must figure out how to turn on and configure the overlay’s magnifier tool rather than being able to use the already-configured preferred tool.
3. Accessibility overlays are not universally consistent
   The incompatibility of accessibility overlays with individual user settings might not be as much of a problem if accessibility overlays were universally consistent. However, accessibility overlays created by different companies must each be used differently as well.
   
   Companies should not burden their customers with figuring out how to use each new accessibility overlay. Instead, company websites should be built to conform to current web and accessibility standards. These standards empower all users to access and navigate the website using their preferred devices.
4. Accessibility overlays can’t detect most accessibility issues
   To make a website accessible, a wide variety of criteria must be evaluated across the entire site. Some of these can be automatically evaluated, such as color contrast. However, many items must be evaluated manually to be fully tested.
   
   For example, automated testing can determine if all images across the website have alt tags or if any are missing alternative text. Unfortunately, automated testing cannot determine if the text within each tag is appropriate for each image or not, which is where accessibility overlays fall short and manual testing is required.
   
   Automated testing can usually detect about 20-30% of accessibility issues, meaning accessibility overlays can only detect and address 20-30% of issues. This leaves 70-80% of accessibility issues completely undetected, never mind remedied, posing a significant legal risk to your company.

Accesibilidad Web: Formularios (2)

 

Accesibilidad Web: Formularios (1)

 

Libro gratuito sobre tipografía

Butterick’s Practical Typography es un excelente libro gratuito sobre tipografía. En él podemos leer y aprender cosas muy interesantes como, por ejemplo:

• El subrayado (underlining) es de los tiempos de las máquinas de escribir y se debe emplear en contadas ocasiones.
• Todo el texto en mayúsculas (all caps) genera muchos problemas, también se debe emplear en contadas ocasiones.
• El texto justificado (justified text) siempre se debe emplear junto con la división de palabras. ¿No es posible la división de palabras, como en las páginas web? No uses el justificado.

Y así un montón de consejos más.

WCAG en lenguaje claro

WCAG in Plain English explica los criterios de Web Content Accessibility Guidelines en Plain English.

Plain English (en español, inglés claro o inglés llano) es una forma de redactar en inglés que busca comunicar ideas de manera clara, directa y sencilla, sin ambigüedades ni tecnicismos innecesarios. El objetivo principal es que cualquier persona, independientemente de su nivel educativo o experiencia, pueda entender el contenido en la primera lectura.

Algunas de las características del Plain English, que también se pueden aplicar al español, son:

1. Lenguaje claro y directo: Se evitan las palabras rebuscadas, jergas, tecnicismos o frases demasiado formales.
2. Frases cortas: Se prefieren oraciones simples y de longitud moderada para facilitar la comprensión.
3. Estructura lógica y ordenada: Las ideas se presentan de forma coherente, con buena organización del contenido.
4. Uso activo de los verbos: Se prefiere la voz activa en lugar de la pasiva. Por ejemplo:
• Voz pasiva: The form must be completed by the applicant.
• Voz activa: You must complete the form.
5. Diseño accesible: A menudo, el Plain English también considera la presentación visual del texto (títulos claros, listas, espacios en blanco).

En realidad, es muy fácil de entender qué es Plain English (o español claro): es justo lo contrario de lo que usan los políticos o la administración pública.

¿Y por qué es importante usar Plain English o español claro? Algunos de los beneficios son:

• Mejora la comunicación con públicos amplios y, en especial, con algunos grupos de personas con discapacidad.
• Facilita la comprensión de documentos legales, administrativos o técnicos.
• Aumenta la transparencia en la comunicación institucional.
• Es clave en ámbitos como el gobierno, la salud, las finanzas, la educación y la accesibilidad web.

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