Da documentação à entrega: como integramos acessibilidade no fluxo de trabalho de design e desenvolvimento.
Ao entregar um protótipo para a equipe de desenvolvimento, é provável que você considere boas práticas como incluir regras de negócio e diretrizes de UX.
Mas já parou para pensar em como será a experiência de pessoas com deficiência visual utilizando seu produto? E um usuário com baixa visão, daltonismo ou dislexia por exemplo. Será que eles conseguem ter uma experiência equivalente?
Essas são questões que no primeiro momento, podem parecer complexas ou até assustadoras (eu entendo!). Mas considerar acessibilidade no seu processo de Handoff é uma etapa essencial para a qualidade da entrega.
Isso permite que seu produto alcance um público mais amplo e diverso e, de quebra, você ainda atende requisitos e diretrizes legais.
E quem ganha com isso?
Todos! Considerar acessibilidade no seu projeto permite criar uma experiência mais inclusiva, promove maior autonomia para os usuários, gera aprendizado para as equipes envolvidas, contribui com o cumprimento de normas e diretrizes e ainda fortalece a imagem da empresa, abrindo portas para novos clientes.
Vou compartilhar um pouco de como foi a minha experiência ao construir uma documentação acessível junto a uma equipe.
Motivação
Percebemos que, para garantir a acessibilidade dos produtos, era essencial atuar na raiz do problema. Isso significava revisar os componentes e construir uma base sólida no Design System.
Com isso em mente, iniciamos um benchmarking e logo percebemos o desafio: encontrar referências de handoff de acessibilidade não é tarefa fácil.
A maioria das documentações disponíveis vêm de empresas estrangeiras, o que dificultava a adaptação à nossa realidade.
Foi então que nos deparamos com o artigo Handoff de acessibilidade do Banco Carrefour e a partir de uma conversa com esses colegas de profissão, surgiram insights valiosos para seguirmos com nosso objetivo.
Por quê ter uma documentação de Handoff acessível?
Incluir acessibilidade no Design System permite criar produtos mais inclusivos desde a ideação.
Quando as diretrizes de acessibilidade fazem parte da documentação de Handoff, elas deixam de ser um conceito abstrato e se tornam algo concreto e aplicável, com especificações claras que podem ser seguidas e implementadas de maneira eficiente. Isso não só facilita a implementação, mas também ajuda a evitar falhas que podem comprometer a experiência do usuário.
O handoff serve para transmitir ideias de design, documentar regras de negócio e fornecer orientações sobre como os componentes devem funcionar, tornando o processo mais eficiente e colaborativo.
Nosso ponto de partida
Construir uma documentação de acessibilidade em um cenário onde “tudo é mato” não foi uma tarefa simples. Iniciar essa jornada exigiu um planejamento estruturado, e algumas etapas se mostraram cruciais:
1. Mapeando componentes
O primeiro passo foi mapear os componentes para entender o cenário atual. A partir dessa análise, percebemos fazer mais sentido iniciar a revisão pela biblioteca Mobile, já que nosso Design System era mais robusto nessa plataforma e nos forneceria uma base mais estruturada.
2. Revisão dos fundamentos
Em seguida, partimos para a revisão dos fundamentos dos componentes, começando por aspectos essenciais como contraste e paleta de cores.
Esse alinhamento inicial foi fundamental para garantir que as próximas etapas, incluindo a estruturação dos componentes no desenvolvimento, fossem construídas sobre bases sólidas.
O papel do time nessa jornada
A equipe de Design System teve um papel fundamental nessa jornada. Contamos com o suporte de desenvolvedores Android e iOS para analisar o comportamento dos componentes utilizando tecnologias assistivas, como TalkBack (Android) e VoiceOver (Apple).
Com base nessas análises, realizamos revisões constantes em agendas semanais e trocas assíncronas, permitindo os ajustes necessários no código dos componentes. Assim, buscamos oferecer uma experiência cada vez mais equivalente para usuários de leitores de tela.
À medida que avançávamos nas revisões, iniciamos a construção das Guidelines. Optamos por manter a mesma estrutura já utilizada em nossa biblioteca de design. Criamos diretrizes individuais para cada componente, detalhando aspectos essenciais, como:
- Especificação e comportamento esperado para tecnologias assistivas no mobile;Evidências de comportamento, garantindo conformidade com as melhores práticas;Exemplos da ordem de navegação, facilitando a implementação acessível.
Esse alinhamento garantiu que a documentação não apenas registrasse as melhorias feitas, mas também servisse como referência para futuras evoluções.
Os pilares da documentação
Para a construção das diretrizes, seguimos três pilares essenciais:
- ComunicaçãoComportamento, eConteúdo
Cada um deles teve um papel fundamental para garantir que a documentação fosse clara, aplicável e eficaz.
Comunicação
- Identificamos cada componente na Spec, garantindo especificações individuais detalhadas.Revisamos os componentes considerando suas variantes dentro da biblioteca.Definimos a ação futura do elemento, ou seja, como ele deve se comportar e qual a resposta esperada para o usuário. (Exemplo: um botão deve indicar que abre um modal? Um item expandível deve informar seu estado?)
Comportamento
Mapeamos a ordem de navegação e o agrupamento de informações, utilizando o plugin Accessibility Assistant para validar essa estrutura nos protótipos. Isso reforçou a coerência entre o que foi documentado na biblioteca e sua aplicação real nas jornadas dos usuários.
Conteúdo
- Títulos: Garantimos que a semântica dos títulos estivesse bem definida, permitindo uma navegação fluida para usuários de leitores de tela.Rótulos descritivos: Estruturamos a identificação dos rótulos diretamente nas especificações para que os desenvolvedores soubessem exatamente o que cada componente deveria vocalizar para o usuário.
- Imagens e iconografias: Aplicamos um componente específico para identificar imagens e ícones decorativos, garantindo que apenas elementos relevantes fossem interpretados pelos leitores de tela.
Casos de uso e Testes
Gherkin: Com o apoio do time de QA, documentamos os casos de uso dos componentes para auxiliar não apenas os desenvolvedores, mas também a equipe responsável por testar os protótipos.
O Analista de Qualidade (QA) garante que o produto ou serviço seja entregue com qualidade, atendendo aos requisitos e proporcionando uma boa experiência ao usuário. Esse profissional atua desde o planejamento até a execução dos testes, identificando falhas e propondo melhorias.
Evidências: Disponibilizamos vídeos demonstrativos para iOS e Android, mostrando o comportamento esperado dos componentes. Isso facilitou a compreensão das equipes que consumiriam esse conteúdo.
Documentação pronta, e agora?
Nossa preocupação era garantir que o acesso às informações fosse prático para quem mais iria utilizá-las: Desenvolvedores, Designers e QA.
Para isso, criamos um guia rápido utilizando a ferramenta Loop onde reunimos os principais pontos aplicados no protótipo, incluindo objetivos, exemplos de especificações, ordem de navegação e diretrizes.
A ideia é oferecer um ponto de partida com instruções claras e diretas sobre as especificações, enquanto os detalhes completos das diretrizes dos componentes permanecem disponíveis para consulta sempre que necessário.
Acessibilidade: Um processo contínuo
Sabemos que ainda temos muito trabalho pela frente, integrar a acessibilidade ao processo não é papel apenas do time de acessibilidade. Esse é um compromisso que deve ser compartilhado por todos os envolvidos no desenvolvimento do produto.
A documentação é apenas o primeiro passo de muitos avanços possíveis. Seja qual for o sistema ou a plataforma, o objetivo é garantir que os produtos não apenas atendam às necessidades de acessibilidade, mas também promovam a inclusão de forma ampla, proporcionando uma experiência equivalente a todos os usuários, independentemente de suas habilidades ou do contexto em que utilizam o produto.
Para encerrar…
Não poderia concluir este artigo sem mencionar as pessoas que ajudaram a tornar este projeto uma realidade.
Agradeço pelo bench realizado com a Ana Cuentro e o Maurício Sá, cujas trocas foram fundamentais para o aprimoramento do processo.
Também os colegas que atuaram no time de design system (Vitor Santos, Paulo Sabaini, Jackeline Lima, Juliana Krupahtz e Gabriel Arruda), cuja contribuição foi essencial para o sucesso das revisões de componentes.
O apoio do gestor Henrique Bustamante, que incentivou e apoiou o processo, e Luciana Oliveira, minha dupla no time que atuou nessa jornada.
Referências e links úteis
- Artigo Banco Carrefour: Handoff de acessibilidadePlugin Accessibility Assistant — MicrosoftFerramenta de edição Microsoft LoopConsulta Critério WCAG: 1.1.1 Conteúdo não textualManual de introdução ao VoiceOver (Apple)Manual de introdução TalkBack (Android)
Construção de Handoff acessível para jornadas mobile was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.
