DEV Community: Luiza Gatti

Agora vamos falar de ARIA

Luiza Gatti — Sat, 03 Jul 2021 20:02:19 +0000

Antes de mais nada, se você não leu minha história anterior, volta lá e dá uma lida porque ela serve de introdução para essa aqui.

A sigla ARIA (Accessible Rich Internet Applications) significa Aplicações para a Internet Ricas em Acessibilidade, que definem as formas de tornar o conteúdo e as aplicações da internet mais acessíveis.

A ARIA permite a marcação de algumas regiões importantes na página que servirão para auxiliar na navegação (para ajudar quem usa um leitor de tela, por exemplo). É um conjunto de atributos especiais para acessibilidade que pode ser adicionado a qualquer linguagem de marcação, mas é especialmente adequado para o HTML, e todos os exemplos que trarei serão nessa linguagem.

Primeira regra de uso de ARIA

Sempre que você puder usar um elemento nativo HTML5 ou atributo com semântica e comportamento que você precisa já incorporados, em vez de redefinir um elemento e adicionar o ARIA para torná-lo acessível, opte pelo HTML5.

Em quais casos isso pode não ser possível?

Quando o recurso está disponível em HTML5, mas não está implementado; ou está implementado, mas não dá suporte a acessibilidade;
Se as restrições de design visual excluem o uso de um elemento nativo específico, porque o elemento não pode ser estilizado conforme necessário;
Se o recurso não estiver disponível em HTML.

Segunda regra de uso de ARIA

Não altere a semântica nativa, a menos que seja realmente necessário.

Não faça:

<h2 role="tab">tab de cabeçalho</h2>

Faça:

<div role="tab"> <h2>tab de cabeçalho</h2> </div>

Nota: Se um elemento não interativo for usado como base para um elemento interativo, pessoas desenvolvedoras terão que adicionar a semântica usando ARIA e o comportamento apropriado usando scripts. No caso de um botão, por exemplo, é muito melhor e mais fácil usar apenas um botão.

Terceira regra de uso de ARIA

Todos os controles interativos de ARIA devem ser utilizáveis via teclado.

Se você cria uma ferramenta onde a pessoa pode clicar, tocar, arrastar, soltar, deslizar ou rolar, a pessoa também deve ser capaz de navegar até a ferramenta e executar uma ação equivalente usando o teclado.

Todas as ferramentas interativas devem ser programadas para responder aos pressionamentos de tecla padrão ou combinações de pressionamento de tecla quando aplicável.

Por exemplo, se estiver usando role="button", o elemento deve ser capaz de receber o foco e a pessoa usuária deve conseguir ativar a ação associada ao elemento usando Enter (WIN OS) ou Return (MAC OS) e a tecla de espaço.

Quarta regra de uso de ARIA

Não use role="presentation" ou aria-hidden="true" em um elemento visível e focalizável. Usar qualquer uma dessas propriedades em um elemento que pode ser visível e focalizável irá resultar em pessoas usuárias clicando em ‘nada’.
Um elemento que for oculto usando display: none também será removido da árvore de acessibilidade, o que torna desnecessária a adição de aria-hidden="true".

Quinta regra de uso de ARIA

Todos os elementos interativos devem ter um nome acessível.

Um elemento interativo só tem um nome acessível quando sua propriedade de nome (name ou equivalente) está preenchida.

Não faça:

<label>Insira seu nome</label> <input type="text"/>

Faça:

<label for="user-name">Insira seu nome</label> <input type="text" id="user-name"/>

O correto acima tem um nome acessível porque o elemento de entrada é um elemento rotulável e o elemento de rótulo é usando corretamente para associar o texto à entrada.

O que adicionar "role" faz com a semântica nativa?

Ao adicionar a função ARIA, estamos substituindo a semântica da função nativa na árvore de acessibilidade e, portanto, ARIA afeta diretamente o que é relatado a uma tecnologia assistiva.
Por exemplo, esse código:

<h1 role=button>text</h1>