Abstract

With the enforcement of the European Accessibility Act (EAA), digital accessibility has shifted for many companies from just a recommendation to a necessity. This article provides an overview of the current state of web accessibility grounded in Web Content Accessibility Guidelines (WCAG) 2.1 and 2.2, the gold standard for the EAA. The article lists the core principles and conformance levels, examines the limitations of current testing methodologies, and identifies weaknesses. Specifically, it addresses the reliance on human evaluation and the related expert problem due to automated tools’ inability to detect more than 20 to 50 percent of violations. The article also reviews modern implementation strategies, such as integrating testing engines like Axe-Core into CI/CD pipelines, and addresses the lack of inherent accessibility support in modern front-end frameworks. Finally, the paper offers an outlook on the evolving WCAG 3.0 standard and explores the transformative potential of AI and large language models (LLMs) in assisting developers and improving assistive technologies.

1. Introduction

The topic of accessibility in modern web technologies is more relevant than ever. With the European Accessibility Act (EAA) already in effect, many companies must take action [4]. The goal is for every company with more than ten employees and a turnover of over two million euros to comply with these rules. This ensures that the web is accessible to everyone. However, there are many challenges to implementing web accessibility after a website or web app has been developed; it can be very costly and time-consuming to do so. To address these challenges, this article analyzes the current landscape of web accessibility under WCAG 2.2, specifically identifying weaknesses in testing methodologies and the reliance on human evaluation. Furthermore, it outlines future advancements by exploring the flexible WCAG 3.0 standard and the transformative potential of AI and Large Language Models in development.

2. Web Accessibility Definition

As stated by Petrie, Savva, and Power (2015), accessibility on the web is a set of rules that, when followed, ensures that all people, particularly those with disabilities and the elderly, can use websites in a variety of contexts, including mainstream and assistive technologies [7].

2.1 WCAG

A cornerstone in the realm of accessibility are the Web Content Accessibility Guidelines (WCAG). Developed by the World Wide Web Consortium (W3C), these guidelines provide a standardized procedure for creating accessible internet offerings.

Over the years, the standards have been reworked several times. The current standard required by the EU in the EAA is WCAG 2.1 [8]. For uniformity purposes, this article focuses on the more current WCAG 2.2. This standard relies on four base principles that are summarized by the acronym “POUR” and contain the following points:

• Perceivable: The information and user interface components must be presented to users in a way that they can perceive.
• Operable: The user must be able to handle the user interface components and the navigation.
• Understandable: The information and the handling of the user interface must be understandable.
• Robust: The content must be robust enough that it can be reliably interpreted by a wide variety of user agents, including assistive technologies.[8]

2.2 The WCAG 2.2 Guidelines in Detail

To fully grasp the topic and its inherent challenges, it is essential to understand the core principles. To ensure a positive experience for every user, evaluations should use specific Success Criteria. This creates a repeatable test to verify that a product conforms to WCAG rules [13]. The key criteria for each principle are as follows:

2.2.1 Perceivable

• Text Alternatives: Requires providing text alternatives for any non-text content (such as images, icons, or input elements) so that it can be transformed into other forms people need, such as large print, Braille, speech, or symbols.
• Time-based Media: Requires providing alternatives for time-based media. This includes providing captions, audio descriptions, and potentially sign language interpretation.
• Adaptable: Content must be created in a way that allows it to be presented in different formats without losing information or structure. This can be achieved with different layout options, for example. Ensuring that the information and structure can be programmatically determined by assistive technology is key.
• Distinguishable: This ensures that it is possible for every user to distinguish the different elements of a digital product from others. That could be achieved by a good contrast ratio, providing the controls attribute for audio elements, and enabling users to change the size of displayed text.

2.2.2 Operable

• Keyboard Accessible: All functionality must be available from a keyboard interface. Providing universal keyboard input is crucial because no other input form offers the same flexibility or is universally supported by people with different disabilities.
• Enough Time: Users must be provided enough time to read and use content, since many users with disabilities require more time to respond, read, or use assistive technology. This can be a problem with automatically disappearing popups or toast messages.
• Seizures and Physical Reactions: Content must be designed to avoid causing seizures or physical reactions, primarily by restricting flashing visual content.
• Navigable: Users must have ways to help them navigate, find content, and determine where they are. This includes ensuring logical focus order, clearly defined headings and labels, and the ability to bypass blocks of repeated content. A good test for this would be trying to navigate a webpage with just the tab key.
• Input Modalities: This requires making the functionality operable through various inputs beyond the keyboard, such as touch, a stylus, or a mouse pointer. This includes providing alternatives for complex pointer gestures, such as drag-and-drop, and ensuring that target sizes are large enough for touch input.

2.2.3 Understandable

• Readable: This aims to ensure that text can be read by screen readers and other assistive technologies.
• Predictable: This guideline focuses on achieving a consistent, repeatable way to interact with webpages.
• Input Assistance: Must help users avoid and correct mistakes. Since people with disabilities may have more difficulty creating or detecting input errors, this guideline requires effective error identification, providing instructions and labels, and error prevention features, particularly for legal or financial transactions. Logical error messages and suggestive labels are a good way to start.

2.2.4 Robust

• Compatible: Due to the rapid changes in modern technology, developers of assistive technologies are struggling to keep up. Thus, the primary focus of this guideline is maximizing compatibility with current and future user agents.
• Technical Compliance: Robustness means ensuring content adheres to conventions so that assistive technologies can reliably recognize and interact with elements.[15]

3. Compliance via WCAG 2.2

Compliance via Web Content Accessibility Guidelines is determined by satisfying its success criteria, which were explained previously [12].

3.1 Conformance Level

To achieve full compliance, the content must meet five conformance requirements. It is possible to conform at different levels and in different categories. However, to fulfill each level, all associated rules must be applied.

• Level A: Contains, for example, all necessary labels and tags that can be associated with the HTML code. No conformance to WCAG is possible without at least satisfying all the Level A success criteria.
• Level AA: The content must satisfy all the Level A and Level AA success criteria. This is the industry standard and the minimum requirement for a WCAG-compliant webpage. It also meets the standards of the EAA because they are based on WCAG Level AA [4].
• Level AAA: All content must satisfy the Level A, Level AA, and Level AAA success criteria. One example of a required service is providing sign language interpretation for all videos and audio content.

For any of these levels, conformance can alternatively be achieved if a conforming alternate version is provided [12].

3.2 Testing Procedures

While accessibility testing is frequently conducted manually through human inspection [1], standardized automated tools also play a valuable role. However, human evaluation remains the best practice, as automation alone is often insufficient. Although automated tests offer significant advantages regarding scalability and integration into the development lifecycle, they frequently fail to detect crucial compliance issues [14]. Consequently, directives such as the European Accessibility Act explicitly require human involvement for validation [3].

4. Challenges in the Current Guidelines

The current Web Content Accessibility Guidelines pose several significant challenges related to their objective testability, consistent implementation, and overall scope.

The fundamental issue with the reliability of the WCAG 2.0 guidelines is its review and testing process. Although the process is partially automated, it still relies heavily on human judgment [1].

The current rules define reliable human testing as when 80 percent of evaluators agree on a website’s compliance. However, empirical studies have shown that approximately 50 percent of WCAG 2.0 success criteria fail to reach this threshold, even when evaluated by accessibility experts. Another issue is the high level of expertise needed to assess conformity [1].

Another significant challenge in passing some tests is the binary approach of WCAG 2.0. Evaluators can only give a pass or fail for each level of conformance [10].

5. The Future Standard: WCAG 3.0

To address these issues, the W3C began developing a new standard called WCAG 3.0. Although it has not yet been released, the first working draft was published in September 2025. The finished guidelines are expected to be released in a few years [5].

5.1 Shift in Philosophy

The new standard aims to move away from rigid rule sets and the traditional “pass/fail” paradigm. Instead, it focuses on a user-centered approach that prioritizes core functionality and the specific needs of individuals using assistive technology. Additionally, the guidelines are intended to support a wider range of disabilities by providing more personalized and adaptable experiences. This flexibility helps it remain relevant as technology evolves over time [11].

Moreover, the standard is designed to regulate not only web applications but also software in general, including smartphone apps and desktop programs. The guidelines cover accessibility across a variety of hardware, ranging from desktops, laptops, and tablets to wearables and Internet of Things (IoT) devices. They also apply to diverse content types, such as static, dynamic, interactive, and streaming media, as well as virtual and augmented reality [11].

WCAG 3.0 intends to build on the current foundations and incorporate accessibility overlays. These overlays can make websites more accessible without redoing previous work, thereby simplifying implementation [10]. However, it is important to acknowledge that this technological approach under the current WCAG 2.2 faces significant criticism within the community. Many experts argue that it does not replace the necessity of intrinsic accessible design [6].

5.2 New Scoring System

The new conformance model will fundamentally change how things are evaluated, building upon similar requirements to the current norm. Since the ruleset and evaluation criteria are still being developed, only a few details are known about how it will work.

The proposed model for WCAG 3.0 conformance is based on three main components:

• Foundational Requirements: These constitute the most basic level of conformance.
• Supplemental Requirements: These are used, alongside Assertions, to define and meet higher levels of conformance.
• Assertions: These are defined as a formal claim of fact, attributed to a person or organization, regarding documented procedures practiced in the development and maintenance of the content or product to improve accessibility.

The main differences and similarities can be seen in Table 1.

Table 1: Comparison of Conformance: WCAG 2.2 vs. WCAG 3.0

Feature	WCAG 2.0/2.2	WCAG 3.0 Draft
Structure	Fixed system based on hierarchical levels: A, AA, and AAA. Conformance requires satisfying all success criteria at the chosen level.	Flexible structure based on three components: Foundational Requirements, Supplemental Requirements, and Assertions.
Minimum Conformance	Level A is the minimum conformance level.	The minimum level requires meeting all Foundational Requirements (which is basically Level A conformance).
Equivalence of Levels	Fixed criteria where Level AA builds upon all criteria from Level A.	The minimum foundational level of conformance in WCAG 3.0 is expected to be somewhat comparable to WCAG 2.2 Level AA.
Scoring Mechanism	Determined by meeting a fixed list of success criteria; no fractional score or points system.	Higher levels of conformance are being explored based on a system utilizing points, percentages, or predefined sets of requirements (modules).
Evaluation Focus	Focused on testable technical success criteria (functional testing), though usability testing is recommended in addition to functional testing.	Incorporates explicit concepts like Assertions which focus on formal claims about development and maintenance procedures that improve accessibility.

Sources: [5, 10, 12]

6. State-of-the-Art Implementation

6.1 Modern Tooling and CI/CD

To ensure inclusivity from the beginning, the best practice is to include automated tests in CI/CD processes. These approaches can identify common issues early on, provide continuous feedback, and are easily scalable [9].

Ci-Accessibility stated that there are many accessibility tools available and suitable for integration into automated testing frameworks:

• Deque Systems’ Axe-Core CLI: This open-source accessibility testing engine is designed to work across modern web techniques and supports WCAG 2.0, 2.1, and 2.2 levels A, AA, and AAA. Axe was found to be among the easiest tools to integrate into a CI/CD workflow, such as using GitHub Actions. It provides good descriptions, precise locations for errors, and links to further documentation, making it highly valuable.
• Squiz Labs’ HTML_CodeSniffer: This tool checks HTML documents for accessibility violations based on rule-sets encompassing the three conformance levels of WCAG 2.2. It can be integrated into a CI pipeline, although it may require additional configuration and coding compared to tools like Axe.
• IBM’s Equal Access Accessibility Checker: This tool consists of open-source components that validate web code against accessibility concerns, complying with WCAG 2.2 levels A and AA. Along with Axe, it was noted as one of the easiest tools to integrate into a CI/CD pipeline.

A comparative study on integrating tools into a GitHub Actions CI/CD workflow found that Axe demonstrated the best overall performance in detecting WCAG violations among the tools tested [9].

All of these options can also be used on the client side to provide easy verification of finished products or to support human evaluations. Despite the advancements in tool integration, automated accessibility tools have significant limitations, underscoring why human expertise, as discussed before, remains critical to comprehensive success. Automated tools can only detect a fraction of Web Accessibility guideline violations. A study found that selected open-source evaluation tools detected, on average, approximately 20 percent of all errors present on a given web page. This falls within the expected range, as accessibility experts note that only 20 percent to 50 percent of all accessibility issues can be automatically detected. Automated tools can produce false positives or false negatives, further reducing the accuracy of the results [9].

6.2 Role of Modern Frontend Frameworks

While specialized tools (often integrated as linters or automated testing components) are essential for checking WCAG conformance, modern frontend frameworks themselves currently provide minimal inherent accessibility support during the development process, as shown in the study of Support-Webframeworks. The testing of modern front-end frameworks (Angular, React, and Vue) was an empirical study designed to evaluate the extent to which they support developers with automated accessibility features during the development process. The study focused on creating inaccessible web applications on purpose and observing whether the frameworks generated internal feedback about the violations. Each framework was configured using its default settings at installation. All development was carried out in Visual Studio Code. The study concluded that the three frameworks offered almost no feedback regarding accessibility violations. React was the only framework able to detect an issue, generating a single warning for the WCAG 1.1.1 Non-text Content violation. This violation occurred due to the absence of a label for non-text content.

The current draft of WCAG 3.0 acknowledges this issue and aims to address it through a holistic, technology-agnostic approach [11].

6.3 Role of Artificial Intelligence

In the study of AI, AI coding assistants, such as GitHub Copilot, are being explored for their potential in creating more accessible user interfaces. A prototype Visual Studio Code extension has been introduced that integrates an LLM to help developers identify and resolve accessibility issues. Similarly, the CodeA11y GitHub Copilot Extension has been developed to make AI coding assistants useful for accessible web development. The most frequent use case leverages LLMs to automatically generate high-quality alternative text for complex web images or labels for different actions in the HTML code. AI-based techniques can also significantly reduce the need for manual checks in accessibility testing by integrating seamlessly into automated environments.

AI can also be integrated into assistive technologies and conversational agents to offer new opportunities for improving accessibility. For instance, AI-assisted speech recognition and conversational AI have demonstrated the ability to overcome the limitations of traditional screen readers, thereby increasing the inclusivity of web resources for blind and visually impaired users [2].

7. Conclusion and Outlook

As of now, the current WCAG 2.2 standard has many weaknesses due to rapid changes in modern technologies, but it remains a very important milestone in making the digital world accessible for everyone. The testability of some applications is slowed down or becomes impossible when human evaluators disagree. Additionally, the binary ‘pass or fail’ nature of the criteria stated, often leads to failed tests. The future of digital accessibility lies in the W3C Accessibility Guidelines (WCAG) 3.0. This new approach, which is currently under development, is a significant evolution toward a framework that is more user-centric, flexible, and not dependent on a specific technology. It tries to address issues with the scoring system and enables better support from frontend web frameworks and AI-driven CI/CD tools, to warn developers from non-compliant code. Complementing this evolution, AI coding assistants and LLMs are becoming essential for automating tasks like alt-text generation, while AI-integrated assistive technologies are overcoming screen reader limitations to further enhance inclusivity for visually impaired users.

References

[1] Brajnik, G., Yesilada, Y., & Harper, S. (2010). Testability and validity of WCAG 2.0: the expertise effect. In Proceedings of the 12th international ACM SIGACCESS conference on computers and accessibility (p. 43–50). New York, NY, USA: Association for Computing Machinery. https://doi.org/10.1145/1878803.1878813

[2] Campoverde-Molina, M., & Luján-Mora, S. (2025). Artificial intelligence in web accessibility: A systematic mapping study. Computer Standards & Interfaces, 96, 104055. https://doi.org/10.1016/j.csi.2025.104055

[3] European Commission. (2025). Web accessibility shaping europe’s digital future. Retrieved 2025-12-03, from https://digital-strategy.ec.europa.eu/en/policies/web-accessibility

[4] European Union. (2019). Richtlinie (EU) 2019/882 des europäischen parlaments und des rates vom 17. april 2019 über die barrierefreiheitsanforderungen für produkte und dienstleistungen (Vol. 151). Retrieved 2025-12-03, from http://data.europa.eu/eli/dir/2019/882/oj

[5] Initiative (WAI), W. W. A. (2025). WCAG 3 introduction. Retrieved 2025-12-04, from https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/

[6] Makati, T., Tigwell, G. W., & Shinohara, K. (2024). The promise and pitfalls of web accessibility overlays for blind and low vision users. In Proceedings of the 26th international ACM SIGACCESS conference on computers and accessibility (pp. 1–12). New York, NY, USA: Association for Computing Machinery. https://doi.org/10.1145/3663548.3675650

[7] Petrie, H., Savva, A., & Power, C. (2015). Towards a unified definition of web accessibility. In Proceedings of the 12th international web for all conference (pp. 1–13). Association for Computing Machinery. https://doi.org/10.1145/2745555.2746653

[8] Routledge Open Research. (2022). The EU accessibility act and web. Retrieved 2025-12-03, from https://routledgeopenresearch.org/articles/1-30

[9] Sane, P. (2021). A brief survey of current software engineering practices in continuous integration and automated accessibility testing. In 2021 sixth international conference on wireless communications, signal processing and networking (wispnet) (p. 130-134). https://doi.org/10.1109/WiSPNET51692.2021.9419464

[10] Sikder, A. S. (2023). The evolution of web accessibility guidelines: A comparative analysis of WCAG 2.0 and WCAG 3.0 in ensuring inclusivity on the web. International Journal of Information Science and Technology, 1(1), 170–185. https://doi.org/10.70774/ijist.v1i1.18

[11] W3C. (2025). W3C accessibility guidelines (WCAG) 3.0. Retrieved 2025-12-04, from https://www.w3.org/TR/wcag-3.0/

[12] W3C Web Accessibility Initiative (WAI). (2025a). Understanding conformance. Retrieved 2025-12-03, from https://www.w3.org/WAI/WCAG22/Understanding/conformance

[13] W3C Web Accessibility Initiative (WAI). (2025b). Understanding techniques for WCAG 2.2 success criteria. Retrieved 2025-12-03, from https://www.w3.org/WAI/WCAG22/Understanding/understanding-techniques

[14] W3C Web Accessibility Initiative (WAI). (2025c). Understanding test rules for WCAG 2.2 success criteria. Retrieved 2025-12-03, from https://www.w3.org/WAI/WCAG22/Understanding/understanding-act-rules

[15] W3C Web Accessibility Initiative (WAI). (2025d). Understanding WCAG 2.2. Retrieved 2025-12-03, from https://www.w3.org/WAI/WCAG22/Understanding/