Agora vamos falar de ARIA
Tags: a11y
Published: 2021-07-03 20:02:19

Antes de mais nada, se você não leu [minha história anterior](https://dev.to/luizagatti/como-aumentar-o-alcance-do-seu-site-um-guia-de-acessibilidade-811), 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.

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fq7rhmf6493bktnaitr0.png)

# 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>```

Fica assim na árvore de acessibilidade:
<img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a9708hvsg9ylzhu0wq5m.png" alt="Heading text - push button" />

Adicionar a ARIA **não** fará com que o elemento pareça ou se comporte de maneira diferente para as pessoas que não estão usando tecnologia assistiva. A função **não altera** os comportamentos, estados e propriedades do elemento host, apenas a semântica da função nativa. Por exemplo, esse código:
```<button role="heading" aria-level=1> Texto </button>```

Fica assim na árvore de acessibilidade:
 <img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5qykj1543amelouxkk73.png" alt="Na primeira linha temos: (none) - heading. Na segunda linha temos: text - editable text" />

Mas ele ainda pode ser pressionado, ainda está na ordem padrão do tab, ainda se parece com um botão e ainda dispara as ações associadas a ele quando pressionado. É por isso que é um erro de conformidade com o HTML5 transformar um botão em um heading.

Nota: alterar a role de um elemento não adiciona comportamentos, propriedades ou estados àquela função. O ARIA não muda a aparência ou a ação no browser. Por exemplo, quando os links são estilizados para se comportarem como botões, adicionar `role="button"` não é suficiente. Também é necessário fazer funcionar como um botão, incluindo um manipulador de eventos de chave que escuta a tecla de espaço como os botões nativos fazem.

# Uso de "role=presentation" ou "role=none"
`role="presentation"` ou seu sinônimo `role="none"` remove a semântica do elemento onde ele está. Por exemplo, esse código:
```<h1 role="presentation"> Texto </h1>```
Fica assim na árvore de acessibilidade:
<img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ylq9jxook2472peznv3n.png" alt="text - editable text" />

Em outras palavras, é apenas relatado na árvore como uma string de texto, sem qualquer significado semântico.

Para elementos sem *children* obrigatórios, quaisquer outros elementos aninhados dentro de um com `role="presentation/none"` preservam sua semântica. Por exemplo, esse código:
```<h1 role="presentation"><abbr> API </abbr></h1>```
Fica assim na árvore de acessibilidade:
<img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0bf3uslad2vnr77qs13g.png" alt="Na primeira linha: (none) - abbr. Na segunda linha: API - editable text" />

Para elementos com children obrigatórios (como `<ul>` ou `<table>`) quaisquer filhos obrigatórios aninhados dentro do primeiro elemento com a `role="presentation/none"` também tem a sua semântica removida. Por exemplo, esse código:
```
<table role="presentation">
   <tr>
      <td>
         <abbr> API </abbr>
      </td>
   </tr>
</table>
```
Fica assim na árvore de acessibilidade:
<img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tr7hlfiek4aeytqq47lc.png" alt="Na primeira linha: (none) - abbr. Na segunda linha: API - editable text" />

Nota: quaisquer elementos que não sejam filhos obrigatórios do elemento com uma `role="presentation/none"` mantém sua semântica. Isso inclui outros como lista ou tabelas aninhadas. Por exemplo, esse código que consiste em uma tabela com outra tabela aninhada:
```
<table>
   <tr>
      <td>
         <table>
            <tr>
               <td>
                  <abbr> API </abbr>
               </td>
            </tr>
         </table>
      </td>
   </tr>
</table>
```

Fica assim na árvore de acessibilidade:
<img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cvg95kfegshf6vdrp8cc.png" alt="(none) - table | (none) - row | (none) - cell | (none) - table | API - row | (none) - cell | (none) abbr | API - editable" />

Ao adicionar role="presentation/none" na tabela mais externa, é assim que fica a árvore:
<img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lxu0zej60wmbmm06xaxa.png" alt="(none) - table | API - row | (none) - cell | (none) - abbr | API - editable" />

# Uso de aria-label, aria-labelledby e aria-describedby
Atualmente `aria-label`, `aria-labelledby` e `aria-describedby` tem um suporte melhor em associar conteúdo de texto a um subconjunto interativo de elementos (por exemplo `<div role="main">` ou `<main>`). Essas três opções não funcionam de forma consistente em links, o suporte a conteúdo embedado e conteúdo agrupado é inconsistente em navegadores, tecnologia assistiva e sistemas operacionais, mas podem ser usados com segurança em controles de formulário HTML5, incluindo vários tipos de `input` e os elementos `<aside>`, `<footer>`, `<article>`, `<header>`, `<nav>`, `<section>` e `<main>`.
O exemplo a seguir de aria-labelledby com várias referências usa um intervalo com um `tabindex=-1`.
 
# Uso de role=application
## Como `role=application` afeta um leitor de tela?
Em muitos leitores de tela populares, a maioria dos pressionamentos de tecla são capturados pelo leitor e não pela página da web quando a pessoa usuária está no modo de navegação. Isso é necessário para a navegação eficiente de uma página. Quando o modo de aplicativo está definido, muitos leitores de tela param de interceptar os pressionamentos de tecla e passam todos os pressionamentos de tecla diretamente para o navegador. Assim, a pessoa usuária não conseguirá navegar na página tão facilmente. Por exemplo, não serão capazes de pular a página por títulos ou ler um parágrafo de texto estático linha por linha. No entanto, vários leitores de tela não se comportam de maneira diferente quando há um conjunto de `role=application`.

## Então quando devemos usar?
Ao determinar quando devemos usar essa propriedade precisamos levar em consideração também as vantagens dos atalhos de teclado do leitor de tela em relação à perda desses recursos. Geralmente não deve ser usado e, se for, devem ser realizados testes de usabilidade com pessoas usuárias de leitores de tela.

**Não usamos** `role=application` se um conjunto de controles tiver apenas esses widgets que fazem parte do HTML padrão. Isso também se aplica se você marcá-los e criar um modelo de interação usando funções WAI-ARIA em vez de widgets HTML padrão:
* `text box` (também se aplica a telefone, pesquisa e senha)
* `textarea`
* `checkbox`
* `button`
* `radio button` (normalmente dentro de um fieldset/legend)
* `select + option`
* `link`, `paragraphs`, `headings` e outros elementos que são clássicos/nativos de documentos web

Nota: não é recomendado que sejam desenvolvidos widgets de entrada de texto personalizados. Quase sempre é melhor usar os inputs nativos.

Também **não usamos** `role=application` se seu widget for de algum dos seguintes tipos mais dinâmicos e não nativos:
* `tree view`
* `slider`
* `table` que tenha elementos focalizáveis e que esteja sendo navegado pelas teclas de seta, por exemplo uma lista de mensagens de e-mail. Outros exemplos interativos são grids, tree grids, etc
* Uma lista de guias (`tab`, `tablist`) onde a pessoa usuária seleciona guias pelas teclas de seta para a direita e para a esquerda. Lembre-se que você tem que implementar o modelo de navegação para esse caso
* `dialog` e `alertdialog`
* `toolbar` e `toolbar buttons`, `menus` e `menu items` e similares

Você **deve usar** `role=application` se o conteúdo que está fornecendo consistir apenas em controles interativos focalizáveis e, principalmente, widgets avançados que emulam um aplicativo desktop real. Observe que, apesar de muitas coisas agora serem chamadas de aplicativo web, a maior parte do conteúdo com que esses aplicativos trabalham ainda são informações baseadas em documentos, sejam postagens e comentários de blogs, feeds e até mesmo acordeões que mostram e ocultam certos tipos de informação. Ainda lidamos principalmente com documentos na web, embora eles possam ter uma aparência semelhante a um desktop na superfície.

Em resumo: as vezes que você realmente irá usar o `role=application` serão **muito raras**!

## Onde usar o `role=application` quando ele for relevante?
Coloque-o no elemento contido mais próximo de seu widget, por exemplo, a `<div>` superior a seu elemento.
Como regra geral, se sua página consiste em mais de 90 ou 95% de widgets, `role=application` *pode ser* apropriado. Mesmo assim, verifique se realmente é o caso. **Jamais** use `role=application` em um elemento amplamente contido, como o `body`, se sua página consistir principalmente em widgets tradicionais ou elementos de página, como links com os quais a pessoa usuária não precisa interagir no modo de foco. Isso causará enormes dores de cabeça para qualquer pessoa usuária de tecnologia assistiva.

### Funções e propriedades de ARIA não disponíveis como recursos em HTML
Abaixo estão listadas as funções e propriedades ARIA não consideradas disponíveis nativamente em HTML. Claro que muitas funções e propriedades fornecidas pelo ARIA, que podem ser usadas para transmitir informações à pessoas usuárias, não estão disponíveis em HTML.

#### ARIA Roles
* [`alert`](https://www.w3.org/TR/wai-aria-1.1/#alert)
* [`alertdialog`](https://www.w3.org/TR/wai-aria-1.1/#alertdialog)
* [`application`](https://www.w3.org/TR/wai-aria-1.1/#application)
* [`directory`](https://www.w3.org/TR/wai-aria-1.1/#directory)
* [`document`](https://www.w3.org/TR/wai-aria-1.1/#document)
* [`feed`](https://www.w3.org/TR/wai-aria-1.1/#feed)
* [`grid`](https://www.w3.org/TR/wai-aria-1.1/#grid)
* [`gridcell`](https://www.w3.org/TR/wai-aria-1.1/#gridcell)
* [`group`](https://www.w3.org/TR/wai-aria-1.1/#group)
* [`log`](https://www.w3.org/TR/wai-aria-1.1/#log)
* [`marquee`](https://www.w3.org/TR/wai-aria-1.1/#marquee)
* [`menu`](https://www.w3.org/TR/wai-aria-1.1/#menu)
* [`menubar`](https://www.w3.org/TR/wai-aria-1.1/#menubar)
* [`menuitemcheckbox`](https://www.w3.org/TR/wai-aria-1.1/#menuitemcheckbox)
* [`menuitemradio`](https://www.w3.org/TR/wai-aria-1.1/#menuitemradio)
* [`none`](https://www.w3.org/TR/wai-aria-1.1/#none)
* [`note`](https://www.w3.org/TR/wai-aria-1.1/#note)
* [`presentation`](https://www.w3.org/TR/wai-aria-1.1/#presentation)
* [`scrollbar`](https://www.w3.org/TR/wai-aria-1.1/#scrollbar)
* [`search`](https://www.w3.org/TR/wai-aria-1.1/#search)
* [`status`](https://www.w3.org/TR/wai-aria-1.1/#status)
* [`switch`](https://www.w3.org/TR/wai-aria-1.1/#switch)
* [`tab`](https://www.w3.org/TR/wai-aria-1.1/#tab)
* [`tablist`](https://www.w3.org/TR/wai-aria-1.1/#tablist)
* [`tabpanel`](https://www.w3.org/TR/wai-aria-1.1/#tabpanel)
* [`timer`](https://www.w3.org/TR/wai-aria-1.1/#timer)
* [`toolbar`](https://www.w3.org/TR/wai-aria-1.1/#toolbar)
* [`tooltip`](https://www.w3.org/TR/wai-aria-1.1/#tooltip)
* [`tree`](https://www.w3.org/TR/wai-aria-1.1/#tree)
* [`treegrid`](https://www.w3.org/TR/wai-aria-1.1/#treegrid)
* [`treeitem`](https://www.w3.org/TR/wai-aria-1.1/#treeitem)

#### Estados e propriedades ARIA (atributos aria-*)
* [`aria-activedescendant`](https://www.w3.org/TR/wai-aria-1.1/#aria-activedescendant)
* [`aria-atomic`](https://www.w3.org/TR/wai-aria-1.1/#aria-atomic)
* [`aria-busy`](https://www.w3.org/TR/wai-aria-1.1/#aria-busy)
* [`aria-controls`](https://www.w3.org/TR/wai-aria-1.1/#aria-controls)
* [`aria-describedby`](https://www.w3.org/TR/wai-aria-1.1/#aria-describedby)
* [`aria-dropeffect`](https://www.w3.org/TR/wai-aria-1.1/#aria-dropeffect)
* [`aria-expanded`](https://www.w3.org/TR/wai-aria-1.1/#aria-expanded)
* [`aria-flowto`](https://www.w3.org/TR/wai-aria-1.1/#aria-flowto)
* [`aria-grabbed`](https://www.w3.org/TR/wai-aria-1.1/#aria-grabbed)
* [`aria-haspopup`](https://www.w3.org/TR/wai-aria-1.1/#aria-haspopup)
* [`aria-hidden`](https://www.w3.org/TR/wai-aria-1.1/#aria-hidden)
* [`aria-label`](https://www.w3.org/TR/wai-aria-1.1/#aria-label)
* [`aria-labelledby`](https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby)
* [`aria-level`](https://www.w3.org/TR/wai-aria-1.1/#aria-level)
* [`aria-live`](https://www.w3.org/TR/wai-aria-1.1/#aria-live)
* [`aria-orientation`](https://www.w3.org/TR/wai-aria-1.1/#aria-orientation)
* [`aria-owns`](https://www.w3.org/TR/wai-aria-1.1/#aria-owns)
* [`aria-posinset`](https://www.w3.org/TR/wai-aria-1.1/#aria-posinset)
* [`aria-pressed`](https://www.w3.org/TR/wai-aria-1.1/#aria-pressed)
* [`aria-relevant`](https://www.w3.org/TR/wai-aria-1.1/#aria-relevant)
* [`aria-setsize`](https://www.w3.org/TR/wai-aria-1.1/#aria-setsize)
* [`aria-sort`](https://www.w3.org/TR/wai-aria-1.1/#aria-sort)


## Referências
[Iniciativa de Acessibilidade Web (WAI) do W3C](https://www.w3.org/WAI/).

[Accessible Rich Internet Applications (WAI-ARIA) 1.1](https://www.w3.org/TR/wai-aria-1.1/)

[WAI-ARIA Authoring Practices 1.1](https://www.w3.org/TR/wai-aria-practices/)