A etapa de checkout é para muitas lojas online a parte mais vulnerável do site em termos de acessibilidade. Enquanto as páginas de produtos frequentemente funcionam razoavelmente bem com um leitor de ecrã, o processo bloqueia assim que um cliente tem de pagar: botões sem etiqueta clara, mensagens de erro que não são anunciadas, ou um widget de pagamento de um fornecedor externo que não pode ser utilizado sem rato. Isto não é coincidência. A etapa de checkout contém os elementos mais dinâmicos de todo o site, e os elementos dinâmicos são precisamente onde os leitores de ecrã e a navegação por teclado mais rapidamente se bloqueiam.
Não se trata de um detalhe menor. A etapa de pagamento está sujeita aos mesmos requisitos EN 301 549 que o resto do site, e o utilizador percorre esta etapa precisamente no momento em que realmente quer comprar algo. Um leitor de ecrã que se bloqueia aí exclui um cliente no momento decisivo. Esta é também a razão pela qual na axessia.eu a etapa de checkout é incluída por padrão na análise completa e não apenas na análise rápida gratuita das páginas principais.
Onde dá errado na prática
Os problemas mais comuns são notavelmente recorrentes. Um botão para "próximo passo" ou "pagar agora" que contém apenas um ícone sem texto que um leitor de ecrã possa ler. Uma mensagem de erro num campo de código postal preenchido incorretamente que aparece visualmente, mas não é anunciada porque falta a ligação técnica correta. Um indicador de progresso ("passo 2 de 3") que é visualmente claro mas permanece invisível para um leitor de ecrã. E o próprio fornecedor de pagamentos: widgets iDEAL ou de cartão de crédito de terceiros são frequentemente integrados de forma isolada e têm o seu próprio nível de acessibilidade, sobre o qual uma loja online tem pouco controlo mas continua a ser responsável.
A ordem de foco também é um problema recorrente. Após o envio de um formulário com um erro, a atenção do utilizador deve ser direcionada para a mensagem de erro. Se isto não acontecer, alguém que trabalha com teclado ou leitor de ecrã continua à procura do que correu mal, sem qualquer pista.
Por que uma análise automatizada deteta isto parcialmente
Uma análise automatizada é boa a identificar etiquetas em falta, botões vazios e problemas estruturais no código-fonte. O que uma análise não consegue avaliar bem é o comportamento: uma mensagem de erro é realmente anunciada verbalmente, o foco salta logicamente, e a etapa de pagamento permanece acessível sem rato após o preenchimento dos dados. Isto requer alguém que percorra realmente a etapa com um leitor de ecrã. Este é precisamente o tipo de limitação que é explicitamente nomeada em cada relatório da axessia.eu: uma análise testa alguns dos requisitos, não todos.
Por esta razão, a análise completa não se concentra apenas na página inicial, mas especificamente nas etapas que um cliente realmente percorre, incluindo início de sessão e checkout. Se pretende primeiro uma indicação sem compromissos, pode ver em algumas perguntas onde o seu site se encontra atualmente.
O que isto significa para os requisitos que tem de cumprir
A norma subjacente, EN 301 549, traduz-se na prática em WCAG 2.1 nível AA. Contém requisitos sobre o nome, função e estado de elementos interativos, sobre notificações de estado que devem ser conhecidas sem atenção visual, e sobre informações que não são transmitidas apenas através de cor ou posição. Para a formulação exata e a localização no texto oficial, a EUR-Lex é a fonte apropriada; traduzimos esses requisitos para situações reconhecíveis como a etapa de checkout, mas não fazemos declarações sobre a sua situação específica. Mais contexto sobre como essa tradução é feita pode ler-se em a página que explica de onde vem a nossa informação.
Como testar isto você mesmo ou mandar testar
Um primeiro passo prático é percorrer o próprio passo de pagamento sem usar o rato: apenas com a tecla Tab e Enter. Se não conseguir avançar em algum ponto, é muito provável que um leitor de ecrã também fique bloqueado aí. Um segundo passo é testar com um leitor de ecrã gratuito como o NVDA, e prestar atenção especial ao que é lido em voz alta quando ocorre um erro. Para uma visão completa, incluindo as partes que só surgem com uma análise manual cuidadosa, é necessária uma avaliação mais abrangente; a axessia realiza essa avaliação e documenta as descobertas numa lista de ações priorizada, mas não realiza trabalhos de correção. Isso fica a cargo do seu próprio programador ou fornecedor, muitas vezes exatamente nos pontos que identificamos. Outros tópicos frequentemente colocados sobre este tipo de dificuldades específicas encontram-se reunidos em a base de conhecimentos com tópicos desenvolvidos por situação.
Se deseja saber quanto custa uma avaliação completa do seu passo de pagamento e ambiente de login, isso está apresentado de forma clara em a página com tarifas e o que está incluído.
Quer primeiro ter uma impressão sem compromissos? A quick-scan gratuita da axessia oferece, em poucos minutos, uma visão inicial das suas páginas principais, e a verificação de âmbito mostra se a regulamentação se aplica à sua organização.