Recentemente entrei no desenvolvimento de aplicações para o poder público, onde tive que atender a algumas exigências que não me eram passadas no desenvolvimento para empresas privadas.

Uma das grander preocupações que se tem quando se desenvolve uma aplicação (site, sistema interno, aplicativo) para o poder público é a acessibilidade. Mais que um bom design, ele precisa ser objetivo e personalizável, para poder ser acessível em qualquer dispositivo e para a maior parte das pessoas, tendo elas algum tipo de deficiência ou não.

Eu achava que acessibilidade era algo complexo, até que tive que aprender e aplicar conceitos e percebi que, na verdade, é algo simples e que parte exclusivamente da cultura de desenvolvimento do programador.

WCAG

A W3C tem um papel fundamental na padronização da Web, e com acessibilidade não é diferente.

A WCAG (Web Content Accessibility Guidelines, ou Diretrizes de Acesibilidade para o Conteúdo da Web) tem como objetivo indicar padrões de desenvolvimento para que desenvolvedores e ferramentas de acessibilidade se comuniquem com mais facilidade, tornando a experiência do usuário melhor.

Prática

Estou montando alguns vídeos mais extensos com dados, casos e experiências sobre o assunto, mas, por hora, vamos praticar acessibilidade na web.

ARIA

Accessible Rich Internet Applications são a representação prática do que falamos acima. As ARIAs te permite definir pontos chave na sua aplicação (tais como campo de busca, cabeçalho, etc.) que servem para facilitar a navegação do usuário.

Os aplicativos de acessibilidade conseguem identificar essas áreas do site com mais facilidade, tornando a experiência do usuário melhor.

Campos de texto

Na prática seria você adicionar um aria-label="campo de busca" ou, se essa informação já estiver na tela, você pode passar o id do label com o aria-labelledby="labelCampoDeBusca".

<!-- Incorreto -->
<form>
  <input placeholder="Busque aqui e pressione enter">
</form>

<!-- Correto -->
<form>
  <input
    aria-label="Formulário de busca"
    placeholder="Busque aqui e pressione enter"
  >
</form>

<!-- Melhor ainda -->
<form>
  <label
    for="campoBusca"
    id="labelCampoBusca"
  >
    Campo de busca
  </label>
  <input
    id="campoBusca"
    aria-labelledby="labelCampoBusca"
    placeholder="Busque aqui e pressione enter"
  >
</form>

Lembre-se de que, sempre que adicionar um label ao input, referenciar o ID do campo com o atributo for do label. Isso permite que, ao clicar no label, o campo de texto tenha foco, e facilita a interpretação da interface pelos softwares de leitura visual.

Imagens

Pessoas com deficiência visual (perda total ou parcial das vistas) também acessam a web, e imagina o quão péssimo deve ser ter uma imagem que pode ser facilmente descrita, dando plena luz ao contexto do conteúdo inacessível, pois o bonito que publicou a página não deixou disponível um texto alternativo para a imagem. Horrível, né?

Com um texto alternativo você consegue descrever uma imagem de forma simples e objetiva, sem dar muitos detalhes (ao menos que sejam necessários no contexto) fazendo com que pessoas com deficiência visual tenham acesso a informação.

<!-- Incorreto -->
<img src="imagem.png">

<!-- Correto -->
<img
  src="imagem.png"
  alt="Dois ursos abraçando um senhor de idade na floresta"
  >

<!-- Melhor ainda -->
<img
  src="ursos-abrancando-senhor.png"
  alt="Dois ursos abraçando um senhor de idade na floresta"
  >

<!-- Desnecessário (sério, não precisa fazer isso) -->
<img
  src="ursos-abrancando-senhor.png"
  alt="Dois ursos de cor marron, aparentemente com 2 metros de altura abraçando um senhor de idade com casaco vermelho xadrez numa floresta dinamarquesa, que já foi palco da inúmeras tragédias no século dezenove"
  >

Seja simples e objetivo ao descrever imagens. Não acrescente detalhes que não fazem parte do conceito principal.

Por diversas vezes (especialmente com a popularização de frameworks como bootstrap e materialize) damos a aparência de botão aos nossos links, e isso, visualmente, não está errado. Conceitualmente, sim. Corrigir isso é bem simples, e podemos usar a role="button" para informar que aquele link tem o papel de ação, ou vice-versa.

<!-- Incorreto -->
<a
  class="btn btn-primary"
  href="#"
  id="botaoAcao"
  >
    Realizar ação
</a>

<!-- Correto -->
<a
  class="btn btn-primary"
  href="#"
  id="botaoAcao"
  role="button"
  >
    Realizar ação
</a>

Acho que aplicando esses 3 pontos, você já melhorou bastante o desenvolvimento acessível. Nos vídeos eu dou uma dicas práticas para aplicar alternativas visuais para elementos com foco, navegação com teclado e outros tipos de suporte.

Ferramentas

Além do própio leitor de telas, existem validações mais simples que podem ser feitas, como daltonismo e checagem rápida de padrões de acessibilidade.

O Chrome oferece um audit de acessibilidade (e outros) diretamente do seu console. Aperte F12 e vá na aba "Audits". Certificado que o checkbox de Accessibility está marcado, clique em "Run audits" e espere a nota do Google.

Ele geralmente vai te mostrar o que está faltando em acessibilidade, com base nas recomedações dele mesmo.

Resultado do audit do meu blog, onde consegui uma ótima nota em SEO e uma nota mediana em Acessbilidade

Também para o Chrome, existe uma extensão chamada Colorblinding, que simula tipos de daltonismo ao vivo na sua página. Com ela, você consegue ter uma noção da usabilidade de uma pessoa daltônica em sua aplicação, e pode corrigir problemas de falta de percepção de cores, entregando um melhor feedback visual para seus usuários.

Você pode baixar a extensão Colorblinding diretamente da Chrome Web Store.

Conclusão

Claro que isso que passei aqui são só algumas das diretrizes e dicas razas, mas que são cruciais para um desenvolvimento com acessibilidade.

Contudo, o que vale é o equilibrio, bom senso e testes.

Vídeos que recomendo sobre o assunto:

Se restou alguma dúvida, comente aí em baixo. Até a póxima.