Web Accessibility Coverage Report 2025

The World Wide Web Consortium (W3C) developed the widely accepted WCAG to help web designers and developers make web content accessible. WCAG defines success criteria as specific, testable standards that help ensure web content is accessible to people with disabilities. These criteria are categorized based on four principles: 

• Perceivable: This involves making information accessible to users with different senses. For example, adding captions to videos, providing transcripts for audio, using alternative text for images, and using color contrast that’s easy to see.
• Operable: This involves making sure everyone can use a website, including people with disabilities. For example, ensuring a website is navigable via keyboard or voice control.
• Understandable: This includes making sure the content is clear and easy to follow. For instance, you can achieve this by using easy-to-see colors, simple language, clear instructions, and error messages. 
• Robust: Ensuring that web content remains accessible across different technologies, including various browsers, screen readers, and assistive devices. For instance, use ARIA attributes where necessary, and continually test for compatibility across a range of browsers, devices, and assistive technologies.

While most legal compliance for accessibility targets is at the WCAG 2.1 AA level, WCAG has three levels of conformance to address varying levels of accessibility requirements:

• Level A defines the minimum accessibility requirements that must be met.
• Level AA addresses major accessibility barriers for most users.
• Level AAA defines the highest and most complex level of accessibility, addressing specific and advanced needs.

• 1,000 webpages were assessed against the latest standards of Web Content Accessibility Guidelines (WCAG) 2.2, Conformance Level AA. 
• These 1,000 web pages spanned various industries—from travel and leisure to public and social services. It was important to have a wide range of people in our sample so that our results would really show the problems that come up with accessibility in a variety of domains, content types, and user groups, not just in one industry or design pattern.
• Our evaluation was led by a team of accessibility experts and individuals with disabilities, utilizing a combination of assistive technologies, manual audits, and testing tools to conduct comprehensive testing. 
• Alongside the time required for the detection of WCAG conformance issues, we also looked at the frequency at which Success Criteria issues occur. 
• During the study, we also evaluated the time taken to manually test compliance to WCAG 2.2 AA success criteria and compared it with automated coverage offered by the BrowserStack Accessibility testing suite.

The scope of our evaluation was restricted to web content. Apps and PDFs were not included in this evaluation. Additionally, some success criteria were not tested as a part of this research study, as explained below:

• We analyzed individual web pages for a domain rather than entire websites. Due to this, certain Success Criteria (like 3.2.3 Consistent Navigation*, 3.2.4 Consistent Identification*, and 3.2.6 Consistent Help*) that pertained to multiple pages in a website were not applicable. 
• Our sample set did not have login and signup pages, making Success Criterion 3.3.8 (Accessible Authentication) inapplicable. 
• Focus Appearance (Success Criteria 2.4.13) from WCAG 2.2 was often found, but since it is a Level AAA criterion, we didn’t include it in our main analysis.

*Based on a separate detection time analysis for these success criteria.

Below are some insights into how issues are distributed across the top 15 success criteria:

• Poor text-background contrast is a widespread issue, as success criterion 1.4.3 Contrast (Minimum) is the most (18.37%) frequently occurring accessibility violation. 
• Many custom-built UI components lack proper Accessible Rich Internet Applications (ARIA) attributes, as success criterion 4.1.2 Name, Role, Value accounts for a large portion of errors (15.76%)
• Many websites fail to provide adequate keyboard navigation and interaction capabilities for essential functions as success criterion 2.1.1 Keyboard is a prevalent issue (12.13%)
• Many modern websites are responsive, but some still struggle with adaptability at higher resolutions and zoom levels. In this study, we found that success criteria 1.4.10 Reflow (1.23%) and 1.4.4 Resize Text (0.89%) account for ~2% of issues, mainly due to overlooked 200% and 400% zoom considerations. Poor Reflow forces users to scroll both ways, while Resize Text issues prevent users with low vision from enlarging text without breaking the layout. 
• Sequential navigation and logical content flow are still problems on many web pages. This is because developers often get the focus order wrong, which causes 1.68% of problems found under success criteria 1.3.2 Meaningful Sequence and 2.4.3 Focus Order.
• The most common success criterion in the new WCAG 2.2 AA guidelines is 2.5.8 Target Size (Minimum). This implies that interactive elements on webpages are not the appropriate size for individuals who struggle with dexterity.

Among the identified issues, we found that the time required for manual detection is not uniform across all success criteria. 

We noticed that a few success criteria can be evaluated quickly—in seconds or minutes—while others may require hours of effort to assess all states per page. The graph below is a representation of our finding, which indicates that there is a small segment of success criteria that takes exponentially longer to detect manually.

Below are success criteria segmented into three categories based on the time required for their manual detection: 

1. 1. Minimal Time Required: It takes an average of 30 seconds per page for violation detection for success criteria such as:
      1. SC 2.4.2 – Page Titled: This criterion requires ensuring that the webpage has a title describing its topic or purpose. This check can be completed in seconds by glancing at the <title> element.
      2. SC 2.4.4 – Link Purpose: This criterion requires checking if the link text couldn’t describe its purpose. This success criteria only takes seconds to be manually tested.
         
   2. Moderate Time Required: It takes an average of 5-10 minutes per page for violation detection for criteria such as:
      1. SC 1.4.4 – Resize Text: This criterion requires ensuring that text can be resized up to 200% without assistive technology and without loss of content or functionality. Testing involves zooming the page and examining every text element for truncation, layout issues, or missing content. Evaluating this on a single webpage typically takes several minutes.
      2. SC 2.4.7 – Focus Visible: This criterion requires that when users navigate a webpage using a keyboard, the element that currently has focus is visually identifiable. This is critical for users who rely on keyboard navigation, including people with motor impairments, screen reader users, and those using alternative input devices. Manually checking Focus Visible issues requires full page interaction and user flow testing, making it a high-effort task for testers as they need to go through each element individually. Websites with custom styling may have low-contrast or invisible focus indicators, making it harder to verify compliance manually.
         
   3. Significant Time Required: It takes several minutes to an hour per page for violation detection for success criteria such as:
      1. *SC 3.2.4 – Consistent Identification: This criterion ensures that components with the same functionality are consistently identified across multiple pages. For instance, if “Helpdesk” is labeled as “Contact Support” on other pages, it violates this criterion. Manually checking consistency across pages involves detailed note-taking and re-evaluation, which can take many minutes per set of pages. Despite the time investment, manual testing may still fail to identify all inconsistencies due to human error.
      2. *SC 3.2.6: Consistent Help: This criterion ensures that help mechanisms, such as contact support, live chat, FAQs, or help documentation, are consistently located across multiple pages of a website. Since the Consistent Help issue requires multi-page comparisons, contextual understanding, and user experience evaluation, it takes significant time to detect accessibility issues for this criterion manually.

*Based on a separate detection time analysis for these success criteria.

3.1. WCAG 2.2 vs 2.1 vs 2.0 issues 

In the research study based on their frequency of occurrence, we found that WCAG 2.0 criteria account for the highest number of issues, followed by WCAG 2.2 and WCAG 2.1: 

• 93.8% of the accessibility issues pertained to Success Criteria introduced in WCAG 2.0 across 35* criteria
• 3% of issues were attributed to WCAG 2.2, covering 4* success criteria
• 3.2% of the issues pertained to criteria introduced in WCAG 2.1 across 12 criteria

WCAG 2.1 issues span 12 Success Criteria, making them more widespread and less concentrated. In contrast, just 4 WCAG 2.2 success criteria account for 3% of all issues (with success criteria 2.5.8 Target Size being most prominent). A small number of WCAG 2.2 criteria account for a significant share of accessibility issues, underscoring their substantial impact despite being fewer in number.

3.2. Level A vs. Level AA issues:

In the research study, we found that Level A success criteria issues were detected more frequently than Level AA, as shown below:

• ~62% of these issues were Level A issues across 30* Success Criteria
• About 38% of these issues were Level AA spread across 21* Success Criteria

While Level A success criteria issues can be seen as a higher priority for remediation, the gap in detection frequency between Level A and Level AA issues is not high. Therefore, the significant number of Level AA issues reinforces the need for comprehensive testing beyond just the basic requirements.

*Totals after removing inapplicable Success Criteria

Out of 41,947 total issues, approximately 3% of success criteria issues are less frequent and distributed across 40 different success criteria. However, we found that the time required to detect these issues is significantly higher due to their complexity. 

Here are some examples: 

1. 3.2.3 Consistent Navigation*: Ensures that navigational mechanisms that are repeated across a set of web pages must be in the same relative order.
2. 2.4.11 Focus Not Obscured: Ensures that user interface components in focus are not fully obscured by other content.

*Based on a separate detection time analysis for these success criteria.

While addressing the top 15 success criteria issues is crucial for real-world WCAG coverage, it is equally essential to identify, test, and fix less frequent issues to ensure both an accessible end-user experience and legal compliance.

For instance, if consistent navigation (i.e., success criterion 3.2.3 Consistent Navigation) is not ensured across web pages, then users with cognitive disabilities or those who use screen readers would struggle to locate important links or menu items. Even if less frequent, such issues affect usability, making websites harder to navigate and interact with effectively. Such issues can also lead to differently abled users not returning to inaccessible websites, resulting in potential opportunity losses for businesses.

By adopting automated accessibility testing, teams can save thousands of hours that a QA or auditor will spend to manually detect issues. While all 15 top success criteria issues can be automatically detected to some degree, it will be most useful for the following 9 of the top 15 success criteria. This is because manually identifying accessibility issues for these 9 success criteria takes a significant amount of time, as shown below:

Therefore, accessibility testing tools like BrowserStack can enable automated WCAG coverage to quickly identify frequently occurring issues. This saves time, speeds up testing, and reduces costs—ultimately driving significant ROI gains.

Our research study found that 18.37% of all identified issues across 1,000 web pages were related to Success Criterion 1.4.3 (Contrast – Minimum). For such widely occurring issues, precise automated testing can provide significant real-world benefits in terms of usability, cost, and time savings. For instance, the BrowserStack Accessibility Testing Suite can automatically detect 1.4.3 Contrast (Minimum) issues for text with 40% greater accuracy compared to other tools. This is crucial since manual detection takes over five minutes per page, whereas automation ensures both speed and accuracy.

Our research study found that ~3% of all identified issues were less frequent and were spread across 40 success criteria. To deliver an inclusive user experience, it is recommended that businesses test, identify, and fix even the issues of less frequently occurring success criteria such as 3.2.3 Consistent Navigation and 2.4.11 Focus Not Obscured. 

Due to their complexity, these success criteria often go unnoticed, making manual detection challenging without proper training. Automation can help detect such issues with limited manual intervention and ensure adequate legal compliance for a larger number of success criteria.