Como aplicar acessibilidade em código?

Dicas para desenvolver projetos mais acessíveis

Anteriormente falei sobre a importância de pensar acessibilidade em projeto e como fazer isso do ponto de vista de UX — perdeu? Comece por aqui!

Para finalizar a trilogia, não poderia deixar de fora a aplicação prática de tudo isso, quando o projeto vai para desenvolvimento. Alô DEVs e QAs, este texto é para vocês!

“Working from home”, Liza Chernenko, via Dribble

É preciso desenvolver pensando em acessibilidade desde o início:

• com empatia;
• inserindo acessibilidade na cultura de código;
• realizando testes.

Separei como pode ser feito em etapas, mas os recursos citados podem ser usados em momentos diversos do projeto, de acordo com a necessidade:

1. Início de projeto

Os padrões de código muitas vezes são acessíveis, o problema são as variações e mudanças que fogem do padrão. O uso do HTML semântico, por exemplo, é um dos pontos mais básicos (e muitas vezes negligenciado) quando falamos em front end.

Pelo VSCode (e outros editores) é possível usar linters que auxiliam a corrigir erros no código enquanto codifica, como o axe (para React, HTML, Angular e Markdown) e Nowill (Vue). Para testes automatizados, existem módulos como o Cypress Axe que incluem verificações de acessibilidade.

Já existem bibliotecas que consideram a acessibilidade na construção de componentes, como a Radix UI. Trabalhar com uma base bem construída pode facilitar a inclusão de acessibilidade sem demandar um esforço adicional.

Outras questões a serem observadas são as propriedades de CSS usadas e a limitação de personalização. Por exemplo, quando são definidas medidas de tamanho fixas (chamadas absolutas, como px e pt) para tamanho de fonte, o usuário perde a possibilidade de personalizar no navegador conforme necessário — para isso ser possível, deve-se usar medidas em ou rem, que são medidas relativas.

2. Projeto em andamento

Desenvolver um projeto do início de forma acessível é mais fácil, mas ajustar e adaptar um projeto existente é possível. Uma análise de código e alguns ajustes podem ser feitos de forma a melhorar a experiência dos usuários.

Ferramentas que podem auxiliar na análise:

• Validador de HTML da W3C
• Lighthouse, Axe DevTools, para Google Chrome
• WAVE, Tenon e A11y.css, ferramentas para avaliação de página web
• Checklists de acessibilidade: A11y project e WebAIM
• Toolkit
• Pa11y

Um exemplo que eu gostaria de dar é de quando trabalhei como front end designer no time de Integração de Impulse, uma suite de soluções de personalização, mídia e retargeting da Linx Digital. Pude mapear e implementar algumas mudanças simples e imediatas, com o objetivo de tornar uma de nossas soluções mais acessível. Alguns dos pontos observados e corrigidos foram:

• Nem toda imagem possuía atributo alt (texto alternativo). Foi inserido como padrão em todas as imagens com conteúdo relevante, e alt vazio quando um elemento deve ser pulado pelo leitor de tela (referência sobre imagens decorativas, em inglês);
• Era utilizado um normalize de CSS padrão, onde alguns estilos importantes estavam desabilitados. O outline (focus: outline), por exemplo, era removido — sendo um estilo importante ao ser usado para saber visualmente qual elemento está em foco enquanto a página é navegada pelo teclado. Foi verificado quais declarações de estilo faziam sentido, e quais não, e corrigido;
• Observado que alguns botões só possuíam ícone, sem texto explicativo de sua função — como, por exemplo o botão de lupa para pesquisa, foi adicionado aria-label a todos estes botões;
• Elementos escondidos também tiveram um reforço, com a adição do estilo visibility:hidden, para garantir que não serão percebidos no uso da página.

3. Finalização de projeto

A acessibilidade precisa ser um critério de qualidade.

Há várias formas de verificar se um projeto foi bem desenvolvido. Para garantir que seja acessível, alguns pontos podem ser incluídos nas rotinas de teste, como: verificar elementos e problemas pelo devtools (no edge ou chrome), utilizar uma ferramenta de avaliação de página web e fazer testes com pessoas.

Segundo Nikita Jain, em “uma perspectiva de QA para testes de acessibilidade”, há quatro etapas a serem seguidas pelo QA, cada uma com seu próprio checklist (detalhado no texto original, em inglês):

1. Uso de ferramentas para teste em desktop e mobile;
2. Testar a navegação por teclado;
3. Testar com leitor de tela;
4. Testar usando uma ferramenta de contraste de cor.

O trabalho dos desenvolvedores e designers é criar aplicativos que tenham o menor número de barreiras possível, seguindo as convenções de código da linguagem em que está sendo escrito. — traduzido de “The Beginner’s Guide to Web Accessibility”, via Deque

Ainda estamos longe de uma internet acessível como precisa ser, mas cada vez mais precisamos tentar chegar nesse objetivo. Por aqui, a construção do nosso Design System está sendo feita com um cuidado especial com a acessibilidade.

E por aí? Quais projetos e iniciativas estão sendo feitas ou poderiam ser? Vamos tornar o digital mais acessível? ;)

Saiba mais:

• Artigos: Reinaldo Ferraz
• Artigo: How to do Web Accessibility QA (em inglês)
• Artigo: The value of baking accessibility testing into the QA process (em inglês)
• Guia: Building a resilient frontend using progressive enhancement (em inglês)
• Guia: 10 Essentials, princípios para desenvolvedores e como testar (em inglês)
• Guia: Accessible to all (em inglês)
• Guia: Accessibility Developer Guide (em inglês)
• Guia: W3C’s Web Accessibility Initiative (em inglês)
• Vídeos: A11ycasts (em inglês)