ARIA e HTML

A maioria dos desenvolvedores está familiarizada com a linguagem de marcação padrão da nossa Web moderna, a linguagem de marcação de hipertexto (HTML, na sigla em inglês). No entanto, talvez você não esteja familiarizado com os Accessible Rich Internet Applications (ARIA) (formalmente chamados de WAI-ARIA): o que são, como são usados e quando (e quando não) usá-los.

HTML e ARIA desempenham papéis importantes para tornar os produtos digitais acessíveis, especialmente quando se trata de tecnologia adaptativa (AT, na sigla em inglês), como leitores de tela. Ambos são usados para converter conteúdo em um formato alternativo, como braille ou conversão de texto em voz (TTS).

Vamos rever um breve histórico da ARIA, por que ela é importante e quando e como usá-la melhor.

Introdução a ARIA

O ARIA foi desenvolvido pela primeira vez em 2008 pelo grupo Web Accessibility Initiative (WAI), um subconjunto do abrangente World Wide Web Consortium (W3C), que rege e regula a Internet.

ARIA não é uma verdadeira linguagem de programação, mas um conjunto de atributos que você pode adicionar a elementos HTML para aumentar a acessibilidade deles. Esses atributos comunicam funções, estados e propriedades para tecnologias adaptativas usando APIs de acessibilidade encontradas em navegadores modernos. Essa comunicação acontece pela árvore de acessibilidade.

"WAI-ARIA, o Accessible Rich Internet Applications Suite, define uma maneira de tornar o conteúdo e os aplicativos da Web mais acessíveis a pessoas com deficiência. Isso ajuda especialmente com conteúdo dinâmico e controles avançados da interface do usuário desenvolvidos com HTML, JavaScript e tecnologias relacionadas.

O grupo WAI

A árvore de acessibilidade

ARIA modifica o código incorreto ou incompleto para criar uma experiência melhor para os que usam TA, alterando, expondo e aumentando partes da árvore de acessibilidade.

A árvore de acessibilidade é criada pelo navegador e baseada na árvore DOM (Modelo de objeto de documentos) padrão. Assim como a árvore do DOM, a árvore de acessibilidade contém objetos que representam todos os elementos de marcação, atributos e nós de texto. A árvore de acessibilidade também é usada por APIs de acessibilidade específicas da plataforma para fornecer uma representação que as tecnologias adaptativas possam entender.

ARIA por si só não altera a funcionalidade ou a aparência de um elemento. Isso significa que apenas os usuários da AT perceberão diferenças entre um produto digital com ARIA e outro sem ele. Isso também significa que os desenvolvedores são os únicos responsáveis por fazer as mudanças adequadas no código e no estilo para tornar um elemento o mais acessível possível.

Os três principais recursos de ARIA são papéis, propriedades e estados/valores.

Os papéis definem o que um elemento é ou faz na página ou no aplicativo.

<div role="button">Self-destruct</div>

As propriedades expressam características ou relações com um objeto.

<div role="button" aria-describedby="more-info">Self-destruct</div>

<div id="more-info">This page will self-destruct in 10 seconds.</div>

Estados/valores definem as condições atuais ou os valores de dados associados ao elemento.

<div role="button" aria-describedby="more-info" aria-pressed="false">
  Self-destruct
</div>

<div id="more-info">
  This page will self-destruct in 10 seconds.
</div>

Embora todos os três elementos de ARIA possam ser usados em uma linha de código, isso não é obrigatório. Em vez disso, coloque papéis, propriedades e estados/valores ARIA em camadas até ter sua meta de acessibilidade final. A incorporação correta de ARIA à sua base de código garante que os usuários de AT tenham todas as informações necessárias para usar seu site, app ou outro produto digital com sucesso e equidade.

Recentemente, o Chrome DevTools criou uma maneira de ver toda a árvore de acessibilidade para que os desenvolvedores entendam como o código afeta a acessibilidade.

Quando usar ARIA

Em 2014, o W3C publicou oficialmente a recomendação HTML5. Ocorreram algumas mudanças importantes, incluindo a adição de elementos de ponto de referência, como <main>, <header>, <footer>, <aside>, <nav> e atributos como hidden e required. Com esses novos elementos e atributos HTML5, além da maior compatibilidade com navegadores, certas partes do ARIA agora são menos importantes.

Quando o navegador é compatível com uma tag HTML com um papel implícito com um ARIA equivalente, normalmente não é necessário adicionar ARIA ao elemento. No entanto, ARIA ainda inclui muitos papéis, estados e propriedades que não estão disponíveis em nenhuma versão do HTML. Esses atributos ainda são úteis.

Isso nos leva à principal pergunta: quando você deve usar ARIA? Felizmente, o grupo da WAI desenvolveu as cinco regras de ARIA para ajudar você a decidir como tornar os elementos acessíveis.

Regra 1: não usar ARIA

Sim, você leu corretamente. Adicionar ARIA a um elemento não o torna inerentemente mais acessível. O relatório anual WebAIM Million de acessibilidade descobriu que as páginas iniciais com ARIA apresentaram uma média de 70% mais erros detectados do que aquelas sem ARIA, principalmente devido à implementação incorreta dos atributos ARIA.

Esta regra tem exceções. ARIA é necessária quando um elemento HTML não tem suporte de acessibilidade. Isso pode ocorrer porque o design não permite um elemento HTML específico ou o recurso/comportamento desejado não está disponível em HTML. No entanto, essas situações são escassas.

<a role="button">Submit</a>

<button>Submit</button>

Em caso de dúvida, use elementos HTML semânticos.

Regra 2: não adicionar (desnecessário) ARIA ao HTML

Na maioria das circunstâncias, os elementos HTML funcionam bem desde o primeiro uso e não precisam de ARIA adicional a eles. Na verdade, desenvolvedores que usam ARIA frequentemente precisam adicionar código adicional para tornar os elementos funcionais no caso de elementos interativos.

<h2 role="tab">Heading tab</h2>

<div role="tab"><h2>Heading tab</h2></div>

Use elementos HTML conforme o esperado e faça menos trabalho e tenha um código com melhor desempenho.

Regra 3: sempre oferecer suporte à navegação pelo teclado

Todos os controles ARIA interativos (não desativados) precisam estar acessíveis pelo teclado. É possível adicionar tabindex= "0" a qualquer elemento que precise de um foco que normalmente não recebe foco de teclado. Sempre que possível, evite usar índices de guias com números inteiros positivos para evitar possíveis problemas de ordem de foco do teclado.

<span role="button" tabindex="1">Submit</span>

<span role="button" tabindex="0">Submit</span>

Regra 4: não ocultar elementos focalizáveis

Não adicione role= "presentation" ou aria-hidden= "true" a elementos que precisam ter foco, incluindo elementos com tabindex= "0". Quando você adiciona esses papéis/estados aos elementos, ele envia uma mensagem ao AT informando que esses elementos não são importantes e pulando-os. Isso pode levar a confusão ou interromper os usuários que tentam interagir com um elemento.

<div aria-hidden="true"><button>Submit</button></div>

<div><button>Submit</button></div>

Regra 5: usar nomes acessíveis para elementos interativos

O propósito de um elemento interativo precisa ser transmitido a um usuário antes que ele saiba como interagir com ele. Verifique se todos os elementos têm um nome acessível para pessoas que usam dispositivos AT.

Nomes acessíveis podem ser o conteúdo cercado por um elemento (no caso de uma <a>), um texto alternativo ou uma etiqueta.

Para cada um dos exemplos de código a seguir, o nome acessível é "botas de couro vermelhas".

<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>

<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>

<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>

Existem muitas maneiras de verificar o nome acessível de um elemento, incluindo inspecionar a árvore de acessibilidade usando o Chrome DevTools ou testá-la com um leitor de tela.

ARIA em HTML

Embora o uso de elementos HTML sozinhos seja uma prática recomendada, os elementos ARIA podem ser adicionados em determinadas situações. Por exemplo, você pode parear ARIA com HTML em padrões que precisam de um nível mais alto de suporte a AT devido a restrições ambientais ou como um método alternativo para elementos HTML que não são totalmente compatíveis com todos os navegadores.

É claro que há recomendações para a implementação de ARIA em HTML. Mais importante: não substitua os papéis HTML padrão, reduza a redundância e esteja ciente dos efeitos colaterais não intencionais.

Vejamos alguns exemplos.

<a role="heading">Read more</a>

<a aria-label="Read more about some awesome article title">Read More</a>

<ul role="list">...</ul>

<ul>...</ul>

<details>
  <summary role="button">more information</summary>
  ...
</details>

<details>
  <summary>more information</summary>
  ...
</details>

Complexidades de ARIA

ARIA é complexa, e você sempre deve ter cuidado ao usá-la. Embora os exemplos de código desta aula sejam bastante diretos, criar padrões personalizados acessíveis pode ficar complicado rapidamente.

Há muitos fatores a serem considerados, incluindo, mas não se limitando a: interações de teclado, interfaces de toque, compatibilidade com AT/navegador, necessidades de tradução, restrições ambientais, código legado e preferências do usuário. Um pouco de conhecimento de programação pode ser prejudicial, ou simplesmente irritante, se usado incorretamente. O código precisa ser simples.

Esses avisos à parte, a acessibilidade digital não é uma situação de tudo ou nada, mas um espectro que permite algumas áreas cinzentas como essa. Várias soluções de codificação podem ser consideradas "corretas", dependendo da situação. O importante é que você continue aprendendo, testando e tentando tornar nosso mundo digital mais aberto a todos.

Teste seu conhecimento

Teste seus conhecimentos sobre ARIA e HTML