Um formulário pode passar em testes funcionais e continuar impossível de usar sem mouse. Um aplicativo pode ter alto contraste em uma tela e perder toda a estrutura quando o texto é ampliado. Uma correção feita na véspera do lançamento costuma voltar a quebrar na próxima versão porque não virou componente, teste nem regra de revisão.
Em 5 de novembro de 2026, o GitHub anunciou um espaço visível para arquivos ACCESSIBILITY.md, reunindo objetivos, limitações conhecidas, ambientes suportados e canais de reporte. A iniciativa evidencia uma mudança importante: acessibilidade em software deve ser responsabilidade contínua e verificável, não uma declaração genérica.
O que WCAG 2.2 organiza
As Diretrizes de Acessibilidade para Conteúdo Web agrupam critérios em quatro princípios: perceptível, operável, compreensível e robusto. Os níveis A, AA e AAA expressam critérios de conformidade. O W3C recomenda usar a versão mais recente, e a WCAG 2.2 também orienta experiências móveis.
Para empresas que atuam na Europa, a acessibilidade também ganhou peso regulatório. O European Accessibility Act cobre produtos e serviços como smartphones, comércio eletrônico, bancos, transporte e livros digitais. A referência técnica costuma combinar WCAG com a norma europeia EN 301 549.
Comece pela jornada, não pelo checklist
Critérios técnicos são indispensáveis, mas o objetivo é permitir que pessoas concluam tarefas. Mapeie jornadas críticas: criar conta, comprar, pagar, agendar, acompanhar pedido, enviar documento e pedir suporte. Para cada uma, teste diferentes formas de interação.
Teclado e foco
A ordem deve seguir o significado visual, o foco precisa ser visível e nenhum componente pode aprisionar o usuário. Modais devem mover e devolver o foco corretamente.
Leitor de tela e semântica
Use elementos nativos, rótulos associados, títulos hierárquicos e mensagens anunciadas. ARIA complementa a semântica; não conserta uma estrutura incorreta.
Contraste, zoom e texto ampliado
Cor não pode ser o único sinal. A interface deve preservar conteúdo e função com zoom e aumento de fonte, sem sobreposição ou rolagem desnecessária.
Toque, movimento e mídia
Alvos pequenos causam erros; gestos complexos precisam de alternativa. Animações devem respeitar preferências de redução de movimento. Vídeos necessitam legendas e, quando adequado, audiodescrição.
Transforme requisitos em componentes
O design system é o ponto de maior alavancagem. Se botão, campo, alerta, modal, menu e tabela já nascem acessíveis, cada equipe reaproveita uma base melhor. Documente nome acessível, estados de foco, comportamento com teclado, contraste, mensagens de erro e exemplos de uso.
Um componente “conforme” ainda pode ser usado de forma errada. Por isso, forneça padrões de composição para formulários, fluxos de autenticação, tabelas e navegação. Inclua conteúdo: rótulos claros, instruções antes do erro e linguagem objetiva.
Exemplo: agendamento de serviço
O fluxo possui calendário, seleção de horário, endereço e confirmação. A equipe define que todas as etapas devem funcionar por teclado e leitor de tela; o dia selecionado precisa ser anunciado; horários indisponíveis não podem depender apenas de cor; erros ficam próximos ao campo e são resumidos no topo.
Testes automáticos detectam campo sem rótulo, contraste insuficiente e atributo inválido. Um teste de componente verifica foco do calendário. No teste manual, uma pessoa usando leitor de tela percebe que a mudança de mês não é anunciada. A correção entra no componente, e não apenas na página, evitando o mesmo defeito em outros produtos.
Crie um pipeline de acessibilidade
- Lint no desenvolvimento: identifica padrões inválidos cedo.
- Teste de componentes: estados, nomes acessíveis e teclado.
- Teste de jornada: percorre tarefas críticas no navegador.
- Auditoria automática no CI: bloqueia violações conhecidas acima do limite.
- Revisão manual: teclado, leitor de tela, zoom, voz e dispositivos reais.
- Teste com pessoas com deficiência: encontra barreiras que ferramentas não compreendem.
O W3C é explícito: nenhuma ferramenta sozinha determina conformidade. Automação oferece velocidade e regressão; avaliação humana interpreta uso, clareza e impacto.
Use severidade em vez de uma nota única
Uma pontuação alta pode esconder uma barreira que impede pagamento. Classifique achados por impacto na tarefa, alcance e existência de alternativa. Um botão sem nome acessível em uma tela de confirmação pode ser bloqueador; uma descrição longa pouco clara pode ser importante, mas não interromper a jornada.
Defina critérios de release: zero bloqueadores em jornadas críticas, nenhuma regressão em componentes compartilhados e plano com responsável e prazo para limitações não bloqueantes.
Documente com transparência
Uma declaração de acessibilidade útil informa padrão adotado, medidas realizadas, ambientes testados, limitações conhecidas e contato para reportar barreiras. O arquivo ACCESSIBILITY.md pode manter essa informação próxima do código e facilitar contribuições, enquanto a versão destinada ao usuário fica no site ou aplicativo.
Evite prometer “100% acessível” sem evidência. Explique o estado atual, alternativas e processo de resposta. Na União Europeia, certos serviços e órgãos públicos possuem formatos e obrigações específicos; valide a legislação aplicável com assessoria especializada.
O que não resolve
- instalar um overlay e considerar o produto corrigido;
- rodar um scanner apenas antes do lançamento;
- usar ARIA em vez de HTML semântico;
- tratar acessibilidade como responsabilidade exclusiva de QA;
- testar somente uma tela e ignorar jornadas;
- usar personas sem incluir pessoas com deficiência na pesquisa;
- publicar declaração sem canal real de retorno.
Roteiro para um produto existente
- Priorize jornadas: receita, acesso, atendimento e obrigações legais.
- Faça inventário: componentes, plataformas, conteúdo e fornecedores.
- Meça o baseline: automação mais revisão manual amostral.
- Corrija na origem: design system e componentes antes de páginas isoladas.
- Adicione gates: impeça a volta de violações conhecidas.
- Publique a declaração: limitações, contato e compromisso.
- Monitore: feedback, métricas e auditorias periódicas.
Acessibilidade como qualidade de produto
Interfaces acessíveis tendem a ser mais claras, robustas e fáceis de operar em diferentes dispositivos. O ganho vai além da conformidade: melhora a experiência de clientes, reduz suporte e amplia o público que consegue concluir tarefas.
A ProativaIA desenvolve aplicativos, sistemas sob medida e plataformas web. Podemos auditar jornadas, evoluir componentes, automatizar testes e incorporar acessibilidade ao ciclo de entrega do seu produto.