Sobre esta regra de acessibilidade
A especificação WAI-ARIA define quais atributos são permitidos, obrigatórios ou proibidos para cada role. Quando você usa um atributo proibido num role, está a contar com uma combinação que as tecnologias assistivas não foram concebidas para suportar. O resultado é que a informação que pretendia comunicar — como uma etiqueta ou descrição — pode ser silenciosamente descartada.
Isto cria um problema sério para utilizadores que dependem de tecnologias assistivas, incluindo pessoas cegas, surdocegas ou com deficiências motoras. Os leitores de ecrã podem ignorar o atributo proibido, deixando o utilizador sem contexto. Algumas tecnologias assistivas podem tentar compensar, levando a comportamentos inconsistentes ou confusos entre diferentes ferramentas e navegadores.
Um exemplo comum é usar aria-label num elemento com role="presentation" ou role="none". Estes roles dizem explicitamente às tecnologias assistivas para ignorarem a semântica do elemento, pelo que etiquetá-lo com aria-label é contraditório. De forma similar, roles semânticos de nível de texto como code, insertion, deletion, strong, emphasis, subscript, superscript e paragraph proíbem aria-label e aria-labelledby porque estes roles representam conteúdo de texto inline que não deve ter um nome acessível separado do seu conteúdo de texto.
Critérios de sucesso WCAG relacionados
Esta regra relaciona-se com o Critério de Sucesso WCAG 4.1.2: Name, Role, Value (Nível A), que exige que para todos os componentes de interface de utilizador, o nome, role e estados/propriedades possam ser determinados programaticamente. Usar atributos ARIA proibidos viola este critério porque a informação de nome ou estado pretendida não pode ser comunicada de forma confiável às tecnologias assistivas.
Como corrigir
Quando o axe sinaliza um atributo ARIA proibido, considere estas abordagens:
- Remova o atributo proibido — Se a informação que transmite não for essencial, simplesmente remova-o.
-
Altere o role do elemento — Mude para um role que permita o atributo de que precisa. Por exemplo, se precisa de
aria-label, não userole="none". - Forneça a informação como texto visível — Em vez de depender do atributo proibido, inclua a informação diretamente no conteúdo da página onde todos os utilizadores a possam aceder.
- Mova o atributo para um elemento diferente — Coloque o atributo num elemento pai ou filho que tenha um role que o suporte.
Exemplos
Incorreto: aria-label num elemento com role="presentation"
O role presentation diz às tecnologias assistivas para ignorarem o elemento. Adicionar aria-label contradiz isto e será ignorado.
<div role="presentation" aria-label="Navigation section">
<a href="/home">Home</a>
<a href="/about">About</a>
</div>
Correto: Use um role que suporte aria-label
Se o elemento precisa de um nome acessível, use um role que permita etiquetagem, como navigation.
<nav aria-label="Navigation section">
<a href="/home">Home</a>
<a href="/about">About</a>
</nav>
Incorreto: aria-label num role semântico de nível de texto
Roles como code, strong, emphasis, insertion e deletion proíbem aria-label e aria-labelledby.
<span role="code" aria-label="JavaScript variable declaration">
const x = 10;
</span>
Correto: Use texto visível em vez disso
Forneça contexto através do conteúdo de texto circundante em vez de um atributo proibido.
<p>
The following JavaScript variable declaration
<code>const x = 10;</code>
assigns the value 10 to x.
</p>
Incorreto: aria-labelledby em role="none"
<h2 id="section-title">Features</h2>
<table role="none" aria-labelledby="section-title">
<tr>
<td>Fast</td>
<td>Reliable</td>
</tr>
</table>
Correto: Remova o role conflituoso ou o atributo proibido
Se a tabela precisa de ser etiquetada, remova role="none" para que mantenha a sua semântica nativa de tabela.
<h2 id="section-title">Features</h2>
<table aria-labelledby="section-title">
<tr>
<td>Fast</td>
<td>Reliable</td>
</tr>
</table>
Se a tabela é verdadeiramente apresentacional e não precisa de uma etiqueta, remova o atributo aria-labelledby em vez disso.
<table role="none">
<tr>
<td>Fast</td>
<td>Reliable</td>
</tr>
</table>
Ajude-nos a melhorar os nossos guias
Detecte problemas de acessibilidade automaticamente
O Rocket Validator examina milhares de páginas com Axe Core e o W3C Validator, encontrando problemas de acessibilidade em todo o seu site.