A maioria dos desenvolvedores conhece a linguagem de marcação padrão da Web moderna, a linguagem de marcação de hipertexto (HTML). No entanto, talvez você não esteja tão 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.
O HTML e o ARIA têm papéis importantes na acessibilidade de produtos digitais, principalmente quando se trata de tecnologia adaptativa (TA), como leitores de tela. Ambos são usados para converter conteúdo em um formato alternativo, como braile ou conversão de texto em voz (TTS).
Confira um breve histórico da ARIA, por que ela é importante e quando e como usá-la da melhor forma.
Introdução à ARIA
O ARIA foi desenvolvido em 2008 pelo grupo Web Accessibility Initiative (WAI), um subconjunto do World Wide Web Consortium (W3C), que governa e regulamenta a Internet.
O ARIA não é uma linguagem de programação verdadeira, mas um conjunto de atributos que podem ser adicionados a elementos HTML para aumentar a acessibilidade deles. Esses atributos comunicam função, estado e propriedade às tecnologias assistivas usando APIs de acessibilidade encontradas em navegadores modernos. Essa comunicação acontece pela árvore de acessibilidade.
"O WAI-ARIA, a Accessible Rich Internet Applications Suite, define uma maneira de tornar o conteúdo e os aplicativos da Web mais acessíveis para pessoas com deficiência. Ele ajuda principalmente com conteúdo dinâmico e controles avançados de interface do usuário desenvolvidos com HTML, JavaScript e tecnologias relacionadas."
O grupo WAI
A árvore de acessibilidade
A ARIA modifica códigos incorretos ou incompletos para criar uma experiência melhor para quem usa TA. Para isso, ela muda, expõe e aumenta partes da árvore de acessibilidade.
A árvore de acessibilidade é criada pelo navegador e baseada na árvore padrão do Modelo de objeto de documentos (DOM). 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 assistivas possam entender.
O ARIA sozinho não muda a funcionalidade nem a aparência visual de um elemento. Isso significa que apenas os usuários de TA vão notar diferenças entre um produto digital com ARIA e um sem ele. Isso também significa que os desenvolvedores são os únicos responsáveis por fazer as mudanças de código e estilo adequadas para tornar um elemento o mais acessível possível.
Os três principais recursos do ARIA são papéis, propriedades e estados/valores.
As funções definem o que um elemento é ou faz na página ou no app.
<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 e valores definem as condições ou valores de dados atuais 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 do ARIA possam ser usados em uma linha de código, isso não é obrigatório. Em vez disso, coloque em camadas funções, propriedades, estados ou valores ARIA até alcançar seu objetivo final de acessibilidade. Incorporar corretamente o ARIA na sua base de código garante que os usuários de TA tenham todas as informações necessárias para usar seu site, app ou outro produto digital com sucesso e de maneira igualitária.
Recentemente, o Chrome DevTools criou uma maneira de ver a árvore de acessibilidade completa facilitando para os desenvolvedores entender como o código deles afeta a acessibilidade.
Quando usar ARIA
Em 2014, o W3C publicou oficialmente a recomendação HTML5. Com ele, vieram
algumas grandes mudanças, incluindo a adição de elementos de referência, como <main>,
<header>, <footer>, <aside>, <nav> e atributos como hidden e
required. Com esses novos elementos e atributos HTML5, além do aumento da compatibilidade com navegadores, algumas partes do ARIA agora são menos importantes.
Quando o navegador é compatível com uma tag HTML com uma função implícita e um equivalente ARIA, geralmente não é necessário adicionar ARIA ao elemento. No entanto, o ARIA ainda inclui muitas funções, estados e propriedades que não estão disponíveis em nenhuma versão do HTML. Esses atributos ainda são úteis por enquanto.
Isso nos leva à pergunta final: quando você deve usar o ARIA? Felizmente, o grupo WAI desenvolveu as cinco regras de ARIA para ajudar você a decidir como tornar os elementos acessíveis.
Regra 1: não use ARIA
Isso mesmo. Adicionar ARIA a um elemento não o torna mais acessível. O relatório anual de acessibilidade do WebAIM Million (em inglês) descobriu que as páginas iniciais com ARIA presente tinham, em média, 70% mais erros detectados do que aquelas sem ARIA, principalmente devido à implementação inadequada dos atributos ARIA.
Há exceções a essa regra. O ARIA é necessário quando um elemento HTML não tem suporte de acessibilidade. Isso pode acontecer porque o design não permite um elemento HTML específico ou porque o recurso ou comportamento desejado não está disponível em HTML. No entanto, essas situações devem ser raras.
Não: atribua uma função.
<a role="button">Submit</a>
Faça o seguinte: use o elemento semântico.
<button>Submit</button>
Em caso de dúvida, use elementos HTML semânticos.
Regra 2: não adicione ARIA (desnecessário) ao HTML
Na maioria das circunstâncias, os elementos HTML funcionam bem como estão e não precisam de ARIA adicional. Na verdade, os desenvolvedores que usam ARIA geralmente precisam adicionar mais código para tornar os elementos funcionais no caso de elementos interativos.
Não: atribua uma função enganosa.
<h2 role="tab">Heading tab</h2>
Faça o seguinte: atribua funções corretamente.
<div role="tab"><h2>Heading tab</h2></div>
Faça menos trabalho e tenha um código com melhor desempenho ao usar elementos HTML conforme o esperado.
Regra 3: sempre oferecer suporte à navegação pelo teclado
Todos os controles ARIA interativos (não desativados) precisam ser acessíveis por teclado. Você pode adicionar tabindex= "0" a qualquer elemento que precise de um foco que normalmente não receba o foco do teclado. Evite usar índices de tabulação com números inteiros positivos sempre que possível para evitar possíveis problemas de ordem de foco do teclado.
Não: adicione um tabindex.
<span role="button" tabindex="1">Submit</span>
Faça o seguinte: defina o tabindex como "0".
<span role="button" tabindex="0">Submit</span>
Se possível, use um elemento <button> real nesse caso.
Regra 4: não oculte elementos focalizáveis
Não adicione role= "presentation" ou aria-hidden= "true" a elementos que precisam
ter foco, incluindo elementos com um tabindex= "0". Quando você adiciona
essas funções e estados aos elementos, uma mensagem é enviada para a TA informando que esses
elementos não são importantes e devem ser ignorados. Isso pode causar confusão ou
interromper os usuários que tentam interagir com um elemento.
Não: oculte elementos focalizáveis
<div aria-hidden="true"> <button>Submit</button> </div>
Faça: exponha elementos focalizáveis
<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 de TA.
Os nomes acessíveis podem ser o conteúdo cercado por um elemento (no caso de um
<a>), texto alternativo ou um rótulo.
Em cada um dos exemplos de código a seguir, o nome acessível é "Botas de couro vermelho".
<!-- 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>
Há muitas maneiras de verificar o nome acessível de um elemento, incluindo a inspeção da árvore de acessibilidade usando o Chrome DevTools ou o teste com um leitor de tela.
ARIA em HTML
Embora usar elementos HTML por conta própria seja uma prática recomendada, elementos ARIA podem ser adicionados em determinadas situações. Por exemplo, você pode combinar ARIA com HTML em padrões que precisam de um nível mais alto de suporte de TA devido a restrições ambientais ou como um método de substituição para elementos HTML que não são totalmente compatíveis com todos os navegadores.
Claro, há recomendações para implementar ARIA em HTML. O mais importante: não substitua papéis HTML padrão, reduza a redundância e fique atento a efeitos colaterais não intencionais.
Confira alguns exemplos.
Não: atribua a função errada.
<a role="heading">Read more</a>
Faça o seguinte: use a função correta e uma descrição extra do link.
<a aria-label="Read more about some awesome article title">Read More</a>
Não: adicione uma função redundante.
<ul role="list">...</ul>
Faça o seguinte: reduza a redundância.
<ul>...</ul>
Não: deixe de mencionar possíveis efeitos colaterais.
<details> <summary role="button">more information</summary> ... </details>
Faça: lide com os efeitos colaterais.
<details> <summary>more information</summary> ... </details>
Complexidades do ARIA
O ARIA é complexo, e você sempre precisa ter cuidado ao usá-lo. Embora os exemplos de código nesta lição sejam bem simples, criar padrões personalizados acessíveis pode ficar complicado rapidamente.
Há muitas coisas a serem consideradas, incluindo, entre outras, interações com teclado, interfaces de toque, suporte a 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 apenas irritante se usado incorretamente.
Apesar desses avisos, a acessibilidade digital não é uma situação de tudo ou nada. É um espectro que permite algumas áreas cinzentas como essa. Várias soluções de programaçã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.