Acessibilidade em produtos digitais

Um case que mostra que nunca é tarde para começar

Bárbara Schoen
Jan 8 · 6 min read

Um produto com mais de 10 anos de mercado recebe reclamações sobre acessibilidade. E agora, o que fazer? Parece difícil saber por onde começar em uma situação dessas, mas simplesmente ouvindo o usuário e juntando forças de desenvolvimento e design, conseguimos melhorar bastante o cenário. Neste post, vamos contar essa história.

O que é o produto?

Um fantasy game de esportes, lançado em 2005, com usuários apaixonados e muito críticos também. São muito comuns os feedbacks em redes sociais, nas lojas dos apps, e até mesmo pessoalmente. O app está disponível para Android, iOS e web, sendo que os usuários Android compõem 80% da base. Possui versão gratuita e paga e 6 milhões de usuários ativos.

Como surgiu a necessidade

Dentre os diversos feedbacks que o produto recebia, um que veio pela central de atendimentos chamou a atenção: a acessibilidade do aplicativo estava deixando muito a desejar.

Quando o time de desenvolvimento recebeu essa notícia, tentamos entender como funcionava a acessibilidade, tanto para iOS, quanto para Android. Testamos nos nossos próprios aparelhos os leitores de tela de cada plataforma, estudamos como precisava ser o desenvolvimento e como organizar o design, estruturamos um documento que mapeava os componentes da tela e o texto a ser lido... até selecionamos uma feature do app para implementar um piloto, mas não conseguimos chegar muito longe sozinhos. Precisávamos de um usuário real, que nos apresentasse suas dores reais!

Conhecendo o problema junto ao usuário

Nessa busca por ajuda, conhecemos o “Rodrigo” (nome fictício). Ele é um jogador experiente, participava de grupos de WhatsApp dedicados ao jogo e, o mais importante pra gente, tem uma deficiência visual e se mostrou muito entusiasmado em poder contribuir com o produto. Passamos quinze dias mantendo contato por mensagens, até que marcamos um teste. Rodrigo estava nervoso e não queria um grande evento, então marcamos uma conversa informal dentro da Concrete mesmo, com o time de desenvolvimento, apenas para que ele fizesse o que tanto queria: ser ouvido.

No dia do teste, quando Rodrigo chegou, tentamos quebrar o gelo apresentando a equipe mas logo ele puxou o celular e começou a nos mostrar como interagia com o aplicativo. A primeira coisa que reparamos é que a velocidade dele era impressionante. Além disso, ele mantinha a velocidade da voz do TalkBack alta também, que para o restante de nós ficava quase impossível de entender. Foram duas horas mostrando sua navegação cotidiana, apontando erros muito graves na acessibilidade e dando possíveis soluções, desde sugestões de apps que mandavam bem na acessibilidade até formas de tornar a tela mais descritiva para os leitores de tela.

Um dos momentos mais interessantes do teste foi quando Rodrigo navegou pela tela em que aplicamos o “piloto da acessibilidade”. Não contamos para ele que tínhamos implementado este teste ali, apenas observamos. Eu fiquei toda pomposa, achando que seria uma das áreas menos problemáticas, mas acabei quebrando a cara. De fato, as reclamações foram quase nulas, mas teve um problema muito evidente: o texto que preparei para certo componente estava atrapalhando o ritmo da navegação. Estava tudo explicado demais, o que fazia Rodrigo levar mais tempo para chegar nas informações que realmente importavam. Ele ainda nos contou que usava aplicativos piratas para realizar certas tarefas, já que no app oficial era quase impossível.

O teste foi se aproximando do fim, mas ainda parecia que tínhamos muito a aprender. Propusemos, então, manter um canal de contato com Rodrigo. Criamos um grupo no WhatsApp com ele e as pessoas diretamente ligadas à implementação da acessibilidade. Ficou combinado que liberaríamos versões beta para receber críticas e sugestões dele. Ele também nos passava feedbacks de amigos com deficiência visual que jogavam com ele.

Aplicando soluções

Após o teste, entendemos muito melhor como de fato a acessibilidade era “consumida”. Porém, ainda tínhamos um grande desafio: um produto enorme para consertar, o que tornava muito difícil saber por onde começar. Foi neste momento que tomamos algumas decisões:

  1. Definir os critérios de acessibilidade;
  2. Incluir estes critérios na definição de pronto;
  3. Como Android representava 80% da base de usuários, foi o canal que escolhemos atacar primeiro;
  4. As novas features tinham que estar acessíveis desde o início;
  5. Mexer aos poucos no legado para se tornar tudo acessível;
  6. Com os feedbacks de Android, evoluir a acessibilidade para iOS.

Começando por definir critérios de acessibilidade, resolvemos começar tagueando botões e descrevendo os componentes necessários. Esse era o mínimo para cobrir a acessibilidade para falta de visão.

Eu, como designer, tive que acordar com os desenvolvedores um formato de documento para acessibilidade, de forma que eles entendessem o que deveria ser implementado. O documento que fizemos antes do teste, usado para implementar o “piloto de acessibilidade” não estava de todo errado, então reaproveitei boa parte. Ele consiste em dar títulos aos botões, determinar a ordem em que os elementos são lidos na tela e descrever textos para os componentes que precisam. Estes textos são estruturados da seguinte forma:

  1. Textos fixos, que não dependem da API para existir;
  2. Textos variáveis, que mudam de acordo com o que a API entrega.

Tudo que fosse desenvolvido de novo em Android recebia um documento desse tipo, e só era considerado pronto quando tudo especificado no documento estava implementado. Além disso, eram feitos documentos para features antigas, que deveriam ser implementados eventualmente.

Coletando os resultados

Como mantivemos contato com Rodrigo, toda vez que o time desenvolvia algo com acessibilidade inclusa enviávamos uma versão beta e evoluíamos de acordo com os feedbacks que ele dava, para aí sim lançar versões na loja. Rodrigo nos ajudava sinalizando quais eram as partes do aplicativo em que mais tinha problemas e nos ajudava, assim, a entender se nossas soluções estavam fazendo sentido.

Aprendizados

Como a Concrete é uma consultoria, eventualmente acabei trocando de projeto. Mas essa experiência ficou comigo e mudou minha forma de trabalhar, passando a pensar mais no papel do design e da tecnologia na inclusão social.

Comecei a trabalhar em um produto com um público bem diferente do anterior. Entretanto, desde o início, levantei a bandeira da acessibilidade. Mas desta vez, com uma vantagem: o produto estava sendo feito do zero! Esse fato facilitava muito, pois além de não existir preocupação com o legado, já era possível criar critérios de acessibilidade e incluir na definição de pronto.

1. O primeiro passo foi determinar os tipos de acessibilidade que abordaríamos:

  • Falta de visão
  • Visão reduzida
  • Daltonismo (todos os tipos)

2. Decidir ações para atacar cada um dos tipos de acessibilidade escolhidos, por exemplo:

Falta de visão:

Todas as telas desenhadas deveriam ter o mesmo modelo de documento feito no projeto anterior, especificando títulos de botões e textos de componentes a serem interpretados por leitores de tela.

Visão reduzida:
Os sistemas operacionais (android e iOS) escalam suas fontes de forma nativa, permitindo que o usuário escolha qual tamanho quer que as letras apareçam na sua tela. Entretanto, no iOS, se não usarmos a fonte nativa no desenvolvimento do aplicativo, é necessário componentizar as fontes para continuar permitindo essa escalabilidade. Então, no styleguide do projeto, todas as fontes são componentizadas para que os desenvolvedores apliquem de forma correta.

Fontes componentizadas

Daltonismo:
Existem três tipos de Daltonismo: acromático, dicromático e tricomático, dependendo da localização do defeito visual ou de quais as cores que o indivíduo não consegue identificar. Para garantir acessibilidade, neste caso, precisamos nos preocupar com o contraste. Todas as telas desenhadas, todos os estados de erro, absolutamente tudo passa por um filtro que simula esses três tipos de condições, apenas para checar se toda a informação está legível.

3. Baseado nestes três tipos de acessibilidade e nas ações, escrevi junto à equipe um documento com as “diretrizes de acessibilidade” do projeto. Um pequeno conjunto de regras para todo o time conseguir manter o produto inclusivo:

Diretrizes de acessibilidade do produto

Conclusões

Essa foi minha experiência meio conturbada com a acessibilidade, mas que me ensinou muito e ajudou a levar esse conhecimento para outros produtos e passando a pensar em mais formas de torná-los acessíveis. Espero que essa história tenha ajudado vocês a se inspirarem a tornar o mundo um pouquinho mais inclusivo :) Tem alguma dúvida ou algo para colaborar? Aproveite e deixe um comentário.

Quer fazer parte deste tipo de descoberta com algum dos nossos times? Vamos aprender juntos. Acesse aqui e veja nossas vagas abertas.

Até a próxima!

“Obrigado por se importar conosco”
Feedback de Rodrigo

Concrete

Nós desenvolvemos produtos digitais com inovação, agilidade…

Bárbara Schoen

Written by

Carioca, 23 anos e Designer de Produtos Digitais na Concrete :)

Concrete

Concrete

Nós desenvolvemos produtos digitais com inovação, agilidade e excelentes práticas, para que o mercado brasileiro e latino-americano acompanhe a velocidade do mercado digital mundial.

More From Medium

More on Artigos from Concrete

More on Artigos from Concrete

Era uma vez… uma Daily!

Apr 2 · 7 min read

20

More on Artigos from Concrete

More on Artigos from Concrete

Prodcast #6 — Entretenimento

Apr 1 · 1 min read

17

More on Artigos from Concrete

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade