WCAG 3.0: An Exciting WCAG Update

In today’s digital world, things change fast. New technologies, new ideas, and a never ending desire to make the world a better place provide the inspiration to develop ways to make everything accessible to every person regardless of their abilities.

The web content accessibility guidelines (WCAG) provide guidance for conforming to accessibility standards. As technologies evolve, standards need to evolve. As such, WCAG 3.0 is in development and the first working draft was released in January 2021.

Before jumping right into what we can expect with WCAG 3.0, we feel it’s important to provide a brief explanation on how we got here. If you prefer to skip over the WCAG history lesson, feel free to jump ahead and go straight to the WCAG 3.0 update explanations.

Web acronyms

As if learning accessibility standards isn’t complicated enough, web development jargon is filled with acronyms. To avoid having to define each acronym in our WCAG 3.0 explanation, here is a list of acronyms we’ll use along with their definitions: 

• WWW: World Wide Web
  British computer scientist, Tim Berners-Lee, invented the world wide web in 1989.
• W3C: Word Wide Web Consortium
  The W3C is an international community founded by Tim Berners-Lee. The W3C develops international standards to ensure the long-term growth of the Web.
• AG WG: Accessibility Guidelines Working Group
  The AG WG develops specifications to support making web technologies accessible.
• WAI: Web Accessibility Initiative
  As part of W3C, WAI (“way”) develops standards and educational materials to help developers understand and implement accessibility.
• WCAG: Web Content Accessibility Guidelines
  Recommendation provided by the WAI to create accessible web content. 
• POUR: Perceivable, operable, understandable, robust
  WCAG uses POUR as their guiding principles.

A brief history of WCAG

Web content accessibility guidelines provide a list of success criteria, explanations, techniques, and common failures that we can use to meet WCAG accessibility expectations. The WAI has a dedicated team of developers and accessibility professionals who work through a tested process to recommend, review, and test techniques that we can use to create and maintain accessible websites, mobile apps, and other wearable technology. Once a guideline is provided as a recommendation, it is considered web standard.

WCAG 1.0

WCAG’s first version, 1.0, was introduced as a recommendation in May 1999. WCAG 1.0 included 14 guidelines for creating accessible web content.

WCAG 2.0

In order to address new technologies, techniques, design trends, and mobile accessibility, WCAG 2.0 was published as a recommendation in December 2008. WCAG 2.0 introduced POUR as guiding principles.

WCAG 2.1

WCAG 2.1 became a W3C recommendation in June 2018. At the time of writing this article, WCAG 2.1 is the current recommendation and provides new success criteria to help cover a wider range of accessibility barriers. Thankfully, WCAG 2.1 is backwards compatible and complying with WCAG 2.1 allows you to comply with previous WCAG versions.

In addition to addressing accessibility for web content on desktops, laptops, and tablets, WCAG 2.1 includes success criteria and techniques for improving mobile accessibility.

WCAG 2.2

WCAG 2.2 is expected to be released mid to late 2023. WCAG 2.2 will include new success criteria such as accessible authentication, findable help, focus appearance, and pointer target spacing.

How web accessibility benefits business owners

If you are a business owner, you may be familiar with the term bounce rate. The bounce rate of a website is the version of a metric that measures the rate of how long users stay on a website. Unlike conversion rates that we want to be high, our goal is to have a lower bounce rate. Following the web accessibility guidelines can significantly contribute to reducing this rate. The lower the bounce rate, the better, because it means people are staying on the website longer. This is often adhered to within various web entities and is incorporated within their policies pertaining to user retention.

On the contrary, a higher bounce rate indicates a poorly constructed site version, particularly if it fails to meet web accessibility standards. A website that ignores the importance of accessibility and lacks necessary elements would fit this description perfectly. Elements of a poorly constructed site include things like non-responsive design, lack of color contrast, and missing form labels.

Our primary aim is to keep people on our website longer so that they discover more reasons why they should choose us over our competitors. A study found that a staggering 71% of disabled web users will leave a website version that does not fulfill accessibility requirements. This is a large enough percentage to significantly impact the overall bounce rate. Hence, all business entities must incorporate accessibility requirements into their policies to avoid a potential loss of customers.

How web accessibility benefits developers and Google

If your web developer argues that web accessibility does not benefit them, then it may be time to seek services elsewhere. The value of web accessibility for developers, especially in today’s digital version of the age, is undeniable. Developers take pride in crafting high-quality websites and understand that cleaner code paves the way for a faster and more proficient website. If a website’s load time is slow or it fails to rank high in search results, the development team is usually held accountable. HTML elements (code) have semantic meaning, and web entities optimize their website’s accessibility and performance by using code as intended.

Apart from reducing bugs and enhancing loading speed, semantic code also aids search engines such as Google and Bing in indexing the content, thus facilitating higher search rankings. Let’s imagine a webpage version constructed to compare web development platforms like WordPress and Shopify and how its organization of content using heads and visual elements can increase its potential visibility.

Looking forward to WCAG 3.0 

In an effort to make WCAG more user friendly and understandable to everyone creating digital content, the goal is to provide an easy-to-understand explanation of requirements. WCAG 3.0 is intended to be more flexible in order to address a variety of web content, apps, and tools. This flexibility will also be implemented in a flexible scoring system. 

Additionally, to help with creating perspective, WCAG 3.0 will provide information on accessibility practices that address disabled users’ specific needs. We are excited about this addition as we find our usability labs particularly useful during our WCAG audits.

WCAG 3.0 adds accessibility techniques for addressing auditory media, virtual and augmented reality, web browsers, assistive technology, content management systems, authoring tools, and testing tools.

WCAG 3.0 Structure

A major change planned for this new version of WCAG will be the structure. If you are familiar with previous versions of WCAG such as WCAG 2.1, you will notice an update to the structure of the content.

Here is a side-by-side comparison of the expected change in structure:

Here is an abbreviated visual structure of WCAG 2.x with the structure notes above presented with bold text:

• Principle 1 – Perceivable
  • Guideline 1.1 – Text Alternatives
    • Success Criteria 1.1.1 Non-text Content — Level A
      • Sufficient Techniques
      • Advisory Techniques
      • Failures

We expect WCAG 3.0 to follow a structure similar to this:

• Guideline (includes How Tos): Use sections, headings, and sub-headings to organize your content.
  • Outcome (includes critical errors and outcome rating): Conveys hierarchy with semantic structure
    • Method: Semantic headings (HTML)
      • Description
      • Examples
      • Tests
      • Test Scoring

Success criteria vs. outcomes

In WCAG 2.x, various success criteria are listed for each guideline. For example, Guideline 2.4 – Navigable has success criteria such as bypass blocks, page titled, and focus order. Each success criterion is evaluated and either passes or fails. 

WCAG 3.0 replaces success criteria with outcomes. Outcomes focus on the needs of users. Outcomes are not a pass or fail test. Each outcome will receive a score between 0 (poor) and 4 (excellent). 

The table below is the example W3C WAI provides to show how the scoring may work. This example is for the outcome “Text alternative available.” 

The combined ratings are averaged and will provide a total score that will determine the level of accessibility. 

This new rating technique will be a tremendous benefit to businesses as it will allow a website to meet a level of conformance even though some accessibility barriers are still being addressed. 

Techniques vs. methods

WCAG 3.0 implements methods that provide

1. detailed descriptions on how to meet outcomes,
2. examples of working code, and
3. tests with step-by-step instructions on how to evaluate based on the technology being used.

Methods include information needed for scoring. The results from testing methods will influence the rating of the related outcome.

Non-interference requirements vs. critical errors

WCAG 2.x includes non-interference requirements. This requirement means that if an element is not accessible but the content of the element is offered in an accessible way, then the non-accessible content does not interfere with the accessible content.

WCAG 3.0 introduces critical errors. An example of a critical error would be an image without alternative text. If a website has any critical errors, it does not conform to WCAG 3.0 at any level.

Conformance levels

Instead of using WCAG 2.x’s A, AA, and AAA conformance levels, WCAG 3.0 introduced bronze, silver, and gold. Most businesses and organizations today aim for WCAG 2.1 AA conformance. This conformance will most closely compare to bronze in WCAG 3.0.

Although this may change since we are still referring to a working draft, bronze conformance requires:

• No critical errors
• Total score of 3.5 or higher
• Score of 3.5 or higher in each functional category

Silver and gold levels require assistive technology and usability testing with participants with disabilities. We have first-hand experience with this requirement and are excited to see it included in WCAG 3.0.

We include a usability lab in our web accessibility audit process. The feedback we receive is a great benefit to the businesses and organizations that we serve. Disabled user testing allows a website owner to see the impact of their website’s accessibility on real people. It creates perspective and influences website owners to remove accessibility barriers.

When will WCAG 3.0 be a completed W3C standard?

The Working Group takes developing standards very seriously and uses detailed processes to develop, test, review, and finalize recommendations. After the structure and conformance model is refined, the Group will work on guidelines, outcomes, and support materials. It will be a couple more years before WCAG 3.0 is released as a completed standard and recommendation.