Acessibilidade Web é tema da primeira parte da trilha front-end na segunda edição do Programaria Summit, que aconteceu no dia 07 de setembro
Bruna Gabriele de Paula/PrograMaria
A palestra foi conduzida por Paula Allemand, desenvolvedora de software na Tera. A presença do tema acessibilidade tende cada vez mais a fazer parte da idealização e desenvolvimento de sites, mas afinal, como trazê-lo do ideal para a prática?
É importante lembrar que quando pensamos em acessibilidade, devemos considerar não somente o acesso para quem usa leitor de tela, mas também pessoas que possuem algum tipo de deficiência cognitiva, como por exemplo a dislexia.
“23% da população brasileira declara possuir algum tipo de deficiência”
Nesse sentido, pensar sobre as práticas que tornam um site mais acessível requer um recorte mais aprofundado dentro do âmbito de acessibilidade web cognitiva. Seguindo esse caminho, Paula apresenta conceitos, práticas e técnicas que nos mostram ‘algo a mais’, além do ALT no IMG.
Essas práticas estão previstas em diretrizes do guia W3Schools, na sua versão mais recente de 2018 (http://www.w3c.br/traducoes/wcag/wcag21-pt-BR/), traduzidas e disponíveis. Lá estão expostos critérios de conformidade e níveis de acessibilidade que um site pode ter, gradualmente em níveis A, AA, AAA.
O foco da apresentação foi direcionado para práticas previstas a nível A, abordando os quatro princípios básicos de acessibilidade: perceptível, operável, compreensível e robusto. Palavras como autonomia e contexto guiaram a apresentação desses critérios, onde Paula destaca que não basta que o conteúdo seja perceptível, precisa ser, principalmente, compreensível para o usuário.
PERCEPTÍVEL— uso de alternativas textuais para conteúdos não-textuais entra como uma das práticas mais comuns na construção de sites acessíveis, com ela podemos converter e tornar elementos perceptíveis de acordo com a necessidade do usuário. Além disso, ajuda a flexibilizar a apresentação de conteúdos em mídia ou texto para que se tornem interpretáveis, por exemplo: impressão com tamanho de fontes maiores.
OPERÁVEL— deve ser operável, de maneira que não seja necessário mouse ou touch-pad para navegar pelo site.
ROBUSTO— um site acessível precisa ser também bem estruturado tecnicamente, com uma lógica de raciocínio bem construída para que seja interpretado corretamente por quaisquer agentes de usuário (ferramentas que auxiliam o acesso e navegação do usuário) e, principalmente, por tecnologias assistivas, mantendo e maximizando a compatibilidade entre atuais e futuras versões de navegadores.
COMPREENSÍVEL— os conteúdos precisam ser simples e objetivos, sem muitos jargões e expostos de forma legível. Nesse contexto, um bom exemplo trazido pela desenvolvedora foi a discussão acerca do debate sobre acessibilidade e uso de expressões inclusivas de gênero:
Todas, Todxs, Tod@s
Utilizar @ ou x se tornou muito comum, principalmente para conteúdos relacionados a questão de gênero e, embora seja uma prática inclusiva nesse âmbito, não beneficia pessoas que usam leitor de tela. Uma dica é procurar uma linguagem neutra, onde se possa substituir homem/mulher, menino/menina por “pessoa”.
UX e Acessibilidade
A conformidade dessas práticas no desenvolvimento do código, também se estende ao estudo de experiência do usuário. A percepção, por exemplo, pode ser pensada a partir de três elementos principais:
Conteúdo de mídia – muito importante que esteja previsto na idealização de sites com vídeos, pois, a lógica é simples, se existe vídeo, deve existir legenda. Nas diretrizes ( https://www.w3.org/Translations/WCAG20-pt-br) /do WCAG (Web Content Acessibility Guidelines) essa alternativa consiste em descrições em texto, corretamente sequenciadas, de informações visuais e auditivas baseadas em tempo.
Áudio — se existe algum elemento sonoro no site, o usuário precisa ter autonomia para parar/iniciar o player.
Visualização— assim como acontece quando usamos parallax(técnica para criar ilusão de profundidade em interfaces), os players devem ser dispostos de forma objetiva, sem que o usuário confunda primeiro e segundo plano, ressalta a desenvolvedora.
Outros conceitos importantes são levados em conta em UX (User Experience) como tempo do usuário e autonomia para navegar pelo site, prezando por processos não muito rápidos de interação. O guia de acessibilidade também oferece uma lista de técnicas que podem ser implementadas no código para controlar o tempo desses processos e evitar gatilhos que afetam, por exemplo, usuários com epilepsia.
Localização é outro ponto muito importante na construção de um site acessível, dentro do site o usuário deve conseguir identificar onde está e para onde vai — se está em “header” e vai para o “main”, de forma que reconheça os marcos de navegação dentro do site sem que blocos de raciocínio lógico interfiram no seu fluxo de navegação pela página.
Por fim, para que essa experiência do usuário seja também lembra que é importante evitar erros, principalmente em formulários, dando alternativas de validação em que o usuário possa voltar para corrigir erros de preenchimento de forma simples.
E na prática?
HTML semântico é importante, mas…
Conteúdos construídos desde o princípio com utilização correta da semântica no HTML (Hyper Text Markup Language), já colabora muito para que a web se torne mais acessível, mas…
É sempre possível ir além na busca por acessibilidade, o que se reflete principalmente quando passamos a discutir sobre a relevância de determinadas práticas no desenvolvimento web.
A robustez do site, como já vimos, está diretamente relacionada com estrutura lógica, uma boa prática para manter essa estrutura é desenvolver sempre levando em conta agentes de usuário (Mozilla, Chrome, etc), bem como tecnologias assistivas capazes de apresentar o conteúdo de forma mais adequada aos usuários de diferentes modalidades.
Right Element, Right Job, First Place
Para saber se um elemento vai ou não prover acessibilidade basta perguntar: “Estou usando o elemento certo? Para o trabalho certo?”, o que podemos garantir usando corretamente tags semânticas por exemplo, há motivos para que um Título, não seja <title>? Paula dá exemplo do uso redundante do atributo ALT:
Será mesmo necessário descrever no alt da tag <img> “Foto de duas pessoas conversando”, quando o próprio leitor de tela já identificou este elemento? Neste caso, seria menos redundante só destacar “Duas pessoas conversando…”
Outras técnicas importantes para referenciar elementos de imagem é utilizar tags auxiliares para descrever logotipo. Principalmente se o logo direciona para Home da página, para elementos como SVG (Scalable Vector Graphics) que se aderem bem com o título mas não são interpretados pelo leitor de tela, outra solução seria adicionar um tag <title> para descrever o elemento.
Não abrir mão dos atributos ID e FOR nas tags para que o leitor identifique o label correspondente ao input. Substituir Disabled por Read Only, que ao contrário de desabilitar um texto na tela, tornará apenas elemento de leitura.
Usar Controls e Track para legendas e controle de vídeo, procurar sempre calibrar contrastes, implementar âncoras que direcionem para o contexto principal (main) do site acionadas assim que o usuário inicia a navegação pela tecla.
Tornar o Javascript acessível, atualizando HTML e CSS a partir de códigos, também é um bom caminho para pensar soluções de acessibilidade.
E assim, dos elementos mais básicos, como o uso do ALT até os conceitos mais aprofundados de acessibilidade e entrando um pouco mais além nessa discussão, seja no dia a dia de usuários, como em locais de trabalho, podemos pensar em como oferecer versões de conteúdos web, de fato, acessíveis para diversas modalidades de usuários.
Para encerrar, recupero uma citação feita no fechamento da apresentação:
“A tecnologia não é neutra. E a única maneira de pensar que a tecnologia é neutra é se você vive em um lugar de extremo privilégio”.
