A mudança estrutural mais subestimada de 2024 no desenvolvimento web diz respeito à camada normativa: WCAG 2.2 e o European Accessibility Act redefinem as restrições de desenvolvimento front-end. As exigências técnicas que pesam sobre as equipes de design evoluíram mais em um ano do que as tendências visuais normalmente divulgadas pela mídia.
WCAG 2.2: os novos critérios que mudam o desenvolvimento de interfaces
A recomendação WCAG 2.2, publicada pelo W3C em outubro de 2023 e atualizada em dezembro de 2024, adiciona critérios que a versão 2.1 não cobria. Três deles têm um impacto direto nas escolhas de design de interfaces.
O critério sobre o tamanho mínimo das áreas táteis impõe a revisão dos componentes de interação em dispositivos móveis. Os botões, links e controles de formulário devem oferecer uma superfície de clique suficiente, o que coloca em questão as interfaces sobrecarregadas onde os elementos clicáveis estão muito próximos uns dos outros.
O critério sobre alternativas ao arrastar e soltar obriga a fornecer um mecanismo de substituição para cada interação baseada no arrasto. Interfaces do tipo kanban, editores visuais e configuradores de produtos estão diretamente envolvidos.
O critério de autenticação acessível proíbe condicionar o acesso a um serviço a uma tarefa cognitiva complexa (resolução de quebra-cabeça, memorização) sem oferecer uma alternativa. Encontramos regularmente as notícias do site Le Carolo Geek entre as fontes francófonas que documentam esse tipo de evolução técnica aplicada à web.
A visibilidade do foco, outra adição da WCAG 2.2, impõe um indicador visível em cada elemento interativo durante a navegação pelo teclado. Os frameworks CSS que ocultam o contorno por padrão geram agora uma não conformidade direta.
European Accessibility Act: conformidade obrigatória para o e-commerce a partir de junho de 2025
O European Accessibility Act se tornará aplicável em 28 de junho de 2025 aos produtos e serviços digitais afetados, incluindo sites de comércio eletrônico. Esta diretiva europeia ultrapassa o âmbito do design: cria uma obrigação legal de conformidade para as empresas que vendem online na União Europeia.
Paralelamente, nos Estados Unidos, o departamento de Justiça adotou em abril de 2024 uma regra impondo o referencial WCAG 2.1 nível AA aos sites e aplicativos das administrações locais. A tendência regulatória é, portanto, transatlântica.
Para as equipes de desenvolvimento, a consequência prática é clara:
- Cada componente de interface deve ser auditado de acordo com os critérios WCAG 2.1 AA no mínimo, com uma progressão gradual para WCAG 2.2
- Os percursos de compra (carrinho, formulário de pagamento, criação de conta) devem oferecer alternativas acessíveis em cada etapa que envolva uma interação complexa
- Os conteúdos gerados dinamicamente (recomendações de produtos, chatbots) devem respeitar as mesmas exigências que o conteúdo estático
Recomendamos integrar uma auditoria WCAG no pipeline CI/CD em vez de tratar a acessibilidade como uma correção pós-lançamento.
IA generativa e qualidade do código: o risco de regressão de acessibilidade
A IA generativa acelera a produção de código front-end, mas introduz um problema concreto em termos de acessibilidade. Uma pesquisa com 88 desenvolvedores, citada pela Zylyn, mostra que o código gerado por IA apresenta um risco concreto de regressão em matéria de acessibilidade.
O problema é estrutural. Os modelos de linguagem produzem código funcional, mas frequentemente omitem os atributos ARIA, os papéis semânticos e os rótulos associados aos controles de formulário. Um desenvolvedor que aceita o código sugerido sem verificação introduz não conformidades invisíveis aos olhos, mas detectáveis por um leitor de tela.
Verificações a sistematizar no código gerado por IA
- Presença dos atributos alt em cada imagem, com um texto descritivo pertinente e não genérico
- Uso correto das tags semânticas HTML5 (nav, main, article, aside) em vez de divs aninhadas
- Atributos aria-label e aria-describedby em elementos interativos sem rótulo visível
- Ordem de tabulação lógica verificada manualmente, não apenas via um linter automático
A inteligência artificial acelera a produção, mas a revisão manual do código continua sendo a única garantia de conformidade WCAG. A automação da verificação através de ferramentas como axe-core ou Lighthouse cobre apenas uma parte dos critérios.
Autenticação e experiência do usuário: o que a WCAG 2.2 impõe aos percursos de login
O critério de autenticação acessível da WCAG 2.2 merece um tratamento dedicado porque toca em um ponto de fricção importante dos sites atuais. Os CAPTCHAs visuais, os códigos enviados por SMS para serem copiados em um curto espaço de tempo e os quebra-cabeças de verificação tornam-se obstáculos regulatórios.
As alternativas conformes incluem a autenticação por chave de acesso, o login via um gerenciador de senhas ou o envio de um link mágico. Esses métodos eliminam a carga cognitiva enquanto mantêm um nível de segurança equivalente.
Para os sites de e-commerce sujeitos ao European Accessibility Act, o percurso de login e criação de conta faz parte do escopo auditável. Um CAPTCHA não acessível na página de login é suficiente para criar uma não conformidade em todo o funil de compra.
As equipes que tratam a WCAG 2.2 como uma restrição de arquitetura desde a fase de design front-end reduzem o risco de reestruturação tardia. A conformidade de acessibilidade tornou-se um critério técnico para a produção, assim como a performance ou a segurança.
