Testes de acessibilidade: o padrão de qualidade no Annecy Design System
Aqui no Banco Carrefour a acessibilidade é um dos pilares do time de Design Ops. No processo de criação do nosso Design System para iOS e Android, uma equipe multidisciplinar composta por Designers, QA, pessoas desenvolvedoras, de conteúdo e de pesquisa, estão atuando para garantir que os componentes estejam em conformidade com as Diretrizes de Acessibilidade de Conteúdo da Web (WCAG) e também que o fluxo entregue a melhor experiência de usabilidade para todas as pessoas.
Para garantir isso, fazemos testes de acessibilidade em todas as etapas do nosso processo do Design System. Neles, validamos aspectos visuais, interação, conteúdo e código, porque temos a responsabilidade de criar documentações e bibliotecas de componentes para toda a empresa — e isso significa que a qualidade é essencial e não deve ser negociável.
Neste artigo, vamos compartilhar um pouco mais sobre nossa experiência na implementação de um processo de testes de acessibilidade no Banco Carrefour, com ênfase no produto Design System. Falaremos sobre as etapas essenciais envolvidas na avaliação de acessibilidade e os diferentes tipos de técnicas e metodologias que estamos aplicando em nossos testes.
Garantindo os testes de acessibilidade no ciclo de desenvolvimento
Planejamento e Design
Muitas vezes, os testes de acessibilidade são deixados para o final do projeto, o que pode gerar custos e trazer um grande esforço de desenvolvimento e retrabalho. É fundamental priorizar esses testes desde as primeiras etapas, como no design e na criação, para evitar problemas que só são identificados mais tarde nos testes e que nem sempre vamos conseguir oferecer a melhor solução.
Em paralelo aos testes, uma das etapas fundamentais é assegurar a conformidade com os requisitos de acessibilidade já no estágio inicial de planejamento e design, por meio da criação de uma especificação de acessibilidade, para orientar as pessoas desenvolvedoras e profissionais de garantia da qualidade (QAs).
Cada componente do nosso Design System possui uma especificação de acessibilidade, que chamamos de ‘handoff’. Essa especificação abrange itens da experiência no código, como 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 tela.
A Ana Cuentro, nossa designer de experiência com foco em Acessibilidade, publicou um artigo muito completo, em que ela detalha todo o funcionamento e criação do nossa especificação de acessibilidade.
Vou aproveitar para me apresentar. Sou Maurício Sá, uma pessoa cega e atuo como Analista de Qualidade com foco em acessibilidade. Junto com a Ana Cuentro, somos as pessoas especialistas em acessibilidade no time de Design Ops.
Gosto muito de destacar que aqui no Banco Carrefour, além de garantir que nossas aplicações e serviços sejam acessíveis a todas as pessoas clientes, também nos preocupamos em oferecer um processo de trabalho inclusivo. Consigo também apoiar na criação do handoff de acessibilidade, usando uma abordagem no Figma, onde transformamos a documentação do handoff em um protótipo acessível. Dessa forma, contribuo na concepção dos critérios de acessibilidade com a pessoa Designer desde a etapa do planejamento dos componentes, levando em consideração todas as diretrizes de acessibilidade e comportamentos específicos da tecnologia nativa de acordo com sua plataforma.
Fase de planejamento dos testes de acessibilidade
Durante essa fase, os casos de teste são elaborados com base nos requisitos de acessibilidade. Isso visa garantir que todas as pessoas compreendam o que foi testado e quais comportamentos são esperados para cada componente. Todos os casos de teste são registrados em nossa plataforma de gestão de tarefas.
Entendendo o escopo dos testes de acessibilidade
Em nossa plataforma de gestão de testes, tanto para Android quanto para iOS, instituímos o conceito de um “Ciclo” como um épico de testes. Dentro deste ciclo, são criadas as suítes de testes específicas para cada componente, onde são organizados todos os casos de teste. Essa abordagem visa fornecer uma cobertura completa, garantindo a conformidade dos componentes com os requisitos estabelecidos na etapa da especificação de acessibilidade.
Para a escrita desses casos de teste, usamos a metodologia BDD, por meio da linguagem natural Gherkin. E ela é composta por três elementos:
- Dado: esta é a nossa pré-condição, o estado inicial necessário para a execução do teste.
- Quando: esta etapa descreve a ação que está sendo realizada. É a parte do teste em que interagimos com o componente.
- Então: aqui está o resultado esperado, a validação que estamos buscando após a ação. É a verificação do comportamento do componente em relação aos critérios de acessibilidade.
Vamos aos exemplos práticos?
Vamos usar como exemplo um componente do DS, o “Notification”, onde incorporamos diversos critérios de acessibilidade segundo a WCAG. A seguir, mostro como fica a escrita de testes dele.
Título: [Acessibilidade] Componente Notification — Rótulo acessível para os ícones de notificação
- Dado que estou navegando no componente Notification
- Quando as notificações de “Sucesso”, “Aviso”, “Erro” e “informação” são exibidas
- Então cada ícone deve possuir um rótulo acessível e o leitor de tela deve anunciar o tipo da notificação, juntamente com a mensagem.
Título: [Acessibilidade] Componente Notification — Feedback em mensagens de erro, definir accessibilityLiveRegion assertive
- Dado que estou navegando no componente Notification
- Quando executo a função que aciona a notificação de erro
- Então ao ser exibida uma notificação de erro, a mensagem deve ser lida automaticamente pelas Tecnologias Assistivas, notificando imediatamente o usuário.
Título: [Acessibilidade] Componente Notification — Ordem de navegação entre os elementos
- Dado que estou navegando no componente Notification
- Quando utilizo um leitor de tela e realizo o gesto de deslizar com um dedo para a direita/esquerda
- Então a ordem dos elementos deve ser lógica e sequencial, em conformidade com a experiência visual proposta, da esquerda para a direita e de cima para baixo.
Para exemplificar trouxemos somente alguns dos casos de testes presentes na suíte de testes do componente. Mas, observe que neles, estamos garantindo vários critérios de acessibilidade da WCAG, como:
- 1.1.1 — Conteúdo não textual. Os ícones estão fornecendo informações visuais, mas também estão associados a rótulos acessíveis, permitindo que usuários de tecnologias assistivas compreendam a função de cada ícone.
- 4.1.3 — Mensagens de status. Ao definir `accessibilityLiveRegion` com o valor `assertive`, a notificação de erro é automaticamente anunciada por tecnologias assistivas, fornecendo feedback imediato, sem que ocorra mudança de contexto.
- 2.4.3 — Ordem do foco. A ordem lógica e sequencial dos elementos, conforme descrita no caso de teste, garante uma navegação lógica e previsível para usuários que fazem a interação via teclado ou de tecnologias assistivas.
Execução dos testes
Nesta etapa, concentramos todos os esforços na realização dos testes manuais, pois esta é a maneira mais garantida de identificar todos os problemas. Dessa forma, asseguramos a experiência real das pessoas usuárias ao executar os testes com leitores de tela nos dispositivos físicos. Em alguns casos também conseguimos realizar alguns testes utilizando emuladores, no entanto, é importante mencionar que temos algumas ressalvas e já enfrentamos alguns problemas relacionados a isso.
Após o desenvolvimento e teste de todas as implementações, garantindo a conformidade com os critérios estabelecidos, marcamos os status dos casos de teste como “Concluído” e incluímos evidências em formato de vídeo para cada teste. Isso tem o objetivo de demonstrar que o componente recebeu a cobertura de testes necessária.
Para a execução dos testes, temos um grande diferencial, que é ter um aplicativo de exemplo do Annecy DS Android e iOS. Nele, é possível testar e explorar todos os comportamentos desenvolvidos para os componentes.
Testes e desenvolvimento em par
Para que os componentes sejam realmente desenvolvidos trazendo uma experiência de navegação acessível a todas as pessoas, os profissionais envolvidos estão sempre em diálogo constante, compartilhando as melhores práticas de código acessível, colaborando na revisão de documentações e testes.
Aqui gostaria de ressaltar uma questão que penso que foi fundamental, uma experiência valiosa e um grande diferencial para os importantes resultados que temos evoluído com o tema acessibilidade. Trabalho em estreita colaboração com QAs, pessoas desenvolvedoras e Designers.
Quando o componente entra na fase de desenvolvimento, sempre realizo um trabalho em conjunto com o time de Desenvolvimento. Neste momento, avaliamos juntos o que foi desenvolvido, conforme o handoff e os casos de teste. Estes momentos são muito ricos, pois é quando podemos até mesmo pensar em melhorias no código e novos comportamentos de acessibilidade que talvez não tenham sido previstos na etapa de planejamento.
Outro aspecto importante desta parceria é o aculturamento. Com todas as trocas e colaborações no dia a dia, estamos conseguindo promover um entendimento sobre o tema com as pessoas desenvolvedoras. É muito gratificante observar a evolução delas neste contexto, tornando-se hoje referências em acessibilidade aqui no Banco.
Na execução dos testes dos componentes, conto muito com a parceria de duas pessoas. A Ana Cuentro realiza testes visuais, principalmente para garantir aspectos como área de toque, contraste, fontes e responsividade. Além disso, ela costuma ser meu par visual nos testes de acessibilidade, auxiliando na interpretação dos comportamentos especificados no handoff de acessibilidade, entregue pelos outros times, principalmente porque ainda não é possível usar o Figma plenamente com acessibilidade em todas as funcionalidades.
Minha outra parceira é a Paula Santiago. Ela é responsável pelos testes funcionais e também vem realizando testes de acessibilidade. É muito gratificante perceber toda a evolução que ela vem alcançando com o tema.
Agradeço imensamente a essas pessoas e a muitas outras envolvidas nesse processo. Com certeza, estamos obtendo ótimos resultados graças a essa parceria incrível que temos no time!
Testes regressivos
Para os testes regressivos, especialmente em componentes e fluxos que apresentaram problemas de acessibilidade, desenvolvemos um modelo de relatório destinado a orientar o time de desenvolvimento na resolução dessas questões. Esse modelo inclui um título explicativo, uma descrição detalhada que fornece embasamentos para compreender o problema, os passos para reprodução, o comportamento esperado e uma avaliação do nível de criticidade, visando priorizar e classificar as correções.
Essa etapa ocorre principalmente durante as releases de liberação de versões dos nossos aplicativos, no processo de migração para a tecnologia nativa.
Novamente, é importante ressaltar o quanto a parceria com todas as pessoas envolvidas dos outros times tem sido de grande importância para alcançar os melhores resultados e promover cada vez mais a disseminação da cultura de acessibilidade.
Também atendemos solicitações por meio do nosso formulário de suporte. Nele, os times podem solicitar uma avaliação de testes de acessibilidade para seus fluxos e, com o apoio da pessoa P.O, conseguimos fazer a priorização.
Treinamento e aculturamento
Além de garantir a acessibilidade dos nossos produtos, através da biblioteca de componentes, estamos prevendo diversas ações que façam que a acessibilidade seja desenvolvida e validada por todos os times de produto, de maneira contínua. Para isso entendemos a importância de promover treinamentos, palestras e materiais educativos sobre o tema, que contribuam no aculturamento dos times, além de materiais que facilitem a verificação das boas práticas, como um checklist para Designers, testes e guias de boas práticas para conteúdo.
Algumas iniciativas que estamos promovendo
Escalando os testes de acessibilidade
Ainda é um grande desafio, mas estamos procurando escalar cada vez mais os testes de acessibilidade aqui no Banco. Entendemos que as pessoas QA (Quality Assurance) são estratégicas e têm um papel fundamental para garantir que os aplicativos sejam acessíveis para todas as pessoas.
Acompanhamento de QAs
Sempre que participo dos testes de acessibilidade solicitados pelos times, envolvo QAs do projeto e faço um acompanhamento. Nesse momento, realizamos uma espécie de treinamento sobre o uso de leitores de tela e boas práticas de acessibilidade, além de eu servir como ponto focal para esclarecer diversas dúvidas.
É uma imensa satisfação perceber o quanto isso já está gerando resultados, vendo algumas pessoas QAs já compreendendo e reportando problemas de acessibilidade com autonomia.
Receber feedbacks delas, dizendo o quanto o meu trabalho tem sido importante para suas carreiras, que mudei a forma de pensar e que agora estão considerando a acessibilidade, é algo que não tem preço. Isso me motiva a continuar cada vez mais forte nesse trabalho de acessibilidade.
Treinamento sobre Acessibilidade para QAs
Neste treinamento o foco foi explicar a importância do tema e como as pessoas analistas de qualidade são estratégicas para a implementação da acessibilidade. São elas que irão realizar testes via leitor de telas, navegação somente via teclado, entre outros testes, além de conseguir analisar a especificação de acessibilidade dos Designers e comparar com o código desenvolvido, apontando eventuais inconformidades para correção antes do lançamento oficial. O treinamento foi aplicado para todas as pessoas do Centro de Excelência de Qualidade, com teoria e prática.
Conclusão
Entendemos que ter um Design System acessível vai facilitar muito a entrega de um produto final padronizado e com acessibilidade, evitando um grande esforço de desenvolvimento e retrabalho.
Com todo esse trabalho que estamos fazendo já conseguimos garantir:
- Semântica no código: transmitir corretamente para as tecnologias o propósito do elemento, informando estado, nome e valor do componente.
- Descrição de ícones: já estamos trazendo muitas opções com um rótulo acessível que descreva sua funcionalidade, como os tipos de notificações e também em alguns botões com ícones.
- Mensagens de feedback em notificações: quando exibido uma notificação, o conteúdo é anunciado automaticamente pelas Tecnologias Assistivas, sem que a pessoa precise explorar o seu conteúdo na tela.
- Ordem de foco: todos os componentes seguem uma ordem de foco que faça sentido para a navegação, de acordo com o que é exibido visualmente.
- Outros requisitos: área de toque, contraste mínimo, fontes e responsividade também estão sendo contemplados.
Porém, é importante lembrar que o Design System, por si só, não garante a acessibilidade do projeto ou fluxo que esteja utilizando ele. Ainda há o trabalho do time de produto de testar com pessoas diversas, ler a especificação, desenvolver aplicando as boas práticas, testar utilizando o leitor de tela para daí sim realizar a entrega com qualidade e, consequentemente, mais acessível.
E como sempre falamos aqui:
Acessibilidade é sobre pessoas, que possuem características, vivências e necessidades diferentes. ✨
