Acessibilidade Web e Padrões WCAG

WCAG 2.1 é organizado em torno de quatro princípios, lembrados pelo acrônimo POUR. Perceptível: os usuários devem ser capazes de perceber todas as informações e componentes da UI através de pelo menos um sentido. Requisitos: todas as imagens possuem texto alternativo descritivo; todo o conteúdo de vídeo possui legendas; a cor não é a única forma de transmitir informações (por exemplo, estados de erro usam texto ou ícones além da cor vermelha); o texto mantém contraste de cor suficiente em relação ao seu fundo (proporção de 4.5:1 para texto normal; 3:1 para texto grande na conformidade AA). Operável: toda a funcionalidade deve ser operável apenas pelo teclado (usuários com deficiências motoras que não podem usar um mouse devem ser capazes de navegar, ativar e completar todos os fluxos de trabalho usando Tab, Enter, teclas de seta e Escape). Requisitos: estados de foco são claramente visíveis; sem armadilhas de teclado (o usuário sempre pode sair de qualquer elemento da UI); links para pular navegação para usuários de leitores de tela. Compreensível: a interface deve ser compreensível em sua linguagem, comportamento e tratamento de erros. Requisitos: a linguagem da página é especificada no HTML; campos de formulário possuem rótulos visíveis; mensagens de erro identificam claramente o que deu errado e como corrigir; o comportamento da UI é previsível (sem mudanças inesperadas de contexto no foco). Robusto: o conteúdo deve ser interpretado de forma confiável por tecnologias assistivas. Requisitos: HTML semântico (usar hierarquia de títulos, elementos de marco, papéis ARIA apropriadamente); elementos de formulário possuem rótulos associados; componentes interativos personalizados implementam o padrão ARIA correto.

O teste de acessibilidade requer uma combinação de varredura automatizada e teste manual — ferramentas automatizadas encontram aproximadamente 30–40% dos problemas do WCAG; o teste manual com tecnologias assistivas e pesquisa com usuários com deficiência encontra o restante. Ferramentas de teste automatizado: Axe (extensão de navegador + integração CI — a ferramenta automatizada mais usada e precisa); WAVE (extensão de navegador da WebAIM — boa para anotação visual de problemas); Lighthouse (integrado ao Chrome DevTools — inclui auditoria de acessibilidade). O teste automatizado deve ser executado no pipeline de CI em cada pull request, falhando a build se novas violações de acessibilidade forem introduzidas. Protocolo de teste manual: auditoria de navegação por teclado (navegar por cada fluxo de trabalho usando apenas o teclado — Tab para avançar, Shift+Tab para retroceder, Enter/Espaço para ativar, Escape para fechar). Documentar quaisquer armadilhas ou caminhos quebrados. Teste com leitor de tela: testar com NVDA + Firefox (Windows, gratuito) e VoiceOver + Safari (macOS, integrado). Navegar pelos fluxos de usuário principais e identificar quaisquer elementos que não são anunciados corretamente, têm contexto ausente ou criam confusão. Verificação de contraste de cor: usar uma ferramenta de análise de contraste de cor (ColorContrastChecker, Colour Contrast Analyser app) em todas as combinações de texto/fundo no sistema de design e produto. Teste de usuário com pessoas com deficiência: sessões trimestrais de usabilidade com 2–3 usuários com deficiências relevantes (visual, motora, cognitiva) fornecem os insights qualitativos que as ferramentas automatizadas não conseguem gerar.

Um Voluntary Product Accessibility Template (VPAT) é um documento padronizado — publicado pelo Information Technology Industry Council (ITI) — que descreve como um produto atende a cada critério WCAG 2.1 e aos requisitos da Seção 508 (a lei federal de acessibilidade dos EUA). Equipes de aquisição empresariais e governamentais exigem um VPAT preenchido (formalmente chamado de Accessibility Conformance Report, ACR) como parte da avaliação do fornecedor. Sem um VPAT, muitos negócios nos setores governamental, de saúde, serviços financeiros e educação são automaticamente desqualificados — o equivalente ao questionário de segurança para acessibilidade. Seções do VPAT: para cada critério de sucesso do WCAG, o VPAT registra: Suporta (o produto atende totalmente ao critério); Suporta Parcialmente (o produto atende a alguns, mas não a todos os requisitos, com explicação); Não Suporta (o produto não atende a este critério, com explicação); e Não Aplicável (o critério não se aplica a este tipo de produto). Honestidade e precisão do VPAT: um VPAT que afirma "Suporta" para critérios que o produto não atende é uma responsabilidade legal. O VPAT deve ser preparado com uma combinação de resultados de auditoria de acessibilidade (testes automatizados + manuais) e revisão legal. Product Ops coordena a produção do VPAT — contratando um consultor de acessibilidade externo para a auditoria, a equipe jurídica para revisão e mantendo uma cadência de atualização trimestral à medida que o produto muda (um VPAT com mais de 12 meses sem atualizações é considerado não confiável pelas equipes de aquisição).