Regra de acessibilidade: Os elementos só devem usar atributos ARIA suportados

Sobre esta regra de acessibilidade

A especificação WAI-ARIA organiza papéis, estados e propriedades numa taxonomia estrita. Cada papel define três categorias de atributos que pode usar:

Atributos obrigatórios — devem estar presentes para que o papel funcione corretamente.
Atributos suportados — opcionalmente melhoram a semântica do papel.
Atributos herdados — vêm de papéis superclasse na hierarquia de papéis ARIA.

Qualquer atributo ARIA que não se enquadre numa dessas categorias não é permitido nesse papel. Isto aplica-se igualmente a papéis explícitos (definidos com o atributo role) e papéis implícitos que os elementos HTML têm por padrão. Por exemplo, <button> tem um papel implícito de button, <input type="checkbox"> tem um papel implícito de checkbox, e <h2> tem um papel implícito de heading.

Quando um atributo não suportado aparece num elemento, o resultado é imprevisível. Um leitor de ecrã pode ignorá-lo silenciosamente, ou pode anunciar informação contraditória — por exemplo, descrever um cabeçalho como um controlo selecionável. No pior caso, combinações inválidas de papel-atributo podem quebrar a acessibilidade de secções inteiras de uma página.

Quem é afetado

Este problema tem um impacto crítico em pessoas que usam tecnologias assistivas:

Utilizadores de leitores de ecrã (utilizadores cegos e surdocegos) dependem de informação precisa de papel e estado para entender e interagir com o conteúdo. Atributos ARIA conflituosos podem fazer com que os elementos sejam anunciados como algo que não são.
Utilizadores de controlo por voz dependem de semântica corretamente exposta para dar comandos direcionados a controlos específicos. Papéis mal representados podem tornar os controlos inacessíveis por voz.
Utilizadores de dispositivos de comutação e métodos de entrada alternativos dependem de ferramentas que interpretam papéis e atributos ARIA para identificar controlos operáveis. Atributos inválidos podem fazer com que os controlos pareçam inoperáveis ou deturpem completamente o seu propósito.

Quando os atributos ARIA entram em conflito com o papel de um elemento, estes utilizadores podem encontrar controlos que mentem sobre o que fazem, estados que nunca se atualizam corretamente, ou regiões inteiras que se tornam completamente inutilizáveis.

Critérios de sucesso WCAG relevantes

Esta regra relaciona-se com o Critério de Sucesso 4.1.2 das WCAG 2.0, 2.1 e 2.2: Nome, Papel, Valor (Nível A), bem como com a cláusula 9.4.1.2 da EN 301 549. Este critério exige que todos os componentes da interface do utilizador exponham o seu nome, papel e valor às tecnologias assistivas de uma forma que possa ser determinada programaticamente. Usar atributos ARIA não suportados num papel viola este critério porque introduz propriedades que entram em conflito com o papel real do elemento, quebrando o contrato entre a página e a tecnologia assistiva.

Como corrigir o problema

Identifique o papel do elemento. Verifique se existe um atributo role explícito. Se não existir, determine o papel ARIA implícito do elemento a partir da sua tag HTML. Por exemplo, <input type="checkbox"> tem um papel implícito de checkbox, e <nav> tem um papel implícito de navigation.
Consulte os atributos permitidos para esse papel nas definições de papéis da especificação WAI-ARIA. Cada página de papel lista os seus estados e propriedades obrigatórios, estados e propriedades suportados, e propriedades herdadas de papéis superclasse.
Remova ou reloque qualquer atributo ARIA que não esteja na lista permitida. Se o atributo pertencer a um elemento diferente dentro do seu componente, mova-o para lá.
Reconsidere o papel. Às vezes a correção certa não é remover o atributo mas mudar o papel do elemento para um que suporte o atributo que você precisa. Se quer um controlo comutável, use role="switch" ou role="checkbox" em vez de role="button".
Consulte a especificação ARIA in HTML para regras de conformidade adicionais sobre quais atributos ARIA são apropriados em elementos HTML específicos, incluindo restrições sobre como os elementos podem ser nomeados.

Exemplos

Incorreto: atributo não suportado num papel explícito

O atributo aria-checked não é suportado em role="textbox" porque uma caixa de texto não é um controlo selecionável. Um leitor de ecrã pode anunciar este elemento como tanto uma entrada de texto quanto um controlo selecionado.

<div role="textbox" aria-checked="true" contenteditable="true">
  Enter your name
</div>

Correto: atributo não suportado removido

Remova aria-checked uma vez que não tem significado numa caixa de texto. Use aria-label para fornecer um nome acessível.

<div role="textbox" contenteditable="true" aria-label="Your name">
</div>

Incorreto: atributo não suportado num papel implícito

O elemento <h2> tem um papel implícito de heading. O atributo aria-selected não é suportado em cabeçalhos porque os cabeçalhos não são itens selecionáveis.

<h2 aria-selected="true">Account Settings</h2>

Correto: atributo não suportado removido do cabeçalho

Se a semântica de seleção não for necessária, remova o atributo. Se precisar de comportamento de seleção, use um elemento com um papel apropriado como tab.

<h2>Account Settings</h2>

Incorreto: papel não corresponde ao comportamento pretendido

O programador quer um controlo comutável mas usou role="button", que não suporta aria-checked.

<div role="button" aria-checked="true" tabindex="0">
  Dark mode
</div>

Correto: papel alterado para um que suporte o atributo

Alterar o papel para switch torna aria-checked válido. O elemento permanece operável por teclado através de tabindex="0".

<div role="switch" aria-checked="true" tabindex="0" aria-label="Dark mode">
  Dark mode
</div>

Incorreto: atributo não suportado num elemento HTML nativo

O elemento <a> tem um papel implícito de link. O atributo aria-required não é suportado em ligações porque as ligações não são campos de formulário que aceitem entrada.

<a href="/terms" aria-required="true">Terms of Service</a>

Correto: atributo não suportado removido da ligação

Remova aria-required da ligação. Se precisar de indicar que concordar com os termos é obrigatório, comunique isso através de um controlo de formulário como uma caixa de verificação.

<a href="/terms">Terms of Service</a>

Correto: atributo suportado num papel implícito correspondente

O atributo aria-expanded é suportado no papel implícito button, tornando esta combinação válida.

<button aria-expanded="false" aria-controls="menu-list">
  Menu
</button>
<ul id="menu-list" hidden>
  <li><a href="/home">Home</a></li>
  <li><a href="/about">About</a></li>
</ul>

Learn more: