Skip to main content
Accesibilidad Axe Core 4.11

Los atributos ARIA deben usarse según se especifica para el rol del elemento

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:

  1. Elimina aria-checked y confía en el atributo o propiedad checked nativa. Si necesitas un estado “mixto” o indeterminado, establece la propiedad indeterminate en la casilla de verificación mediante JavaScript.
  2. Reemplaza la casilla de verificación nativa con un elemento personalizado (por ejemplo, un <div> o <span>) que use role="checkbox" junto con aria-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>

Ayúdanos a mejorar nuestras guías

¿Te ha sido útil esta guía?

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.

¿Listo para validar tus sitios?
Inicia tu prueba gratuita hoy.