CAPTCHA: Análisis de su accesibilidad

 

Selección del perfil de persona con discapacidad

El sitio web Accessible Kazakhstan permite consultar las características de accesibilidad de varias ciudades de Kazajistán.

La primera vez que se accede al sitio web aparece un selector de perfiles de discapacidad:

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

¿aria-label o title?

En aria-label or title? Screen Reader Behaviour Explained se explica la diferencia entre los atributos aria-label y title, su importancia para la accesibilidad web y consejos para su correcto uso.

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.