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 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 ignores the importance of accessibility and lacks necessary elements 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:

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.