Veja como é um achado da ComplyPages
Os nossos relatórios foram concebidos para ação. Cada achado explica onde o problema aparece, porque importa e o que o seu desenvolvedor ou agência pode fazer a seguir.
Estrutura do relatório
- Resumo executivo
- Fluxo analisado
- Principais riscos de acessibilidade visíveis
- Detalhes de problemas prontos para desenvolvedores
- Fila de correções sugerida
- Lista de verificação de reteste
- Recomendação de monitorização
1. Resumo executivo
Este snapshot de exemplo analisa um percurso de pagamento público e identifica riscos de acessibilidade visíveis que podem afetar a navegação por teclado, a compreensão por leitor de ecrã e o preenchimento de formulários. Não é uma avaliação jurídica nem uma certificação, mas observações práticas para ajudar uma equipa web a priorizar correções num percurso crítico para o cliente.
2. Fluxo analisado
Snapshot de exemplo para
example-store.com
Carrinho → Encomenda → Pagamento
Tipo de fluxo
Checkout de comércio eletrónico
Páginas analisadas
4 páginas públicas
3. Principais riscos de acessibilidade visíveis
- O botão de encomenda não tem nome acessível (alta)
- Um campo obrigatório não está etiquetado programaticamente (média)
- A mensagem de erro não é exposta com clareza após a submissão (média)
4. Detalhes de problemas prontos para desenvolvedores
O botão de encomenda não tem nome acessível
Element: button.checkout-submit
EAA relevance: Preparação EAA — risco de acessibilidade visível no percurso de pagamento público
Passos de reprodução
- Abrir https://example-store.com/checkout com artigos no carrinho
- Inspecionar o botão final com leitor de ecrã ou axe DevTools
- Observar a ausência de nome acessível em button.checkout-submit
Impacto no cliente
Quem usa leitor de ecrã pode não perceber que ação o botão executa.
Impacto no negócio
Se o cliente não identificar a ação final de encomenda, pode ficar impedido de concluir a compra. Nota técnica: O botão é visível, mas o seu nome acessível está ausente ou pouco claro.
Correção sugerida
Acrescentar um texto visível claro ou um nome acessível que descreva a ação.
Exemplo para copiar
Apenas um exemplo — adapte-o ao seu código.
<button class="checkout-submit" aria-label="Confirmar encomenda">
Confirmar encomenda
</button>Critérios de aceitação
- As tecnologias de apoio anunciam o botão como «Confirmar encomenda» ou equivalente
- O botão pode ser alcançado e ativado pelo teclado
Um campo obrigatório não está etiquetado programaticamente
Element: input#customer-email
EAA relevance: Preparação EAA — risco de acessibilidade visível no percurso de pagamento público
Passos de reprodução
- Abrir https://example-store.com/checkout
- Navegar com Tab até ao campo de e-mail
- Confirmar que input#customer-email não tem etiqueta associada na árvore de acessibilidade
Impacto no cliente
Quem usa tecnologias de apoio pode não saber que informação é pedida.
Impacto no negócio
Um preenchimento mais difícil aumenta o abandono da encomenda. Nota técnica: A etiqueta visível não está corretamente ligada ao campo de entrada.
Correção sugerida
Associar a etiqueta ao campo através de uma relação for/id válida ou de um método de etiquetagem acessível equivalente.
Exemplo para copiar
Apenas um exemplo — adapte-o ao seu código.
<label for="customer-email">Endereço de e-mail</label>
<input id="customer-email" type="email" name="email" required />Critérios de aceitação
- A etiqueta do campo é anunciada corretamente pelas tecnologias de apoio
- A obrigatoriedade do campo é clara
A mensagem de erro não é exposta com clareza após a submissão
Element: .field-error
EAA relevance: Preparação EAA — risco de acessibilidade visível no percurso de pagamento público
Passos de reprodução
- Submeter o formulário de encomenda com um e-mail inválido
- Observar que a mensagem de erro visual aparece
- Confirmar que o erro não é anunciado nem está ligado ao campo
Impacto no cliente
Os utilizadores podem não perceber por que não conseguem continuar.
Impacto no negócio
Erros de validação não anunciados impedem a conclusão da encomenda. Nota técnica: A mensagem de erro aparece visualmente, mas pode não ser anunciada nem ligada ao campo em causa.
Correção sugerida
Ligar a mensagem de erro ao campo e garantir que é anunciada quando a validação falha.
Critérios de aceitação
- Os utilizadores identificam qual o campo com erro
- Os utilizadores compreendem o problema e conseguem corrigi-lo sem pistas apenas visuais
5. Fila de correções sugerida
Os problemas são priorizados por gravidade e impacto no cliente. O seu desenvolvedor ou agência trabalha a fila por ordem.
6. Lista de verificação de reteste
- Repetir as verificações de acessibilidade em /checkout após o deployment das correções
- Verificar com leitor de ecrã se o botão de encomenda tem nome acessível
- Confirmar que as etiquetas do formulário estão associadas aos respetivos campos
- Testar se as mensagens de erro são anunciadas quando a validação falha
7. Recomendação de monitorização
Após as primeiras correções, considere a monitorização contínua do percurso de transação para detetar regressões nas etapas de encomenda e pagamento.