Como formar um time que pensa em acessibilidade desde o briefing

A acessibilidade digital ainda é tratada, na maioria das agências e departamentos de marketing no Brasil, como a última etapa de um projeto. É o ajuste que se tenta fazer às pressas na véspera do lançamento, quando o código já está fechado, o design aprovado pelo cliente e as peças de redes sociais programadas. O resultado dessa abordagem tardia é previsível: retrabalho, custos elevados, prazos estourados e, no fim, uma experiência que continua excludente para milhões de pessoas.

Eu vivencio essa realidade sob duas perspectivas. Como profissional de marketing, conheço as pressões por entregas rápidas e orçamentos otimizados. Como pessoa com baixa visão, sinto na pele a frustração de tentar navegar por plataformas, campanhas e aplicativos que simplesmente ignoraram a minha existência durante a sua concepção. Quando um layout chega até mim com baixo contraste ou sem uma hierarquia de informação clara, eu sei que a falha não ocorreu no desenvolvimento. Ela ocorreu muito antes: na folha em branco do briefing.

Formar um time que pensa em acessibilidade desde o início não é apenas uma questão de empatia ou cumprimento de obrigações legais, como a Lei Brasileira de Inclusão (LBI). É uma decisão estratégica de eficiência operacional e design inteligente. Quando a acessibilidade faz parte do DNA do briefing, ela deixa de ser uma barreira ou um custo extra para se tornar o padrão de qualidade de toda a entrega.

O conceito de "Shift Left" aplicado à acessibilidade digital

Para compreender como transformar a mentalidade de uma equipe de marketing ou produto, precisamos emprestar um conceito muito comum na engenharia de software: o Shift Left (ou descolar para a esquerda, em uma tradução literal). No ciclo tradicional de desenvolvimento de projetos, a acessibilidade costuma ficar localizada na extrema direita, ou seja, na fase de testes finais ou pós-lançamento.

Mover a acessibilidade para a esquerda significa trazê-la para o início do fluxo de trabalho. Em vez de testarmos a acessibilidade na homologação, nós a planejamos durante a concepção do produto, no desenho da estratégia e, fundamentalmente, na elaboração do briefing.

Quando aplicamos o Shift Left, o impacto financeiro e operacional é mensurável. Estudos de engenharia de sistemas apontam que corrigir um erro de design ou arquitetura de informação na fase de código pode custar até cem vezes mais do que corrigi-lo na fase de planejamento. No marketing, isso se traduz em não precisar refazer uma identidade visual inteira porque as cores escolhidas não passam nos testes de contraste da WCAG (Web Content Accessibility Guidelines). Significa não ter que reescrever centenas de textos alternativos de imagens às pressas porque a equipe de conteúdo não sabia que as postagens precisavam ser descritas.

A acessibilidade integrada desde o início flui de maneira orgânica. Ela se torna invisível e elegante, pois passa a fazer parte da estética e da usabilidade natural do produto ou da campanha, e não um remendo técnico adicionado de última hora.

Por que o briefing tradicional falha com a acessibilidade

O briefing tradicional é estruturado para responder a perguntas como: qual é o objetivo de negócio, qual é a verba disponível, quais são os canais de veiculação e quem é a persona. O erro crítico reside na forma como definimos essa persona e o público-alvo.

Geralmente, as personas de marketing são descritas de forma idealizada: "Letícia, 28 anos, publicitária, usuária intensa de redes sociais, busca praticidade no dia a dia". Essa descrição ignora que Letícia pode ser uma pessoa cega que utiliza leitores de tela para consumir conteúdo no Instagram. Ignora que ela pode ter baixa visão, como eu, e precisar de zoom de 200% para ler o texto de um e-commerce. Ou que Letícia pode ter uma deficiência motora temporária, como um braço engessado, e precisar navegar por um site usando apenas o teclado.

Ao omitir a diversidade funcional do público-alvo no briefing, a equipe assume, por padrão, que todos os usuários interagem com a tela da mesma forma: usando os olhos, as mãos e o mouse. Esse viés de normalidade molda todas as decisões criativas subsequentes. O designer criará telas baseadas apenas no seu próprio padrão visual; o redator criará textos baseados na premissa de que a imagem resolve a compreensão; o desenvolvedor construirá o código sem se preocupar com a semântica necessária para as tecnologias assistivas.

O briefing tradicional também falha ao não estabelecer requisitos claros de conformidade. Dizer apenas que o projeto deve ser "acessível" é o mesmo que não dizer nada. É preciso especificar parâmetros técnicos claros, baseados em diretrizes globais e na legislação local.

Como estruturar um briefing inclusivo: os novos campos indispensáveis

Para que um time comece a pensar em acessibilidade na largada, o documento de briefing precisa ser modificado. Ele deve provocar a reflexão e exigir definições específicas que orientarão o trabalho dos criativos e técnicos.

Abaixo, apresento os campos que considero indispensáveis em um briefing verdadeiramente inclusivo.

1. Definição do público-alvo ampliado e espectro de habilidades

Em vez de limitar a persona a dados demográficos e comportamentais padrão, o briefing deve incluir o espectro de habilidades dos usuários. Devemos responder explicitamente a perguntas como:

• Como este produto ou campanha será consumido por pessoas com deficiências sensoriais (visuais, auditivas), motoras ou cognitivas?
• Quais adaptações de linguagem são necessárias para garantir que pessoas com deficiência intelectual ou neurodivergentes compreendam a mensagem principal?

2. Requisitos de conformidade técnica e diretrizes adotadas

O briefing deve definir o nível de conformidade técnica exigido para o projeto. No ambiente digital, a referência global são as Diretrizes de Acessibilidade para Conteúdo Web (WCAG), atualmente em sua versão 2.2.

• O projeto visa a conformidade com o nível AA da WCAG (o padrão recomendado para a maioria das organizações e exigido por legislações internacionais)?
• Quais são as diretrizes específicas da Lei Brasileira de Inclusão (LBI, Artigo 63) que se aplicam a este projeto de comércio eletrônico ou portal corporativo?

3. Canais, formatos e tecnologias assistivas previstas

Diferentes canais exigem diferentes abordagens de acessibilidade. O briefing deve mapear os formatos e as tecnologias assistivas que interagirão com a entrega:

• Para vídeos: o briefing prevê orçamento e cronograma para audiodescrição, legenda (oculta ou aberta) e janela de Libras (Língua Brasileira de Sinais)?
• Para plataformas digitais: o design deve suportar navegação exclusiva por teclado e compatibilidade com leitores de tela como NVDA, JAWS e VoiceOver?

Papéis e responsabilidades na equipe: quem faz o quê?

Para que o briefing inclusivo saia do papel e se transforme em realidade, cada membro da equipe precisa compreender seu papel na entrega da acessibilidade. A acessibilidade não pertence a um único profissional ou a uma área isolada; ela é uma responsabilidade compartilhada e distribuída ao longo de todo o fluxo de produção.

O papel do Product Owner e do Gerente de Contas

Esses profissionais são os guardiões do briefing. Cabe a eles garantir que as premissas de acessibilidade definidas no início do projeto não sejam sacrificadas ao longo do caminho devido à pressão por prazos ou escopo.

• No planejamento: Incluir critérios de aceitação de acessibilidade em cada tarefa (User Stories).
• Na gestão de recursos: Garantir que o cronograma preveja tempo para testes de acessibilidade e que haja orçamento para a contratação de consultorias especializadas ou testes com usuários reais com deficiência.
• Na interlocução com o cliente: Defender a importância estratégica da acessibilidade, mostrando que ela amplia o alcance do público e protege a marca contra riscos reputacionais e legais.

O papel do Redator e do UX Writer

O texto é a base da acessibilidade digital. Sem uma redação estruturada de forma inclusiva, as tecnologias assistivas não conseguem traduzir a experiência de forma satisfatória.

• Linguagem simples: Escrever textos claros, objetivos, evitando jargões excessivos e estruturas gramaticais muito complexas, o que beneficia pessoas com deficiência cognitiva, dislexia ou pessoas surdas que têm a Libras como primeira língua.
• Textos alternativos: Redigir as descrições de imagens (o atributo alt no HTML) de forma contextualizada, permitindo que pessoas cegas ou com baixa visão compreendam a informação visual veiculada nas peças de marketing ou no site.
• Links descritivos: Evitar termos genéricos como "clique aqui" ou "saiba mais". O texto do link deve descrever claramente o destino da ação (ex: "baixe o relatório de sustentabilidade em PDF"), atendendo ao Critério de Sucesso 2.4.4 da WCAG (Propósito do Link).

O papel do Designer e do UX Designer

O design acessível não é feio, monótono ou limitado. Pelo contrário: ele desafia o designer a encontrar soluções estéticas que sejam elegantes e altamente funcionais para todos os usuários.

• Contraste de cor: Garantir que o texto em relação ao fundo tenha uma relação de contraste adequada. Para o nível AA da WCAG (Critério 1.4.3), a proporção mínima de contraste é de 4.5:1 para texto normal e 3:1 para texto grande.
• Elementos visuais não exclusivos: Nunca utilizar a cor como único meio de transmitir informação, conforme o Critério 1.4.1 da WCAG. Se um campo de formulário estiver com erro, por exemplo, o design deve apresentar um ícone ou um texto de aviso além da borda vermelha, garantindo a compreensão por pessoas com daltonismo.
• Indicador de foco visível: Projetar o estado de foco para navegação por teclado (Critério 2.4.7). Pessoas com deficiência motora que usam apenas o teclado precisam ver claramente onde o cursor virtual está posicionado na tela através de uma borda visualmente destacada.

O papel do Desenvolvedor e do Tech Lead

O desenvolvimento é onde a estrutura semântica da acessibilidade é consolidada. O código precisa traduzir as intenções do design e do conteúdo de forma que os sistemas operacionais e as tecnologias assistivas possam interpretá-las.

• HTML Semântico: Utilizar tags HTML corretas (<header>, <main>, <nav>, <button>, <a>) em vez de genéricas (<div> ou <span>) para ações interativas. Isso garante a acessibilidade nativa por teclado e leitores de tela sem a necessidade de correções complexas com ARIA (Accessible Rich Internet Applications).
• Navegação lógica: Programar a ordem de tabulação do teclado para seguir a sequência visual natural de leitura do site (Critério 2.4.3).
• Responsividade e Zoom: Garantir que o layout não quebre ou perca funcionalidade quando o usuário ampliar a tela em até 200% (Critério 1.4.4), um requisito fundamental para a autonomia de pessoas com baixa visão.

Exemplos práticos do mercado brasileiro

Para ilustrar como a acessibilidade desde o briefing transforma resultados, podemos olhar para marcas do mercado brasileiro que compreenderam essa dinâmica e se tornaram referências de maturidade digital.

Um exemplo consistente é o Magazine Luiza. A empresa possui uma cultura forte de diversidade que se reflete em seus canais digitais. Ao planejar o desenvolvimento do seu aplicativo e do portal de e-commerce, as diretrizes de acessibilidade foram estabelecidas como requisitos de negócio inegociáveis desde as primeiras reuniões de concepção. O resultado é um fluxo de navegação e compra que é frequentemente testado e elogiado por pessoas cegas e com baixa visão pela consistência na etiquetagem de botões, clareza nas descrições de produtos e facilidade de fechamento de carrinho por meio de leitores de tela.

Outro caso relevante é o do Itaú Unibanco. O banco mantém um time fixo dedicado à acessibilidade digital e aplica o conceito de design inclusivo desde as fases de pesquisa de novos produtos bancários. Suas diretrizes visuais e de conteúdo contemplam o contraste rigoroso, a simplicidade de termos técnicos de economia e a navegação estruturada para teclado. Isso garante que milhões de brasileiros, incluindo idosos e pessoas com diferentes tipos de deficiência, consigam realizar transações financeiras com autonomia e segurança em seus canais digitais.

Por outro lado, quando analisamos campanhas sazonais como as de Black Friday no varejo brasileiro, percebemos o contraste gritante entre quem planejou a acessibilidade e quem tentou inseri-la de última hora. Campanhas que não incluem a acessibilidade no briefing costumam publicar posts de redes sociais com textos críticos em formato de imagem, sem qualquer descrição alternativa, ou landing pages promocionais com contadores regressivos piscando sem controle do usuário — violando o Critério 2.2.2 da WCAG (Pausar, Parar, Ocultar), o que pode provocar crises em pessoas com epilepsia fotossensível ou transtorno de déficit de atenção.

Erros mais comuns ao tentar implementar a acessibilidade desde o início

Na minha prática como consultora de marketing acessível, observo organizações que desejam genuinamente ser mais inclusivas, mas que acabam cometendo falhas metodológicas que geram frustração e desperdício de recursos. Identificar esses erros é o primeiro passo para evitá-los.

1. Tratar a acessibilidade como uma lista de tarefas técnicas ao final do projeto

Este é o erro conceitual mais frequente. A liderança acredita que a acessibilidade é um checklist de conformidade que o desenvolvedor deve aplicar no momento de subir o código para produção. O problema é que, se o design de interação foi mal estruturado, se o contraste da marca é ruim ou se o fluxo do usuário é confuso, o desenvolvedor não conseguirá salvar a experiência apenas com linhas de código. A acessibilidade precisa ser encarada como uma disciplina de design de experiência, e não apenas de desenvolvimento.

2. Confiar cega e exclusivamente em plugins de acessibilidade (overlays)

No mercado brasileiro, tornou-se comum o uso de ferramentas de terceiros que prometem tornar qualquer site acessível instantaneamente por meio de uma única linha de código. Essas ferramentas costumam apresentar um menu lateral com opções de zoom, alteração de contraste e leitura de texto.

Esse recurso é uma ilusão de acessibilidade. Na prática, esses overlays frequentemente entram em conflito com os leitores de tela que as pessoas cegas e com baixa visão já utilizam por padrão em seus computadores e celulares. Além disso, essas barras de ferramentas adicionais não corrigem a falta de semântica do código subjacente, não substituem uma descrição de imagem malfeita e costumam criar barreiras adicionais de navegação por teclado. A verdadeira acessibilidade é construída na estrutura do site, não mascarada por um plugin de superfície.

3. Excluir pessoas com deficiência dos testes com usuários

Muitos times criam personas com deficiência no papel, preenchem o briefing com referências técnicas da WCAG, mas não validam a entrega com pessoas reais com deficiência. Os testes automatizados de acessibilidade são ótimos e necessários, mas eles conseguem detectar apenas cerca de 30% a 40% das barreiras de acessibilidade. O restante só é identificado quando uma pessoa com deficiência tenta interagir com a interface no mundo real. Sem essa validação humana, o time corre o risco de criar um produto que é teoricamente conforme com as regras, mas praticamente inutilizável.

4. Usar termos capacitistas e desatualizados na comunicação interna

A mudança de mentalidade do time também passa pela forma como nos comunicamos. O uso de expressões capacitistas ("isso está cego", "um briefing capenga", "você é surdo?") ou o uso de nomenclaturas defasadas como "portador de necessidades especiais" cria um ambiente que marginaliza o tema. O termo correto, estabelecido pela Convenção da ONU sobre os Direitos das Pessoas com Deficiência e adotado na legislação brasileira, é pessoa com deficiência. Reconhecer a pessoa antes de sua condição física, sensorial ou intelectual é o alicerce do respeito e da empatia profissional.

Checklist de maturidade: seu time está pronto?

Antes de mudar os seus processos, é preciso entender o estágio atual de maturidade da sua equipe em relação à acessibilidade. Use o checklist abaixo para fazer um diagnóstico realista do seu cenário:

• [ ] O template de briefing do seu time possui campos obrigatórios sobre público-alvo com deficiência e requisitos de acessibilidade?
• [ ] Os designers da equipe possuem ferramentas de checagem de contraste de cores instaladas e ativas no seu software de design (como Figma ou Adobe XD)?
• [ ] Os redatores e UX Writers sabem redigir textos alternativos úteis e objetivos para imagens e conhecem as diretrizes de linguagem simples?
• [ ] Os desenvolvedores dominam o uso de HTML semântico e realizam testes rápidos de navegação usando apenas o teclado antes de enviar o código para revisão?
• [ ] A definição de "concluído" (Definition of Done) das tarefas do seu time inclui a verificação de critérios básicos da WCAG?
• [ ] O time realiza testes de usabilidade com usuários reais com deficiência de forma recorrente, e não apenas de maneira esporádica?
• [ ] A liderança entende que a acessibilidade é um indicador de qualidade de entrega e um diferencial estratégico de mercado, apoiando a alocação de tempo para esse fim?

Se você respondeu "não" para a maioria dessas perguntas, não se preocupe. O caminho para a acessibilidade é uma construção gradual e contínua de cultura e processos.

Por onde começar: passo a passo para a transformação

Mudar a cultura de um time de marketing ou de produto não acontece do dia para a noite. Exige planejamento, paciência e constância. Se você deseja liderar essa transformação na sua organização e fazer com que a acessibilidade seja pensada desde o briefing, recomendo seguir estes passos:

Passo 1: Sensibilização e letramento da equipe

Não exija conformidade técnica antes de explicar o propósito. O primeiro passo é promover reuniões e dinâmicas de conscientização. Mostre como as pessoas com deficiência utilizam a tecnologia. Faça demonstrações ao vivo de leitores de tela em funcionamento e exiba os problemas comuns de navegação que ocorrem em sites de baixa acessibilidade. Traga profissionais com deficiência para falar sobre suas vivências digitais. Quando o time compreende o impacto humano da exclusão digital, o engajamento técnico surge naturalmente.

Passo 2: Reformulação do documento de briefing

Atualize o template oficial de briefing da sua agência ou departamento. Insira as perguntas que estruturam a acessibilidade desde o início, como os requisitos de contraste de cores, a previsão de legendas e audiodescrição para conteúdos de vídeo e as especificações de navegação por teclado. Não permita que um projeto comece sem que essas perguntas tenham sido, no mínimo, discutidas e preenchidas de forma consciente pelas lideranças ou pelos clientes.

Passo 3: Capacitação técnica segmentada

Cada profissional precisa de um tipo específico de conhecimento. Não adianta dar um treinamento genérico de WCAG para todo o time. Forneça:

• Treinamento de contraste e tipografia para os designers.
• Treinamento de textos alternativos e linguagem simples para redatores e produtores de conteúdo.
• Treinamento de HTML semântico e testes de teclado para a equipe de desenvolvimento.
• Treinamento de gestão inclusiva e métricas de impacto para gerentes de projeto e líderes de conta.

Passo 4: Atualização da "Definition of Done" (Definição de Concluído)

Estabeleça que nenhuma entrega (seja uma postagem de rede social, um e-mail marketing ou uma nova funcionalidade de aplicativo) será considerada concluída se não atender aos critérios mínimos de acessibilidade definidos no briefing. Insira a verificação de acessibilidade nas etapas regulares de controle de qualidade (QA) da equipe. Se o design não passa no contraste, ele volta para ajuste. Se o post não tem texto alternativo, ele não é programado. Essa disciplina operacional consolida a cultura do processo.

Passo 5: Testes contínuos e documentação de aprendizados

Após o lançamento de cada campanha ou produto, faça uma avaliação pós-projeto (post-mortem) para analisar o que funcionou e o que pode ser aprimorado em termos de acessibilidade. Documente as lições aprendidas, os erros cometidos e as soluções encontradas pelo time. Crie um guia interno de boas práticas de design e redação acessível da própria marca para facilitar o treinamento de novos membros que integrarem a equipe no futuro.

A jornada para consolidar um time focado em acessibilidade desde o briefing exige dedicação, mas traz resultados consistentes e duradouros. Ao transformar o seu processo de trabalho, a sua equipe deixará de criar campanhas e plataformas que excluem pessoas, passando a construir marcas sólidas, responsáveis e genuinamente humanas, conectando-se de forma respeitosa e inteligente com toda a diversidade de consumidores do mercado brasileiro.

Se você deseja iniciar essa transformação nos processos de marketing e design do seu time, entender os gargalos da sua operação atual ou precisa de um direcionamento estratégico personalizado para os seus projetos de acessibilidade digital, convido você a entrar em contato comigo. Vamos conversar e desenhar, de forma conjunta, caminhos práticos para tornar a sua comunicação verdadeiramente acessível para todas as pessoas.