Acerca de esta regla de accesibilidad
Cuando los atributos ARIA se aplican a elementos donde la especificación dice que no deben usarse, el resultado es un comportamiento impredecible entre navegadores y tecnologías de asistencia. Diferentes navegadores manejan estos conflictos de manera inconsistente: algunos ignoran el atributo ARIA, otros anulan el estado nativo, y otros pasan ambos valores. Esta inconsistencia significa que un usuario de lector de pantalla en un navegador puede escuchar un estado completamente diferente al de un usuario de lector de pantalla en otro, creando una experiencia confusa y poco confiable.
Esta regla se relaciona con WCAG 2.0/2.1/2.2 Criterio de Éxito 4.1.2: Nombre, Función, Valor (Nivel A), que requiere que para todos los componentes de la interfaz de usuario, el nombre, función y estados puedan determinarse programáticamente. Cuando los atributos ARIA entran en conflicto con la semántica nativa o se usan fuera de su contexto permitido, el estado determinado programáticamente se vuelve ambiguo o incorrecto. Los usuarios afectados incluyen personas ciegas o sordociegas que dependen de lectores de pantalla, así como personas con discapacidades motrices que usan dispositivos de entrada alternativos que dependen de información ARIA precisa.
Hay dos escenarios principales que esta regla verifica:
El atributo aria-checked en casillas de verificación nativas
El atributo aria-checked no debe usarse en un elemento <input type="checkbox">. Las casillas de verificación HTML nativas ya comunican su estado marcado al árbol de accesibilidad del navegador a través de la propiedad checked. Cuando añades aria-checked encima de esto, creas dos fuentes de verdad que compiten. Si el estado checked nativo y el valor aria-checked se dessincronizan, lo cual es fácil que ocurra, algunas tecnologías de asistencia reportarán el estado nativo mientras que otras reportarán el estado ARIA. El usuario no tiene forma de saber cuál es correcto.
Cómo solucionarlo
Tienes dos opciones:
-
Elimina
aria-checkedy confía en el atributo o propiedadcheckednativa. Si necesitas un estado “mixto” o indeterminado, establece la propiedadindeterminateen la casilla de verificación mediante JavaScript. -
Reemplaza la casilla de verificación nativa con un elemento personalizado (por ejemplo, un
<div>o<span>) que userole="checkbox"junto conaria-checked. Al hacer esto, también debes asegurar que el elemento sea accesible por teclado (enfocable y activable con Espacio) y tenga un nombre accesible.
Atributos específicos de fila fuera de un treegrid
Los atributos aria-posinset, aria-setsize, aria-expanded y aria-level solo son válidos en una fila (un elemento <tr> o un elemento con role="row") cuando esa fila está dentro de un treegrid. Estos atributos describen relaciones jerárquicas de árbol: posición dentro de un conjunto, nivel de anidamiento y capacidad de expansión, que son conceptos que solo tienen sentido en el contexto de una cuadrícula de árbol. Cuando se usan dentro de una <table> simple o grid, estos atributos no sirven ninguna función y pueden hacer que los lectores de pantalla anuncien información confusa o sin sentido.
Cómo solucionarlo
O bien elimina los atributos no compatibles de las filas, o cambia el rol del contenedor padre a treegrid si los datos realmente representan una estructura jerárquica y expandible. Si cambias a treegrid, asegúrate de que las celdas usen role="gridcell" y que el patrón de interacción con el teclado coincida con lo que los usuarios esperan de una cuadrícula de árbol (navegación con teclas de flecha para expandir/contraer filas).
Ejemplos
Ejemplo malo: aria-checked en una casilla de verificación nativa
El atributo aria-checked entra en conflicto con el estado de la casilla de verificación nativa.
<label>
<input type="checkbox" aria-checked="true">
Acepto hacer mi sitio web accesible
</label>
Ejemplo bueno: casilla de verificación nativa sin aria-checked
El navegador comunica el estado marcado de forma nativa, no se necesita anulación ARIA.
<label>
<input type="checkbox" checked>
Acepto hacer mi sitio web accesible
</label>
Ejemplo bueno: casilla de verificación personalizada usando aria-checked
Al construir una casilla de verificación personalizada, aria-checked es apropiado porque no hay estado marcado nativo.
<div role="checkbox" aria-checked="true" tabindex="0" aria-label="Acepto hacer mi sitio web accesible">
✓ Acepto hacer mi sitio web accesible
</div>
Ejemplo malo: atributos de árbol en filas dentro de una tabla simple
Los atributos aria-level y aria-expanded no son válidos en filas dentro de una <table>.
<table>
<tr aria-level="1" aria-expanded="false">
<td>Mis Descargas</td>
</tr>
<tr aria-level="2">
<td>Documentos</td>
</tr>
</table>
Ejemplo bueno: atributos de árbol en filas dentro de un treegrid
Cambiar el rol de la tabla a treegrid hace que estos atributos sean válidos y significativos.
<table role="treegrid">
<tr aria-level="1" aria-expanded="false">
<td role="gridcell">Mis Descargas</td>
</tr>
<tr aria-level="2" class="hidden">
<td role="gridcell">Documentos</td>
</tr>
</table>
Ejemplo bueno: eliminando atributos no compatibles de una tabla simple
Si los datos no son jerárquicos, simplemente elimina los atributos relacionados con árboles.
<table>
<tr>
<td>Mis Descargas</td>
</tr>
<tr>
<td>Documentos</td>
</tr>
</table>
Learn more:
Ayúdanos a mejorar nuestras guías
Detecta problemas de accesibilidad automáticamente
Rocket Validator escanea miles de páginas con Axe Core y el W3C Validator, encontrando problemas de accesibilidad en todo tu sitio web.