Eu estava em um evento remoto na área de produto e assim que começou a primeira palestra tive uma surpresa, a plataforma desenvolvida para o evento fornecia recursos de acessibilidade para pessoas com deficiências visuais e auditivas.
“Ok, então qual foi o problema?”
O problema é que isso não deveria ter sido uma surpresa. Segundo o Censo demográfico do IBGE de 2010, há por volta de 45 milhões de pessoas que apresentam pelo menos uma deficiência no Brasil (Auditiva, Visual, Motora ou Cognitiva), o que representa 23,9% da população brasileira e 1.85 bilhões no mundo, ou seja, se o seu produto não trabalha questões de acessibilidade você está deixando de fora da sua base por volta de 3,4 bilhões de potenciais usuários (incluindo familiares e amigos próximos à pessoa com deficiência) e perdendo por volta de $17,1 bilhões a partir da desistência das pessoas por falta de acessibilidade.
E não pense que acessibilidade é uma questão que se detém apenas suporte a pessoas com algum tipo de deficiência, segundo Torres: acessibilidade digital consiste em tornar disponível todas as informações, de maneira autônoma, ao usuário da forma que lhe for acessível e sem comprometer o seu entendimento do conteúdo, ou seja, os 28 milhões de idosas e 11 milhões de analfabetos no Brasil também compõe esse grupo.
Antes que você se pergunte se tantos produtos assim não têm acessibilidade, eu adianto que sim, pegando uma métrica que cobre apenas sites, sem contemplar apps e sistemas, apenas 21 milhões, ou seja 0,46% dos sites ativos são, de fato, acessíveis. O que fere diretamente a Lei Brasileira de Inclusão (LBI - 13146) que procura garantir a obrigatoriedade de acessibilidade nos sites da internet mantidos por empresas com presença no Brasil, além de órgãos governamentais.
“Tá, mas o meu produto já tem todos os recursos de acessibilidade!”
O olhar sobre a acessibilidade implementada no produto deve ser constante. Tenha em mente que o seu produto é mutável e após construído irá passar por evoluções ao longo do tempo, tanto por implementação de novas feature quanto por necessidade de correção de bugs.
A arquitetura deve ser concebida para comportar essas futuras atualizações e constantemente revisada após novas implementadas, para medir o impacto sobre.
Um exemplo dos produtos que trabalhei: a parte de acessibilidade por meio do teclado ao menu não tinha sido construída com as melhores práticas da web, logo não tinha suporte para comportar evoluções no produto sem prejudicar essa área. Quando estávamos realizando uma manutenção foi percebido que não estava mais com o funcionamento adequado - originalmente o produto tinha passado por várias mudanças tanto de layout quanto de adição de conteúdo naquela parte - ao acessar pelo teclado usando a tecla “Tab” a estrutura não permitia descer para os subitens do dropdown de menu e saltava direto para opções alternadas, se tornando praticamente inutilizável para pessoas que usam tecnologias assistivas ou que dependem de navegação por teclado. Foi uma parte que o HTML precisou ser reformulado e os estilos (CSS) existentes adaptados ao novo cenário do produto.
Em alguns casos, identificar entre os colaboradores a ideia de que acessibilidade não é um trabalho contínuo, pode significar um reflexo cultural da empresa.
De um jeito simples, quando a acessibilidade não é um item cultural acontece o seguinte: [7]
- Os requisitos não contemplam a acessibilidade ou preveem testes apenas no final do ciclo de desenvolvimento;
- Os designers não se preocupam com cores, fontes e animações acessíveis;
- Os desenvolvedores codificam de acordo com suas práticas habituais;
- A equipe de testes não faz testes de acessibilidade;
- O marketing usa cores com baixo contraste e não descreve as imagens no sítio ou nas redes sociais;
- A equipe de conteúdo não utiliza legendas, audiodescrição e transcrições de vídeos.
Quando a acessibilidade faz parte da cultura, o cenário pode mudar: [7]
- Os requisitos contemplam pessoas com deficiência, prevendo necessidades legais, padrões e testes ao longo de todo o ciclo de desenvolvimento;
- Os designers baseiam-se nos requisitos para projetar a solução e seguem boas práticas de desenho acessível;
- O desenvolvimento é baseado nos requisitos e nas documentações de desenho de componentes acessíveis;
- Os requisitos de acessibilidade tornam-se critérios de aceitação nos testes manuais e automáticos;
- O marketing, o design e o conteúdo estão alinhados no uso de cores, fontes e elementos gráficos acessíveis. Além disso, as imagens são descritas e os vídeos possuem legenda, transcrição e audiodescrição.
Fica difícil, no dia a dia, pensar nessas questões quando não se sente a dor deste tipo de usuário, quando não tem pessoas nos times ou na empresa que se sensibilizam com o tema ou que possuem algum tipo de deficiência. Eu, por exemplo, tenho astigmatismo então me preocupo naturalmente por questões assim pois me impactam diretamente, daí percebemos a importância de ter um ambiente com diversidade, porque um ambiente onde eu tenho colaboradores que representam diferentes públicos, o meu produto acaba sendo impactado.
Mas isso também pode ser feito por meio de um exercício de empatia, que é inclusive um dos pilares do Design Thinking: o olhar a um problema através do ponto de vista de quem o vivencia. Por exemplo, estava trabalhando com o desenvolvimento de um site que atenderia pessoas idosas, então desde a etapa de design, foi tida uma preocupação na construção do layout para o público, inserindo menos animações e aumentando o tamanho da fonte.
Neste contexto, não poderíamos ter uma aplicação muito pesada, pois o aparelho usado poderia não ter muito suporte, o pacote de telefonia móvel por vezes é de poucos megas que atendem apenas uso de Whatsapp; os fluxos de usabilidade tinham que ser o mais simples possíveis para que não ocorresse uma desistência por parte do usuário por achar muito complicado.
Em resumo, é importante pensar se o seu produto digital é ou não inclusivo de fato e, a partir disso, realizar ações que abarquem a parcela do público que pode estar ficando de fora do que você oferta no meio digital. Caso você não conheça muito sobre ou não saiba por onde começar para implementar no seu produto, consulte o WCAG (Guia de acessibilidade Web e mobile), eMAG (Modelo de acessibilidade em governo eletrônico) ou a cartilha da W3C Brasil.
Faz sentido pra você? Que tal deixar a sua opinião?
