Two-Thirds of Europe's Top Sites Fail Basic WCAG 2.1 Accessibility

Widespread Accessibility Failures on European Websites

The European Union is gearing up for the next iteration of its accessibility standard, EN 301 549 V4.1.1, which is slated for citation on November 30, 2026. This update will replace WCAG 2.1 with WCAG 2.2, introducing six new success criteria at Level A and AA. While a niche industry of readiness checklists has emerged, a recent analysis of Europe's most-visited websites reveals a stark reality: a significant majority are not even meeting the current accessibility requirements.

The analysis scanned the most popular websites across EU member states, assessing their compliance with the currently enforced version of EN 301 549. The results indicate that many organizations are far from prepared for the upcoming WCAG 2.2, let alone meeting existing obligations. The deadline people are preparing for is not the one they have missed; the current standard, in force since before the European Accessibility Act deadline passed in June 2025, is already proving too challenging for many.

The most critical failure point is clause 9.4.1.2, "Name, Role, Value." A staggering 64% of the scanned websites fail this Level A criterion. This is not a new or complex requirement; it has been a foundational part of WCAG since 2008, forming the lowest accessibility bar. Its widespread failure suggests a systemic issue in how accessibility is being implemented, or perhaps ignored, across the digital landscape.

The "Name, Role, Value" Failure Explained

The "Name, Role, Value" (NRV) success criterion is fundamental to making web content accessible to users of assistive technologies, particularly screen readers. It mandates that user interface components (like buttons, links, form fields, and custom controls) must have programmatically determinable names, roles, and states/properties. This allows assistive technologies to convey the purpose and current status of these components to the user.

Name: This refers to the accessible name of an element, which is what a screen reader announces to the user. For a button, it might be the text inside it. For an icon button, it should be provided via an `aria-label` or similar mechanism. Without a proper name, a screen reader might announce "button" without any context, leaving the user confused.

Role: This defines the type of user interface element. For standard HTML elements like ``, the role is implicit. However, for custom controls built with generic elements (like `

` or ``), the `role` attribute must be used to convey its purpose (e.g., `role="dialog"`, `role="tab"`). This tells the assistive technology what kind of element it is interacting with.

Value: This applies to elements that have a state that can change, such as form inputs or custom widgets. For a text input, the value is the text the user types. For a checkbox, it's whether it's checked or unchecked. For a slider, it's the current position. This information must be programmatically available.

Failing NRV means that interactive elements on these websites are not properly identified or described to assistive technologies. This can render entire sections of a website unusable for individuals who rely on screen readers, keyboard navigation, or other assistive tools. It's akin to a physical building having doors that don't open, or signs with illegible text. Given that this criterion has been in place for over 15 years, its pervasive failure is a critical oversight.

Beyond NRV: Other Failing Criteria

While "Name, Role, Value" is the most common failure, other significant accessibility gaps exist. The analysis also highlighted failures in other crucial areas:

• 9.1.2.1 Audio and video information (Level A): This criterion requires that information conveyed by audio or video is available in text or can be perceived through other means. For example, captions for videos or transcripts for audio content.
• 9.1.3.1 Information and relationships (Level A): This requires that information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. This includes correctly using headings, lists, and semantic markup.
• 9.4.1.1 Non-text Content (Level A): Previously, this criterion required that all non-text content that is presented to the user has a text alternative that serves the equivalent purpose. This has been updated in WCAG 2.2, but its predecessor was a frequent failure point.

The prevalence of these failures, even on high-traffic sites, suggests that accessibility is often treated as an afterthought rather than an integral part of the design and development process. The upcoming WCAG 2.2, with its new criteria, will only add to the challenge for organizations that have not yet mastered the basics.

Why Are These Sites Still Failing?

Several factors contribute to the persistent accessibility failures. Firstly, a lack of awareness or understanding of accessibility principles among development teams. Accessibility is complex, and without proper training, developers may not know how to implement accessible features correctly. Secondly, the integration of third-party widgets and content management systems that are not inherently accessible. Websites often pull in components that haven't been vetted for accessibility, introducing new barriers.

Thirdly, the pressure to meet tight deadlines for new features or product launches can lead to accessibility being deprioritized. It is often seen as a compliance issue to be addressed later, rather than a core quality attribute. The results of this scan, however, demonstrate that the "later" has passed for many, with the current standard already missed.

Finally, the complexity of modern web development, with its myriad frameworks, libraries, and dynamic content, makes ensuring accessibility a continuous effort. Automated testing tools can catch some issues, but they cannot replace manual testing with assistive technologies and expert review. The gap between the ideal of an accessible web and the reality for many users remains significant.

Implications for WCAG 2.2 Readiness

The findings are a stark warning for organizations preparing for WCAG 2.2. The new criteria in WCAG 2.2, such as "Focus Not Obscured (Minimum) at Level AA" and "Accessible Authentication at Level AA," build upon the foundations of WCAG 2.1. If basic Level A criteria like NRV are failing, it is highly improbable that these organizations will meet the more advanced requirements of WCAG 2.2 without a substantial shift in their approach to digital accessibility.

The European Accessibility Act mandates compliance, and the upcoming citation of EN 301 549 V4.1.1 will bring these requirements into sharper focus. Websites that fail to comply risk legal challenges, reputational damage, and exclusion from a significant portion of their user base. The time for superficial checklists is over; a fundamental commitment to inclusive design and development is required.

The fact that two-thirds of Europe's biggest sites are still failing a 15-year-old Level A accessibility standard is not just a technical failing; it's a barrier to inclusion. It highlights a critical need for better education, more robust development practices, and a cultural shift within organizations to prioritize accessibility from the outset.