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)