Afonso Pacifer

Posted on Jun 16

Criando componentes para Web #01: Acessibilidade (a11y) na prática com WAI-ARIA

#frontend #a11y #webdev #html

O que abordaremos nessa série?

Olá, nessa série de artigos vamos abordar todos as especialidades que uma pessoa profissional de Front-End precisa compreender para criar componentes acessíveis, performáticos, responsivos, manuteníveis, reutilizáveis, documentados, customizáveis, testados e que atendem as reais necessidades de produtos e times de desenvolvimento, independente da tecnologia escolhida, seja React.js, Angular, Vue.js ou qualquer outra.

Como vamos abordar cada assunto?

Pensei em seguirmos um roteiro para que cada assunto possa ser abordado com o mesmo padrão, dessa forma não perdemos nenhum ponto importante e ainda me ajuda na hora de escrever hehe.

Roteiro genérico:

Introdução
Qual a importância?
Principais referências
Aplicando na prática
Como testar
Dicas de especialista
Próximos passos

Ok, agora que estamos alinhados com as ideias por trás dessa série, vamos partir para o primeiro assunto. Bem vindos ao mundo da a11y ❤️.

Introdução

Primeiro precisamos entender o que significa o tal a11y. Basicamente é a abreviação da palrava em inglês accessibility (acessibilidade), sendo a + 11 letras no meio + y. Apenas abreviamos o termo para facilitar o uso no dia a dia.

Dica: Fazemos o mesmo com a palavra internationalization (internacionalização), sendo i + 18 letras no meio + n, logo temos como resultado o tão famoso termo i18n (Que será assunto de um próximo artigo).

Dentre todos os aspectos relacionados a acessibilidade web, hoje abordaremos o famoso WAI-ARIA, mas antes, precisamos conhecer a WAI.

WAI ou Web Accessibility Initiative (Iniciativa de Acessibilidade na Web), é uma iniciativa da W3C para desenvolver padrões e materiais de apoio que nos ajudam a compreender e implementar a acessibilidade.

Já o WAI-ARIA nós podemos definir como uma especificação que traz uma extensão para o HTML, adicionar muito mais dinamismo e controle sobre a semântica.

Qual a importância da a11y?

Antes de demonstrar o WAI-ARIA em ação, e para nivelar o conhecimento, precisamos abordar a importância da acessibilidade na web, e para isso, eu trouxe alguns links de experts que já explicaram muito bem o assunto na comunidade Front-End ❤️.

Referências sobre a11y na Web

Aplicando na prática

Antes de aplicarmos o WAI-ARIA, para que tudo faça sentido precisamos entender de forma prática a importância da semântica e ir muito além de simplesmente dizer que "HTML semântico é o certo", sem um critério objetivo.

Vamos começar com um simples componente de toggle button, e para facilitar o exemplo vamos trabalhar apenas com HTML + CSS + JS:

<span class="toggle">
  <span> OFF </span>
  <button class="toggle__button"></button>
  <span> ON </span>
</span>

Resultado:

PS: O código completo desse exemplo, incluindo CSS e Javascript, pode ser acessado no meu Codepen.

Conseguem perceber os graves problemas de semântica dessa botão? Não?

Do ponto de vista de um usuário comum, o comportamento está bem claro e bem fácil de entender, mas a semântica não foi feita para um usuário "comum".

A principal função da semântica no HTML é ser interpretada por robôs, sejam mecanismos de busca (tentando entender sua página para rankea-la) ou leitores de tela (transcrevendo o conteúdo, iterações e estados para um usuário com deficiência visual).

O WAI-ARIA em especial é extremamente importante para adicionar significado para a interface através da semântica, afinal, entender que uma interface na web não é algo apenas visual, faz parte das bases para um pessoa verdadeiramente profissional em Front-End.

Para ficar mais claro, vamos testar esse botão com um software leitor de tela e analisar os resultados:

Como podemos perceber, o toggle-button não indica o estado de ON ou OFF, em outras palavras, não sabemos se o botão está clicado ou não.

Para corrigir isso, podemos adicionar a propriedade aria-pressed, que tem como valores possíveis:

true: para indicar que está "clicado".
false: indicando que "não esta clicado".
mixed: para indicar que está entre os dois estados.

<span class="toggle">
  <span> OFF </span>
  <button class="toggle__button" aria-pressed="false"></button>
  <span> ON </span>
</span>

Resultado:

Bem melhor, porém ainda temos um grave problema na experiência do usuário. Apesar do comportamento do botão estar claro, como não existe conteúdo de texto dentro do elemento button, não é possível saber o que o botão faz, a única informação que o leitor de tela tem é um toggle-button sem descrição.

Vamos adicionar um aria-label para resolver esse problema.

<span class="toggle">
  <span> OFF </span>
  <button
    class="toggle__button"
    aria-pressed="false"
    aria-label="Alterna entre os modos ON e OFF">
  </button>
  <span> ON </span>
</span>

Resultado:

Ainda podemos ir além, caso o toogle-button abra dropdown, podemos vincular os componentes usando o atributo aria-haspopup, e assim por diante.

Na categoria States and Properties (Estados e propriedades) do WAI-ARIA, temos uma longa lista de atributos possíveis para adicionar semântica em nossas aplicações, recomendo a consultar a lista completa na documentação da Mozilla Developer Network.

Indo além com `WAI-ARIA Roles`

Quando falamos em componentes, na maioria das vezes criamos elementos que não existem no HTML, e mesmo quando existem, é bem comum ignorar o elemento nativo e criar um comportamento personalizado, como exemplo ignorar a tag <dialog>e criar um modal do zero utilizando apenas <div>. Não há nada de errado com essa pratica, desde que deixe claro para o leitor de tela que o papel (em inglês: role) daquela <div> é se comportar como modal, ai entram os atributos da categoria WAI-ARIA Roles.

Vamos nos aprofundar com um exemplo mais crítico

Sabe quando utilizamos elementos semânticos do HTML para construir algo? Podemos, por exemplo, criar a estrutura de uma página da seguinte forma não semântica:

<div>
  <div></div>
  <div>
    <div></div>
    <div></div>
  </div>
  <div></div>
</div>

Ou seguindo um HTML semântico:

<div>
  <header></header>
  <main>
    <section></section>
    <section></section>
  </main>
  <footer></footer>
</div>

Até aí tudo bem, aprendemos que devemos escrever de forma semântica e os motivos da sua importância. Mas e quando não encontramos uma tag HTML perfeita para nossa necessidade? Ai entra o atributo role.

Vamos ao exemplo de um alerta de erro:

<div class="snackbar-error">
  Ouve um problema ao enviar sua solicitação
</div>

Parando para pensar com calma, entendemos que simplesmente jogar um alerta visual na tela não alerta um usuário de leitor de tela, certo?

Para que o papel de alerta seja realizado corretamente pelo componente, precisamos adicionar esse papel:

<div class="snackbar-error" role="alert">
  Ouve um problema ao enviar sua solicitação
</div>

Dessa forma o leitor de tela avisa ao usuário que existe um alerta e lê a mensagem assim que o alerta for disparado ❤️.

Mais uma vez eu recomendo consultar a lista completa de roles na documentação da Mozilla Developer Network .

Como testar

Nos exemplos acima, eu usei o leitor de tela chamado Voice Over, que já vem instalado por padrão nos computadores com sistema operacional macOS, mas obviamente existem leitores de tela para Windows, Linux, Android, etc... Recomendo pesquisar, instalar e aprender bem a usar ao menos um leitor de tela, afinal, seria no mínimo estranho projetar interfaces visuais sem monitor, logo, pensar em semântica sem se quer testar o que você esta fazendo, beira o absurdo! (desculpem a falta de decoro, me exaltei rsrsrs).

Dicas de especialista

Na hora de criar um componente, não pule etapas por achar que HTML é simples. Planeje a semântica, pesquise e teste.
Durante sua analise de requisitos, crie uma tarefa para pesquisar e construir a semântica do componente antes mesmo de começar a trabalhar no CSS.
Tente recriar um botão sem usar a tag <button>, o aprendizado vai trazer bons insights, confia.

Conclusão

Lembre-se! Se você se considera uma pessoa boa com HTML, mas nunca abriu um leitor de tela, repense, saber como o HTML funciona e ser profissional são coisas diferentes.

Ah, se você gostou do conteúdo e quer que essa série continue, comente com um feedback e compartilhe com seus amigos Devs.

E claro! Me siga para mais dicas 😎:

Obrigado por ler e te vejo na próxima ❤️.