The most underestimated structural change of 2024 in web development concerns the normative layer: WCAG 2.2 and the European Accessibility Act redefine front-end development constraints. The technical requirements placed on design teams have evolved more in one year than the visual trends typically reported by the media.
WCAG 2.2: the new criteria that change interface development
The WCAG 2.2 recommendation, published by W3C in October 2023 and updated in December 2024, adds criteria that version 2.1 did not cover. Three of them have a direct impact on interface design choices.
The criterion on the minimum size of touch areas requires a review of interaction components on mobile. Buttons, links, and form controls must provide a sufficient click area, which challenges overloaded interfaces where clickable elements are too close to each other.
The criterion on alternatives to drag-and-drop requires providing a replacement mechanism for each drag-based interaction. Kanban-style interfaces, visual editors, and product configurators are directly affected.
The accessible authentication criterion prohibits conditioning access to a service on a complex cognitive task (puzzle solving, memorization) without offering an alternative. We regularly find news from the site Le Carolo Geek among the French-speaking sources documenting this type of technical evolution applied to the web.
The visibility of focus, another addition of WCAG 2.2, requires a visible indicator on each interactive element during keyboard navigation. CSS frameworks that hide the outline by default now generate a direct non-compliance.
European Accessibility Act: mandatory compliance for e-commerce starting June 2025
The European Accessibility Act becomes applicable on June 28, 2025 to the relevant digital products and services, including online shopping sites. This European directive goes beyond design: it creates a legal obligation for compliance for businesses selling online in the European Union.
Meanwhile, in the United States, the Department of Justice adopted a rule in April 2024 imposing the WCAG 2.1 level AA standard on local government websites and applications. The regulatory trend is therefore transatlantic.
For development teams, the practical consequence is clear:
- Each interface component must be audited according to the WCAG 2.1 AA criteria at a minimum, with a gradual transition to WCAG 2.2
- Shopping journeys (cart, payment form, account creation) must offer accessible alternatives at each step involving a complex interaction
- Dynamically generated content (product recommendations, chatbots) must meet the same requirements as static content
We recommend integrating a WCAG audit into the CI/CD pipeline rather than treating accessibility as a post-launch fix.
Generative AI and code quality: the risk of accessibility regression
Generative AI accelerates front-end code production, but it introduces a concrete problem regarding accessibility. A survey of 88 developers, cited by Zylyn, shows that AI-generated code presents a real risk of regression in terms of accessibility.
The problem is structural. Language models produce functional code but frequently omit ARIA attributes, semantic roles, and labels associated with form controls. A developer who accepts the suggested code without verification introduces invisible non-compliances detectable by a screen reader.
Checks to systematize on AI-generated code
- Presence of alt attributes on every image, with relevant and non-generic descriptive text
- Correct use of HTML5 semantic tags (nav, main, article, aside) instead of nested divs
- aria-label and aria-describedby attributes on interactive elements without a visible label
- Logical tab order manually verified, not just via an automatic linter
Artificial intelligence accelerates production, but manual code review remains the only guarantee of WCAG compliance. Automation of checks via tools like axe-core or Lighthouse only covers part of the criteria.
Authentication and user experience: what WCAG 2.2 imposes on login journeys
The accessible authentication criterion of WCAG 2.2 deserves dedicated treatment because it touches on a major friction point of current websites. Visual CAPTCHAs, codes sent via SMS to be copied within a short time, and verification puzzles are becoming regulatory obstacles.
Compliant alternatives include passkey authentication, login via a password manager, or sending a magic link. These methods remove cognitive load while maintaining an equivalent level of security.
For e-commerce sites subject to the European Accessibility Act, the login and account creation journey is part of the auditable scope. An inaccessible CAPTCHA on the login page is enough to create non-compliance across the entire purchase funnel.
Teams that treat WCAG 2.2 as an architectural constraint from the front-end design phase reduce the risk of late redesign. Accessibility compliance has become a technical criterion for production, on par with performance or security.
