Regra de acessibilidade: Os elementos devem usar apenas atributos ARIA suportados

Sobre esta regra de acessibilidade

A especificação WAI-ARIA organiza roles, estados e propriedades numa taxonomia rigorosa. Cada role define três categorias de atributos que pode usar:

Atributos obrigatórios — devem estar presentes para que o role funcione corretamente.
Atributos suportados — opcionalmente melhoram a semântica do role.
Atributos herdados — provêm de roles superclasse na hierarquia de roles ARIA.

Qualquer atributo ARIA que não se enquadre numa destas categorias não é permitido nesse role. Isto aplica-se igualmente a roles explícitos (definidos com o atributo role) e roles implícitos que os elementos HTML têm por defeito. Por exemplo, <button> tem um role implícito de button, <input type="checkbox"> tem um role implícito de checkbox, e <h2> tem um role 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 marcável. No pior caso, combinações inválidas de role-atributo podem quebrar a acessibilidade para secções inteiras de uma página.

Quem é afetado

Esta questão 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 sobre roles e estados para compreender e interagir com o conteúdo. Atributos ARIA conflituosos podem causar que elementos sejam anunciados como algo que não são.
Utilizadores de controlo por voz dependem de semântica corretamente exposta para emitir comandos que visem controlos específicos. Roles mal representados podem tornar controlos inacessíveis por voz.
Utilizadores de dispositivos de comutação e métodos de entrada alternativos dependem de ferramentas que interpretam roles e atributos ARIA para identificar controlos operáveis. Atributos inválidos podem fazer com que controlos pareçam inoperáveis ou deturpem completamente o seu propósito.

Quando atributos ARIA entram em conflito com o role 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 WCAG 2.0, 2.1, e 2.2 Critério de Sucesso 4.1.2: Nome, Role, Valor (Nível A), bem como a cláusula EN 301 549 9.4.1.2. Este critério exige que todos os componentes de interface de utilizador exponham o seu nome, role e valor às tecnologias assistivas de forma que possa ser determinado programaticamente. Usar atributos ARIA não suportados num role viola este critério porque introduz propriedades que entram em conflito com o role real do elemento, quebrando o contrato entre a página e a tecnologia assistiva.

Como corrigir o problema

Identifique o role do elemento. Verifique se existe um atributo role explícito. Se não houver nenhum, determine o role ARIA implícito do elemento a partir da sua tag HTML. Por exemplo, <input type="checkbox"> tem um role implícito de checkbox, e <nav> tem um role implícito de navigation.
Procure os atributos permitidos para esse role nas definições de roles da especificação WAI-ARIA. Cada página de role lista os seus estados e propriedades obrigatórios, estados e propriedades suportados, e propriedades herdadas de roles superclasse.
Remova ou transfira 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 role. Por vezes a correção certa não é remover o atributo mas alterar o role do elemento para um que suporte o atributo que você precisa. Se quiser 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 role explícito

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

<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 role implícito

O elemento <h2> tem um role implícito de heading. O atributo aria-selected não é suportado em cabeçalhos porque 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 role apropriado como tab.

<h2>Account Settings</h2>

Incorreto: role 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: role alterado para um que suporte o atributo

Alterar o role para switch torna aria-checked válido. O elemento permanece operável pelo 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 role 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 role implícito correspondente

O atributo aria-expanded é suportado no role 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: