Skip to main content
Accesibilidad Axe Core 4.11

Los atributos ARIA deben usarse como 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 indica que no deberían usarse, el resultado es un comportamiento impredecible entre navegadores y tecnologías de asistencia. Los diferentes navegadores manejan estos conflictos de forma inconsistente: algunos ignoran el atributo ARIA, otros sobrescriben 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 que un usuario de lector de pantalla en otro, creando una experiencia confusa y poco confiable.

Esta regla se relaciona con el Criterio de Cumplimiento 4.1.2 de WCAG 2.0/2.1/2.2: Nombre, Rol, Valor (Nivel A), que requiere que para todos los componentes de interfaz de usuario, el nombre, rol 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 motoras que usan dispositivos de entrada alternativos que dependen de información ARIA precisa.

Hay dos escenarios principales que verifica esta regla:

El atributo aria-checked en casillas de verificación nativas

El atributo aria-checked no debería 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 nativo checked y el valor aria-checked se dessincronizan, lo cual es fácil de hacer, algunas tecnologías de asistencia informarán el estado nativo mientras que otras informará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 nativa checked. Si necesitas un estado “mixto” o indeterminado, establece la propiedad indeterminate en la casilla de verificación vía 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 conmutable 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 un contexto de cuadrícula de árbol. Cuando se usan dentro de una <table> plana o grid, estos atributos no sirven ninguna función y pueden causar que los lectores de pantalla anuncien información confusa o sin sentido.

Cómo solucionarlo

O 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 expandible. Si cambias a treegrid, asegúrate de que las celdas usen role="gridcell" y que el patrón de interacción de 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

Mal ejemplo: aria-checked en una casilla de verificación nativa

El atributo aria-checked entra en conflicto con el estado nativo de la casilla de verificación.

<label>
  <input type="checkbox" aria-checked="true">
  Acepto hacer mi sitio web accesible
</label>

Buen ejemplo: casilla de verificación nativa sin aria-checked

El navegador comunica el estado marcado nativamente; no se necesita sobrescribir ARIA.

<label>
  <input type="checkbox" checked>
  Acepto hacer mi sitio web accesible
</label>

Buen ejemplo: casilla de verificación personalizada usando aria-checked

Al crear 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>

Mal ejemplo: atributos de árbol en filas dentro de una tabla plana

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>

Buen ejemplo: 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>

Buen ejemplo: eliminando atributos no compatibles de una tabla plana

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.