Fallo común WCAG 2.2
F59Controles hechos con div o span que no dicen qué son
Nombre oficial en el W3C: Fallo del criterio de conformidad 4.1.2 debido a usar scripts para convertir un div o un span en un control de interfaz de usuario en HTML sin proporcionar una función (role) al control
En pocas palabras
Se produce cuando un botón, una casilla o una pestaña se fabrica con un div o un span y JavaScript, sin indicar su función. El lector de pantalla no sabe qué es ese elemento ni en qué estado está. Lo mejor es usar el elemento HTML nativo; si no se puede, añadir el role de ARIA adecuado.
Por qué es importante
Un lector de pantalla (programa que lee en voz alta lo que hay en la pantalla) anuncia cada control con su tipo: «botón», «casilla de verificación, marcada», «pestaña». Así la persona sabe qué puede hacer con él.
Un div o un span no tienen función propia. Aunque parezcan una casilla, el lector solo lee su texto. La persona no sabe que puede pulsarlo ni si está marcado. Además, estos elementos no reciben el foco del teclado por sí solos.
Cómo evitarlo
- Use primero el elemento nativo:
<button>,<input type="checkbox">,<a href>o<select>. Ya traen función, estado y manejo con teclado. - Si tiene que usar un
divo unspan, añada unrolede ARIA, comorole="checkbox"orole="button". ARIA son atributos que dan información extra a los lectores de pantalla. - Indique el estado con atributos como
aria-checkedoaria-pressed, y actualícelos desde el script. - Dele foco con
tabindex="0"y programe las teclas habituales, como Espacio en una casilla. - Asegúrese de que el control tiene un nombre, por ejemplo su texto visible.
Cómo comprobarlo
- Busque elementos
divospancon eventos comoonclick. En Firefox, la pestaña «Inspector» marca con «event» los elementos que tienen eventos. - Para cada uno, compruebe si tiene un
roleadecuado. - En el panel «Accesibilidad» de las herramientas del navegador (F12), mire su función («Role»). No debe ser «generic» ni estar vacía.
- Llegue al control con NVDA o VoiceOver. Debe anunciar su tipo y su estado.
Ejemplo
Una casilla nativa y, si no hay más remedio, un span con función, estado y foco (el script debe gestionar también la tecla Espacio).
<!-- Mejor opción: casilla nativa -->
<label>
<input type="checkbox"> Incluir firma
</label>
<!-- Si no hay más remedio: span con role y estado -->
<span role="checkbox" aria-checked="false" tabindex="0">
Incluir firma
</span>Ver el texto completo del W3C (traducción al español)
Aplicabilidad
HTML
Descripción
Este fallo muestra cómo el uso de elementos HTML genéricos para crear controles
de interfaz de usuario puede hacer que dichos controles sean inaccesibles para las tecnologías
de asistencia. Las tecnologías de asistencia necesitan conocer la función y el estado actual
de un componente para poder transmitir esa información al usuario. Muchos
elementos HTML tienen funciones bien definidas, como los enlaces, los botones, los campos de texto,
etc. Los elementos genéricos como div y span no
tienen ninguna función predefinida. Cuando se usan estos elementos genéricos para crear
controles de interfaz de usuario en HTML, es posible que la tecnología de asistencia no disponga de la
información necesaria para describir el control e interactuar con él.
span y div, puede resultar desorientador para los
usuarios. Incluso si se tiene cuidado de proporcionar acceso por teclado a estos elementos,
a los usuarios les puede costar descubrir que hay controles interactivos
en el contenido o entender qué tipo de comportamiento esperar
de ellos. Por ejemplo, es posible que los usuarios no sepan qué pulsaciones de teclas admite
el script para activar el elemento. Además, estos elementos no
generan los mismos eventos del sistema operativo que los elementos interactivos, por lo que
es posible que la tecnología de asistencia no reciba ninguna notificación cuando el usuario los activa.Accessible Rich Internet Applications (WAI-ARIA) describe mecanismos para proporcionar la información necesaria sobre función y estado y crear así controles de interfaz de usuario totalmente accesibles.
Ejemplos
El siguiente ejemplo falla porque crea una casilla de verificación con un span y una imagen.
<p>
<span onclick="toggleCheckbox('chkbox')">
<img src="unchecked.gif" id="chkbox" alt=""> Include Signature
</span>
</p>Este es el código del script que cambia el origen de la imagen cuando se hace clic con el ratón en el span.
var CHECKED = "check.gif";
var UNCHECKED = "unchecked.gif";
function toggleCheckbox(imgId) {
var theImg = document.getElementById(imgId);
if (theImg.src.lastIndexOf(CHECKED)!= -1) {
theImg.src = UNCHECKED;
// additional code to implement unchecked action
}
else {
theImg.src = CHECKED;
// additional code to implement checked action
}
}
Una casilla de verificación creada de esta manera no funcionará con las tecnologías de asistencia, ya que no hay ninguna información que la identifique como casilla de verificación. Además, este ejemplo tampoco se puede manejar con el teclado, por lo que fallaría la pauta 2.1.
Pruebas
Procedimiento
- Examinar el código fuente procesado en busca de elementos que tengan manejadores de eventos asignados en el marcado o mediante scripts (lo que indica que el elemento es un control de interfaz de usuario).
- Comprobar si la función del control ya está definida de forma nativa en el lenguaje de marcado.
- Comprobar si se ha usado otro método válido, como la asignación de un role de WAI-ARIA adecuado, para definir la función del control.
Resultados esperados
Si las comprobaciones n.º 2 Y n.º 3 son falsas, se da la condición de fallo.
Recursos
- Accessible Rich Internet Applications (WAI-ARIA)
- WAI-ARIA Authoring Practices Guide (guía de prácticas de autor de WAI-ARIA)
Cómo lo comprobamos en ADDAW
Este error es uno de los que buscamos en cada auditoría de ADDAW. Se lo entregamos con capturas y la forma de corregirlo.
Basado en la técnica F59 del W3C (WCAG 2.2). Explicación y ejemplos: ADDAW. Traducción no oficial del texto del W3C © W3C, licencia de documentos del W3C. ¿Ha visto un error? Escríbanos.