Donar
Donar
Para los componentes de interfaz con etiquetas que incluyen texto o imágenes de texto, el nombre accesible contiene el texto que se presenta visualmente.
Una buena práctica es poner el texto de la etiqueta al comienzo del nombre accesible.
El objetivo de este Criterio de Conformidad es asegurar que las palabras que etiquetan visualmente un componente sean también las palabras asociadas con el componente de manera programática. Esto ayuda a garantizar que las personas con discapacidades puedan confiar en las etiquetas visibles como medio para interactuar con los componentes.
La mayoría de los controles van acompañados de una etiqueta de texto visible. Esas mismas etiquetas tienen un nombre programático, también conocido como Nombre Accesible. Los usuarios generalmente tienen una experiencia mucho mejor si las palabras y caracteres en la etiqueta visible de un control coinciden o están contenidos dentro del nombre accesible. Cuando coinciden, los usuarios de entrada de voz (es decir, usuarios de aplicaciones de reconocimiento de voz) pueden navegar hablando las etiquetas de texto visibles de los componentes, como menús, enlaces y botones, que aparecen en la pantalla. Los usuarios con discapacidades visuales que utilizan texto a voz (por ejemplo, lectores de pantalla) también tendrán una mejor experiencia si el texto que escuchan coincide con el texto que ven en la pantalla.
Cabe destacar que este Criterio de Conformidad no se aplica a los componentes que no tienen una etiqueta de texto visible.
Cuando existen etiquetas de texto y están correctamente vinculadas a los componentes de la interfaz de usuario a través de prácticas de autoría establecidas, la etiqueta y el nombre suelen coincidir. Cuando no coinciden, los usuarios de entrada de voz que intentan utilizar la etiqueta de texto visible como medio de navegación o selección (por ejemplo, 'mover a Contraseña') no tendrán éxito. La navegación basada en voz falla porque la etiqueta visible hablada por los usuarios no coincide (o no forma parte de) el nombre accesible que está habilitado como un comando de entrada de voz. Además, cuando el nombre accesible es diferente de la etiqueta visible, puede funcionar como un comando oculto que puede ser activado accidentalmente por usuarios de entrada de voz.
Las discrepancias entre las etiquetas visibles y los nombres programáticos de los controles son aún más problemáticas para los usuarios de entrada de voz y texto a voz que también tienen desafíos cognitivos. Las discrepancias crean una carga cognitiva adicional para los usuarios de entrada de voz, que deben recordar decir un comando de voz diferente a la etiqueta visible que ven en un control. También crea una carga cognitiva adicional para un usuario de texto a voz absorber y comprender la salida de voz que no coincide con la etiqueta visible.
Para que el texto de la etiqueta y el nombre accesible coincidan, primero es necesario determinar qué texto en la pantalla se debe considerar como la etiqueta de cualquier control dado. A menudo, hay múltiples cadenas de texto en una interfaz de usuario que pueden ser relevantes para un control. Sin embargo, hay razones por las que es mejor interpretar de manera conservadora que la etiqueta es solo el texto en proximidad cercana.
Convencionalmente, la etiqueta para los componentes de la interfaz de usuario es la cadena de texto adyacente. La posición típica para idiomas de izquierda a derecha es:
Es importante sesgar hacia tratar solo el texto adyacente como una etiqueta porque interpretaciones amplias de lo que constituye una etiqueta de texto pueden poner en peligro el valor de este Criterio de Conformidad (CE) al reducir la previsibilidad. El aislamiento de la etiqueta a la única cadena de texto en proximidad cercana al componente facilita que los desarrolladores, probadores y usuarios finales identifiquen la etiqueta objetivo de evaluación en este CE. La interpretación previsible de la etiqueta permite a los usuarios de tecnologías de reconocimiento de voz interactuar con el elemento a través de su etiqueta posicionada convencionalmente, y permite a los usuarios de tecnologías de lectura de pantalla disfrutar de consistencia entre la etiqueta visible cercana y el nombre anunciado del componente.
Cabe destacar que el texto de marcador de posición dentro de un campo de entrada no se considera un medio apropiado para proporcionar una etiqueta. La especificación de HTML5 establece que el atributo de marcador de posición no debe usarse como una alternativa a una etiqueta. Sin embargo, vale la pena mencionar que 'etiqueta' en esa declaración de HTML5 está entre corchetes de código y enlaza con el elemento de etiqueta. Para los propósitos de este Criterio de Éxito de Etiqueta en Nombre, 'etiqueta' no se utiliza en un sentido programático, sino que simplemente se refiere a una cadena de texto en proximidad visual cercana a un componente. Como tal, en ausencia de cualquier otra cadena de texto cercana (como se describe en la lista anterior), si un campo de entrada contiene texto de marcador de posición, dicho texto puede ser considerado como candidato para Etiqueta en Nombre. Esto es respaldado tanto por el cálculo del nombre accesible (discutido posteriormente) como por el sentido práctico de que cuando no se proporciona una etiqueta visible de otra manera, es probable que un usuario de entrada de voz intente usar el valor del texto de marcador de posición como medio para interactuar con la entrada.
Las etiquetas de texto 'expresan algo en lenguaje humano'
Caracteres de texto simbólicos
Para los fines de este CE, el texto no debe considerarse una etiqueta visible si se utiliza de manera simbólica en lugar de expresar directamente algo en lenguaje humano, según la definición de texto en las Pautas de Accesibilidad para el Contenido Web (WCAG, por sus siglas en inglés). Por ejemplo, el criterio de conformidad 1.4.5 Imágenes de Texto describe consideraciones para 'caracteres de texto simbólicos'. En el ejemplo de imágenes de texto, 'B', 'I' y 'ABC' aparecen en iconos en un editor de texto, donde se utilizan como símbolos de las funciones de Negrita, Cursiva y Ortografía, respectivamente. En este caso, el nombre accesible debería ser la función que cumple el botón (por ejemplo, 'Revisar ortografía' o 'Verificar ortografía'), no los caracteres simbólicos visibles. Se muestra un editor de texto similar en la figura siguiente.
Figura 1. Detalle del editor de texto enriquecido en Github, que muestra una variedad de íconos sin etiquetas, incluyendo íconos que se asemejan a caracteres de texto.
Del mismo modo, cuando un autor ha utilizado un símbolo de mayor que ('>') para imitar la apariencia de una flecha hacia la derecha, el texto no comunica algo en lenguaje humano. Es un símbolo, en este escenario probablemente destinado a imitar los íconos utilizados para un botón de 'Reproducir' o una flecha de 'Siguiente'.
Puntuación y mayúsculas
El uso de puntuación y mayúsculas en las etiquetas también puede considerarse opcional por la misma razón. Por ejemplo, los dos puntos que se agregan convencionalmente al final de las etiquetas de entrada no expresan algo en lenguaje humano, y las mayúsculas en la primera letra de cada palabra en una etiqueta normalmente no alteran el significado de las palabras. Esto es especialmente relevante en el contexto de este SC, ya que está dirigido principalmente a usuarios de reconocimiento de voz; las mayúsculas y la mayoría de la puntuación suelen ser ignoradas cuando un usuario habla una etiqueta como medio de interacción con un control.
Si bien no es un error incluir los dos puntos y las mayúsculas en el nombre accesible, un nombre computado de 'Nombre' no debe considerarse un error de 'Nombre:'.
Igualmente, 'Siguiente...' mostrado visiblemente en un botón podría tener 'Siguiente' como nombre accesible. Cuando haya dudas, si existe una etiqueta visible significativa, coincida exactamente con la cadena para el nombre accesible.
Expresiones matemáticas y fórmulas
Las expresiones matemáticas son una excepción a la sección anterior sobre caracteres simbólicos. Los símbolos matemáticos se pueden usar como etiquetas; por ejemplo, '11x3=33' y 'A>B' transmiten un significado. La etiqueta no debe ser modificada en el nombre accesible, y se deben evitar las sustituciones de palabras donde se utiliza una fórmula, ya que hay varias formas de expresar la misma ecuación. Por ejemplo, cambiar el nombre a 'once multiplicado por tres es equivalente a treinta y tres' podría significar que un usuario que dijo 'once por tres igual a treinta y tres' no coincide. Es mejor dejar las fórmulas tal como se usan en la etiqueta y confiar en la familiaridad del usuario con su software de reconocimiento de voz para lograr una coincidencia. Además, convertir una etiqueta de fórmula matemática en un nombre accesible que sea equivalente escrito puede crear problemas de traducción. El nombre debe coincidir con el texto de fórmula de la etiqueta. Tenga en cuenta que una consideración para los autores es usar el símbolo adecuado en la fórmula. Por ejemplo, '11x3' (con una letra X en minúscula o mayúscula), '11*3' (con el símbolo de asterisco) y '11×3' (con el símbolo de ×) son fáciles de interpretar para los usuarios con visión, pero es posible que no sean todos reconocidos como '11 por 3' por el software de reconocimiento de voz. Se debe usar el símbolo de operador adecuado (en este caso, el símbolo de multiplicación)
Especificación de cálculo de Nombre y Descripción Accesible
Es importante entender cómo se deriva el nombre accesible. La Especificación de Cálculo de Nombre y Descripción Accesible 1.1 y las Asignaciones de la API de Accesibilidad HTML 1.0 describen cómo se calcula el nombre accesible, incluyendo qué atributos se consideran en su cálculo y en qué orden de preferencia. Si un componente tiene varios posibles valores de atributos que podrían ser usados como su nombre accesible, solo se calculará el valor más preferido de esos valores. Ninguno de los otros valores menos preferidos formará parte del nombre. En su mayor parte, las relaciones programáticas establecidas existentes entre etiquetas y controles se refuerzan mediante la especificación.
Otros textos mostrados en la pantalla que estén correctamente codificados para cumplir con el Criterio de Conformidad 1.3.1: Información y Relaciones normalmente no se tienen en cuenta en el cálculo del nombre accesible de un componente de interfaz de usuario sin intervención del autor (a través de técnicas de etiquetado ARIA). Los más comunes de estos son:
Esta información textual puede constituir parte de la descripción del componente. Por lo tanto, desde un punto de vista programático y desde la táctica conservadora de considerar solo una 'etiqueta de texto adyacente' como etiqueta, ni los encabezados, ni las instrucciones, ni las 'etiquetas' de grupo normalmente deben considerarse etiquetas con el propósito de este Criterio de Conformidad.
Es importante tener en cuenta que la especificación permite a los autores anular el nombre calculado a través de la semántica nativa. Tanto aria-label como aria-labelledby tienen prioridad en el cálculo del nombre, anulando el texto visible como nombre accesible incluso cuando la etiqueta de texto visible está asociada programáticamente con el control. Por esta razón, cuando ya existe una etiqueta visible, se debe evitar el uso de aria-label o usarlo con cuidado, y aria-labelledby se debe usar como un complemento con precaución.
Finalmente, aria-describedby no se incluye en el cálculo del Nombre Accesible (en cambio, forma parte del cálculo de la Descripción Accesible). Por convención, el texto asociado a un control a través de aria-describedby se anuncia inmediatamente después del nombre accesible por los lectores de pantalla. Por lo tanto, el contexto de los encabezados, instrucciones y etiquetas de grupo se puede proporcionar a través de la descripción accesible para ayudar a los usuarios de lectores de pantalla sin afectar la experiencia de aquellos que navegan usando software de reconocimiento de voz.