Novedades de WCAG 2.1: Etiqueta en el nombre

Las recomendaciones WCAG 2.1 se implementaron en 2018. Han pasado un par de años y hay algunos criterios de éxito nuevos. En este artículo, analizaré Label in Name , que es cómo etiquetamos visualmente los componentes. Veremos cómo se ven algunos estados de falla, cómo solucionarlos y ejemplos de cómo hacerlos correctamente.

Me perdiste en Success Criterion…

Un criterio de éxito es una declaración comprobable que no es específica de una tecnología. Es la base a partir de la cual determinamos si nuestro trabajo es “accesible”. En este caso, lo que se evalúa es “Etiqueta en el nombre”, que se encuentra entre una gran cantidad de otros criterios. WCAG 2.1 es la versión actual de la especificación y “Etiqueta en el nombre” es el elemento 2.5.3, lo que indica que está en la segunda categoría (“Operable”) del criterio, en la quinta sección (“Modalidades de entrada”) de esa categoría. marcado como el tercer elemento de la sección.

WCAG 2.1 es compatible con versiones anteriores de WCAG 2.0, lo que significa que es una extensión de WCAG 2.0. Además, las versiones de WCAG 2.1 y 2.2 se combinan entre sí y todas funcionan juntas.

Etiqueta en nombre

Entonces, volviendo a las cosas, 2.5.3 Etiqueta en el nombre (Nivel A) es nueva y está definida en el Criterio de éxito WCAG 2.1. Así es como se describe:

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

La intención de este Criterio de Conformidad (SC) es garantizar que las palabras que una etiqueta tiene visualmente en el componente también se incluyan en las palabras asociadas programáticamente con el componente. Esto ayuda a garantizar que cualquier persona, ya sea alguien que utilice software de reconocimiento de voz o alguien con discapacidad visual, pueda confiar en las etiquetas para describir la intención de un componente o cómo interactuar con él. La etiqueta de texto visual y el nombre programático no tienen que ser exactos, pero deben contener un trabajo común que los asocie (por ejemplo, “Enviar” con “Enviar ahora”).

La cuestión es que no haya confusión, por discrepancia, entre lo que se lee y lo que se ve.

Tecnología de asistencia en acción

Usemos el ejemplo de un formulario de contacto HTML. Un usuario puede utilizar software de reconocimiento de voz para completar un formulario y llegar al final donde se envía el formulario y se envía.

Digamos que la etiqueta del botón y el texto visual del botón no son consistentes:

form  label    Message:    textarea name="message"/textarea  /label  button aria-label="Submit"Send/button/form

En el ejemplo anterior, el botón no funciona correctamente para la tecnología de asistencia . El botón contiene el texto “Enviar”, pero aria-labeles “Enviar”. Aquí es donde reside el fracaso. La etiqueta visual (“Enviar”) no coincide con el nombre programático (“Enviar”) y no proporciona ninguna asociación entre los dos.

Cuando coinciden o tienen un término común, los usuarios de software de reconocimiento de voz pueden navegar hablando las etiquetas de texto visibles de componentes como enlaces, botones y menús. En este caso podríamos solucionarlo haciendo coincidir la etiqueta y el texto. Pero como aria-labelno agrega ningún valor, eliminarlo por completo es una mejor solución:

form  label    Message:    textarea name="message"/textarea  /label  buttonSend/button/form 

Los usuarios videntes que utilizan lectores de pantalla también tendrán una mejor experiencia si el texto que escuchan es similar al texto que ven en la pantalla.

Cuando la etiqueta y el texto visual no coinciden, los usuarios de entrada de voz que intenten utilizar la etiqueta de texto visible como medio de navegación (por ejemplo, “mover al nombre”) o selección se quedarán atascados porque la etiqueta visible pronunciada por el usuario no coincide. no coincide o no forma parte del nombre accesible que está habilitado como parte del comando de entrada de voz.

Además, cuando el nombre accesible es diferente de la etiqueta visible, puede funcionar como un comando oculto que los usuarios de entrada de voz pueden activar accidentalmente . SC no se aplica cuando no existe una etiqueta de texto visible para un componente.

Código en acción

Aquí hay tres estados de falla diferentes.

• buttonUn elemento problemático donde la etiqueta hablada y la etiqueta visual no tienen asociación.
• Una falta de coincidencia de etiquetas en la que el texto hablado lee más contenido que la etiqueta visual debido a un lapso “accesiblemente oculto”.
• Una entrada con una etiqueta hablada a través de aria-labelledby, que no logra establecer una correlación entre la etiqueta hablada y visual.

Nuevamente, todos estos son ejemplos de malas prácticas, según la Etiqueta 2.5.3 en Nombre SC.

En 2020, el proyecto WebAIM Million evaluó 4,2 millones de entradas de formularios y descubrió que el 55% no estaban etiquetados incorrectamente, ya sea a través de label, aria-label o aria-labelledby.

Cuando trabajamos con formularios, la mayoría de nosotros estamos bastante acostumbrados a combinar a labelcon inputotro control de formulario. Eso es increíble y una excelente manera de indicar lo que hace el control, pero también está el nombre programático del control , que también se conoce como el “nombre accesible” usando un archivo aria-label.

Obtenemos una mejor experiencia de usuario cuando el nombre del archivo labelse puede asociar con el nombre programático (o accesible) en el archivo aria-label. Por ejemplo, si usamos “Nombre” para una entrada label, entonces probablemente queramos que nuestro aria-labelsea “Nombre” o algo por el estilo también. No lograr establecer una conexión entre los nombres programáticos y las etiquetas visibles puede ser un desafío mayor para los usuarios con desafíos cognitivos. Requiere una carga cognitiva adicional para los usuarios de entrada de voz que deben recordar decir un comando de voz que sea diferente de la etiqueta visible que ven en un control. También se crea una carga cognitiva adicional cuando un usuario de texto a voz necesita absorber y comprender la salida de voz que no se puede conectar a la etiqueta visible. Estos formularios se enviarán, pero esto tiene un costo para la accesibilidad y los usuarios discapacitados.

¡Aquí están esos tres ejemplos de arriba arreglados!

Texto en detalles de la etiqueta

Según las WCAG SC, el texto no debe considerarse una etiqueta visible si se usa de manera simbólica en lugar de expresarlo directamente en lenguaje humano. Un editor de texto enriquecido es un buen ejemplo de esto porque un editor puede usar imágenes como texto (lo cual se incluye en 1.4.5 Imágenes de texto ).

Para hacer coincidir el texto de la etiqueta y el nombre accesible, es importante determinar qué texto debe considerarse la etiqueta de cualquier componente para un control determinado. A menudo hay varias cadenas de texto en una interfaz de usuario que pueden ser relevantes para un control. Hay razones por las que la etiqueta que se encuentra muy cerca debe considerarse la etiqueta de texto. Se trata de establecer un patrón de previsibilidad para los usuarios que interactúan con un componente. Estas razones sugieren que se deben colocar etiquetas visibles:

• inmediatamente a la izquierda de las entradas de texto, cuadros desplegables y otros widgets o componentes.
• inmediatamente a la derecha de las casillas de verificación y los botones de opción.
• dentro de botones o pestañas o inmediatamente debajo de iconos que sirven como botones.

La puntuación y las mayúsculas también pueden considerarse opcionales si se utilizan de forma simbólica. Por ejemplo, “Nombre” está bien en lugar de “Nombre:” y “Siguiente” está bien en lugar de “Siguiente…” y así sucesivamente.

Otra cosa a considerar: las WCAG SC no consideran los componentes sin una etiqueta visual.

Un etiquetado adecuado tiene sus ventajas

El principal beneficio de hacer coincidir las etiquetas de un componente con su correspondiente nombre accesible es que brinda a los usuarios de entrada de voz la capacidad de activar controles en una página sin tener que cambiar el enfoque o hacer conjeturas entre dos términos diferentes.

Al final, utilizar una terminología clara y coherente entre lo que se ve y lo que se habla proporciona una experiencia de usuario más agradable (para todos) porque las etiquetas que se leen mediante tecnologías de asistencia coinciden con las etiquetas visibles que también se pueden ver y leer. De esto hablamos con el diseño inclusivo: todos ganan y nadie queda fuera.

Resumen

Acabamos de desglosar algunos de los puntos más finos del Criterio de éxito WCAG 2.5.3 para etiquetas en nombres. Parece algo sencillo de seguir. Pero como hemos visto, hay situaciones en las que no está tan claro.

El objetivo de adherirse a este criterio es, por supuesto, hacer que nuestro trabajo sea accesible e inclusivo para todas las personas. Las WCAG nos ayudan a saber si tenemos éxito no solo al proporcionar pautas, sino también al establecer grados de cumplimiento (A, AA, AAA, donde AAA es el más alto). El texto en la etiqueta cae en la calificación A, lo que significa que es un nivel básico de cumplimiento. Para obtener la calificación, la WCAG busca :

[…] componentes de la interfaz de usuario con etiquetas que incluyen texto o imágenes de texto , el nombre contiene el texto que se presenta visualmente.

Podemos probar y asegurarnos de que nuestro código esté completo y correcto mirando el código fuente del sitio, usando DevTools de un navegador, como Chrome o Firefox, o ejecutando una auditoría de accesibilidad usando herramientas como la extensión del navegador WAVE (Chrome y Firefox) y Axe de Deque Systems (Chrome).

En resumen, hay personas reales al otro lado del cristal y hay cosas que podemos hacer en nuestro código y diseños para ayudarlos a disfrutar de la interacción con los componentes que fabricamos. El texto en la etiqueta es solo uno de los muchos criterios descritos en las WCAG y, si bien puede parecer un pequeño detalle, cumplirlo puede tener un gran impacto en nuestros usuarios.