Acessibilidade web na prática: um checklist que começa no projeto

Acessibilidade não deve aparecer como correção final. Ela precisa estar no escopo, nos componentes, no conteúdo e nos critérios de aceite.

A auditoria final encontrou problemas que o projeto já havia aprovado O layout estava concluído. O conteúdo havia sido publicado. O prazo de lançamento estava próximo. Na revisão final, surgiram problemas: contraste insuficiente; menu inacessível por teclado; campos sem rótulos; foco invisível; erros indicados somente por cor; modal que prendia a navegação; imagens com textos não disponíveis em formato alternativo; títulos usados apenas pelo tamanho visual. Corrigir tudo naquele momento exigiria alterar componentes já reutilizados em várias páginas, revisar conteúdo e reabrir decisões de design. A acessibilidade não falhou no teste. Ela falhou quando não entrou no briefing, nos componentes e nos critérios de aceite. A referência técnica atual: WCAG 2.2 As Web Content Accessibility Guidelines 2.2 são uma Recomendação do W3C. Os critérios são organizados em quatro princípios: Perceptível: a informação precisa poder ser percebida; Operável: controles e navegação precisam funcionar; Compreensível: conteúdo e comportamento precisam ser entendidos; Robusto: a implementação precisa ser interpretável por diferentes agentes e tecnologias assistivas. Os níveis de conformidade são A, AA e AAA. Em muitos projetos, A e AA são usados como meta, mas a definição deve considerar obrigações, políticas e contexto. Conformidade não significa que todas as necessidades humanas foram atendidas. A própria WCAG reconhece que as diretrizes não cobrem integralmente todos os tipos e graus de deficiência. O contexto brasileiro O artigo 63 da Lei Brasileira de Inclusão da Pessoa com Deficiência estabelece a obrigatoriedade de acessibilidade em sites mantidos por empresas com sede ou representação comercial no Brasil e por órgãos de governo, conforme melhores práticas e diretrizes internacionais. Este artigo apresenta orientação técnica, não interpretação jurídica. Obrigações específicas, riscos e contratos devem ser avaliados por profissionais competentes. A acessibilidade, no entanto, não deve ser tratada apenas como reação a uma exigência. Ela afeta a possibilidade real de utilizar um serviço. Antes do design: checklist de planejamento Escopo e responsabilidade [ ] A meta de acessibilidade foi registrada. [ ] A versão de referência da WCAG foi definida. [ ] O nível pretendido foi definido. [ ] Uma pessoa responde pela coordenação. [ ] Conteúdo, design, desenvolvimento e testes possuem responsabilidades. [ ] O orçamento inclui testes e correções. [ ] Componentes de terceiros serão avaliados. [ ] Exceções terão justificativa e plano de correção. [ ] O processo prevê manutenção após a publicação. Público e tarefas [ ] As tarefas principais foram identificadas. [ ] Pessoas com deficiência podem participar da pesquisa ou validação quando possível. [ ] O projeto considera teclado, leitor de tela, ampliação e comando por voz. [ ] Os fluxos críticos foram priorizados. [ ] Conteúdos urgentes ou essenciais receberam atenção adicional. Acessibilidade não pode depender exclusivamente de uma pessoa “especialista” no final. Cada papel precisa produzir entregas compatíveis. Conteúdo: clareza também é acessibilidade Títulos Use uma hierarquia que represente a estrutura, não apenas o tamanho visual. Evite selecionar níveis apenas pela aparência. O CSS deve cuidar da apresentação. A estrutura de página do W3C mostra como títulos e regiões ajudam pessoas a navegar e identificar partes importantes. Links Texto insuficiente: Texto contextual: Uma lista de links deve continuar compreensível fora do parágrafo. Imagens Pergunte qual função a imagem exerce. Informativa Decorativa Funcional Não use o alt para repetir legendas ou descrever detalhes irrelevantes. Imagens complexas podem exigir descrição no texto. Checklist de conteúdo [ ] Cada página possui título claro. [ ] Os títulos formam estrutura lógica. [ ] Links descrevem destino ou ação. [ ] Imagens informativas possuem alternativa adequada. [ ] Imagens decorativas usam alternativa vazia. [ ] Vídeos possuem legendas quando aplicável. [ ] Áudio importante possui alternativa. [ ] Instruções não dependem apenas de posição, forma ou cor. [ ] Abreviações e jargões são explicados. [ ] Linguagem é compatível com o público. [ ] Conteúdo possui responsável e data de revisão. Design: desenhe todos os estados Uma tela estática costuma mostrar apenas o estado ideal. A interface real também possui: foco; hover; pressionado; selecionado; desabilitado; carregando; vazio; erro; sucesso; aviso; conteúdo longo; zoom; contraste forçado. Cor Não use apenas cor para indicar estado. Insuficiente: Melhor: Foco O indicador de foco precisa ser visível. Não remova outline sem substituição adequada. A cor e a espessura precisam ser avaliadas no contexto visual. Movimento Animações devem ter propósito e respeitar preferências de movimento reduzido. Essa regra ampla pode ter efeitos colaterais. É preferível revisar os componentes e remover movimentos não essenciais conscientemente. Checklist de design [ ] Contraste de texto foi medido. [ ] Contraste de componentes e estados foi avaliado. [ ] Foco é visível. [ ] Estados não dependem somente de cor. [ ] Alvos de interação possuem tamanho e espaçamento utilizáveis. [ ] Conteúdo funciona com zoom. [ ] Layout aceita texto maior e mais longo. [ ] Não há informação essencial apenas em hover. [ ] Movimento possui alternativa reduzida. [ ] Formulários exibem rótulos e instruções. [ ] Erros foram desenhados. [ ] Estados de carregamento e vazio foram desenhados. O artigo sobre design responsivo além do celular aprofunda zoom, reflow e entrada. Desenvolvimento: comece pelo HTML nativo A orientação atual do W3C para uso de ARIA mantém um princípio fundamental: quando existe elemento HTML nativo com semântica e comportamento necessários, ele deve ser preferido. Use: em vez de: O segundo exemplo exige implementação manual de teclado, estados e semântica. Mesmo com role="button" , o div não recebe automaticamente todo o comportamento de um botão. Regiões da página Um link de salto ajuda quem usa teclado: Ordem do foco A sequência deve acompanhar a ordem lógica do documento. Evite valores positivos de tabindex : Eles criam uma ordem artificial difícil de manter. Use tabindex="0" somente quando um elemento realmente precisar entrar na sequência e tabindex=" 1" para foco programático quando apropriado. Componentes dinâmicos Menus, abas, diálogos e comboboxes exigem: papel adequado; nome acessível; estado; comportamento de teclado; foco; anúncio de mudanças. ARIA não corrige um componente incompleto. Ela comunica semântica; o comportamento continua sendo responsabilidade da implementação. Formulários: rótulo, instrução e erro O tutorial de formulários do W3C recomenda rótulos, instruções e feedback adequados, além de observar que formulários simples e curtos tendem a ser preferidos. Rótulo explícito Placeholder não substitui rótulo. Ele desaparece durante a digitação e pode possuir contraste insuficiente. Instrução associada Erro associado Após o envio, preserve valores válidos e leve a pessoa a compreender onde estão os erros. Em formulários longos, um resumo no início pode ajudar. Checklist de formulários [ ] Todo campo possui rótulo. [ ] Campos obrigatórios são identificados. [ ] Formato esperado é informado antes do erro. [ ] Autocomplete é usado quando apropriado. [ ] Agrupamentos possuem fieldset e legend quando necessário. [ ] Erros são textuais e associados. [ ] Valores válidos são preservados. [ ] A ordem de foco é lógica. [ ] O envio funciona por teclado. [ ] Tempo limite possui tratamento quando aplicável. [ ] Autenticação não depende desnecessariamente de tarefa cognitiva. [ ] Mensagens de sucesso são percebidas. Teclado: o teste manual mais produtivo Retire a mão do mouse e percorra a página. Verifique: 1. é possível acessar todos os controles; 2. o foco está visível; 3. a ordem faz sentido; 4. menus podem ser abertos e fechados; 5. não existe armadilha; 6. diálogos gerenciam foco; 7. conteúdo revelado por hover também aparece com foco; 8. ações podem ser executadas; 9. a pessoa consegue retornar ao ponto anterior. O guia de testes manuais do web.dev destaca teclado, avaliação visual e aspectos cognitivos como áreas que ferramentas automatizadas não cobrem integralmente. Automação ajuda, mas não decide sozinha Ferramentas podem detectar: atributos ausentes; determinados problemas de contraste; IDs duplicados; rótulos ausentes; relações ARIA inválidas; estruturas incorretas. Elas não conseguem decidir com segurança: se um alt descreve o que importa; se a ordem de leitura faz sentido; se a mensagem é compreensível; se o fluxo é utilizável; se o foco vai ao lugar correto; se uma tarefa pode ser concluída. Uma estratégia de teste precisa combinar: O web.dev também orienta testes com tecnologias assistivas, incluindo leitores de tela, como continuação dos testes automatizados e manuais. A integração com a estratégia geral é discutida em testes web orientados por risco. Checklist por fase Descoberta [ ] Público e tarefas principais identificados. [ ] Meta de acessibilidade definida. [ ] Obrigações e políticas avaliadas. [ ] Responsáveis nomeados. [ ] Componentes críticos inventariados. Conteúdo [ ] Estrutura de títulos. [ ] Links descritivos. [ ] Alternativas de mídia. [ ] Linguagem compreensível. [ ] Instruções independentes de características sensoriais. Design [ ] Contraste. [ ] Foco. [ ] Estados. [ ] Reflow. [ ] Alvos. [ ] Movimento. [ ] Erros. Desenvolvimento [ ] HTML semântico. [ ] Teclado. [ ] Nomes acessíveis. [ ] Gerenciamento de foco. [ ] ARIA somente quando necessária. [ ] Anúncio de conteúdo dinâmico. [ ] Compatibilidade com zoom. Teste [ ] Automação. [ ] Teclado. [ ] Zoom. [ ] Leitor de tela. [ ] Conteúdo ampliado. [ ] Contraste. [ ] Formulários. [ ] Fluxos críticos. [ ] Navegadores suportados. Operação [ ] Canal de feedback. [ ] Responsável por correções. [ ] Regressões verificadas no CI. [ ] Componentes compartilhados mantidos. [ ] Conteúdo novo revisado. [ ] Auditorias periódicas. [ ] Declarações públicas atualizadas. Critério de aceite para uma página Uma página pode ser considerada pronta para validação quando: possui estrutura semântica; funciona por teclado; mantém foco visível; apresenta conteúdo com zoom; não depende apenas de cor; possui alternativas para conteúdo não textual; apresenta formulários rotulados; comunica erros; passou por testes automatizados; passou por revisão manual; não introduz regressões conhecidas nos fluxos críticos. Esse critério não equivale automaticamente a conformidade WCAG. Ele funciona como barreira mínima no processo. O melhor momento para corrigir Corrigir um rótulo durante a criação do componente custa pouco. Corrigir cinquenta formulários depois que o componente incorreto foi reutilizado custa mais. Corrigir a arquitetura de navegação depois que conteúdo, analytics e integrações dependem dela custa ainda mais. Por isso, acessibilidade precisa aparecer no processo do briefing ao site no ar, e não apenas na auditoria final. A pergunta que deve acompanhar cada entrega é simples: Uma pessoa que não usa a interface da mesma forma que a equipe ainda consegue perceber, compreender e concluir a tarefa? O checklist começa no projeto porque acessibilidade é uma propriedade do produto inteiro, não um recurso que pode ser instalado depois.