WCAG 3.0: What you need to know about the future of accessibility standards

As of the writing of this article, WCAG 3.0 is out as a Working Draft. This means AGWG (Accessibility Guidelines Working Group) is satisfied that the draft is ready for public feedback.

Take a look for yourself: WCAG 3.0 Working Draft

WCAG 3.0 isn’t supposed to finalize until 2023. Don’t be surprised if it gets pushed to an even later date, though.

WCAG 2.2 is/was supposed to be finalized in 2021; but it will likely finalize in 2022. The good news is the new standards probably won’t change much between now and the time it does. WCAG 2.2 will be the last iteration of the 2 Series.

Take a look: WCAG 2.2 Working Draft

The WCAG 2 Series, which will end with WCAG 2.2, isn’t going anywhere anytime soon. So, don’t panic.

WCAG 3.0 will not be backwards compatible with the WCAG 2 Series; but the 2 Series will not be deprecated by the 3 Series. Both will be parallel standards.

So, if your content is compliant with WCAG 2.2, then it will not have to be tested against WCAG 3.0 standards (unless you want it to). Compliance with either of the standards will be acceptable.

There are known challenges with how the WCAG 2 Series was written. While AGWG has attempted to address some of those challenges in WCAG 2.1 and 2.2, it’s clear the standards need an overhaul.

Changes in Technology

WGAC 2.0 finalized in 2008. That’s just one year after Apple released the original iPhone. Obviously, technology has made great leaps since then, which includes web technologies as well as assistive technologies.

WCAG 3.0 hopes to account for those changes in technology, especially with mobile and wearable devices; they’re even getting into virtual and augmented reality.

In fact, AGWG has decided WCAG no longer stands for “Web Content Accessibility Guidelines”. It now stands for “W3C Accessibility Guidelines”. This change reflects the expanding scope of accessibility standards to more than just web content.

Inclusion of More Disability Groups

AGWG recognizes a wider variety of user needs and our responsibility as the publishers of technology content to accommodate them.

Part of this goes with the changes in technology. For example, there weren’t the myriad of virtual assistant options in 2008 as there are now, such as Siri and Alexa.

AGWG has identified more than 50 categories of functional needs according to Jeanne Spellman, co-leader of the task force responsible for WCAG 3.0:

According to the Editor’s Draft of the WCAG 3.0 Explainer, these Functional Categories include (more will likely be added):

• Vision and Visual
• Hearing and Auditory
• Sensory Intersections
• Mobility
• Motor
• Physical and Sensory Intersections
• Speech
• Attention
• Language and Literacy
• Learning
• Memory
• Executive
• Mental Health
• Cognitive and Sensory Intersections

Readability

The WCAG 2 Series is not the easiest to understand. Since stakeholders include people from many different professions with varying levels of technical knowledge, the language for WCAG 3.0 will be easier to understand and communicate.

Change Frequency

Once WCAG 3.0 is finalized AGWG plans on having more frequent updates. They have adopted an Agile approach to the standards. AGWG recognizes it’s far more difficult to future-proof the standards, especially with scope of the content going beyond the web.

Categorization of Standards

The Success Criteria from the WCAG 2 Series will be called Outcomes in WCAG 3.0. Guidelines are the generic, non-technical summary statements about the standard to be met.

Take a look at these two criteria from WCAG 2.2:

Success Criterion 2.4.6 Headings and Labels:
Headings and labels describe topic or purpose.

Success Criterion 2.4.10 Section Headings:
Section headings are used to organize the content.

For WCAG 3.0, these two will be merged into a single standard, with the Label criteria from 2.4.6 moving to its own standard. Now the “Heading” Outcome (as of the writing of this article) looks like this:

Structured Content
Guideline: Use sections, headings, and sub-headings to organize content
Outcome: Headings organize content — Organizes content into logical blocks with headings relevant to the subsequent content. This makes it easier to locate and navigate information more quickly.

The consolidation of the headings and sections into a single Outcome and moving the labels out is a welcome change because labels are all over the place in WCAG 2.2.

Scoring Based Off Needs and Standards

In the WCAG 2 series, the success criterion’s test was pass or fail. There was no in-between. The Scoring for the 2 Series was A, AA, and AAA. To be compliant, a website had to at least meet AA standards. AAA was considered above and beyond. Few companies even attempted to meet AAA standards because their efforts rarely were rewarded.

In WCAG 3.0, the Scoring is a little more complicated. While the WCAG 2 Series scored only on the standards, WCAG 3.0 also scores based on the Functional Category. So, after the final score is tallied, a company will be able to see how well their content accommodates those with Learning, Speech, and Memory challenges, for example.

This new scoring system acknowledges accessibility isn’t always a pass/fail model. It also helps guide stakeholders away from the erroneous idea that accessibility is just for those using screen readers.

Terms

Before we get into the Scoring system, we need to define some terms. Some of these are new to WCAG 3.0:

• Atomic tests: Accessibility tests as you know them now; for example, tests against the Success Criteria of the WCAG 2 Series or the Outcomes in WCAG 3.0. These can be done manually or automated.
• Holistic tests: Real-world Accessibility tests. These typically occur with assistive technology tools. Think of these as customer acceptance testing with the customer being those that require accommodation. As of the writing of this article, there isn’t much on the process or rating for holistic tests — except that holistic tests will be required to get the higher finals scores.
• Functional categories: I mentioned these earlier in the article. These are groups of disability types; e.g., Vision and Visual, Hearing and Auditory, etc.
• Rating: The grade awarded (0 through 4) for individual Outcomes, functional categories, and the final average grade.
• Conformance: The final accessibility grade. The three conformance levels are Bronze, Silver, and Gold.
• Critical Error: A violation of the most basic accessibility requirement for an individual Outcome. Any critical errors result in a Rating of 0 for the corresponding standard.

Rating Outcomes

There is a Rating for each of the Outcomes from 0 to 4. Zero is a failing score; but each Rating has a threshold.

If there are any Critical Errors for the Outcome, it will receive an automatic Rating of 0.

Here’s an example Outcome from the WCAG 3.0 Working Draft:

Text alternatives
Guideline: Provide text alternative for non-text content.
Outcome: Text alternative available — Provides text alternatives for non-text content for user agents and assistive technologies. This allows users who are unable to perceive and / or understand the non-text content to determine its meaning.
Critical Error: Any image of text without an appropriate text alternative needed to complete a process

And here are the possible Ratings:

• Rating 0 (Very Poor): Less than 60% of all images have appropriate text alternatives OR there is a critical error in the process
• Rating 1 (Poor): 60% to 69% of all images have appropriate text alternatives AND no critical errors in the process
• Rating 2 (Fair): 70% to 79% of all images have appropriate text alternatives AND no critical errors in the process
• Rating 3 (Good): 80% to 94% of all images have appropriate text alternatives AND no critical errors in the process
• Rating 4 (Excellent): 95% to 100% of all images have appropriate text alternatives AND no critical errors in the process

The Rating for this Outcome along with all of the others will be averaged, which will represent the final score. This final score is used to determine Conformance.

Rating Functional Categories

Currently, the Rating Functional Categories is a little unclear. Each Outcome has a set of Functional Categories the standard is seeking to address. Since every Outcome receives a Rating and every Outcome has Functional Categories associated with it, my guess is that each Function Category will have a score that is the average of all Outcomes associated with that Functional Category.

For example, if there are 5 Outcomes associated with the “Motor” Functional Category and their scores were 3, 4, 4, 2, and 1, this means the Functional Category of Motor received an overall Rating of 2.8 (14 divided by 5 equals 2.8).

Again, this is my best guess based off the information currently available. AGWG hasn’t demonstrated the specific methodology yet.

Conformance

As stated earlier, the three levels of Conformance are Bronze, Silver, and Gold. Until AGWG updates the WCAG 3.0 Working Draft to include the parameters for holistic testing, we won’t know exactly how products can earn Silver or Gold. According to the draft:

“Bronze is the minimum conformance level. Content that does not meet the requirements of the bronze level does not conform to WCAG 3.0.”

Here’s what’s available from the Working Draft as of the writing of this article:

Bronze:

• The total score and score within each of the functional categories MUST be at least 3.5; and
• Views and processes MUST NOT have critical errors.

Silver:

• All views MUST satisfy the Bronze criteria; and
• Use of holistic tests to meet this level will be further explored in future drafts

Gold:

• All views MUST satisfy the Silver criteria; and
• Use of holistic tests to meet this level will be further explored in future drafts

So, the equivalent of WCAG 2.2’s Level AA is a final score of 3.5 out of 4 AND a score of 3.5 for each of the Functional Categories.

Whatever you do, don’t put off getting your content accessible.

Get Compliant with the WCAG 2 Series

The WCAG 2.1 (and soon 2.2) standards are still the standing recommendations from the W3 Consortium.

If you have kept your content compliant with WCAG 2.1, start to look into the changes for WCAG 2.2. The new criteria for 2.2 will not likely change much between now and the time AGWG finalizes it. Once you’ve met these criteria , making the leap to 3.0 should not be terribly difficult as far as changes to the content.

Keep Checking for Updates

Keep checking the Working Draft for changes. The date is near the top of the page. Be flexible as 3.0 is a lot more fluid than 2.2.

Hire Members of Various Disability Groups

You should seek out those who use assistive technology or require accommodations as part of a disability group. Hire them to test your content and/or hire them to create and maintain your content. As AGWG updates the Working Draft to explain how holistic testing will work, you can have the personnel and tools in place to implement right away.

Make Accessibility a Priority

I would say “this goes without saying”; but it still has to be said. There’s a difference between a company that says “Take this thing we built and make it compliant!” and one where accessibility is woven into the process from start to finish. Promote a work culture for the latter.

Also, foster a friendly working relationship between the builders of the content (usually developers) and accessibility testers. Hire developers/architects who take accessibility seriously and who challenge themselves to learn and teach best practices.

Plan to Make the Switch

WCAG 3.0 looks like it will be a more superior standard set than its predecessors. The language will be clearer, the scoring will be fairer, and the results will be far more informative with respect to the improvements needed and how well you accommodate the various disability groups.

Make sure, as the document is further refined, your team isn’t caught by surprise. Let them know it’s coming and how it will be different.

Be Very Skeptical of Third-Party Libraries and UI Frameworks

This is a bit out of scope for this article; but if it is at all within your power, keep your dependence on third-party JavaScript libraries to a minimum. Native HTML is your friend, not just from an accessibility standpoint.

For the most part, the people behind many of these libraries and frameworks are focused on “eye candy”, not accessibility. It’s easy to be tempted; I get it. Don’t trust them when they say their controls are accessible.