O formulário está visível, mas a pessoa não consegue chegar ao botão pelo teclado. A imagem mostra uma informação essencial, mas seu texto alternativo diz apenas “banner”. Problemas assim podem ficar escondidos em uma revisão visual. Para quem cria sites, uma primeira rodada de acessibilidade precisa observar tarefas completas e registrar barreiras. Este roteiro ajuda a encontrar e encaminhar falhas comuns. Ele não substitui uma avaliação abrangente nem permite declarar conformidade integral com as WCAG.
Escolha uma tarefa e prepare um registro de barreiras
Comece pelo caminho mais importante do site: entender um serviço e enviar uma solicitação, por exemplo. Inclua a página inicial, o menu, uma página interna e o formulário. Se existir aviso de cookies, janela de conversa ou outro elemento sobreposto, mantenha-o na avaliação. O visitante encontra a experiência inteira, não apenas os componentes que ficaram bons na demonstração.
As verificações iniciais do W3C cobrem problemas frequentes e deixam claro seu alcance limitado. Uma página pode passar nesses testes e ainda apresentar barreiras. Use o roteiro como etapa de trabalho e encaminhe necessidades de avaliação aprofundada a profissionais com experiência, especialmente quando houver requisitos contratuais específicos.
Considere um exemplo fictício: um estúdio de treinamento oferece oficinas para equipes e usa um formulário de interesse. Na revisão, você encontra menu difícil de operar, campos identificados apenas por textos internos e uma programação publicada como imagem. O objetivo será permitir encontrar a oficina, compreender sua data e iniciar o contato sem depender de uma única forma de interação.
Registre página, tarefa, dispositivo ou tecnologia usada, comportamento observado e efeito sobre a pessoa. “O botão de contato não recebe foco ao navegar com Tab” é mais útil que “melhorar acessibilidade”. Inclua resultado esperado, responsável e reteste. Não coloque dados reais de visitantes nas evidências.
Percorra a página pelo teclado e acompanhe onde está o foco
No computador, deixe o mouse de lado e comece a navegar com o teclado. Use Tab para avançar entre elementos interativos e Shift com Tab para retornar. Observe se é possível reconhecer qual elemento está selecionado. Links, botões e campos precisam ser utilizáveis; textos comuns e títulos não precisam receber uma parada de Tab apenas para serem lidos.
O critério de operação por teclado das WCAG explica a necessidade de acesso às funcionalidades por uma interface de teclado, com as exceções previstas no próprio critério. Para o seu teste inicial, tente realizar a tarefa inteira, incluindo abrir e fechar o menu e enviar o formulário. Encontrar o primeiro botão não basta.
No exemplo da oficina, o menu abre ao passar o mouse, mas não oferece um caminho equivalente pelo teclado. O problema pode estar no componente escolhido, em uma personalização ou no tema. Registre a barreira e procure uma correção compatível com a plataforma. Não tente resolver todo componente adicionando números de ordem de foco arbitrariamente.
Janelas sobrepostas merecem atenção especial. Abra o recurso, percorra seus controles e tente fechá-lo. Verifique se o foco permanece identificável e se a pessoa consegue continuar a tarefa. Se não souber avaliar o comportamento esperado daquele componente, consulte documentação específica ou um especialista. Esconder a janela do teste não resolve o problema que estará no site publicado.
Depois da correção, repita a sequência desde o início. Uma mudança no menu pode afetar todas as páginas. Anote exatamente o cenário conferido e evite afirmar “teclado aprovado em todo o site” quando você testou apenas a página inicial. A cobertura precisa acompanhar a conclusão.
Faça os campos explicarem o que pedem e como corrigir erros
Preencha o formulário sem depender da memória do que estava escrito dentro de cada campo vazio. Se a palavra “E-mail” desaparece assim que você começa a digitar e não existe outra identificação visível, pode ser difícil revisar o preenchimento. Um rótulo persistente ajuda a pessoa a entender a finalidade do controle.
O tutorial do W3C sobre rótulos orienta associar os textos aos controles de forma apropriada. Colocar uma frase perto do campo não garante essa associação para tecnologias assistivas. Se o construtor oferece uma opção de rótulo, confira o resultado gerado; se não oferece o controle necessário, registre a limitação para o fornecedor.
No estúdio fictício, o campo “Empresa” é obrigatório, mas isso só aparece depois de tentar enviar. Uma melhoria é explicar antecipadamente o que é obrigatório e por quê. Aproveite para revisar a necessidade do dado: se profissionais independentes também podem participar, o campo pode exigir outra formulação ou outra regra aprovada pelo negócio.
Teste um envio incompleto e outro com formato inválido. Observe se a mensagem identifica o campo e orienta a correção. “Erro 12” e uma borda vermelha não oferecem a mesma ajuda que uma explicação compreensível. Confira também se as demais informações continuam disponíveis para revisão, conforme o funcionamento contratado.
Uma avaliação com leitor de tela pode revelar problemas que o teste visual não encontrou, mas exige conhecimento para interpretar o resultado. Se você está aprendendo, não apresente uma tentativa breve como auditoria profissional. Combine ferramentas automáticas, testes manuais e avaliação especializada de acordo com o projeto. Guarde uma lista do que foi verificado e do que permanece sem conclusão.
Decida o que cada imagem comunica e confira legibilidade
Texto alternativo depende da função da imagem no contexto. Uma fotografia que explica uma etapa de trabalho precisa transmitir essa informação essencial. Um detalhe puramente decorativo pode exigir alternativa vazia. Uma imagem usada sozinha como link precisa comunicar a ação ou o destino. A árvore de decisão do W3C ajuda a distinguir os casos.
No exemplo, a programação da oficina existe somente em um cartaz. Escrever “Cartaz da oficina” não entrega data, duração e local para quem não acessa a informação visual. Uma solução editorial é colocar os dados relevantes em texto na página e tratar a imagem de acordo com sua função remanescente. A pessoa também poderá selecionar, ampliar e consultar o conteúdo textual com mais facilidade.
Para uma foto de pessoas participando de uma atividade, descreva apenas o que importa e pode ser observado. Não atribua emoções, condições de saúde ou identidades que você não conhece. Evite transformar a alternativa em uma lista de palavras-chave. Ela existe para comunicar a informação da imagem naquele ponto da leitura.
Confira também contraste entre texto e fundo, inclusive em botões e mensagens de erro. O critério de contraste mínimo das WCAG apresenta os parâmetros e exceções. Não avalie apenas pelo gosto ou pelo fato de você conseguir ler no seu monitor. Use uma verificação apropriada para as cores e condições reais.
Se o texto estiver sobre uma fotografia, lembre que o fundo varia. Um trecho legível sobre a área escura pode desaparecer quando a imagem muda ou é recortada no celular. Confira o conteúdo ampliado e os estados dos controles. No exemplo da oficina, mover a data para uma área de fundo estável pode resolver simultaneamente legibilidade e manutenção do conteúdo.
Priorize o que bloqueia o uso e repita a avaliação após mudanças
Organize os achados pelo efeito sobre a tarefa. Não conseguir abrir o menu ou enviar o formulário é uma barreira central. Uma descrição inadequada de imagem pode esconder informação indispensável. A prioridade não depende apenas do tempo da correção nem da nota de uma ferramenta automática.
Para o estúdio, a sequência de trabalho pode começar pelo menu, continuar com rótulos e erros do formulário e depois corrigir a apresentação da programação. Cada item recebe uma forma de verificação. Se a solução depende do fornecedor, registre a solicitação e evite prometer conformidade enquanto o comportamento essencial continua sem solução.
Inclua essas verificações na rotina editorial. Uma página corrigida pode voltar a apresentar problemas quando alguém troca cores, remove rótulos ou publica um cartaz com informação exclusiva. O treinamento do cliente deve mostrar como atualizar conteúdo preservando as decisões que foram tomadas.
Conclua a revisão com um relato honesto: tarefas conferidas, ferramentas e métodos usados, barreiras corrigidas e limitações conhecidas. Uma nota alta não comprova ausência de barreiras, e instalar um recurso adicional não dispensa conferir o site. A melhoria mais útil é aquela que permite a uma pessoa completar uma tarefa que antes estava impedida.
Este registro liga o defeito ao uso e ao reteste. Ele não representa uma avaliação completa de conformidade.
| Barreira no exemplo | Efeito sobre a tarefa | Reteste necessário |
|---|---|---|
| Menu abre só com mouse | Visitante não chega à oficina | Abrir, navegar e fechar pelo teclado |
| Rótulo desaparece no campo | Preenchimento perde contexto | Preencher e revisar com identificação persistente |
| Erro mostrado só por cor | Correção fica sem explicação | Errar, localizar instrução e reenviar |
| Data apenas no cartaz | Informação depende da imagem | Encontrar data em texto na página |
Ao descrever o problema, registre também a sequência que o produziu. Um menu pode funcionar quando aberto pela primeira vez e prender o foco depois que uma janela de conversa aparece. Teste as combinações relevantes para a tarefa, sem tentar cobrir todas as permutações possíveis. Se uma pessoa encontra uma barreira que você não reproduz, peça contexto suficiente e preserve o relato; não descarte a dificuldade apenas por diferença de ambiente. O objetivo do registro é permitir investigação e correção, não provar que a experiência do avaliador foi a única válida.
