Uma concepção equivocada comum entre designers de UX é que a acessibilidade é exclusivamente responsabilidade dos desenvolvedores. Alguns acreditam que, ao usar uma paleta de cores de alto contraste e entregar designs limpos, o produto final será automaticamente acessível.

Mas a acessibilidade no UX vai muito além do contraste de cores do design. Não é apenas responsabilidade dos desenvolvedores. Designers desempenham um papel crucial em garantir a acessibilidade desde o início. Desenvolvedores podem saber intuitivamente como criar produtos acessíveis, mas muitas vezes dependem dos designers para fornecer experiências que considerem uma ampla gama de necessidades dos usuários, especialmente para usuários com deficiência.

A acessibilidade web não é um recurso opcional — é uma necessidade. Designers e desenvolvedores devem colaborar para construir produtos acessíveis. Designers estabelecem a base com suas escolhas de design, mas também devem defender a implementação acessível durante o desenvolvimento.

Quem realmente é responsável pela acessibilidade?

Como designer, você pode pensar: “A acessibilidade web não depende do código e de como os designs são implementados?” Embora haja alguma dependência de como os desenvolvedores codificam um design, a acessibilidade web historicamente tem sido isolada dentro da equipe de desenvolvimento, o que significa que os designers muitas vezes se sentem “livres de culpa” quando se trata de criar designs acessíveis.

Fatores que causam o isolamento da acessibilidade

• Acessibilidade é percebida como técnica — Designers podem pensar que não precisam se preocupar com acessibilidade porque envolve o código subjacente, como HTML e CSS. Mas a acessibilidade começa com o designer garantindo que os designs sejam amigáveis ao teclado, tenham contraste de cor suficiente, etc.
• Treinamento e conscientização insuficientes — Alguns designers e desenvolvedores não têm as habilidades para entender a acessibilidade web, o que leva a oportunidades perdidas e produtos inacessíveis.
• Falta de colaboração em equipe — Quando designers, desenvolvedores e gerentes de projeto não colaboram sobre acessibilidade, ela não é realizada. As anotações e a documentação sobre acessibilidade podem facilmente se perder enquanto os desenvolvedores priorizam a funcionalidade e o lançamento de um produto mínimo viável (MVP).
• Acessibilidade não está integrada no ciclo do produto — A acessibilidade não é considerada até o final do ciclo de desenvolvimento do produto, o que faz com que as equipes abordem reativamente os problemas de acessibilidade em vez de preveni-los desde o início.

Estes fatores levam a produtos inacessíveis, causando experiências de usuário ruins para grupos específicos de usuários, como usuários com baixa visão ou usuários que usam apenas o teclado. Quando as equipes de produto são questionadas sobre por que o produto não é acessível, inicia-se um jogo de culpa.

Em última análise, os desenvolvedores não são os únicos na equipe de produto que são responsáveis pela acessibilidade. Todos os membros da equipe são (especialmente os designers). Os designers têm a obrigação de criar designs com uma mentalidade “acessível em primeiro lugar” e defender a implementação acessível, fornecendo anotações e recomendações para seus colegas desenvolvedores.

Erros comuns de colaboração

Um dos maiores obstáculos na criação de produtos acessíveis é a falta de colaboração em equipe. No entanto, pode ser desafiador determinar se sua equipe tem colaboração eficaz quando se trata de acessibilidade, especialmente quando está sendo integrada pela primeira vez em seu fluxo de trabalho.

Para entender melhor os erros comuns de colaboração, vamos observar alguns exemplos:

• Armadilha da “transferência” de acessibilidade — Designers assumem que os desenvolvedores sabem como codificar corretamente seus designs após uma simples transferência, seja através de um walkthrough dos designs no Figma ou de um link para a documentação. Mas se os desenvolvedores não estão familiarizados com requisitos específicos, como a ordem correta das abas, ele não será implementado após a transferência do design.
• Especificações de design ambíguas — Designers têm muito em suas mãos ao gerar especificações de design para desenvolvedores; eles precisam criar fluxos de usuário, protótipos e anotações especificando padrões de interação. Mas quando as anotações estão faltando ou as especificações têm rótulos pouco claros, os desenvolvedores terão que adivinhar o que está implícito nos designs.

Para criar sites e aplicativos inclusivos, toda a equipe de desenvolvimento do produto deve estar alinhada e ter canais de comunicação eficazes. Estratégias como educação da equipe e ferramentas compartilhadas para teste podem melhorar a colaboração.

Onde a acessibilidade começa e termina

Como discutido anteriormente, se a acessibilidade não estiver integrada no ciclo de vida do produto, há um risco maior de criar sites e aplicativos inacessíveis e exclusivos. O pensamento inclusivo começa no início do desenvolvimento do produto, com a descoberta inicial e a coleta de requisitos, e continua ao longo de todo o ciclo do produto.

Como os designers podem ter uma atitude “acessível em primeiro lugar”

A acessibilidade não acontece magicamente quando os designs são entregues para desenvolvimento; começa no início de um projeto, seja um novo recurso ou um produto inteiro. Embora haja muitas variações do ciclo de desenvolvimento do produto, algumas começando com “Descoberta” e outras com “Ideação”, a acessibilidade deve ser integrada desde este passo e em cada etapa seguinte.

• Descoberta e ideação — Compreender padrões de acessibilidade como as Diretrizes de Acessibilidade para Conteúdo Web (WCAG), definir metas de acessibilidade e conduzir pesquisas com usuários de diversas habilidades para entender suas necessidades.
• Design — Usar paletas de cores com alto contraste, fornecer texto alternativo para quaisquer imagens usadas, oferecer uma ordem de abas sugerida e estados de foco para todos os elementos interativos, e usar cabeçalhos ou organizar o conteúdo (entre H1 e H6).
• Desenvolvimento — Garantir que os desenvolvedores usem HTML semântico em vez de divs e spans, dar rótulos adequados a todos os elementos interativos e fornecer alternativas de texto para conteúdo não textual, como legendas para conteúdo de vídeo.

Ferramentas de acessibilidade para designers

Integrar a acessibilidade no processo de desenvolvimento de produtos, especificamente na fase de design, pode parecer tedioso e desafiador. Mas existem ferramentas feitas para designers que tornam este processo mais fácil. Vamos ver algumas:

• Stark — Stark oferece um plugin para Figma que designers podem usar para verificar o contraste de cores, anotar a ordem das abas/foco e marcos, bem como simular deficiências visuais, como daltonismo vermelho-verde.
• Plugins do Figma — Existem muitos plugins do Figma focados em acessibilidade, mas Text Resizer-Accessibility Checker e A11Y Annotation Kit são alguns dos favoritos. O plugin Text Resizer ajuda os designers a entender como o conteúdo aparecerá quando os usuários aumentarem o texto para o tamanho preferido, e o Annotation Kit fornece recursos que os designers podem usar ao criar especificações para desenvolvedores.

Modelo coletivo para sucesso em acessibilidade

Como a acessibilidade web é uma preocupação em todo o produto, toda a equipe precisa ter um modelo em vigor para garantir seu sucesso. E integrar um modelo para acessibilidade não acontece da noite para o dia; leva tempo e esforço de todos os membros da equipe.

Embora existam ferramentas como o Modelo de Maturidade de Acessibilidade Digital (DAMM) da Level Access que podem medir a maturidade da acessibilidade de sua equipe de produto, existem estratégias que sua equipe pode focar agora para iniciar sua conformidade com a acessibilidade:

Educação da equipe

Antes que uma equipe de produto possa pensar sobre acessibilidade, todos precisam entender o que é, quem afeta e como é regulamentada. Muitas pessoas pensam que a acessibilidade é um esforço para garantir um contraste de cores adequado em uma interface, mas também abrange muitos outros requisitos, como funcionalidade de teclado e leitor de tela.

Formas de educar todos os membros da equipe de produto incluem:

• Sessões de treinamento — Convide um especialista em acessibilidade para conduzir uma sessão de treinamento e aumentar a conscientização. Existem opções para treinamento específico para equipe ou função, para designers, desenvolvedores e gerentes de projeto.
• Cursos autoinstrucionais — Exigir que os membros da equipe de produto completem cursos de treinamento em acessibilidade que revisem os princípios fundamentais, como a Introdução à Acessibilidade Web do W3C.
• Uso de leitor de tela e teclado — Ensinar os membros da equipe a usar o básico de um leitor de tela e teclado, como o VoiceOver no Mac, e pedir que naveguem no produto usando um leitor de tela somente com o teclado.

A acessibilidade web não é mais um “agradável de ter” que pode ou não acontecer se a equipe tiver tempo. É um “essencial” para garantir que pessoas com habilidades diversas possam acessar e usar qualquer produto que desejarem sempre que quiserem.