Como avaliar uma auditoria de acessibilidade de um site

O que devo avaliar depois de contratar um freelancer para uma auditoria de acessibilidade de um site?

Uma auditoria de acessibilidade de um site é útil quando ajuda a sua equipa a identificar barreiras e a decidir o que fazer a seguir. Um relatório com uma longa lista de problemas pode parecer minucioso, mas pode deixar os programadores sem saber onde ocorre cada problema, quem afeta ou como confirmar que foi resolvido.

Depois de contratar um freelancer, avalie a qualidade das evidências e das decisões que elas permitem tomar — não apenas o número de problemas encontrados. Para perceber como avaliar uma auditoria de acessibilidade de site, verifique se as páginas e tarefas acordadas foram testadas, se a sua equipa consegue reproduzir cada problema e quais continuam por resolver. Assim, terá uma resposta mais fiável à pergunta «o que devo avaliar depois de contratar um freelancer para uma auditoria de acessibilidade de um site?» do que com uma única pontuação ou uma afirmação genérica de conformidade.

1. Defina o que significa «acessível» neste projeto

Uma auditoria de acessibilidade tem limites. Pode abranger cinco páginas importantes, o processo de finalização da compra ou um conjunto de componentes reutilizáveis, em vez de todas as páginas e interações de um site grande. Antes de começar, registe exatamente o que está incluído. Se o freelancer analisar a página de produto e a finalização da compra, mas não a área da conta, o relatório deve deixar essa distinção clara.

Combine as normas ou diretrizes que o freelancer irá seguir e pergunte como se aplicam ao trabalho de que precisa. Por exemplo, mencionar as WCAG não basta: o relatório deve indicar os critérios aplicáveis e explicar o que foi testado. Especifique também as tecnologias de apoio e as configurações de navegação incluídas na auditoria. A combinação exata dependerá do seu público e do projeto; registe a configuração acordada, em vez de presumir que todas as combinações possíveis serão abrangidas.

Indique as tarefas dos utilizadores que a auditoria irá analisar. Podem incluir encontrar informações sobre a política de entregas, enviar um formulário de contacto ou concluir uma compra. Um site pode ter modelos de página aparentemente acessíveis e, ainda assim, impedir alguém de avançar numa determinada etapa — por exemplo, se uma mensagem de validação não for anunciada depois do envio de um formulário.

Mantenha a descrição do âmbito curta e específica. Deve indicar o que foi analisado, o que ficou de fora e o que a auditoria não comprova. Assim, evita-se que a análise de algumas páginas seja confundida com uma garantia sobre o site inteiro.

2. Reúna evidências que possam ser reproduzidas

É muito mais fácil agir com base numa descoberta quando outra pessoa consegue reproduzi-la. Para cada problema relatado, procure o nome da página ou do componente, uma localização precisa e os passos necessários para encontrar a barreira. «O menu é inacessível» é demasiado vago; «prima Tab desde o logótipo até ao botão do menu e, em seguida, prima Enter — o submenu abre-se visualmente, mas o foco permanece no botão» dá ao programador algo concreto para investigar.

O relatório também deve registar o navegador e a tecnologia de apoio relevantes. Se o problema ocorreu numa combinação específica de leitor de ecrã e navegador, a sua equipa precisa desses detalhes para verificar o mesmo comportamento. As evidências do freelancer podem incluir uma gravação curta, uma captura de ecrã ou uma descrição escrita do comportamento esperado e do observado. Uma captura de ecrã, por si só, não explica um problema de foco do teclado; por isso, as evidências devem ser adequadas ao problema.

Para saber como verificar problemas de acessibilidade num site, tente reproduzir algumas das descobertas, por conta própria ou com um programador, antes de aceitar o relatório. Se estiverem dentro do âmbito, escolha um problema relacionado com a utilização do teclado, outro com um formulário e outro com a estrutura da página. Se a sua equipa não conseguir seguir os passos, peça ao freelancer que os esclareça enquanto ainda se lembra bem do contexto da auditoria.

Este registo também será importante depois da auditoria. Quando um programador altera um componente partilhado, os passos originais ajudam a confirmar se a alteração resolveu a barreira identificada ou apenas mudou a forma como ela se manifesta.

3. Compare as descobertas com percursos reais dos utilizadores

Teste as tarefas que as pessoas realmente precisam de realizar, não apenas elementos isolados da interface. Um percurso do utilizador pode revelar uma sequência de pequenos obstáculos: um botão de menu com um nome pouco claro, um formulário que apaga os dados introduzidos após um erro e uma mensagem de confirmação que não é anunciada. Cada problema pode parecer insignificante por si só; em conjunto, podem impedir alguém de concluir uma solicitação.

Percorra alguns dos trajetos prioritários usando apenas o teclado e, em seguida, utilize a tecnologia de apoio relevante, se estiver incluída no âmbito acordado. Num formulário de contacto, verifique se consegue aceder a todos os campos, compreender quais são obrigatórios, identificar os erros, corrigi-los e confirmar o envio. Registe exatamente em que ponto o percurso falha e se existe uma alternativa. Uma alternativa é uma evidência útil, mas não elimina a barreira.

Inclua também o resultado da tarefa na sua análise. O utilizador conseguiu encontrar a informação pretendida? Conseguiu enviar o formulário sem ajuda? Conseguiu perceber se a compra foi concluída? Estas perguntas relacionam as descobertas técnicas com a finalidade da página, sem dar a entender que uma auditoria breve representa a experiência de todos os utilizadores.

Se o seu site combinar trabalho de acessibilidade com outros projetos freelance, deixe claras as responsabilidades. Um programador pode implementar uma correção e o freelancer verificá-la; combine quem irá registar o resultado antes do início do trabalho. No 24freelance.pro, pode consultar o perfil de IT IT IT IT IT IT como ponto de partida para conversar sobre os requisitos técnicos do projeto.

4. Avalie se a sua equipa consegue utilizar as descobertas

Cada descoberta deve explicar a barreira, as pessoas ou interações afetadas, onde ocorre e por que motivo o freelancer lhe atribuiu determinado nível de gravidade. A explicação deve ajudar a sua equipa a definir prioridades, sem tratar o nível de gravidade como algo autoexplicativo. Por exemplo, um bloqueio de teclado durante a finalização da compra tem consequências diferentes de uma inconsistência nos níveis dos títulos numa página pouco visitada.

Ao rever o que deve incluir um relatório de acessibilidade web, procure também uma recomendação prática. Um relatório útil pode sugerir que o programador exponha o rótulo visível como nome acessível do controlo e indicar como voltar a testar o resultado. A recomendação deve ser suficientemente específica para orientar a investigação, sem impor uma alteração ao código que talvez não seja adequada à estrutura do seu site.

Tenha cautela se os resultados de ferramentas de verificação automática forem apresentados como se fossem a própria auditoria. As ferramentas automáticas conseguem identificar determinados padrões, mas não determinam se uma tarefa pode ser concluída com o teclado ou se as instruções fazem sentido no contexto. Pergunte quais das descobertas foram analisadas por uma pessoa e como o freelancer verificou o comportamento do ponto de vista do utilizador.

Descobertas vagas geram trocas de mensagens desnecessárias. Se um pedido de trabalho disser apenas «corrigir o contraste», pergunte que texto ou componente está em causa, o que foi observado e que evidências sustentam a recomendação. Uma descrição clara evita que o programador tenha de adivinhar e permite à sua equipa verificar a alteração mais tarde.

5. Avalie as correções pela resolução verificada, não pelo estado do pedido

Um pedido de trabalho marcado como «concluído» não prova que um problema de acessibilidade tenha sido resolvido. Para cada correção acordada, registe se a alteração foi implementada e testada novamente com os passos originais para reproduzir o problema. Depois, confirme se resolveu a barreira original sem criar outra.

Por exemplo, um programador pode fazer com que um menu personalizado responda ao teclado, mas deixar o foco numa posição inesperada quando o menu fecha. Uma verificação visual rápida pode dar a impressão de que o problema original foi resolvido, embora o percurso continue a falhar para quem utiliza o teclado. Voltar a testar toda a interação — e não apenas a linha de código alterada — pode revelar essa diferença.

Mantenha dois estados simples no seu sistema de acompanhamento: correções verificadas e itens a aguardar revisão. Registe quem voltou a testar a alteração e que evidências ou passos foram utilizados. Se a verificação for responsabilidade do freelancer, deixe isso explícito; se a sua equipa interna for repetir os testes, designe uma pessoa responsável para que a verificação não se perca na passagem do trabalho entre equipas.

Não agrupe uma correção com uma reformulação sem relação com ela, a menos que continue a ser possível identificar o que mudou. Quando várias alterações são lançadas em conjunto, uma breve nota que associe cada problema à versão ou ao componente relevante facilita verificações futuras.

6. Acompanhe as exceções e os riscos que permanecem

Alguns problemas podem ficar por resolver porque uma funcionalidade está a ser reconstruída, há uma ferramenta de terceiros envolvida ou a equipa não dispõe de uma alternativa adequada. Registe cada exceção, indicando a pessoa responsável, o motivo, uma solução temporária e a data de revisão. «À espera do fornecedor» não é um registo completo se ninguém for responsável pelo acompanhamento.

O conteúdo de terceiros merece um registo próprio e claro. Se uma ferramenta de reservas incorporada impedir a navegação pelo teclado, indique onde aparece e o que os utilizadores podem fazer em alternativa, caso exista uma opção realmente viável. O freelancer pode não controlar o código desse fornecedor, mas a barreira continua a afetar os visitantes do seu site.

Distinga entre «não testado», «não corrigido» e «fora do âmbito deste trabalho». Estas expressões significam coisas diferentes. Se uma página ficou fora da auditoria, não a registe como aprovada; se uma descoberta foi adiada, não a encerre apenas porque a sua equipa não consegue fazer a alteração hoje.

Reveja as exceções numa data específica ou numa etapa definida do projeto. Uma solução temporária pode ficar desatualizada quando um formulário, fornecedor ou esquema de página muda. Atribuir uma pessoa responsável e uma data de revisão lembra à equipa que deve verificar se o risco restante se alterou.

7. Conclusão: avalie a auditoria pela sua capacidade de apoiar decisões mais seguras

Uma auditoria de acessibilidade útil deixa a sua equipa com evidências que consegue reproduzir, descobertas em que pode agir e uma descrição clara do que continua por testar ou resolver. Não deve sugerir que uma análise limitada prova que o site inteiro é acessível. O que importa, na prática, é saber se a auditoria ajuda a decidir o que corrigir, como verificar a correção e quem ficará responsável pelos problemas restantes.

Antes de aceitar o trabalho, confirme se o âmbito corresponde ao acordado, experimente reproduzir alguns dos problemas e verifique se os itens adiados têm pessoas responsáveis e datas de revisão. Estas verificações demoram menos do que reabrir um relatório vago meses depois, quando a pessoa que realizou a auditoria talvez já não se lembre de como o problema se manifestava.