Executando verificação de segurança...
20
pmenta
7 min de leitura ·

Guia (quase definitivo) de acessibilidade na web 🦯

Este não é um guia definitivo, mas podemos criar um! Então compartilhe seus conhecimentos e vamos criar o guia definitivo!

Tá, mas o que é acessibilidade na web de verdade?

Acessibilidade na web não se resume a otimizar um site para leitores de tela.
*Até você, sem alguma deficiência precisa de acessibilidade (ou melhor, você quer!)*.

Acessibilidade é sobre criar uma web acessível a TODOS, independente se seu mouse quebrou e você só consegue navegar com o teclado (ou você simplesmente quer navegar pelo teclado), independente de deficiência ou limitação, seja ela temporária ou permanente!

Isso significa que, mesmo que o usuário seja portador de qualquer doenças, transtornos ou deficiências de fala, visual, auditiva, cognitiva, neurológica ou física, ele deve ser capaz de entender, navegar e interagir e contribuir com a Web.

Oliveira, Josheph. 2022

Ok, entendi. Exemplifique por-favor:

Calma, jovem padawan. Vamos chegar nas diretrizes da WVAG (Web Content Accessibility Guidelines) jajá!

Temos milhares de maneiras de tornar um site mais acessível, e nem tudo (alías, quase nada) é complicado.

  • Elementos de texto com um bom contraste em comparação ao seu plano de fundo. E isso implica diretamente na legibilidade
  • Idioma da página especificado no HTML. Ajuda leitores de telas e navegadores em uma língua diferente da do seu site traduzirem o conteúdo automaticamente
  • O texto deve ser redimensionável quando um zoom é aplicado na página pelo navegador. Podemos fazer isso especificando o tamanho dos textos em medidas relativas como o REM
  • Navegação pelo teclado. Talvez o que mais dificulta os devs, mas relaxa, aqui no artigo vai ter umas dicas de implementação no React e com HTML puro.

A WCAG

a base fundamental para que você tenha produtos digitais verdadeiramente inclusivos e acessíveis

WCAG são diretrizes e recomendações organizadas e mantidas pelo W3C que fundamentam a construção de conteúdos digitais com qualidade e acessíveis a qualquer pessoa independentemente de sua deficiência e/ou habilidade.

Atualmente na versão 2.1 (2018), desde a versão 2.0 (2008) foram organizadas de forma que fossem independentes de qualquer tecnologia criada e que também fossem facilmente testáveis e validadas.

Os princípios

  • Perceptível: O conteúdo deve ser apresentável a todos usuários, vendo ou ouvindo.
  • Operável: A interface deve ser navegável, seja por texto ou voz
  • Compreensível: A interface e o conteúdo devem ser facilmente entendíveis pelos usuários
  • Robusto: O conteúdo pode ser interpretado por diversas tecnologias assistivas

Se algum desses princípios não for seguido usuários com deficiências não poderão usar a Web.

Critérios de sucesso

A última versão da WCAG (2.1) possui 78 critérios de sucesso, 17 a mais que a versão anterior (2.0). A versão 3.0 irá trazer ainda mais critérios de sucesso e está prevista para chegar em 2024

Critérios de sucesso especificam o comportamento esperado de uma aplicação acessível, e descrevem situações em que usuários com deficiências teriam dificuldades para navegar.

Níveis de sucesso

Os critérios de sucesso estão divididos em 3 níveis, do A ao AAA. Quanto maior o nível, mais específico é o critério de sucesso e mais acessível se torna sua aplicação.

  • Nível A: Devem ser atingidos 30 critérios específicos, que não impactam tanto o design ou a estrutura da aplicação. Pode ser o seu objetivo se você está começando a estudar sobre acessibilidade.

  • Nível AA: Além de todos os critérios do nível A, tem mais 20 critérios de sucesso. Podem alterar o design da aplicação e sua estrutura. Em alguns países, tipos específicos de sites podem ser obrigados por lei a oferecer esse nível de acessibilidade.
    É o padrão de acessibilidade na maioria dos grandes websites

  • Nível AAA: Além de todos os critérios do nível AA, tem mais 28 critérios de sucesso. Esse nível não é obrigatório e pode não ser possível de alcançar em alguns tipos de conteúdo.

Os critérios de sucesso

Você não precisa saber todos os critérios de cor (e você provavelmente não ia conseguir decorar todos), mas você pode encontrar eles em: https://www.w3.org/TR/WCAG21/.

Vamos ver um critério de sucesso em cada um dos princípios:

além disso, vamos conhecer um site em português que pode servir de referência ao pesquisar sobre os critérios. Todas as imagens a seguir são de:: https://guia-wcag.com/

Perceptível:

Card com descrição sobre o critério de sucesso: Qualquer conteúdo não textual e relevante para compreensão da informação, deve trazer uma descrição alternativa em texto (visível ou não) para identificar o conteúdo (inclusive captcha, por exemplo).

Para atingir esse critério devemos fornecer textos alternativos para todos conteúdos que não sejam textos. Você pode fazer isso usando a propriedade alt disponível em elementos HTML de imagens

Operável:

Card com descrição sobre o critério de sucesso: Todas as funcionalidades devem ser acionadas via teclado, a menos que a funcionalidade não possibilite o controle apenas por teclado

Esse critério beneficia, não exclusivamente, pessoas cegas que não conseguem usar mecanismos como mouse, pessoas com baixa visão que podem ter dificuldade de encontrar o cursor do mouse e também pessoas que podem possuir tremores nas mãos, dificultando o uso de mouse e, por isso, usam o teclado como meio de navegação.

Atingir esse critério pode não ser tão simples ao implementar funcionalidades como modais. Algumas das soluções ao por exemplo, implementar um modal, é trabalhar com o elemento Dialog e tentar ao máximo se manter as funcionalidades do HTML Nativo.

Outra solução mais especifica ao React é a https://www.radix-ui.com/, componentes totalmente acessíveis, sem estilos e extremamente leves. Uma ótima opção ao construir design systems acessíveis!

O proximo passo desse guia é um artigo sobre a implementação de algumas funcionalidades como modais acessíveis no React - e vai estar disponível muito em breve (confira na discussão do artigo se a proxima parte já está disponível!)

Compreensível

Card com descrição sobre o critério de sucesso: Declarar adequadamente o idioma da tela faz com que leitores de telas utilizem uma entonação correta para citar conteúdos. Sempre os declare

Declarar o idioma da página no atributo lang no HTML já nos traz o sucesso para esse critério, uma coisa interessante nessa guideline é que ela também torna o site mais acessível a pessoas que não falam a língua da sua aplicação, assim o navegador consegue automaticamente ao entrar na página recomendar uma tradução da página com o Google Tradutor.

Robusto

Card com descrição sobre o critério de sucesso: Qualquer tipo de mensagem que é resultado de uma ação ou que informa o andamento de um processo e que seja relevante para a pessoa, deve ser transmitida sem que ocorra uma mudança de contexto (foco) na tela. Nota: é altamente recomendado a leitura completa do critério para identificar exemplos e casos de uso

As vezes pode parecer obvio e talvez você até ache que sua aplicação é acessível nesse ponto, mas aqui temos uns pontos especificos para tocar:

  • As mensagens de status devem ser declarativas e "user-friendly", não basta exibir um erro se você traz uma mensagem que o usuário pode não entender, como: ERRO H248. Algo como "Formato de data inválida" ou "Algo de errado aconteceu" (caso seja um erro não tratado) seria a mensagem correta.

  • Não deve acontecer mudança de contexto (foco) na tela, e leitores de tela devem ler automaticamente a informação quando exibida.

Futuro desse guia

Tenho um "roadmap" de artigos que vão ser escritos até 15/12/22 e que vão incrementar e contribuir diretamente com esse guia.

São eles:

  • Desenvolvimento de modais acessíveis no React
  • Otimizando aplicação para leitores de tela
  • Testes de acessibilidade em aplicações React

Transformando isso no guia definitivo de acessibilidade no React

Esse só vai se tornar um grande guia com a ajuda da comunidade e você é essencial para isso!

Contribua com o seu conhecimento, me questione se você acha que eu falei *****, e deixei seu tabcoin se curtiu o conteúdo!

Conclusão

Isso foi um pouco do que eu aprendi com o curso de acessibilidade no React da Rocketseat e em artigos e guias da WCAG. Todo o conteúdo desse artigo é fortemente inspirado e tem como fonte o artigo do Joseph Oliveira, instrutor do curso da Rocket.

https://www.rocketseat.com.br/ - Rocketseat
https://www.w3.org/TR/WCAG21/ - WCAG 2.1 Guidelines
https://www.w3.org/WAI/WCAG21/Understanding/ - Understanding WCAG 2.1

https://guia-wcag.com/ - Guia WCAG em português

feito com 🌶 por João "pmenta" Martins

Fonte: https://www.w3.org/WAI/

Carregando publicação patrocinada...
5
luispa

Parabéns João, excelente artigo cara!

Quero deixar a minha contribuição para o teu guia, que é falar sobre o atributo aria-label que é essencial em situações onde adicionamos um ícone SVG dentro de uma tag <button>, por exemplo:

<button aria-label="Fechar" onclick="modal.close()">
    <svg aria-hidden="true" focusable="false" width="17" height="17" xmlns="https://www.w3.org/2000/svg"> <path d="m.967 14.217 5.8-5.906-5.765-5.89L3.094.26l5.783 5.888L14.66.26l2.092 2.162-5.766 5.889 5.801 5.906-2.092 2.162-5.818-5.924-5.818 5.924-2.092-2.162Z" fill="#000" />
</button>

O SVG se trata de um ícone "X", comumente utilizado para indicar que ao clicar nele alguma coisa será fechada. Notem que na tag <button> existe o atributo aria-label com o valor "Fechar", ou seja, está dando um significado para esse botão, até porque "X" não quer dizer nada e usuários que utilizam leitores de tela teriam sérios problemas com isso!

Podemos dizer que o atributo aria-label em situações como essa funciona da mesma forma que o atributo alt para uma imagem que precisa ter um(a) significado/descrição.

2
pmenta
Autor
Autor

Cara, excelente contribuição.

Eu vou trazer um pouquinho mais sobre aria-roles e mais alguns atributos aria no próximo artigo, fica ligado!

1
luispa

Opa, valeu João!

Com certeza eu vou acompanhar sim. Acessibilidade é um tema muito importante e interessante. Apesar da plataforma ainda não ter a opção de salvar um artigo, eu já salvei nos meus favoritos do navegador haha!

Aguardando ansiosamente pelos próximos updates. Sucesso!

2
1
3
Imperatore

Obrigado, meu nobre Jedi.
Gostei muito de seu artigo e acredito que ele seja muito importante para os criadores de conteúdo. Não irei mentir que meu BPM aumentou quando eu li muito rápido, achei que as pessoas do Twitter estavam migrando por toda a internet e espalhando sua mediocridade, mas graças que eu estava errado.

Extrapolando a idéia de um tutorial em um video game, em minha concepção, a acessibilidade definitiva seria modelar a página para que você nem precise se quer falar o idioma presente na página ou em suas imagens. Infelizmente, eu sou apenas um estudante de direção e não um programdor, então não entendo como isso poderia ser aplicado.

2
ngoma

[Acessibilidade na web] Cara eis aqui um artigo que para mim vale muito a pena, terei muito gosto em dar 2 upvote. Valeu pmenta.

2
2
2
thiagoomatheus

[ACESSIBILIDADE]
Excelente! Me desepertou alguns detalhes que preciso melhorar na hora de codar e me fez ver que a acessibilidade é benefica para todas as pessoas.

2
1
pmenta
Autor
Autor

Cara, muito interessante. Joguei a URL desse artigo lá e ele me atentou em algumas coisas que eu nem sabia! E ainda me deu uma brecha para falar um pouquinho sobre a atenção e pesquisa na hora de realizar testes de acessibilidade na web.

Todas as imagens do meu markdown tem uma descrição alt com o conteúdo do card.

Ele me atentou que todas essas imagens tem uma alt maior que 100 caracteres e me recomenda usar o atributo longdesc.

Então meus elementos de imagem ficariam assim:
<img src="{url}" alt="Card com descrição de critério de sucesso" longdesc="{url.txt contendo a descrição longa com o conteúdo do card}" />

mas além de ser um atributo não suportado por quase nenhum browser moderno (se por algum acaso as imagens acabarem não carregando, o usuário só seria capaz de saber que aquilo era um card, mas não o que o card dizia), nem todos os leitores de telas tem suporte para long-desc.

Esse atributo não fez sentido nesse contexto, mas talvez faça no seu! Então sempre pesquise bastante e analise o seu caso e pense em qual solução seria a mais acessível para todos!

2
1
1
1
Rakupo

Post top demais. É um assunto muito importante que todo dev deveria se atentar, já que até grandes empresas não se preocupam com acessibilidade na maioria das vezes. Trabalhei em um projeto que tentamos nos atentar ao máximo sobre acessibilidade, inclusive fazendo testes de qualidade utilizando leitores de tela (ios, android, windows e linux). É muito importante mesmo.

1
1
d0100g

geralmente existe a maneira certo e a maneira errada como tambem o jeito fácil e o jeito difícil... o problema é que existe um universo grande entre esses pontos sendo negigenciados hoje, e lançar uma luz, como neste artigo, é fundamental... parabens pela iniciativa

1
thFernandes

muito bem escrito e bem explicado o conteúdo, parabéns 👏🏽👏🏽

é um assunto extremamente importante que por muitas vezes é deixado de lado ou feito de maneira incompleta. como por exemplo o tópico de mensagens de status que por muitas vezes é mostrado um erro que assusta qualquer usuário