Concrete Logo
Hamburger button

Trilha de acessibilidade no TDC: o que aprendi

  • Blog
  • 19 de Setembro de 2018

Assim como os testes, a acessibilidade das aplicações costuma ser um dos primeiros requisitos a ser deixado de lado. A maioria delas são desenvolvidas sem considerar o público PCD (Pessoas Com Deficiência) e em consequência a acessibilidade não é implementada. Eu mesmo nunca pensei em acessibilidade, até substituir um QA que saiu de licença e o projeto, o aplicativo de um banco, tinha a acessibilidade como requisito obrigatório.

Enquanto estava neste projeto, ganhei da Concrete a oportunidade de participar da TDC. Escolhi a trilha de acessibilidade por ser a única que eu não tinha nenhuma noção e que fosse talvez a mais difícil de se encontrar especialistas no assunto. Decisão correta!

Neste post, vou falar sobre algumas lições aprendidas e outras mais confirmadas, que podem (e devem) ser usadas fora do “mundo acessível”.

Algumas definições

Acessibilidade significa disponível para todos. Quando falamos em software acessível, a primeira deficiência que vem à cabeça é a visual, ou seja, precisamos de um leitor de tela. Só que cegueira total não é a única deficiência existente, inclusive no evento mostraram uma estatística que diz que grande parte dos deficientes visuais nem utilizam o leitor de tela. Existem vários níveis de cegueira.

E também existem as deficiências físicas, motoras e cognitivas. Uma aplicação fácil de ser entendida e de se usar também é, de uma maneira superficial, uma aplicação acessível.

Dito isso, daqui para frente vou usar a palavra acessibilidade também como sinônimo de usabilidade, ok? Mesmo elas não tendo o mesmo significado.

Facilite as coisas

Na primeira palestra, “Acessibilidade Toolkit: Entendendo de uma vez por todas a WCAG!“, Marcelo Sales simplificou as regras do WACAG (Web Content Accessibility Guidelines) e as colocou em cartões, utilizando a dinâmica de card sorting, para facilitar o entendimento.

Um dos pontos apresentados sobre poucos estudarem sobre acessibilidade é a maneira como a documentação está escrita. Veja por você.

Levando para software, não adianta ter uma aplicação completa se ninguém consegue ou não é prazeroso usar. Deixe a usabilidade o mais simples e a curva de aprendizado a menor possível. Se algo não foi intuitivo para você, que está desenvolvendo e/ou testando a aplicação, imagine para quem usa pela primeira vez?

Você pode acessar os cards pelo site guia-wcag.com. O código fonte também está disponível no GitHub.

O artigo completo sobre este trabalho pode ser lido no Medium //ux.blog e a apresentação está no Slideshare.

Acessibilidade não é somente tags

Quando se fala em deixar uma aplicação acessível, muitos pensam somente em colocar tags como arias e alt, ou seja, completar o código para que leitores de tela consigam ler. Mais uma vez só estamos pensando em quem tem cegueira total.

Na palestra “Achou que CSS não tem a ver com Acessibilidade? Achou errado!“, Lucas Silva contou como o CSS pode ajudar (ou estragar) a acessibilidade.

Algumas dicas que ele deu:

Cor sólida como fundo de imagem

Se uma imagem não for carregada pelo browser, a maneira como isso é mostrado pode não ser perceptível para o deficiente visual. Deixe uma cor sólida de alto contraste com o fundo da página para sinalizar uma imagem não carregada.

Destaque campos de formulários

Quem tem baixa visão muitas vezes não consegue identificar qual campo está ativo em um formulário. Instruções como “os campos em vermelho são obrigatórios” não funcionam para daltônicos, por exemplo. Uma dica é transformar o formulário em preto e branco. Se não conseguir dizer qual campo está ativo, revise.

Outro passo importante é testar a navegação pelo teclado. Todos os campos devem ser acessíveis via teclado.

Mantenha a ordenação dos elementos

Uma parcela das PCDs navegam pelas aplicações utilizando o teclado do computador ou o swipe do celular. A ordenação natural que os itens são percorridos é da esquerda para a direita e de cima para baixo. Se ao implementar o CSS da sua página você muda essa ordenação para ficar mais bonito visualmente, a pessoa com deficiência se perde na sua página. Mude o design, mas não mude a ordem.

Dados devem estar disponíveis sem o CSS

Nenhuma informação de conteúdo deve ser passada via CSS. Para confirmar, deixe a página somente com HTML e leia o conteúdo. Todas as informações devem estar lá e fazer sentido. Se você quiser saber mais, a apresentação está disponível no Slideshare.

Complementando esse assunto, na palestra “Implementando acessibilidade em uma aplicação fora dos padrões” Michelle Frasson explicou mais tecnicamente que não é só sair colocando atributos e esperar que tudo fique semântico. Ela comentou sobre o WAI-ARIA (Accessible Rich Internet Applications) e como seus roles, states e properties podem ajudar a deixar o conteúdo e aplicativos web mais acessíveis,

Cegos não vêem

Parece óbvia essa afirmação, mas a Juliana Fernandes contou na palestra “O fantástico mundo da descrição de imagens” que fazer um “cego ver” é um pouco mais complexo do que se pensa. Ela começou se descrevendo fisicamente: cor e comprimento dos cabelos, como era seu casaco e tênis, que usava óculos… Tudo isso ajuda principalmente a quem se tornou cego.

Na palestra ela mostrou exemplos de descrição de imagens, ruins e boas, e mostrou que não existe certo ou errado. As boas práticas dizem para a descrição ser de cima para baixo e da esquerda para direita, mas se existir um tema principal, comece por ele. O fundo e elementos secundários também devem ser descritos, exceto quando não contribuem para a interpretação da cena. Cabe a decisão a quem vai descrever.

Outra dica legal da Juliana é tomar cuidado para não colocar a sua interpretação na descrição, como dizer se algo é bonito ou feio, porque essas qualidades não são absolutas. Ao invés disso, descreva o que vê e deixe a pessoa interpretar.

Veja mais exemplos na apresentação da Juliana.

Um erro muito comum ao aparecer imagens em uma apresentação é quem apresenta dizer “como podemos ver”. Se existir pelo menos uma pessoa com deficiência na plateia, ela não pode ver… Descreva!

Pense sempre nos usuários do seu software

No início, a iFood não se preocupava com a acessibilidade do seu aplicativo. Até que receberam uma reclamação que, em um sábado chuvoso, um cego que mora sozinho não conseguiu completar seu pedido pelo app. Izabela de Fátima e Juliana Salgado Oliveira da Silva contaram na palestra “Acessibilidade: da pesquisa à criação de cultura no iFood” como essa reclamação as fez pensar e redesenhar o aplicativo.

Elas mostraram como a app lia as informações antes, que era praticamente impossível de se entender. Depois, ao reformularem o aplicativo, não só a leitura dos elementos foi reorganizada, como também foram dados contextos na leitura de alguns elementos. O feedback positivo dos usuários foi praticamente imediato!

A apresentação delas está disponível em vídeo na íntegra na Eventials. Vale muito a pena!

Depois, a Tatiane Levrero continuou o assunto com a palestra “Qual o papel do usuário no desenvolvimento de aplicações acessíveis?

A principal lição que tirei dessa palestra foi que a maioria são pessoas sem deficiência criando para pessoas com deficiência. Então, vamos expandir o horizonte. Muitos aplicativos são desenvolvidos com funcionalidades que o time ou quem pagou pelo aplicativo quer e acha melhor, sem nenhuma pesquisa de campo.

“Nenhum plano sobrevive ao primeiro contato com os clientes”.

Se acredita em algo, não desista, insista

A Natália Raythz, mulher negra, da periferia e com deficiência auditiva, contou sua jornada e dificuldades de vida até se tornar programadora em Big Data na palestra “Sou deficiente auditiva, e daí?”. Nunca passei pelo que ela contou, então o que consigo fazer são analogias com o que já esbarrei tanto pessoal quanto profissionalmente. Uma delas é a que dá título a esta sessão.
Deixando o lado pessoal de lado, o que consigo trazer para a área de testes e produto é que se você acredita que algo está errado ou pode melhorar, insista até conseguir ou ser convencido de que a sua não é a melhor ideia.

As três palestras restantes não foram sobre desenvolvimento de software, mas também foram bem interessantes. Dou destaque para a palestra “Recrutamento de pessoas com deficiência”, do Sérgio Ramos de Faria. Ela merece um post completo. É muito ruim confirmar que muitas empresas só contratam PCDs porque são obrigadas a cumprir cotas e para fazer propaganda.
Muito do que foi falado também se aplica a pessoas sem deficiência. As outras duas você pode consultar o resumo no site da Trilha Acessibilidade do TDC.

  • “Neurodildo: um vibrador controlado por ondas cerebrais para pessoas com deficiências físicas severas” de Leonardo Mariano Gomes
  • “Projeto Bengala IoT” de Rodrigo Ferraz Azevedo

Para finalizar, vou tomar a liberdade de modificar um dito popular:

“Em terra de cego, quem enxerga é quem tem a deficiência”

Essa foi minha sensação! Ser “um peixe fora d’água”, no meio de pessoas que “falam” a mesma língua, mas não a mesma linguagem. Ficou alguma dúvida ou tem algo para contribuir? Aproveite os campos abaixo. Até a próxima!