O dia 28 de junho de 2025 marcou a entrada em vigor do European Accessibility Act (diretiva UE 2019/882) para a maioria dos produtos e serviços de e-commerce vendidos a consumidores europeus. Um ano depois, o diagnóstico de terreno é límpido: a maioria das lojas PrestaShop a operar em Portugal não está conforme, e a maioria dos comerciantes ainda o ignora.
O tema não é só ético. É agora um risco jurídico, comercial (perda de contratos públicos, B2B sensível) e de reputação. Este artigo faz o ponto sobre o quadro legal real, as sanções aplicáveis e a folha de rota técnica para pôr uma loja PrestaShop 8 ou 9 em conformidade sem refundir o tema.
O quadro legal que se aplica a uma loja PrestaShop em 2026
O EAA foi transposto para o direito português pelo Decreto-Lei n.º 82/2022. O perímetro é largo: qualquer serviço de comércio eletrónico destinado a consumidores europeus está abrangido, incluindo o site, a aplicação móvel, o processo de compra e a comunicação pós-venda.
Duas isenções estruturantes:
- As microempresas no sentido europeu (menos de 10 trabalhadores E volume de negócios ou balanço inferior a 2 milhões de euros) estão isentas para os seus serviços. Atenção: o limiar aprecia-se ao nível do grupo.
- Os conteúdos de terceiros não controlados (comentários de utilizadores em bruto, por exemplo) não estão no perímetro, mas o comerciante continua responsável pela estrutura que acolhe esses conteúdos.
A norma técnica de referência na Europa é a EN 301 549, que se alinha com as WCAG 2.1 nível AA. Na prática, a norma internacional que guia o trabalho no dia a dia é a WCAG 2.2, publicada em outubro de 2023, que acrescenta nove critérios de sucesso, nomeadamente o foco visível (2.4.11), os alvos de ponteiro suficientemente grandes (2.5.8) e a persistência dos elementos de ajuda (3.2.6). Uma loja conforme WCAG 2.2 AA cumpre a EN 301 549.
As sanções aplicáveis em Portugal
A fiscalização está repartida entre a ASAE e as autoridades setoriais, consoante o serviço em causa. Um ano depois da entrada em vigor, o quadro é o seguinte:
- Fase pedagógica maioritária: as primeiras ações de 2025 desembocaram sobretudo em notificações e compromissos de correção, com poucas coimas firmes.
- Endurecimento progressivo em 2026: as autoridades europeias anunciaram uma intensificação das fiscalizações, e as primeiras coimas começam a ser aplicadas nos Estados-membros, escalonadas segundo a dimensão do operador e a gravidade (ausência total de declaração de acessibilidade, em particular).
- O teto legal é elevado: no regime das contraordenações económicas, as infrações muito graves podem custar várias dezenas de milhares de euros às grandes empresas, com agravamento em caso de reincidência.
- Risco indireto provavelmente superior: exclusão dos contratos públicos, recusa de referenciação por centrais de compras B2B, sinalizações de clientes nos comparadores.
A obrigação visível mais sistematicamente controlada é a declaração de acessibilidade, que deve estar publicada no site, datada, e indicar o nível de conformidade atingido (totalmente, parcialmente ou não conforme), bem como um plano de correção. Uma loja sem esta página é imediatamente localizada.
A auditoria de terreno: o que falha de facto no PrestaShop
Com base nas auditorias que fazemos em temas Classic, Hummingbird, Warehouse e temas à medida, as não conformidades recorrentes concentram-se em seis famílias:
1. Contraste insuficiente (critério WCAG 1.4.3 / 1.4.11)
O cinzento claro sobre fundo branco usado nos preços riscados, nas menções «IVA incluído» ou nos ícones de confiança falha quase sistematicamente o rácio 4,5:1 (texto normal) ou 3:1 (texto grande e interfaces). Uma passagem de auditoria com o Lighthouse ou o axe-core devolve em geral 15 a 40 defeitos de contraste numa página de produto normal.
2. Navegação por teclado partida
O menu pendente do topo, os filtros de facetas à esquerda, o seletor de quantidade à medida, o popup de newsletter: todos estes componentes são frequentemente inacessíveis só com o teclado (Tab, Enter, Espaço). O foco visível desaparece em metade dos temas premium. É um critério bloqueante.
3. Formulário de checkout mal etiquetado
Campo sem atributo label associado, indicação de erro só pela cor (vermelho), sem atributo aria-describedby para as restrições («8 caracteres no mínimo»), resumo inacessível ao leitor de ecrã. O checkout numa página nativo do PrestaShop 8 progrediu, mas fica por completar, sobretudo assim que se acrescenta um módulo de pagamento ou um seletor de morada de terceiros.
4. Imagens sem texto alternativo estruturado
O velho problema: todas as imagens de produto têm um atributo alt vazio ou repetido (nome do produto copiado). A lógica correta: alt vazio nas imagens puramente decorativas (alt=””), alt descritivo e diferenciado nas vistas secundárias («vista de trás», «pormenor da costura»). O PrestaShop não o faz automaticamente; cabe ao comerciante introduzi-lo na importação do catálogo.
5. Vídeos e carrosséis automáticos
Carrossel da página inicial que roda sozinho sem botão de pausa, vídeo de produto em reprodução automática: violação direta do critério 2.2.2 (pausar, parar, ocultar). E, tecnicamente, num visitante com perturbação vestibular, o deslocamento automático pode provocar mal-estar.
6. Captcha bloqueante e popups intrusivos
reCAPTCHA v2 «assinale a caixa» sem alternativa para os utilizadores de leitores de ecrã, popup de newsletter sem armadilha de foco, janela de cookies impossível de fechar com o teclado. Três clássicos que qualquer auditoria da ASAE deteta em poucos minutos.
Folha de rota de conformidade, sem refundir o tema
Boa notícia: a maioria das lojas consegue atingir uma conformidade substancial WCAG 2.2 AA em 4 a 8 semanas de trabalho dirigido, sem refundição completa. Esta é a sequência que funciona:
Semana 1: auditoria quantificada
Lançar uma auditoria automatizada (axe DevTools, WAVE, Lighthouse) em 10 páginas representativas: página inicial, categoria, página de produto, carrinho, etapa de entrega, etapa de pagamento, confirmação, blogue, contacto, declaração legal. Duplicar com um teste manual só com teclado e um teste com leitor de ecrã (NVDA, gratuito em Windows, VoiceOver em Mac). Produzir uma matriz «critério / página / gravidade» com pontuações.
Semanas 2 e 3: correções de superfície com forte impacto
- Revisão da paleta de cores para atingir os rácios de contraste; muitas vezes basta ajustar uma variável CSS, ou duas ou três.
- Acréscimo de um foco visível global e legível (contorno de 2 píxeis com cor contrastante).
- Revisão dos textos alt no catálogo: regra automatizável por script SQL ou por um módulo de correções WCAG automáticas.
- Remoção das reproduções automáticas e acréscimo de um controlo de pausa no carrossel.
Semanas 4 e 5: componentes críticos
- Refundição do menu principal com gestão completa por teclado (Tab, Enter, Esc, setas).
- Etiquetagem ARIA correta dos filtros de facetas, do seletor de quantidade, das notificações do carrinho.
- Revisão dos formulários: labels associados, indicações de erro em texto E em cor, foco no primeiro campo com erro.
Semanas 6 e 7: conformidade editorial e declaração
- Auditoria das páginas CMS e dos artigos de blogue (estrutura de títulos, alt das imagens).
- Redação e publicação da declaração de acessibilidade conforme ao modelo oficial (estado de conformidade, derrogações justificadas, retorno do utilizador, via de recurso). Nota prática: os modelos de declaração entregues com a maioria dos módulos não cobrem o português, pelo que a versão portuguesa se redige a partir do modelo europeu.
- Plano plurianual de correção publicado na mesma página.
Semana 8: teste com utilizadores e documentação
Um teste com um utilizador real em situação de deficiência (visual ou motora) continua a ser a única forma de validar que não falhou um critério subtil. É também um argumento em caso de fiscalização: provar uma abordagem de melhoria contínua.
A armadilha dos módulos de terceiros
O ângulo morto principal: os módulos de terceiros acrescentam permanentemente elementos não auditados. Um popup de lista de desejos, um módulo de venda cruzada com carrossel, um widget de avaliações de terceiros: cada acréscimo pode partir a conformidade adquirida. A regra sã: auditar cada módulo novo com o axe-core antes de o implementar, e exigir ao programador uma declaração de compatibilidade WCAG 2.2 AA.
Do lado da DataFirefly, todos os módulos recentes (carrinho lateral, alertas, pesquisa em direto, page builder) são testados com o axe-core e com leitor de ecrã antes da publicação, e a declaração de conformidade técnica é fornecida a pedido aos comerciantes em fiscalização.
Conclusão: o risco já não é teórico
O argumento «ninguém fiscaliza» deixou de ser sustentável um ano depois da entrada em vigor do EAA. As coimas começam a cair, a declaração de acessibilidade tornou-se o mínimo visível, e a pressão B2B intensifica-se (centrais de compras, contratos públicos e grandes contas exigem agora compromissos WCAG nos seus contratos).
O bom ângulo estratégico para um comerciante PrestaShop não é fazer o mínimo cosmético, mas usar a conformidade como uma auditoria de UX geral: a maioria das correções de acessibilidade melhora também a conversão (legibilidade, contraste, navegação por teclado apreciada pelos utilizadores avançados, estrutura semântica melhor para o SEO e o AEO). Um investimento de 4 a 8 semanas que serve vários objetivos. Para cobrir os outros temas regulamentares da página de produto (Omnibus, GPSR, garantia legal, ESPR), a nossa seleção de módulos de conformidade de produto para PrestaShop completa este estaleiro.
Leia também: a checklist GPSR e a diretiva Omnibus e o preço de referência.
