Em 2020 eu assumi um desafio de implementar acessibilidade em uma das maiores instituições financeiras do Brasil. Assim como em muitas outras companhias de grande porte, escalar soluções e mudanças de processos é um misto entre negociar custos, otimizar tempo e inspirar pessoas. Agora, como defender uma iniciativa tão humana, falando de resultados sem números? Mesmo que seja possível, não soa como algo correto. A necessidade de implementar acessibilidade deve ser um fato, e os números, bem, os números podem ser voltados a como conseguimos fazer isso da forma mais eficiente possível. Com este objetivo, consegui mesclar dois assuntos que guiam minha carreira há um tempo e que eu gosto tanto: acessibilidade e otimização de processos!
Após uma jornada de mais de um ano, é possível compartilhar várias das estratégias que guiaram esse time, algumas que resultaram em sucesso, outras em dor de cabeça, mas todas resultaram em muito aprendizado. Para 2022, gostaria de descrever o que acredito que mais gera resultado de longo prazo e que, pelo seu escopo, possibilita colocar o time de design na liderança, sem a necessidade de negociações com outras especialidades que ainda estão aprendendo como acessibilidade é essencial para a inovação e o desenvolvimento de uma empresa. Neste artigo, quero dar dicas práticas de como você e sua empresa podem fazer isso no próximo ano e embarcar nesse universo (ainda pouco explorado no Brasil) do que é ser uma empresa digital acessível. Sendo assim, vamos falar um pouco sobre como criar ou tornar um design system acessível!
A primeira coisa para se criar um design system acessível é, infelizmente, entender que o impacto dessa ferramenta na solução final do seu produto possui limites (que cobrirei em detalhes mais adiante). Neste caso, é essencial ter estratégias em paralelo para ensinar o time sobre acessibilidade, como implementá-la e, é claro, ter iniciativas de diversidade e inclusão de pessoas com deficiência em todas as áreas da empresa. Agora, se esta barreira te faz repensar se realmente tem sentido tornar o seu design system acessível, leve em consideração a seguinte afirmação de uma das maiores referências no assunto:
"Mas eu posso te dizer uma coisa que eu sei com certeza: Se o design system não é acessível, não existe a possibilidade do produto final ser acessível"
(Sheri Byrne-Haber)
Com isto em mente, posso listar os pontos que seu design system provavelmente não vai resolver:
Além disso, incluímos a estratégia, a forma como o conteúdo chega do backend ao frontend (ex: se o dado não é tratado e chega todo em letra maiúscula, ele dificilmente será acessível), o fluxo e conceito da experiência, o conteúdo e, é claro, a escolha de elementos do próprio design system que irão integrá-la. Resumindo, nem um design system nem acessibilidade salvam um conceito e experiências com problemas de usabilidade, apesar de serem parte fundamental deste alicerce e seu time deve estar preparado e bem treinado para isso. Para tal, o time de Ops, responsável pelo design system, tem como missão não só criar a ferramenta, mas garantir que os times estão usando-a corretamente. Por isso, a documentação, orientações e melhores práticas nela contidas também fazem parte de um design system acessível.
"Na maioria das situações não é necessário diferenciar usabilidade de acessibilidade, por que os dois conceitos são complementares"
(Anna Cook 2021)
Outro ponto importante de se saber é que assim como qualquer experiência, digital ou física, construir um design system acessível desde seu início é bem menos trabalhoso e mais barato do que refatorá-lo depois de já criado. Então se você está estruturando um design system agora e pensou em acabar de criar o que já está planejado, pense duas vezes, talvez seja melhor dar alguns passos para trás e fazer certo de primeira.
Entendidas as limitações, agora vamos para a parte legal! O que fazer e quais passos você pode seguir para construir o seu design system acessível?
Passo 1: Siga os mestres
Inspire-se e tenha como referência design system acessíveis do mercado: Carbon (IBM), Material (Google), Spectrum (Adobe), Lightning (Salesforce), entre outros. Aprenda com quem é mestre, lembre-se que as tecnologias assistivas criadas por essas instituições são amplamente utilizadas e siga as convenções de design ou do segmento em que sua empresa trabalha.
Passo 2: Entenda o seu produto atual
Caso seu design system já exista, faça um teste de qualidade e entenda quais critérios de acessibilidade ele já cumpre e quais não. Além disso, entender seu produto final, mesmo que não possua um design system ainda, te ajudará a planejar melhor as próximas etapas como priorização e criação de componentes com base nas suas principais utilizações.
Passo 3: Priorize
Entenda e alinhe quais elementos são prioritários no seu design system. Isto possibilitará que design e programação andem bem próximos, garantindo a disponibilidade de cada elemento o quanto antes. Em casos de refatoração, cadenciar em partes as entregas de design e tecnologia, agilizará a escalabilidade da acessibilidade.
Caso seu design system já exista, analise quais elementos são mais utilizados pelos clientes através da ferramenta de analytics da sua empresa, caso não seja possível, faça um mapeamento da experiência da aplicação. Normalmente, elementos de interação como botões, tab bar e inputs, acabam sendo os mais prioritários devido a sua ampla utilização em fluxos e importância para conclusão de tarefas core da aplicação.
Faça a priorização junto ao Product Manager e desenvolvedores, assim vocês podem levar em consideração outras variáveis como complexidade e serviços/squads impactadas.
Passo 5: Especifique a acessibilidade de cada componente seguindo a WCAG
Acessibilidade ainda é tratada como 8 ou 80 no mercado, "se não é para ser 100%, nem precisa fazer", porém isso vai muito contra a própria jornada de tornar algo acessível. Tratarmos a acessibilidade como um processo é a primeira etapa para nos livrarmos das desculpas para não criarmos produtos acessíveis. O objetivo será alcançado com passos curtos e o primeiro deles é certamente seguir a WCAG. Entenda o conceito e a WCAG te dará a rota, testes, exemplos e etc.
"Ah, mas Maju, e o teste com o cliente?"
A WCAG tem como objetivo criar atalhos para times que querem ser acessíveis, mas seguir a normativa não te garante uma solução 100% acessível, pois sempre haverão casos de exceção, todavia, se seu design system ou produto seguem a WCAG, certamente a maior parte dos casos de uso de acessibilidade estão cobertos. Seguir a WCAG vai tornar seu processo mais fácil, rápido, assertivo e menos custoso, além de possibilitar a realização de testes de qualidade com o cliente no futuro. Como você vai testar uma coisa com o cliente já sabendo que tem erros? Planeje o teste de acessibilidade com o cliente para quando seu produto já estiver cumprindo o básico.
Mesmo seguindo a WCAG, para que os componentes sejam acessíveis, é importante uma parceria forte entre o designer e o time de tecnologia. Uma forma de facilitar essa comunicação é adicionar o detalhamento de acessibilidade às especificações do componente. Essas especificações podem ser utilizadas pelo time que irá programar o componente, mas também pelo time que irá utilizá-lo depois. Já devem estar validadas segundo a WCAG e podem contemplar exemplos de como o componente deve se comportar em determinadas situações ou em contato com determinadas tecnologias assistivas, como leitores de tela. Uma alternativa legal é criar uma especificação para o desenvolvedor e outra para o designer, desta forma, conseguimos orientar cada especialidade segundo a sua atuação no dia a dia.
Principais pontos de atenção na hora de criar seus componentes e especificá-los:
Contraste: Item mais focado por designers quando o assunto é acessibilidade. Selecione cores validadas em contraste, crie elementos com contraste testado, documentações orientando o time e se apoie em plugins que podem ajudar o seu time a não descumprir essa regra - o Figma tem várias ótimas alternativas.
Fonte: Optar por mesclar tipos de fonte para o seu design system pode ser uma estratégia visual interessante, mas tome cuidado com fontes que podem impactar a leitura, como tipos light ou com serifa para textos longos ou pequenos.
Ainda falando de fonte, cabe ao planejamento de Ops definir se a hierarquia dos tokens estará programada no design system. Normalmente, isso só é viável se todas as páginas da sua solução seguem um padrão muito fechado. De forma geral, a documentação do design system orienta a utilização de fontes em determinados casos, mas a hierarquia em si é definida pelo time das squads.
Pouca complexidade: Crie componentes de menor complexidade e sem muitas interações conjuntas. Se um componente tem muitos elementos de interação simultânea, ele dificilmente entregará a melhor experiência para todos os contextos e você provavelmente já estará criando uma sub-cena.
Espaçamento: Pense no grid e deixe clara a utilização dos espaçamentos na documentação. A padronização dos espaçamentos também é importante para o contexto e acessibilidade das páginas, sendo essencial para leitura. Ao pensar neste item, também garanta a área de toque entre os elementos, já que este é um dos principais erros encontrados em experiências digitais e que pode ser sanado com um bom design system.
Honestidade material: No mundo do design, nem sempre tudo é o que parece e isso, por si só, já deveria ser considerado um problema de acessibilidade. A estética dos produtos atuais muitas vezes quebra padrões visuais buscando a beleza (ex. Criação de botões personalizados através de divs ao invés de usarmos elementos nativos). Por conta disto, é importante que sua especificação contemple a honestidade material de cada elemento.
Resumindo, diga ao desenvolvedor o que cada elemento é pela sua função, independente do que ele parece ser. Isto é essencial para que as tecnologias assistivas se conectem de forma adequada à aplicação e para estabelecer as expectativas de interação do usuário - este é um dos principais ganhos de se criar um design system acessível. Conseguir fazer esse tipo de correção em grande escala melhora muito a usabilidade da sua aplicação e limita qualquer possibilidade de "gambiarra" na hora de programar seus componentes.
Ícones e ilustrações: Já comentei que a descrição de imagens e elementos visuais é uma coisa que dificilmente será escalada em um design system, mas essa aqui pode ser umas das poucas exceções ao caso. É bem comum todo design system ter ícones e ilustrações que são repetidos em situações de erro, alerta e sucesso, por exemplo. Nestes casos, é interessante já inserir a label nesses elementos, já que serão utilizados de forma padronizada, assim, o contexto das mensagens será sempre informado, mesmo quando o time responsável esquecer dessa boa prática.
Exemplo do componente de alerta do Spectrum Design system
Exemplos de uso: Essa é uma boa prática para a documentação de qualquer design system, mas quando se trata de acessibilidade é mais importante ainda, tendo em vista que muitos ainda desconhecem as formas de interação através das principais tecnologias assistivas.
Somar a essa documentação, os critérios da WCAG que estão sendo seguidos, a forma de testá-los e implantá-los, é super interessante, seja para o desenvolvedor que irá criar o componente inicial, seja para os times que irão utilizá-lo poderem testá-lo e se familiarizar cada vez mais com a diversidade das formas de uso da tecnologia.
Passo 6: Treine o time
Essa etapa deve ser feita em paralelo às anteriores, mas é na hora que os times consumirem o design system que ela demonstrará o seu real valor com a iniciativa. Como já comentei, nem todos os problemas de acessibilidade podem ser resolvidos com o design system, então é aqui que a importância de um bom treinamento e educação sobre o tema fazem a diferença.
Treinar o seu time te permitirá não só utilizar o design system criado da forma correta, mas também a desenvolvê-lo ao longo do tempo com a cultura e conhecimentos para isso. Ter um time que entende de acessibilidade e a discute no dia a dia do conceito do produto te ajudará na priorização de backlog de melhoria contínua dos componentes e te permitirá refinar a acessibilidade deles ao longo do tempo e com base em casos reais de utilização.
Curiosidade: Você sabia que cerca de 67% dos problemas de acessibilidade encontrados em uma experiência são criados na fase de conceito do design? Sendo assim, o treinamento do próprio time de design é um ótimo começo para tornar a experiência dos produtos da sua empresa mais inclusiva.
Passo 7: Programe
Após a especificação detalhada da função e variações de cada token/componente, está na hora de transformar esse conceito em realidade e sentar do ladinho do seu melhor amigo, o desenvolvedor. Neste caso, muitas empresas não possuem um time de tecnologia amplo dedicado à construção do design system e contam com os times de tecnologia dos produtos para fazer o refinamento e construção dos componentes conforme a necessidade de cada experiência. Se essa for a sua situação, a documentação criada tem um papel ainda mais fundamental, além da importância de você estar disponível para acompanhar os times em caso de dúvidas. O mais importante é garantir que a qualidade do conceito original seja mantida e, neste caso, que a acessibilidade não seja despriorizada porque é "complexa" (por isso o passo 6 é essencial).
Alguns designers entendem mais de programação do que outros, mas para deixar essa etapa mais fácil para todos, também vou dar algumas dicas do que pedir e validar com os programadores durante esse processo:
Possibilite a personalização: A maioria dos dispositivos hoje em dia possuem soluções nativas que possibilitam os usuários aumentarem ou alterarem o tipo de fonte e contraste das aplicações. Para que o seu produto seja compatível com essa tecnologia assistiva, é importante que, antes de tudo, seus componentes prevejam quebras em caso de zoom, mudança de fonte ou contraste.
Label: Não esqueça de colocar o lugar da label a ser preenchido em cada elemento do componente. Isso facilitará o trabalho dos próximos desenvolvedores e garantirá que os times não esqueçam de inserir conteúdos essenciais para o entendimento do contexto de cada experiência.
Siga os padrões de semântica: Lembra que especificamos a honestidade material no passo 5? Pois é aqui precisamos garantir que a semântica do código realmente está correta e seguindo a função que desejamos.
Cuidado com Browser Specific Code: Sério, evite ao máximo! Isso começará a criar diversos casos de uso e variantes de tratativa, o que vai contra o próprio conceito de um design system. Na dúvida sobre o suporte cross-browser do elemento, propriedade ou estilo, uma boa dica é consultar o site "caniuse.com".
ARIA Label: Lembre-se, a primeira regra do ARIA é não usar ARIA. Tudo que puder ser solucionado de forma efetiva com elementos nativos, use. Não altere semântica nativa com ARIA, use as roles de forma apropriada e lembre-se de cobrir todos os status de um elemento de interação, não basta apenas inserir o ARIA.
Passo 8: Teste
Crie testes automatizados e faça testes unitários. Uma vez que os fluxos já estejam estruturados, testes com o cliente. Teste com frequência, na tentativa de encontrar erros e novos casos de uso. Teste em conjunto com os times de qualidade e de produto. Use ferramentas que podem ajudar na identificação de problemas de semântica, como o WAVE ou o AXE, e faça testes manuais para garantir que contexto, semântica e conteúdo realmente fazem sentido. Documente os erros encontrados e discuta, com o time de tecnologia e produto, a melhor estratégia para priorizar a correção necessária, quais impactos essa correção poderá acarretar e o que fazer para mitigá-los.
Para fechar, gostaria reforçar que, para que sua empresa comece a priorizar acessibilidade, você precisa dar uma cutucada na cultura e pilares que ditam o dia a dia dos colaboradores e projetos. Para isso, ter um time excepcional, aliado ao tema e disposto a investir energia dando esse primeiro passo é essencial! Por isso, gostaria de agradecer e deixar aqui o contato das pessoas que fizeram parte dessa jornada comigo e que podem te ensinar muito sobre design system e acessibilidade, assim como me ensinaram nesse primeiro ano! Bianca Kondo, Gustavo Chisti, Flavia Santinon, Fernando Dutra, Victor Caetano, Renan Silveira, Alex Rodrigues, Willian Kuster e Raphael Sonsino.
Obrigada! s2
Designer, atuando no mercado há mais de 11 anos, desses, 7 no mercado financeiro. Possuo foco em design de experiência, tendo cursado MBA em Business Process, com objetivo de escalar as soluções a nível corporativo e melhor integrá-las em todas as áreas da empresa. Tenho um envolvimento profundo em temas relacionados à inclusão e acessibilidade, principalmente no ambiente digital. Atualmente, faço parte de um grupo que desenvolve o tema dentro da XPinc.
