ARIA e HTML

A maioria dos desenvolvedores está familiarizada com a linguagem de marcação padrão dos nossos Linguagem de Marcação de Hipertexto (HTML, na sigla em inglês). No entanto, talvez você não esteja familiarizado com Accessible Rich Internet Applications (ARIA) (link em inglês) (formalmente chamada de WAI-ARIA): o que é, como é usada, quando e quando não usar.

HTML e ARIA desempenham papéis importantes para tornar produtos digitais acessíveis, especialmente quando se trata de tecnologia assistiva (TA), 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 revisar uma breve história de ARIA, por que ela é importante, quando e como melhor usá-lo.

Introdução a ARIA

A ARIA foi desenvolvida pela primeira vez em 2008 pela da Iniciativa de Acessibilidade na Web (WAI, na sigla em inglês): subconjunto do Consórcio World Wide Web (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 Elementos HTML para aumentar sua acessibilidade. Esses atributos comunicam função, estado e propriedade para tecnologias assistivas por meio de APIs de acessibilidade encontrados em navegadores modernos. Essa comunicação ocorre por meio da acessibilidade árvore.

WAI-ARIA, o Accessible Rich Internet Applications Suite, que define uma maneira de tornar conteúdo e aplicativos da Web mais acessíveis para pessoas com deficiência. Ela ajuda especialmente com conteúdo dinâmico e controles avançados de interface do usuário desenvolvido 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 aqueles que usam TA, alterando, expondo e ampliando partes da acessibilidade árvore.

A árvore de acessibilidade é criada pelo navegador e baseada na configuração Árvore do Modelo de objeto de documentos (DOM, na sigla em inglês). Assim como a árvore do DOM, a árvore de acessibilidade contém objetos que representam todos os elementos, atributos e textos nós. A árvore de acessibilidade também é usada por modelos de acessibilidade APIs para fornecer uma representação que as tecnologias assistivas possam entender.

ARIA por si só não muda a funcionalidade ou aparência visual de um elemento. Isso significa que apenas usuários de TAs notarão diferenças entre um produto digital com ARIA e outra sem ela. Isso também significa que os desenvolvedores são responsáveis para fazer o código adequado e as mudanças de estilo para fazer um elemento como o mais acessível possível.

Os três principais recursos de ARIA são funções, 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 as características ou as 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 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 os três elementos ARIA possam ser usados em uma linha de código, não é obrigatórios. Em vez disso, sobreponha funções, propriedades e estados/valores ARIA até que você atingiu seu objetivo final de acessibilidade. Incorporar ARIA corretamente em sua base de código garante que os usuários de AT tenham todas as informações de que precisam para usem seu site, app ou outro produto digital com sucesso e equidade.

Recentemente, o Chrome DevTools criou uma maneira de ver a árvore de acessibilidade completa ajudando os desenvolvedores a entender como o código afeta acessibilidade.

Quando usar ARIA

Em 2014, o W3C publicou oficialmente a recomendação HTML5. Com ele veio algumas grandes mudanças, 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, aliados maior suporte a navegadores, algumas partes de ARIA agora são menos críticas.

Quando o navegador é compatível com uma tag HTML com uma função implícita com uma ARIA equivalente, geralmente não há necessidade de adicionar ARIA ao elemento. No entanto, ARIA ainda tem muitos papéis, estados e propriedades que não estão disponíveis em nenhum mais recente do HTML. Esses atributos continuam úteis por enquanto.

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

Regra 1: não usar ARIA

Sim, é isso mesmo. Adicionar ARIA a um elemento não o torna inerentemente mais acessíveis. O relatório anual WebAIM Million (em inglês) descobriu que as páginas iniciais com ARIA apresentaram, em média, 70% mais erros detectados do que aqueles sem ARIA, principalmente devido à implementação incorreta dos atributos ARIA.

Há exceções a essa regra. ARIA é necessária quando um elemento HTML não tem compatibilidade com acessibilidade. Isso pode ser porque o design não permitir um elemento HTML específico ou o recurso/comportamento desejado não estiver disponíveis em HTML. No entanto, essas situações são raras.

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

<button>Submit</button>

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

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

Na maioria das circunstâncias, os elementos HTML funcionam bem assim que podem ser usados e não precisam adicionar ARIA a eles. Na verdade, os desenvolvedores que usam ARIA muitas vezes precisam incluir 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>

Faça menos trabalho e tenha um código com melhor desempenho ao usar elementos HTML como pretendido.

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

Todos os controles ARIA interativos (não desativados) precisam ser acessíveis pelo teclado. Você pode adicionar tabindex= "0" a qualquer elemento que precise de um foco que normalmente receber o foco do teclado. Evite usar índices de guias com números inteiros sempre que possível 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 oculte elementos focalizáveis

Não adicione role= "presentation" ou aria-hidden= "true" a elementos que precisam tenham foco, incluindo elementos com uma tabindex= "0". Ao adicionar essas funções/estados aos elementos, ele envia uma mensagem à AT de que esses não são importantes e devem ser ignorados. Isso pode causar confusão ou interromper a tentativa de interação dos usuários com um elemento.

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

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

Regra 5: use nomes acessíveis para elementos interativos

A finalidade de um elemento interativo precisa ser comunicada a um usuário antes para que elas saibam como interagir com ele. Certifique-se de que todos os elementos tenham um nome acessível para pessoas que usam TA dispositivos.

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

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

<!-- 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, inclusive inspecionando a árvore de acessibilidade usando o Chrome DevTools ou testando-a com um leitor de tela.

ARIA em HTML

Embora usar elementos HTML sozinhos seja uma prática recomendada, elementos ARIA podem ser adicionados em determinadas situações. Por exemplo, você pode parear ARIA com HTML no que precisam de um nível mais alto de suporte de TA por conta dos fatores ou como um método substituto para elementos HTML que não são totalmente compatível com todos os navegadores.

Claro, existem recomendações para implementar ARIA em HTML. Mais importante: não substitua papéis HTML padrão, reduzir a redundância e estar ciente de 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ê deve sempre ter cuidado ao usá-la. Enquanto o os exemplos de código desta aula são bem diretos, criando opções os padrões personalizados podem se complicar rapidamente.

Há muitos aspectos em que você deve prestar atenção, incluindo, mas não se limitando a: interações com o teclado, interfaces de toque, compatibilidade com AT/navegador, necessidade de tradução, restrições ambientais, códigos legados e preferências do usuário. Um pouco de em programação pode ser prejudicial ou simplesmente irritante, se usado de forma incorreta. Lembre-se de manter o código simples.

Deixando esses avisos à parte, a acessibilidade digital não é algo impossível situação, é 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 é continuar aprendendo, testando e tentando tornar nossos o mundo digital mais aberto a todos.

Teste seu conhecimento

Teste seus conhecimentos sobre ARIA e HTML