Digital

Acessibilidade Digital — Como preparar uma avaliação de acessibilidade digital

Dimensão principal: Acessibilidade Digital. Pergunta respondida: como preparar, planejar e escopar uma avaliação de acessibilidade digital para um site ou aplicação web (foco: definição de propósito, escolha de critérios e amostra, métodos — automatizado, manual e com usuários — e entregáveis). Este texto delimita o foco à etapa preparatória da avaliação (não cobre a correção técnica detalhada).

Redação Hub de Acessibilidade · 2026-09-22

Equipe diversa reunida ao redor de uma mesa em sala iluminada por janela, planejando avaliação de acessibilidade digital: cinco profissionais interagem com laptops, tablet e papéis; uma pessoa em cadeira de rodas participa ativamente; outra usa fone de ouvido (uso de leitor de tela). Tablet mostra o título curto “Checklist de Avaliação de Acessibilidade”. Foco na colaboração, documento e dispositivos, com luz natural e paleta sóbria. — Ilustração gerada por IA

Abertura: objetivo e escopo da pergunta

Pergunta central: como preparar uma avaliação de acessibilidade digital que forneça evidências úteis para priorizar correções e para comunicar conformidade parcial ou total com padrões reconhecidos? Este texto explica quais decisões tomar antes de iniciar a análise técnica, quais normas referenciar, como definir a amostra e que entregáveis produzir. Dimensão principal: acessibilidade digital; escopo delimitado a sites e aplicações web (front-end e conteúdo), excluindo auditorias técnicas de infraestrutura e políticas organizacionais extensas.

Contexto essencial: avaliar acessibilidade digital precisa apoiar-se em padrões reconhecidos (por exemplo WCAG) e em uma metodologia de avaliação que combine varredura automatizada, inspeção manual e testes com usuários, com amostragem clara e relatório documentado. ([w3.org](https://www.w3.org/WAI/standards-guidelines/wcag/))

Passo 1 — Defina propósito, público e critério de conformidade

Antes de qualquer análise, responda: a avaliação servirá para (a) mapear prioridades internas, (b) produzir uma Declaração de Acessibilidade pública, (c) atender obrigação legal (ex.: Lei nº 13.146/2015 no Brasil) ou (d) cumprir contrato/licitação? A finalidade orienta o nível de evidência exigido e a abrangência da amostra. ([planalto.gov.br](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13146.htm))

Escolha o padrão de referência para o teste de conformidade (p.ex. WCAG 2.2 / 2.x, ou WCAG 3 quando aplicável) e o nível de conformidade pretendido (A, AA, AAA). Registre a versão exata do WCAG usada na avaliação. Isso garante clareza na declaração de conformidade. ([w3.org](https://www.w3.org/WAI/standards-guidelines/wcag/))

Passo 2 — Escopo e amostragem (o que será avaliado?)

Delimite o 'alvo' da avaliação: site inteiro, subconjunto de páginas, fluxos críticos (cadastro, compra, acesso a serviços), documentos e componentes reutilizáveis (biblioteca de componentes). Para aplicações, especifique views/funcionalidades. A amostragem deve ser justificada e documentada. ([w3c.github.io](https://w3c.github.io/wai-wcag-em/))

Use a metodologia WCAG-EM para orientar a seleção e justificar o tamanho da amostra e os critérios de seleção (páginas representativas, páginas de maior tráfego, fluxos críticos). A WCAG-EM descreve como determinar, documentar e ajustar a amostra durante a avaliação. ([w3c.github.io](https://w3c.github.io/wai-wcag-em/))

Passo 3 — Equipe, ferramentas e ambiente de teste

Monte uma equipe que combine competências: avaliadores de acessibilidade com experiência WCAG, desenvolvedor (para entendimento do código), especialista em UX e, sempre que possível, pessoas usuárias de tecnologias assistivas. Inclua também um contato responsável pelo produto para validar contextos e fluxos. ([w3c.github.io](https://w3c.github.io/wai-wcag-em/))

Defina ferramentas automáticas (axe, Lighthouse, Deque, WAVE etc.), navegadores e leitores de tela (NVDA, VoiceOver), e dispositivos móveis a serem usados nos testes. Registre versões e configurações; elas influenciam os resultados. Lembre-se: ferramentas automáticas detectam uma parte das falhas — a combinação com inspeção manual é obrigatória. ([w3.org](https://www.w3.org/WAI/standards-guidelines/wcag/))

Passo 4 — Métodos: automatizado, manual e com usuários

Defina um fluxo de avaliação que combine: (1) varredura automática para identificar problemas óbvios; (2) inspeção manual para critérios não automatizáveis (semântica, ordem de foco, descrições adequadas); e (3) testes com usuários reais em um conjunto selecionado de tarefas representativas. A W3C recomenda essa combinação para avaliações robustas. ([w3.org](https://www.w3.org/WAI/standards-guidelines/wcag/))

Para testes com usuários, documente o objetivo (ex.: completar compra, usar busca), critérios de sucesso, perfil dos participantes (incluir pessoas com deficiências relevantes) e protocolos de consentimento. Os resultados qualitativos dos testes com usuários ajudam a priorizar correções de maior impacto. ([w3c.github.io](https://w3c.github.io/wai-wcag-em/))

Passo 5 — Entregáveis: o que o relatório deve conter

Defina os entregáveis antes de iniciar: relatório executivo (risco/impacto e prioridades), relatório técnico detalhado por página/fluxo com referência exata aos critérios WCAG ou requisitos normativos, evidências (prints, gravações, trechos de código), plano de ação com estimativa de esforço e cronograma e uma Declaração de Acessibilidade quando aplicável. Use modelos recomendados pelo W3C como referência de estrutura. ([w3.org](https://www.w3.org/WAI/test-evaluate/report-template/))

Se a avaliação se basear em normas brasileiras (por exemplo ABNT NBR 17225:2025), inclua mapeamento explícito entre itens da norma e achados do relatório — isso facilita a conformidade normativa e a comunicação com auditorias internas ou órgãos reguladores. ([sinallink.com.br](https://sinallink.com.br/wp-content/uploads/2026/02/ABNT-NBR-17225-Acessibilidade-Digital.pdf))

Passo 6 — Cronograma, custo estimado e governança pós-avaliação

Explique o cronograma previsto (ex.: 2 semanas para varredura automatizada e inspeção inicial de 50 páginas; 1–2 semanas para testes com usuários e consolidação). O tempo varia conforme escopo e maturidade do produto. Documente critérios para reavaliações periódicas. ([w3c.github.io](https://w3c.github.io/wai-wcag-em/))

Inclua um plano de governança: quem valida correções (produto e acessibilidade), como priorizar correções (impacto + frequência), e um calendário de acompanhamento para confirmar a resolução das não conformidades. Isso transforma a avaliação em processo contínuo, não evento isolado. ([w3c.github.io](https://w3c.github.io/wai-wcag-em/))

Checklist rápido para iniciar hoje

1) Defina propósito e nível WCAG; 2) escolha escopo (páginas/fluxos); 3) selecione equipe e ferramentas; 4) planeje combinação de métodos (automático + manual + usuários); 5) defina entregáveis (executivo + técnico + plano de ação); 6) agende reavaliação. As referências WCAG, WCAG-EM, guias do governo e normas brasileiras ajudam a justificar técnica e juridicamente as escolhas. ([w3.org](https://www.w3.org/WAI/standards-guidelines/wcag/))

Limites e considerações finais

Este texto aborda apenas a preparação da avaliação. A execução técnica exige detalhamento dos critérios, habilidades de desenvolvimento front-end e validação com usuários reais. Afirmações sobre obrigação legal citam a Lei Brasileira de Inclusão (Lei nº 13.146/2015) como base geral — recomenda-se consultar equipe jurídica quando a avaliação tiver fins de conformidade legal formal. ([planalto.gov.br](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13146.htm))

Se desejar, a Sinal Link oferece serviços de diagnóstico, plano de ação e acompanhamento (serviço de Plano de Acessibilidade) que podem ser integrados ao cronograma da avaliação. Consulte a organização responsável pelo produto para decidir entre avaliação interna ou auditoria externa. ([sinallink.com.br](https://sinallink.com.br/service/plano-acessibilidade/))