lunes, 9 de julio de 2018

WCAG 2.1 Comprende el criterio "2.5.3 Etiqueta en el nombre"

En este vídeo explico algunos de los problemas que pretende evitar el nuevo criterio "2.5.3 Etiqueta en el nombre (A)" de las WCAG 2.1, el cual dice así:

Para los componentes de la interfaz de usuario con etiquetas que incluyen texto o imágenes de texto, el nombre accesible contiene el texto que se presenta visualmente.

Nota: una buena práctica es poner el texto de la etiqueta al comienzo del nombre accesible.

Transcripción del vídeo

Ver el vídeo en YouTube

Nota errata: al comienzo del vídeo nombro el criterio como "2.5.3 Nombre en la etiqueta" pero es en realidad "2.5.3 Etiqueta en el nombre".

Hay que tener en cuenta que la interacción dependerá del programa de reconocimiento de voz y el navegador utilizado. Yo he utilizado Edge y el programa de reconocimiento de voz que viene por defecto con Windows 10. Puedes activarlo pulsando las teclas Control + Tecla Windows + S, y configurarlo desde "Configuración > Accesibilidad > Voz"

En el vídeo pongo como ejemplo botones input cuya etiqueta visible determinada por el atributo value no se corresponde con su nombre accesible determinado por el atributo aria-label.

Errores comunes en los nombres accesibles:

  • que no contengan el texto visible: <button aria-label=”Volver a inicio”>Subir arriba</button>
  • que contenga el texto visible pero las palabras de la etiqueta visible estén en un orden diferente: <button aria-label=”Arriba. Subir a inicio”>Subir arriba</button>
  • que contengan el texto visible pero una o más palabras se entremezclan con la etiqueta: <button aria-label=”Subir con este botón a la parte de arriba de la página”>Subir arriba</button>
  • que contengan el texto visible pero que haya una o más palabras adicionales antes del texto de la etiqueta visible: <button aria-label=”Volver a inicio (Subir arriba)”>Subir arriba</button>

Excepción

No aplica si la etiqueta visible se usa de manera simbólica en vez de expresar algo directamente en lenguaje humano.

Por ejemplo, los botones de flecha en un carrusel o el botón "B" en una barra de herramientas para formatear un texto en negrita.

Por tanto, podría considerarse que la "X" para cerrar una ventana modal entra dentro de esta categoría y no sería obligatorio incluirla en el aria-label.

Recursos de interés

Si quieres ver cómo utiliza un persona con poca destreza manual un programa de reconocimiento de voz, en concreto Dragon Naturally Speaking, te recomiendo el vídeo de Claudia Tecglen en el canal de YouTube de la UNED.

Descarga la herramienta gratuita para evaluar el criterio generar gráficas, estadísticas y tablas resumen para informes de accesibilidad web de acuerdo a las WCAG 2.1. También disponible para WCAG 2.0

Audit Tool WCAG 2.1 (artículo de presentación)

Audit Tool WCAG 2.1

Descarga la herramienta gratuita para validar el criterio 1.4.12 Espaciado del texto (AA)

WCAG 2.1. Criterio 1.4.12 (AA) Herramienta gratuita para evaluarlo

Ventana de menú de Explorer para indicar tu CSS personal. Por debajo los destacados de una web con el texto desbordado o cortado.

Transcripción del vídeo

Hola, soy Olga Carreras del blog "Usable y accesible" y en este vídeo te voy a explicar uno de los problemas que pretende evitar el criterio "2.5.3 Etiqueta en el nombre", que es uno de los nuevos criterios de las WCAG 2.1 de nivel A.

Para ello he abierto un programa de reconocimiento de voz, en concreto el que viene por defecto con Windows 10, que es un tipo de software que permite interactuar mediante la voz y es muy útil para muchas personas con discapacidad motriz. Voy a activarlo y mediante la voz voy a pulsar el botón "Subscribir" a través de su etiqueta visible.

[Se activa el programa de reconocimiento de voz y se dice:] "Subscribir".

Como hemos visto, cuando he dicho la etiqueta visible "subscribir" he activado el botón y se ha abierto una ventana. Vamos a ver qué ocurre si modifico este elemento, que es un botón estándar, y le añado el atributo aria-label="hola" que permite etiquetar elementos pero anulando la etiqueta nativa, es decir, a partir de ahora el lector de pantalla me anunciará "botón Hola" en vez de "botón Subscribir", y voy a poder interactuar con él mediante el programa de reconocimiento de voz a través de la palabra "hola" en vez de la palabra "subscribir", que es ahora su nombre accesible (ya no lo es su etiqueta visible).

[Se activa el programa de reconocimiento de voz y se dice:] "Hola".

Como hemos visto, ahora he activado el botón con la palabra "hola". Entonces este criterio lo que pretende es evitar los problemas derivados de que la etiqueta visible no coincida con el nombre accesible, porque en esos casos las personas que utilizan un programa de reconocimiento de voz podrían activar sin querer algún los elementos o por el contrario, no conseguir activar otros.

Además, las personas que ven la pantalla pero utilizan un lector de pantalla podrían sentirse desconcertadas cuando la etiqueta visible y el nombre que les está anunciado el lector no coinciden.

Sin embargo, el criterio no obliga a que sean iguales (el nombre accesible y la etiqueta visible) sino a que al menos el nombre accesible comience con el texto de la etiqueta visible.

En este segundo ejemplo tenemos una ventana modal y un botón con la etiqueta visible "X". A este botón le hemos añadido el atributo aria-label para anular su etiqueta nativa, es decir, la visible ("X") por una etiqueta más clara ("Cerrar ventana").

De tal manera que al usuario de lector de pantalla se le anuncie "botón Cerrar ventana" en vez de "botón x". Pero, cumpliendo con el criterio 2.5.3 lo que hacemos además es, para evitar los problemas que hemos visto a los usuarios que utilizan un programa de reconocimiento de voz, añadirle delante el texto de la etiqueta visible, es decir "x Cerrar ventana".

Vamos a ver que el programa de reconocimiento de voz no tiene problemas para activarlo.

[Se activa el programa de reconocimiento de voz y se dice:] "x".

Bueno, como veis no ha habido ningún problema para cerrar la ventana diciendo "x". Espero que os haya sido útil este vídeo para aclarar un poco más el criterio 2.5.3 y podéis seguir consultando el blog para leer más artículos o descargar herramientas relacionadas con las WCAG 2.1.

[Fin de la transcripción]

3 comentarios :
Grup TO de la Fundación COAATT (to.fundacio@coaatt.org) dijo...

Muchas gracias, ha sido muy instructivo.

Berta Nicolau dijo...

Hola Olga, nos surge una duda, que pasa con todos los botones que tienen forma de icono? Por ejemplo:

Un input con un botón de busqueda en forma de lupa, o un slider con las flechas atras y adelante, que funcionamiento deben tener ahora? Hasta ahora las cargavamos como imagen con texto alternativo, pero visto esto de las etiquetas parece que los enlaces tendran que ser siempre texto?

Muchas gracias por tu blog! Es de gran ayuda

Olga Carreras dijo...

Hola Berta,

Este criterio aplica a:

- los botones de tipo imagen que tienen un texto
- cualquier otro elemento de texto que tiene aria-label / aria-labelledby

Si tienes un botón sin texto, como una lupa, no aplica. Puede una imagen con un texto alternativo. Simplemente preocupante de que el texto alternativo explique bien su función, de que se pueda llegar hasta él con el teclado y que cumpla con los requisitos de contraste de color.

Saludos,

Publicar un comentario