7 erros comuns de acessibilidade (e como evitá-los)

É provável que já tenha ouvido falar de acessibilidade digital antes, e sabe que é importante otimizar o seu produto online para pessoas com deficiências. É compreensível que se sinta sobrecarregado com todas as informações e tarefas que deve efetuar para melhorar o seu produto. Talvez tenha concluído que é tão complicado que precisa de contratar um especialista para fazer o trabalho. Entretanto, você preocupa-se! Só não sabe como começar.

Não se preocupe; corrigir ou evitar estes problemas muitas vezes não é assim tão demorado! Isto é, se souber onde procurar e o que fazer em vez disso. Nos anos em que trabalhei como programador Web e engenheiro de software de front-end, deparei-me com muitos problemas de acessibilidade. Muitas vezes, resumem-se ao mesmo conjunto de pontos. Na maioria dos casos, uma abordagem orientada para a acessibilidade não demora muito tempo. Não é mais difícil ou dispendiosa. É fazer o seu trabalho diário com uma mentalidade diferente que melhora tremendamente a acessibilidade.

Mas agora vamos ao que interessa: deixe-me explicar quais são os problemas de acessibilidade mais comuns e, mais importante, como evitá-los.

Erro 1: Marcação semântica deficiente

Evitar problemas de acessibilidade não requer trabalho extra. Simplesmente requer um trabalho diferente

Um dos erros mais comuns, com consequências lamentavelmente graves, é a má marcação semântica. Se conhece um pouco de HTML, deve saber que uma página é constituída por elementos definidos por HTML tags, por exemplo <h1> e <p>. A maioria dos elementos são semânticos: descrevem claramente o seu significado de uma forma legível por humanos e máquinas.

Se visualizar o código-fonte de qualquer página Web, também notará uma grande quantidade de elementos <div> e <span>; estes são os elementos não semânticos. Estes elementos são contentores genéricos, não aplicando qualquer significado ao seu conteúdo.

Os leitores de ecrã baseiam-se fortemente no HTML semântico. Formam uma árvore de acessibilidade com base na semântica da página. Um utilizador com um leitor de ecrã pode saltar de elemento para elemento utilizando atalhos. Indica-lhe quais são os botões, quais são os títulos, onde está a navegação, como a informação na página se relaciona com outros elementos na página, etc.

Utilização excessiva de elementos não semânticos

Se utilizar elementos <div> e <span> onde deveria estar um elemento semântico, perde-se instantaneamente informação essencial. Os utilizadores com deficiência visual não conseguem ver a estrutura do sítio Web com base no que vêem. Não conseguem ver os botões ou o menu de navegação. A página Web torna-se numa grande pilha de conteúdos não estruturados. Pior ainda, muitas vezes os elementos interactivos - como os botões - tornam-se completamente inutilizáveis. Ao navegar na Web, encontro frequentemente elementos <span> controlados por JavaScript, com o estilo de um botão. O JavaScript é escrito para ser ativado por um clique do rato. Isto funciona bem para todos os que podem usar um rato, mas não pode ser controlado pelo teclado, e é muitas vezes impossível para um utilizador de leitor de ecrã encontrá-lo.

Sugestão: utilizar HTML semântico

Se se parece com um botão e se comporta como um botão, deve ser um botão

A minha dica para evitar este comportamento indesejado provavelmente não é uma surpresa: use appropriate semantic HTML elements as much as possible. Os únicos casos em que você deve usar os elementos <div> e <span> são quando não há outro elemento disponível para transmitir significado. Isso geralmente se resume apenas a fins decorativos.

A utilização de elementos semânticos aumentará exponencialmente a acessibilidade da sua página Web. Isto deve-se ao facto de estes conterem informações para o browser sobre a forma como devem ser utilizados. Além disso, como programador ou engenheiro, até poupa tempo. Não precisa de pensar em imitar o comportamento de um botão, por exemplo, porque ele já funciona dessa forma.

Utilizar os elementos semânticos errados

Outro erro comum nesta categoria é escolher o elemento semântico errado. Isso geralmente é o resultado da escolha de um elemento por sua aparência em vez de seu comportamento ou sua finalidade. Talvez você não tenha usado um <button> nativo porque achou que ele parecia feio. Ou talvez você tenha pulado alguns níveis de cabeçalho e escolhido um <h4> em vez de um <h2>, porque você gostou que ele tinha um tamanho de fonte menor. Este é o caminho errado; temos CSS para esse fim.

Sugestão: escolher um elemento pelo seu significado

Utilize elementos HTML para estruturar o seu conteúdo com base no significado de cada elemento e não no seu aspeto. Em seguida, aplique estilos ao seu gosto com CSS.

Sugestão: utilizar ferramentas automatizadas

Uma boa forma de o ajudar com a semântica é utilizar uma HTML validator tool. Algumas ferramentas incluem isso em testes de acessibilidade automatizados, como axe Tools. Lembre-se de que as ferramentas automatizadas não podem testar tudo e muitas vezes incluem falsos positivos e negativos. Mas podem ajudar a detetar rapidamente erros que possam ter passado despercebidos. A melhor opção é combinar testes automatizados e manuais de acessibilidade.

Erro 2: Etiquetas de formulário mal estruturadas

Se se parece com um botão e se comporta como um botão, deve ser um botão.

Este erro também tem muito a ver com HTML semântico. Não se engane: conceber e implementar um formulário utilizável, acessível e com bom aspeto é um grande desafio!

O formulário de início de sessão do Easy LMS. As etiquetas movem-se para cima quando preenche um campo do formulário, pelo que permanecem visíveis.

A entrada e o rótulo não estão ligados

Cada formulário tem um campo de entrada e uma etiqueta que descreve esse campo de entrada. Por exemplo, tenho três campos de entrada: "Nome", "Endereço de correio eletrónico" e "Empresa". Eu poderia adicionar os nomes acima das entradas em texto simples (como dentro de um elemento <span> ?). Infelizmente, um utilizador de leitor de ecrã irá encontrar três entradas de texto vazias sem indicação do que deve preencher.

Sugestão: emparelhar etiqueta e entrada

A utilização de elementos HTML semânticos para as etiquetas já é uma grande ajuda, mas se quiser realmente ajudar os seus utilizadores, deve também pair your label and input. Agora o navegador sabe que os dois pertencem um ao outro. No Easy LMS, diríamos: lucro!

Utilizar atributos de marcador de posição como etiquetas

Outra prática que impede a acessibilidade é omitir rótulos e, em vez disso, usar placeholder attributes nas entradas. Esta é uma má prática por várias razões. Em primeiro lugar, muitas vezes não está disponível para muitas tecnologias de apoio. Em segundo lugar, assim que um utilizador escreve a entrada (ou preenche automaticamente o formulário), as etiquetas desaparecem. Desta forma, é difícil verificar se existem erros no formulário. Por último, um marcador de posição serve como uma sugestão adicional - não como uma etiqueta.

Dica: Não substitua uma etiqueta por um marcador de posição

Nunca omita etiquetas num formulário. Se for necessário, utilize marcadores de posição apenas para dar dicas adicionais aos utilizadores (com visão) nos formulários. Melhor ainda: não utilize de todo atributos de marcadores de posição e certifique-se de que as informações importantes sobre o formulário estão disponíveis para todos.

Erro 3: Utilizar hiperligações não descritivas

Quantas vezes já se deparou com hiperligações que dizem "clique aqui", ou "leia mais", ou "vá para esta página"? O meu palpite: mais do que podes contar! Uma das razões pelas quais esta é uma má prática é o facto de não permitir a compreensão do objetivo da ligação fora do contexto. Com as tecnologias de apoio, os utilizadores podem navegar rapidamente pelas ligações de uma página. Imagine um leitor de ecrã a comunicar-lhe o seguinte: "Aqui, ligação. Ler mais, ligação. Esta página, ligação". Isto não lhe diz nada, pois não?

Sugestão: incluir o assunto da página na hiperligação

Então, como é que podemos evitar isto? Na maioria dos casos, isto pode ser resolvido facilmente incluindo o assunto ou o título da página a que se está a referir dentro da hiperligação. Deixe-me dar-lhe um exemplo: pode saber mais sobre diferentes tipos de deficiências neste artigo do W3C. Agora, o leitor de ecrã comunicará: "diferentes tipos de deficiências, link". Lucro!

Sugestão: otimizar as ligações repetidas

Imagino que não queira incluir o título em todas as ligações "Ler mais" numa lista de artigos. Isso adiciona muita confusão à página. Há uma série de diferentes abordagens sobre como tornar acessíveis as hiperligações "leia mais", e cada caso de utilização tem de escolher a que melhor funciona. Em the overview of this blog, optámos por otimizar as hiperligações para leitores de ecrã adicionando um aria-label que inclui o título do artigo.

Erro 4: Depender de imagens como a única forma de transmitir informação

Sendo eu um pensador visual, sei como é mais fácil compreender algo a partir de uma imagem do que a partir de um texto. Não vou dizer que utilizar imagens para explicar ou fazer referência numa explicação é mau. De facto, encorajaria toda a gente a utilizar imagens dessa forma, uma vez que, para algumas deficiências (como a dislexia), melhora efetivamente a acessibilidade. No entanto, utilizar imagens como única forma de transmitir informação é uma má prática.

A nível mundial, cerca de 43 milhões de pessoas são cegas e cerca de 295 milhões de pessoas têm uma deficiência visual moderada a grave. Este número não inclui apenas a cegueira total, mas também, por exemplo, a perda de visão central ou periférica e a visão turva. Se depender de imagens para explicar o seu ponto de vista, arrisca-se a que uma parte do seu público perca uma grande parte da informação.

Capturas de ecrã

Um exemplo real deste problema é a explicação de como utilizar uma interface através de capturas de ecrã. O texto diz simplesmente: "clique no botão assinalado na imagem" ou "faça a sua configuração como na imagem seguinte". Sem estas imagens, é impossível saber o que fazer com essas instruções. Considerando que este tipo de artigos é frequentemente encontrado em bancos de conhecimento, documentação ou tutoriais, torna-se ainda mais problemático.

Um exemplo de uma captura de ecrã do nosso Centro de Ajuda. O texto que acompanha o artigo de ajuda diz: "Pode ajustar as definições da sua categoria de Passe selecionando Editar".

Sugestão: o seu texto deve ser compreensível sem imagens

O seu público deve ser capaz de compreender as informações sem as imagens. Com instruções tanto em texto como em imagens, o leitor pode escolher a sua forma preferida de obter as informações ou tem uma alternativa em caso de dificuldade. Um truque que utilizo pessoalmente é escrever o texto como um todo e adicionar as imagens depois, como fiz para este artigo do blogue. Desta forma, não caio na armadilha de deixar de fora informação porque era visível numa imagem enquanto estava a escrever.

Falta de texto alternativo

Muitas vezes, as imagens informativas que encontra nos sítios Web têm um texto alternativo fraco ou não o têm de todo. O objetivo dos textos alternativos é descrever a imagem para os utilizadores de leitores de ecrã. Se este texto estiver vazio, os utilizadores de leitores de ecrã não saberão o que está na imagem ou se perderam alguma informação importante.

Sugestão: adicionar textos alternativos a imagens funcionais e informativas

O texto alternativo será comunicado a um utilizador que não consiga ver a imagem (corretamente). Aconselho toda a gente a não os ignorar, mas a adicionar um clear descriptive alternative text para a imagem. Isso pode ser feito no código-fonte. Num CMS, existe frequentemente um campo de entrada dedicado para o efeito.

Sugestão: tratar de forma diferente as imagens decorativas para leitores de ecrã

Por vezes, as imagens são adicionadas apenas como decoração para tornar uma página visualmente mais atractiva. Por vezes, é preferível que as imagens sejam completamente ignoradas por um leitor de ecrã. Existem diferentes abordagens sobre como lidar com textos alternativos dependendo do objetivo da imagem.

Texto em imagens

O texto em imagens também não é compreensível para pessoas com deficiências visuais. Ficaria surpreendido com a quantidade de texto que se encontra dentro das imagens (basta olhar para qualquer plataforma de redes sociais). Mais uma vez, isto não é mau por si só, mas certifique-se de que adiciona o texto numa descrição ou como texto alternativo.

Erro 5: Fraco contraste de cores

Escolha um elemento HTML pelo seu significado, não pela sua aparência

O texto com pouco contraste foi o problema de acessibilidade mais frequentemente detectado pelos testes automáticos efectuados pelo WebAIM. Isto não é apenas problemático para as pessoas que sofrem de baixa visão, mas também afecta as pessoas com deficiência de visão cromática (diferentes tipos de daltonismo). Cerca de 1 em cada 12 homens e 1 em cada 200 mulheres têm algum grau de daltonismo. Algumas pessoas nem sequer sabem que têm este problema. Se olhar para a imagem abaixo, qual é o número que vê?

Which number do you see? Image source

Se vir 74, pode ter uma visão cromática normal. Se vir 21 ou nenhum número, pode ter uma deficiência de visão cromática vermelho-verde. Nesse caso, pode ter-se deparado com sítios Web com partes difíceis de ler.

No WCAG a Success Criterion é definido para quando o contraste entre o texto e o seu fundo é suficientemente elevado para que as pessoas com visão moderadamente reduzida o possam ler. As diretrizes das WCAG estão categorizadas em três níveis de conformidade. No Easy LMS, o nosso objetivo é o nível AA. Estes rácios de contraste são de 4,5:1 para texto pequeno e 3:1 para texto grande.

Sugestão: utilizar uma ferramenta para verificar o contraste de cores

Então, como é que se descobre se o contraste do texto é suficientemente elevado? Existem muitas ferramentas de contraste de cores disponíveis que podem ser utilizadas para efetuar testes na sua página Web. Também pode testar o contraste de cores manualmente, introduzindo os códigos de cores do primeiro plano e da cor de fundo num verificador de contraste online.

Sugestão: utilizar tons mais escuros ou mais claros de uma cor

Um desafio que surge frequentemente com esta questão é o facto de as cores utilizadas na interface do utilizador corresponderem às cores do logótipo da marca. Isto pode dificultar a resolução do problema, uma vez que as cores parecem fazer parte da identidade da marca. Uma boa prática é usar um tom mais escuro ou mais claro da cor desejada para melhorar o contraste. Ajustámos as cores do Easy LMS por esta razão há alguns anos atrás!

Utilizar a cor como única forma de transmitir informação

Há pouco referi os problemas que resultam da utilização de imagens como única forma de transmitir informação. O mesmo se aplica às cores. As cores vermelho e verde são frequentemente usadas como a única forma de informar sobre estados de sucesso e erro. Infelizmente, o daltonismo vermelho-verde é o tipo mais comum de daltonismo. Para estes utilizadores afectados, o vermelho e o verde serão parecidos.

Sugestão: prever várias formas de comunicar os estados

Não há problema em utilizar o vermelho e o verde para estes fins, mas certifique-se de que fornece sempre outra forma de comunicar estados, como texto, formas diferentes ou ícones (rotulados).

Erro 6: Não fornecer uma indicação visual do foco atual

A maioria dos utilizadores navega nos seus computadores com um dispositivo apontador, como um rato ou um trackpad num computador portátil. Nos dispositivos móveis, utilizamos os nossos dedos num ecrã tátil. Para alguns utilizadores, isto é difícil ou impossível devido à sua deficiência. Exemplos disso são a paralisia, a falta de uma parte do corpo, a artrite ou as lesões por esforço repetitivo. Nestes casos, os utilizadores mudam frequentemente para um teclado ou um dispositivo de introdução alternativo que possa imitar o comportamento do teclado. Os utilizadores com deficiência visual utilizam sobretudo um teclado juntamente com o seu leitor de ecrã ou gestos nos seus dispositivos móveis.

Se premir a tecla Tab do seu teclado, pode saltar entre elementos interactivos de uma página Web, como botões e ligações. Pode experimentá-lo nesta página: após cada separador, verá uma indicação visual da sua localização no ecrã.

Estilos de focagem CSS

No CSS, é possível adicionar estilos para vários estados diferentes de botões, tais como hover, foco e ativo. Muitas vezes, alguns ou todos estes estados são deixados de fora, e o botão não muda de aspeto com a interação. Neste caso, um utilizador de teclado está a voar às cegas.

Sugestão: aplicar estilos de focagem juntamente com os estilos de foco

Enquanto estiver a adicionar estilos para o estado de foco dos botões, é boa prática adicioná-los também para os estados de foco. Idealmente, o estilo de foco deve ser mais visível do que o estilo de foco, pelo que também pode adicioná-los separadamente numa tonalidade diferente.

Contorno do foco do navegador

Um indicador de foco básico é fornecido automaticamente pelo navegador Web e é normalmente apresentado como um contorno. Se acabou de percorrer esta página, pode tê-lo visto. Infelizmente, este contorno é frequentemente desativado com CSS, por razões estéticas. Mas com o contorno desativado e sem estilos de focagem, é impossível navegar numa página Web apenas com o teclado.

Sugestão: não desativar o contorno

Os utilizadores de ratos não verão o contorno do navegador que se vê quando se faz tabulação numa página Web com um teclado. Não desactive este contorno com CSS, pois é uma ajuda essencial para os utilizadores com deficiência. Também funciona muito bem como apoio no caso de os seus estilos de focagem não serem muito claros ou desaparecerem por acidente.

Não se esqueça de que os indicadores de foco do teclado dos navegadores podem variar e assumir diferentes formas. Por este motivo, não se pode confiar totalmente neles. Por outro lado, seriam necessários muitos testes para saber com certeza se os seus estilos de focagem são suficientemente claros para os utilizadores com deficiência. É por isso que aconselho a ter sempre ambos.

Erro 7: Utilizar ícones não identificados em botões e hiperligações

Os ícones utilizados no software tornam-se reconhecíveis com a utilização repetida

Os ícones são uma óptima forma de evitar a desordem no seu produto em linha. Também têm o poder de melhorar a acessibilidade para várias deficiências, isto é, se não forem ambíguos. A maioria de nós sabe que, se virmos um ícone de lápis, significa "editar" e que um caixote do lixo significa "apagar". Quando utilizamos ícones numa interface de utilizador, é melhor usar os que conhecemos para evitar adivinhações. Mas mesmo assim, em termos de acessibilidade, muita coisa pode correr mal.

Os ícones podem ser utilizados juntamente com a etiqueta de texto correspondente ou isoladamente. Na maior parte das vezes, não é fornecida qualquer etiqueta quando são utilizados isoladamente. Por exemplo, adiciono um botão de ícone para uma ação de edição, apenas com um ícone de um lápis no interior. Se não adicionar uma etiqueta de texto para este ícone, o botão torna-se um botão vazio. É isso mesmo: um leitor de ecrã comunica-me: "Botão". Isso não é muito útil.
Mais ainda: Estou a partir do princípio de que o utilizador sabe que um ícone de lápis significa "editar". Mas não tenho a certeza disso.

Sugestão: adicionar uma etiqueta para os ícones

Se o ícone for uma parte importante da sua interface de utilizador, então é melhor adicionar uma etiqueta. Pode fazê-lo adicionando um aria-label no ícone. Uma segunda forma é adicionar text that you hide for screens but is visible for screen reader users. É melhor adicionar um atributo de título também. Desta forma, se um utilizador passar o rato por cima, a etiqueta é apresentada.

Botões de ícones no painel de controlo do Easy LMS que mostram um título quando se passa o rato sobre eles

Sugestão: ocultar ícones decorativos

Se adicionou um ícone apenas como açúcar no topo e a informação é compreensível sem ele, então é melhor hide the element for screen reader users.

Conclusão: não trabalhe mais, trabalhe de forma mais inteligente

A ideia de que é necessário alterar estas coisas pode ainda ser um pouco assustadora. Quando comecei a aprender sobre acessibilidade, tive a mesma reação. Há tanto para aprender e tantos tipos diferentes de deficiências. É difícil criar uma interface de utilizador perfeita para todos.

Mas quero dizer-vos: não se trata de reformular o vosso produto ou sítio Web. Descobri que a melhor forma de o fazer é integrá-lo no seu fluxo de trabalho. Da próxima vez que criar ou repetir uma parte do produto, aplico imediatamente o que aprendi sobre acessibilidade. Desta forma, podemos melhorar a acessibilidade um passo de cada vez. Como aconselha um dos meus heróis da acessibilidade Léonie Watson: "Não tem de ser perfeito; só tem de ser um pouco melhor do que ontem." Prega!