Elemento ARIA oculto não deve ser focalizável ou conter elementos focalizáveis

O atributo aria-hidden="true" indica às tecnologias assistivas para ignorarem um elemento e todos os seus descendentes. Isto é útil para ocultar conteúdo puramente decorativo — como fontes de ícones ou elementos visuais redundantes — que iriam confundir a experiência do leitor de ecrã. No entanto, surge um problema sério quando elementos focalizáveis como links, botões, campos de formulário ou elementos com tabindex="0" existem dentro de um contentor com aria-hidden="true".

Quando isto acontece, os utilizadores que navegam pelo teclado ainda podem usar Tab para chegar a esses elementos, mas os leitores de ecrã não os anunciarão. O utilizador para no que parece ser um controlo invisível e sem etiqueta. Não têm forma de saber o que é o elemento ou o que faz. Isto afeta utilizadores cegos, utilizadores surdocegos, utilizadores com baixa visão que dependem de leitores de ecrã e utilizadores com mobilidade reduzida que navegam exclusivamente pelo teclado.

É também importante compreender que aria-hidden="false" num descendente não sobrepõe aria-hidden="true" num ancestral. Uma vez que um pai esteja oculto da árvore de acessibilidade, todos os filhos permanecem ocultos independentemente do seu próprio valor aria-hidden. Qualquer filho focalizável dentro dessa subárvore ainda cria o mesmo problema.

Critérios de sucesso WCAG relacionados

Esta regra relaciona-se principalmente com o Critério de Sucesso WCAG 4.1.2: Nome, Função, Valor (Nível A). Este critério exige que para todos os componentes da interface do utilizador, o nome e a função possam ser determinados programaticamente, e estados, propriedades e valores possam ser definidos programaticamente. Um elemento focalizável dentro de um contentor aria-hidden="true" viola isto porque o seu nome e função são removidos da API de acessibilidade enquanto permanece acessível via teclado — tornando impossível para as tecnologias assistivas transmitirem o seu propósito. Esta regra é sinalizada nas WCAG 2.0, 2.1 e 2.2 ao Nível A, bem como nas diretrizes Trusted Tester, EN 301 549 e RGAA.

Como corrigir

Existem várias estratégias para resolver este problema:

1. Remover aria-hidden="true" de elementos que contêm filhos focalizáveis, se esses filhos precisam de ser interativos.
2. Remover elementos focalizáveis de dentro do contentor aria-hidden="true" se toda a secção estiver realmente destinada a estar oculta.
3. Tornar elementos focalizáveis não focalizáveis adicionando tabindex="-1" a links, botões ou outros elementos interativos dentro do contentor oculto.
4. Usar o atributo disabled em controlos de formulário (não aria-disabled, que não impede efetivamente o foco).
5. Ocultar elementos com CSS usando display: none ou visibility: hidden, que os remove tanto da árvore de acessibilidade como da ordem de foco simultaneamente.

Se precisar de ocultar conteúdo das tecnologias assistivas, certifique-se de que o significado e funcionalidade equivalentes ainda estão disponíveis através de outros meios acessíveis.

Exemplos

Incorreto: Link focalizável dentro de aria-hidden="true"

O link é removido da árvore de acessibilidade mas ainda recebe foco do teclado.

<div aria-hidden="true">
  <a href="/home">Home</a>
</div>

Incorreto: Link focalizável fora do ecrã dentro de aria-hidden="true"

Mover um link para fora do ecrã não o remove da ordem de foco.

<div aria-hidden="true">
  <a href="/" style="position:absolute; top:-999em">Link</a>
</div>

Incorreto: Usar aria-disabled em vez de disabled

O atributo aria-disabled não impede efetivamente que o input receba foco.

<div aria-hidden="true">
  <input aria-disabled="true" />
</div>

Incorreto: Elemento com tabindex="0" e aria-hidden="true"

Adicionar tabindex="0" torna um elemento normalmente não focalizável em focalizável, criando um conflito com aria-hidden="true".

<p tabindex="0" aria-hidden="true">Algum texto descritivo</p>

Incorreto: Tentar sobrepor aria-hidden num descendente

Definir aria-hidden="false" num filho não o reexpõe quando um pai tem aria-hidden="true". O botão permanece oculto das tecnologias assistivas mas ainda recebe foco.

<div aria-hidden="true">
  <div aria-hidden="false">
    <button>Submeter</button>
  </div>
</div>

Incorreto: <summary> focalizável dentro de aria-hidden="true"

O elemento <summary> é nativamente focalizável.

<details aria-hidden="true">
  <summary>Mais informação</summary>
  <p>Detalhes adicionais aqui.</p>
</details>

Correto: Conteúdo não focalizável dentro de aria-hidden="true"

Um parágrafo sem elementos interativos é seguro de ocultar.

<p aria-hidden="true">Texto descritivo decorativo</p>

Correto: Elementos focalizáveis ocultos com CSS display: none

Usar display: none remove o link tanto da ordem de foco como da árvore de acessibilidade.

<div aria-hidden="true">
  <a href="/" style="display:none">Link</a>
</div>

Correto: Elementos focalizáveis tornados não focalizáveis com tabindex="-1"

Adicionar tabindex="-1" remove o botão da ordem de tabs.

<div aria-hidden="true">
  <button tabindex="-1">Fechar</button>
</div>

Correto: Input de formulário adequadamente desativado com o atributo disabled

O atributo disabled impede que o input receba foco inteiramente.

<input disabled aria-hidden="true" />

Correto: Remover aria-hidden e manter elementos interativos

Se o conteúdo precisa de ser focalizável, simplesmente não o oculte das tecnologias assistivas.

<div>
  <a href="/home">Home</a>
</div>

Learn more:

Deque Reference

Deque University - How To Fix

→

W3C Reference

WCAG 2.1 - Understanding Success Criterion 4.1.2: Name, Role, Value

→

W3C Reference

W3C WAI ARIA 1.1 - aria-hidden

→

WHATWG Spec

HTML Spec - focus

→