WCAG 3.0: An Exciting WCAG Update

WCAG 3.0

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: 

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 in the summer of 2021. WCAG 2.2 will include new success criteria such as accessible authentication, findable help, focus appearance, and pointer target spacing.

We’ve posted free resources to help you learn and apply web accessibility into your workflow.

Access to free resources

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 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. The lower the bounce rate, the longer people are staying on the website. 

On the contrary, a higher bounce rate indicates a poorly constructed site. A website that lacks accessibility would be considered a poorly constructed site. A poorly constructed website includes things like non-responsive design, lack of color contrast, and missing form labels.

Our goal 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 71% of disabled web users will leave a website when it is not accessible. This is a large enough percentage to have a significant impact against the overall bounce rate. Business owners must prioritize web accessibility to avoid 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 find a new developer as it is just undeniable how vital web accessibility for developers is, especially nowadays. Developers aim to create high quality websites and know that the cleaner the code is, the faster their websites will run. If a website’s load time is slow or a website fails to rank high in search results, the development team is responsible. Cleaner code means faster, high quality code. Semantically correct code is cleaner code. Accessible code is semantically correct. This means that code is written according to specifications. HTML elements (code) have semantic meaning. Developers optimize a website’s accessibility and performance by using code as it is intended. 

Aside from having fewer bugs and making a website load faster, semantic code also helps search engines such as Google and Bing to index the content and achieve higher search rankings. For example, let’s say that a web page is about comparing web development platforms such as WordPress and Shopify. The page visually uses headings to organize its content. The code of the page uses paragraph tags with classes (used for targeting styles) to create the visual appearance of headings like this:  

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:

WCAG 2.xWCAG 3.0
Principles (POUR)Removed
GuidelinesGuidelines
Success criteria (Pass or fail statements)Outcome (Score rating)
TechniquesMethods
Non-interference requirementsCritical errors
Conformance levels A, AA, AAABronze, Silver, Gold

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.” 

RatingCriteria
0Less than 60% of all images have appropriate text alternatives or there is a critical error in the process
160% – 69% of all images have appropriate text alternatives and no critical errors in the process
270%-79% of all images have appropriate text alternatives and no critical errors in the process
380%-94% of all images have appropriate text alternatives and no critical errors in the process
495% to 100% of all images have appropriate text alternatives and no critical errors in the process

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.

Avatar for David Gevorkian

By David Gevorkian

David Gevorkian started Be Accessible because of his passion for delivering exceptional customer service. Prior to Be Accessible, he spent much of his early career working for financial institutions in sales, treasury, and product management. David earned his Master’s in Business Administration from Salve Regina University in Newport, Rhode Island. He discovered a common need for web and mobile accessibility during his previous roles, and as a result, he created Be Accessible to make accessibility in reach for any type of business. David is a strong advocate for creating aesthetic and accessible products usable by all people across the world.

Contact Us

Please complete all fields.

Recent Posts

lady shocked at the thought of accessibility overlay

Accessibility Overlays are Not a Web Accessibility Solution

Accessibility overlay companies continue to lie about the ability of their products to provide web accessibility and protect your business against legal complaints. 

Read more about Accessibility Overlays are Not a Web Accessibility Solution
documents for tax credit calculation

IRS Tax Credit to Write Off Web Accessibility Expenses

In an effort to encourage compliance with the Americans with Disabilities Act (ADA) and help provide relief to businesses who encounter web accessibility expenses, the Disabled Access Credit provides up to a $5000 tax credit for expenses related to web accessibility. 

Read more about IRS Tax Credit to Write Off Web Accessibility Expenses
accessibility icons

Who Benefits from Web Accessibility

By designing and developing a website for all users/devices, we create the best inclusive experience possible. We give all users the opportunity to receive and interact with the content of a website.

Read more about Who Benefits from Web Accessibility