Imagino que vocês devem estar pensando: “de novo esse assunto?” E a resposta é simples: claro! Como tivemos muitas mudanças em nossa especificação, nada melhor do que trazer uma atualização. E essas evoluções vão continuar acontecendo, já que ela é uma documentação viva que vai se ajustando de acordo com as experiências das pessoas designers do Banco Carrefour.

Só para ressaltar um pouco sobre a especificação de acessibilidade: ela é uma etapa obrigatória para todas as pessoas designers. O seu objetivo é detalhar pontos da experiência no código, seja a ordem de leitura, agrupamento de informações, leitura ou não das imagens e ícones, gestos, rótulos acessíveis, entre outras informações que possam aprimorar a experiência de quem está navegando pelo código, ou seja, via leitor de telas.

No ano passado, divulgamos aqui no nosso Medium um artigo bem legal sobre a primeira versão da nossa Especificação de Acessibilidade.

Por que devemos fazer a especificação?

Em uma auditoria de estudo de caso realizada pelo Deque, eles descobriram que 67% dos problemas de acessibilidade estavam relacionados ao design. É muito importante o uso da especificação nos seus produtos e serviços, do começo até o final. Nós não podemos deixar apenas para o final do desenvolvimento. Quanto mais cedo analisarmos o nosso trabalho para ser acessível, mais beneficiadas as pessoas usuárias serão e, ao mesmo tempo, economizamos tempo e dinheiro. Se deixar um problema de acessibilidade para etapa de desenvolvimento ou de teste, isso vai levar mais tempo para ser corrigido e gastaremos mais dinheiro. Além de ainda poder atrasar as suas entregas.

Um breve histórico

Alguns meses depois que lançamos o primeiro artigo, aconteceu a contratação de duas pessoas especialistas em Acessibilidade para o time de Design Ops aqui do Banco. O objetivo era de avançar ainda mais no aculturamento e evolução dos processos de desenvolvimento de produtos digitais. Com isso, tivemos também aumento na diversidade do nosso time.

É agora o momento que eu me apresento. Eu sou uma pessoa com deficiência auditiva e atuo como designer de experiência com foco em Acessibilidade. E, aqui em Ops também sou par visual do Mauricio Sa, uma pessoa com deficiência visual que atua como Analista de Qualidade.

Mas, afinal, o que mudou na nossa especificação?

Como era necessário escalar a especificação de uma maneira mais prática e fácil, precisávamos criar uma biblioteca própria. Nela, conseguimos ter uma centralização de conteúdos, exemplos, checklist, boas práticas e componentes da especificação.

Só que, antes de começar esse trabalho, eu tive um papo com a Edilene Mendes, o ponto focal da nossa Guilda de Acessibilidade, para captar quais eram as necessidades e dores. Nessa conversa, chegamos a uma lista de dores:

• Trabalho repetitivo de ter que copiar e colar as especificações, inclusive dos componentes que já estavam acessíveis.
• Dificuldade na leitura da especificação pela quantidade de texto
• Especificação voltada para web enquanto estávamos indo para o nativo
• Dificuldade de designers em entender como faz e dos devs em ler e aplicar.
• Pessoas Analistas de Qualidade também não entendiam e não sabiam como cobrar.

E mais uma lista que precisávamos aprimorar a especificação:

• Revisão dos componentes existentes (a parte descritiva): a ideia era deixar a especificação o mais enxuta possível e não ser repetitiva.
• Adição do fundo cinza para o componente de “Ignorar elemento” (indicar que a imagem ou ícone é decorativo): apenas o ícone de “Ignorar elemento” (que é um olho cortado) não era suficiente e passava despercebido.
• Adição de tipo de elemento: já que temos apenas o texto descrito.
• Não especificar o conteúdo apenas textual, pois não tem tipo, nem status do elemento: assim não precisaria ter muitas especificações numa mesma tela.
• Adição de componente “Título”: assim poderíamos diminuir o número de especificações ao lado da tela, já que não tem necessidade de falar nível, pois não existe a hierarquia no nativo, diferente da web.

Só que ainda faltava arrumar um jeito de automatizar a ordem de navegação. Antes ela era colocada de uma forma manual, o que deixava esse processo muito trabalhoso para telas bem longas. A pessoa tinha que marcar cada componente com linhas tracejadas e ainda colocar enumerações em cada elemento. Se tivesse um erro na ordem, ela precisava renomear cada número, era um trabalho bem cansativo.

Foi então que pesquisamos alguns plugins na comunidade do Figma e achamos um que tem ajudado bastante — embora seja um pouco demorado. Ele se chama A11y Focus Order. É bem legal que ele permite o ajuste da ordem de navegação direto ali na interface do plugin só arrastando para cima ou para baixo. Ele também gera um relatório, que no nosso caso não é necessário, então a gente apenas oculta para guardar os dados para quando precisar reajustar.

Indo além

Como eu trabalho no time de Design Ops e com o Design System, pensei: “por que não componetizar a especificação, de uma maneira mais completa?”

Assim a pessoa designer não precisaria pensar e descrever em cada componente, porque já estaria pronto ali para ser selecionado de acordo com o tipo, o status do elemento e instrução para ação futura. Aqui na imagem embaixo mostra que tem algumas palavras na cor rosa, significa que é possível editar o texto.

Eu comecei a colocar todas as informações que o leitor de tela anunciava em cada componente do nosso Design System em duas categorias Android e iOS, pois existem algumas diferenças em alguns componentes. Por exemplo, sabe o input text? Então no Android, o Talkback verbaliza como “Caixa de edição”, enquanto no iOS, é “Campo de texto”. Outro exemplo mais marcante é o do Radio button:

• No Android fica assim: Selecionado (estado), Rótulo (texto), botão de opção (tipo).
• No iOS fica dessa forma: Rótulo (texto), marcado (estado), botão (tipo).

Isso acontece porque não existe uma semântica do botão de opção no iOS como tem para Android.

Componetizei de acordo com o tipo de componente, o estado se está habilitado ou desabilitado, os sistemas Android e iOS, o tipo do elemento que varia de cada componente (por exemplo, o Checkbox tem Selecionado/Não selecionado e o Accordion tem Expandido/Recolhido), Instrução de ação futura, se tem Badge, se tem quantidade de itens.

Uma ajudinha a mais para pessoas designers e desenvolvedoras

Essas divergências podem assustar as pessoas designers e até QAs que não têm familiaridade com tecnologias assistivas, no caso, leitores de tela. Então, pensamos que essa “colinha” poderia ajudar na hora de especificar e de testar.

Depois que finalizei a parte mais técnica pensei: “é… talvez essa biblioteca possa assustar as pessoas com a quantidade de coisa para ler, para aplicar nos seus designs. Pode ser muita coisa!”

Foi então que criamos um checklist de especificação para saber exatamente o que queremos especificar e revisar. E nele utilizei um plugin para deixar mais dinâmico para a pessoa dar um check em qualquer momento.

Cada item do checklist foi pensado junto com o nível de conformidade de acessibilidade — aqui usamos os níveis A e AA como referência para a nossa especificação.

Ainda assim, estava muito simples e faltava explicar melhor cada etapa. Para ajudar nisso, fizemos duas versões de checklist: uma fica no Figma e temos outra mais completa no Notion para quem quiser ler. Nela, detalhamos como se faz em cada etapa, trouxemos um pedaço da tela como exemplo com um componente da especificação e ainda complementamos com um vídeo-tutorial de como aplicar.

Além dos componentes da especificação, temos a parte de código que vai ajudar o time de desenvolvimento a codificar de forma mais acessível. Mas, percebemos que isso só estava presente no Notion. Essa necessidade surgiu quando o Maurício fez testes de acessibilidade e comentou que os problemas de acessibilidade já estavam especificados nos fluxos, mas talvez as pessoas desenvolvedoras não soubessem como.

Então tivemos um papo com o nosso time de desenvolvimento de Design Ops que já tem uma experiência por conta do nosso Design System acessível. Depois disso, criamos uma categoria no Figma que é apenas puxar esses detalhes de código no Figma para facilitar a leitura.

E agora apresento para vocês um comparativo da versão antiga e da nova. Vocês podem perceber que a leitura ficou mais simples e fácil.

Sala de Acessibilidade

Aqui no Banco Carrefour temos uma regra de suporte já estabelecida: o time de Design Ops é responsável pelo desenvolvimento dos componentes e o time de produto é responsável pelo desenvolvimento do fluxo — desenvolvendo conforme a especificação e também testando pra ver se está de acordo com o especificado e acessível.

Os componentes podem ser acessíveis, mas aqueles que são mais complexos podem precisar de mais atenção, já que são mais exclusivos para cenários mais específicos.

Por exemplo, temos o card que é capaz de receber vários componentes. E então surgiu uma necessidade de dar uma consultoria para o time que criou esse card. Mesmo sendo acessível, o leitor de tela estava anunciando cada elemento: você precisaria dar swipe (gesto de deslizar), ou seja, era necessário dar swipe 4 vezes para ler o conteúdo todo dentro de um card. O que não é uma experiência agradável.

Eu e Maurício ficamos discutindo até chegar a esse card acessível com apenas 2 swipes, que tem um título e um botão, já que ele é todo clicável para pessoas videntes. Ainda não está perfeito, porque tem muito conteúdo agrupado, mas foi a solução mais adequada que conseguimos pensar.

É por este motivo que destaco aqui a importância da revisão da especificação com as pessoas especialistas em Acessibilidade. Aproveitamos essas situações para explicar de uma forma mais educativa para que as pessoas designers e desenvolvedoras compreendam e também possam criar os componentes com uma mentalidade acessível desde o início. Assim como também para as pessoas QA usem tecnologias assistivas, como leitores de tela, em seu dia a dia, realizar testes que ultrapassem as simples boas práticas e proporcionem uma boa experiência.

E, por estarmos recebendo uma grande quantidade de demandas e fazendo diversos atendimentos individuais, percebemos a necessidade de ter um espaço, além da Guilda de Acessibilidade. Então criamos a Sala de Acessibilidade onde eu e Maurício juntos disponibilizamos um tempo de consultoria numa sala online (no caso, o Meet) uma vez por semana durante uma hora. Já conseguimos revisar alguns fluxos, tirar dúvidas, testar telas, fazer consultorias, tudo voltado para acessibilidade, como diz o nome.

Para fechar…

Foram muitos avanços na especificação que conseguimos muitos elogios e como tem ajudado muito, mas ainda falta muita coisa para evoluir. Desde então muitos times têm especificado seus fluxos e tirado dúvidas. Cada time tem colocado uma página específica para acessibilidade, o que melhora a sua visibilidade.

Estamos disponibilizando a biblioteca da Especificação de Acessibilidade na comunidade de Figma para que vocês possam usar. 🎁

Além da especificação, temos a documentação e o handoff de acessibilidade no Figma e no Zeroheight. Mas esse vai ser um papo para uma segunda parte.

E, se você quiser saber mais sobre o trabalho de acessibilidade que a gente tem feito por aqui, o Paulo Aguilera Filho escreveu um artigo só sobre isso!