An insider look at WCAG 3.0

The First Public Working Draft of W3C Accessibility Guidelines (WCAG) 3.0 is ready for public feedback. When it is complete, it will replace WCAG2 versions, but we expect that WCAG 2 will remain valid even after WCAG 3 is complete. This article is intended to give you a detailed look at WCAG3, highlight new features, and ask the important questions we debated for your feedback. I’m one of the leaders in the Silver project that has been developing this first draft for several years. Here’s the insider look.

WCAG 3.0 is a rough first draft. It will be years before WCAG3 is complete, so don’t worry that you have to meet it next week. It only has 5 guidelines that we selected to demonstrate specific features. Despite that, there is a lot that is changing. This draft is primarily about structure, with the guidelines as examples to illustrate the structural changes. Note the change in name from Web Content Accessibility Guidelines to W3C Accessibility Guidelines. It maintains the well-known acronym of WCAG, but shows our intent to have WCAG3 apply more broadly than just web content.

Throughout this blog article, I have put particular questions that we debated and would like public feedback on. I certainly don’t expect everyone to answer every question. If you see a question that interests or outrages you, please give us feedback. The feedback questions are indented, formatted as code samples and are preceded with “Feedback:”.

For those who would like a less detailed overview:

• WCAG 3 FPWD Published
• WCAG 3 Introduction
• presentation at Bay Area Accessibility Camp with speaker notes.

Thank you to those brave souls who are continuing to read on. Here are the topics covered (no TOC feature in Medium that I could find):

• What to look for overall
• The Requirements
• The Introduction and Structure
• The Guidelines
• Scoring & Point System
• Including ATAG and UAAG
• Conformance (meeting the guidelines)
• Metrics we are testing WCAG3 against

What to look for overall

We wanted to take a fresh look at what was needed in accessibility guidelines. We worked with academic and corporate researchers to identify priorities. We brought together industry leaders in a design sprint to brainstorm new approaches. We spent years proposing, debating, and discarding prototypes until we agreed on this draft. We have lots of questions that we want your feedback on.

We had goals that were difficult to resolve together. On one hand, we want the guidelines to be used in a regulatory environment the way WCAG2 is referenced in laws and regulations around the world. On the other hand, we wanted to make it easier to use, serve more types of disabilities, and better serve the organizations that want to do accessibility — especially the large dynamic sites that millions of people use everyday. These goals were not easy to resolve, but I’m very excited with the approach we have come up with and am eager to see the public feedback.

In our two years of research in partnership with academic and industry researchers, we found that generally, people like the content of WCAG2, but they find it hard to understand and find the information they need. We have a new structure for WCAG3 that will help us move toward developing a content management system that can serve you the advice and guidelines you are looking for without having to wade through hundreds of pages of documentation. We don’t have that yet, but that is where we are going. You can see the prototypes of what we are thinking about in the HowTos and Methods. For this first version, we needed to publish a First Public Working Draft in the W3C template. We hope to show progress toward an easier interface in future drafts.

The Requirements

We want to publish the Requirements for WCAG 3.0 alongside WCAG3 so that you can see what is guiding our thinking and work in developing this first version of WCAG3. Skim the Design Principles section for the goals that are less measurable and the Requirements section for the measurable goals that we must demonstrate that we meet to have an approved and complete W3C Technical Recommendation (the standard).

Feedback: Are there additional Design Principles and Requirements that should be included in the WCAG3 project?

The Introduction and Structure

There is a lot to explain that is new and different that we want to highlight. Perhaps we should reduce these sections in a future version as more people get used to the new structure.

Feedback: Does the Structure section give a useful overview of WCAG3? Are there improvements that would help understand the WCAG3 design?

The Guidelines

There are only 5 guidelines in WCAG3 so far. Each one was selected to demonstrate a feature of the new structure. They are rough. They certainly will change in a future version. Notice that we no longer have Level A, AA, and AAA success criteria. We are using a point scoring system to prioritize the importance of solving accessibility errors.

Alternative Text — This was selected as a baseline. There is little substantive change from WCAG2, except that it is re-written to fit the new structure. In this first draft, it only covers HTML images. Note the new scoring which makes it possible to pass at a high score with 95% of the images having alternative text. See the new “on the process” concept where essential images (like navigation icons) must have alt text to pass, while less important images do not have to be perfect. Alternative text also includes a new Method that applies to authoring tools. This is an example of the way we envision including guidance for both authoring tools and browsers in WCAG3.

Feedback: Does this scoring approach help organizations conform even if their site is not 100% perfect? 
Feedback: Do you think that organizations will interpret that they only need 95% of text alternatives for images and then stop adding alternative text?
Feedback: Are the bands of numbers for the different ratings correct? 
Feedback: Do people with disabilities in particular feel that this approach will meet their needs?

Clear Words — this guideline originally came from a request from the W3C Cognitive Accessibility Task Force for a new success criteria for WCAG 2.1. It couldn’t be included in 2.1 because the kind of testing that would be required didn’t fit in the structure of 2.1. The Clear Words guideline shows how a new type of test can use a rating scale to come up with a single score instead of a 100% true/ false test. We have developed a proof-of-concept tool to partially automate testing of this guideline.

Feedback: Would writers and editors in your organization find this guideline useful in making their writing more accessible? 
Feedback: Could writers and editors in your organization evaluate accessibility using the rating scale?
Feedback: There are a number of exceptions to this guideline. We are interested in feedback where to put that information for ease of use.

Captions — This is an example of using WCAG3 in emerging technologies like virtual reality. Most of the virtual reality guidance didn’t make the cutoff for publishing. There will be more in a future draft. We used Captions as a way to experiment with some of the scoring flexibility. For example, Media that is essential to accomplishing the task that does not have captions is a critical error and automatically fails (a 0 rating). Examples include educational videos, entertainment site previews, or directions for installing a product. Other videos without captions that are not essential to the task such as advertising and promotional videos that are not essential to shopping experience are not automatically failed, but the cumulative lack of captioning reduces the score.

Feedback: The scoring approach potentially allows flexibility by industry application of the media. For example, should educational media organizations have higher requirements for critical errors than advertising 3rd party content? 
Feedback :Should Open Captions (burned in captions) be considered as equivalent to Closed Captions? Closed captions are text that can be customized to meet user needs, for example, a hard of hearing person with low vision (like a lot of aging people). Open captions are burned in and cannot be customized. In this version, we give more points to closed captions than open captions, but we don't fail open captions.
Feedback: Note that the advanced XR outcomes and metadata do not have critical errors. This is a way that best practices can be included so that they are not punitive, but could give extra points for an organization who implements them. These points could potentially raise their score. We are interested in your feedback about this approach.

Structured Content — This was a prototype guideline to illustrate how several different WCAG2 success criteria could be merged, including merging level AA and level AAA success criteria. See how the points increase for including more advanced techniques without requiring the higher level.

Feedback:  We are looking for feedback on using scoring as a way to encourage adoption of AAA success criteria without failures. Do you like the inclusion of broader needs for structured content than simply requiring semantics for screenreader users?

Visual Contrast — This is an exciting development. Visual Contrast merges the existing color contrast level AA and AAA success criteria of WCAG2 and merges them using a new algorithm developed from current vision research. We hope it will give you a much wider color palette while improving the clarity of text for people with low vision. We will be adding non-text contrast in a future draft. There is a proof-of-concept visual contrast testing tool for the new algorithm privately developed by one of the Silver members. You can find a link to the tool in the Method.

Feedback: Would you like to see a percentage score for varying levels of contrast (more than just fail or 100%)?
Feedback: Designers: Does this approach give you more flexibility and solve some of the color contrast palette issues? (Orange, I’m looking at you.)
Feedback: Experts in color or readability: Does the new algorithm provide a more accurate measure of visual contrast in text?

Some general questions about the guidelines that we would like your feedback on:

Feedback: We have changed the informative (not required) information to include more information for beginners and by activity.  Are there usability improvements that would make it easier to use and find information?
Feedback: We are interested in your comments about the structure and the design of the HowTos and Methods.  
Feedback: Does the tab layout of the HowTos and Methods make it easier or harder to find information?  
Feedback: Do people with disabilities find WCAG3 easier or harder to use than WCAG2?

Scoring & Point System

One outcome of the initial research project was that people wanted a more nuanced way of seeing how accessible their site or product was than a simple Pass/Fail. We went through a lot of prototypes before discovering that we needed to customize scoring at the individual guideline level, and then average the outcomes for all the guidelines

Look at the scoring for each guideline and outcome. See how we are adapting WCAG2 material to a more flexible system that gives a good score for good accessibility instead of requiring perfection or you fail. We have a number of different ways to approach scoring different guidelines. We can also prioritize some guidelines over a task (which can span multiple pages or views), which we call “in the process”. This gives us the flexibility to preserve the serious impact of critical accessibility failures, without requiring a difficult-to-achieve perfection.

We are doing this primarily through the concept of critical errors. So far, we have 3 kinds:

1. Errors that wherever they occur are a serious problem: Flashing, keyboard traps, etc. These always fail.
2. Errors “in the process”. For example, a missing alt text in an image in the footer is likely not to be essential to accomplishing a task and will pass, while a missing alt text “in the process” (like a navigation icon) is a critical error and will not pass. We spent a lot of time trying to make sure this isn’t a huge testing burden.
3. Errors that when aggregated within a view or across a process cause failure (example: a large amount of confusing, ambiguous language)

Once you finish the test scoring, your outcome score is ranked on a scale of 0–4. The outcome scores are averaged across all the guidelines for an overall score and a score per disability type.

Feedback: Please share your thoughts on the proposal to change the conformance model to a scoring system that allows for minor accessibility bugs as proposed?

I know this is confusing and will take some time and explanation to work out the details and make it easier to understand. If you are interested in scoring and conformance, we want your feedback. If you are more interested in the accessibility guidance and find this very confusing, skip these feedback questions. Please give us time to work out the details and simplify the scoring.

Feedback: We have a new structure for scoring. We would like feedback and examples of why you would or would not implement it in your organization once WCAG3 is complete. 
Feedback: Processes are included to address two problems:  content that is generally accessible, but may have minor errors or bugs that prevent them from declaring conformance; and  content that may meet WCAG2 success criteria but are still inaccessible to people with disabilities.  Is this approach workable for different types of organizations such as very large, dynamic, or complex, medium sized relying on external accessibility resources, or very small with limited resources? Real world examples of why or why not would be very helpful.  
Feedback: This approach of assigning overall rating scores for each outcome allows the tester some flexibility in assigning scores. It has the advantage of simplicity and allowing a tester to take the context into account beyond the simple percentages. The second option we are exploring is to carry percentages from tests through to a final score. In this case a bronze rating would require a total score of at least 90% and at least 90% within each functional need category. This number would likely shift as we continue testing.  We invite comment on these options as well as suggestions for an alternative solution.

Including ATAG and UAAG

In the Introductory section 1.1 and in the Methods for Text Alternatives (Author Control of Text Alternatives) and Captions (Reflow of captions and other text in context) we demonstrate how we envision including Authoring Tool Accessibility Guidelines (ATAG) 2.0 and User Agent Accessibility Guidelines (UAAG) 2.0 guidance into WCAG3.

Feedback: Do you think providing non-normative guidance to help authoring tools and user agents know how to support WCAG3 in their products is an effective way to approach this important aspect of accessibility?

Conformance (meeting the guidelines)

If your score is high enough in each disability category (like cognitive, vision, hearing, fine motor, etc) then you achieve Bronze level. We expect that Bronze level will be the level recommended for regulations. We plan Silver and Gold levels, but we haven’t done a lot with that yet, pending feedback on what you all think about Bronze level. The idea proposed by industry leaders in our 2018 Design Sprint was to have Silver level include various types of usability testing and user research and Gold level to include elements of Maturity Modeling. Expect more in future versions.

Notice that we no longer have level A, AA, and AAA. We have replaced it with a more flexible point system (see the Scoring & Point System section above) where each guideline has outcomes. The outcomes have scoring formulas that vary by the guideline and outcome. This allows us to include guidelines that couldn’t be measured with the strict true/false success criteria of WCAG3. The approach includes WCAG 2.x AAA success criteria into the guidelines not as requirements but as contributing to the overall score as additional points.

Feedback: Should we even have a Conformance section? One comment we received before publishing stated that insufficient time was spent analyzing whether we should have a Conformance section.  
Feedback: If you think WCAG 2.x AAA SC should be addressed differently, how should they be incorporated?
Feedback: Outcomes are normative. Should guidelines, methods, critical errors, and outcome ratings be normative (required) or informative (supporting information), and why?

We have changed to a site or product model instead of a page model for conforming. We thought this was more consistent with the reality of how people use WCAG2 today. It gives us the ability to expand into providing more guidance for applications, which was another request from the research.

Feedback: Should the conformance model change to a site or product model instead of the page model? Do you have suggestions on better naming?

Metrics we are testing WCAG3 against

We decided early on in the project that we wanted to be research driven and data informed. We don’t want the conformance to just be our good idea. We have already started testing our design both with real world websites and with dummy websites where there are specific errors we can control to test specific aspects of the Scoring and Conformance.

In 2011, W3C Research & Development Working Group held a conference on web accessibility testing metrics where leading academic and industry researchers presented papers. The R&D Working Group published a paper with the conclusions of the conference. We have tried to base our testing procedure on their recommendations. We are testing for validity (of course), but also for reliability, sensitivity, adequacy, and complexity. We have information we can share on the details of this work, but it’s too specialized for a general blog, even this already wonky article! If you are interested in this, we would appreciate your input and (especially) your help.

Members of the project have developed two proof-of-concept tools — one for testing the new visual contrast algorithm, and one for testing for common words, including loading specialized vocabularies. We are interested in feedback from tool developers.

Please contact me at jspellman@spellmanconsulting.com if you would like to contribute to the metrics testing.

Conclusion

Building a new standard is a challenge. This one represents thousands of hours of work and active participation from over 100 people. I’m confident that we will receive a lot of feedback from the people who don’t like what we have done. If you made it to the end of this article (thank you for your interest and patience), please take a few minutes and also let us know what you liked as well as what you think needs to be changed or improved. The “Likes” also make a difference in accessibility standards development. It’s not that we want to be patted on the back and told “nice job”. When the people say “you can’t do it that way” it’s helpful to be able to say: “we received feedback from [x] number of people who thought it is an improvement.”

Your feedback matters and is taken into serious account. To submit feedback, file an issue in the W3C Silver GitHub repository. Please file one issue per discrete comment. If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org (comment archive). The Working Group requests comments on this draft be sent by 26 February 2021.