In January 2021 W3.org released the initial draft for WCAG 3. WCAG, or Web Content Accessibility Guidelines, are the standard that defines what is and is not accessible on the web. This new standard builds on WCAG 2.1, the current standard, but makes many changes. Unlike the change from 2.0 to 2.1 that added new guidelines and clarified others, this proposes major structural changes. Even the name will change from “Web Content Accessibility Guidelines” to “W3C Accessibility Guidelines” under the proposed draft.
The proposed draft largely has significant improvements across the board. However, there are certainly changes that I’m not a fan of, like removing the POUR categories. If you aren’t familiar with the current WCAG 2.0 and 2.1 standards, POUR is the acronym for the top four Principles that organize the guidelines and success criteria found in the standard:
- Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
- Operable – User interface components and navigation must be operable.
- Understandable – Information and the operation of user interface must be understandable.
- Robust – Content must be robust enough that a wide variety of user agents can reliably interpret it, including assistive technologies.
The initial draft is an early proposal and will take years to fully implement, but we at Reaktiv are working hard to stay on top of changes. We strive to assure our clients that they will receive the best in web accessibility for their users.
Here are my top 3 takeaways for WCAG 3 starting with number 3:
3. New Functional Categories Support Documentation
The support documentation will be changing with WCAG 3. The current proposal will rename “Techniques” to “Methods” and “Understanding” to “How-to documents.” In addition to making the documentation purpose clearer, this also improves the documentation specifications, resulting in easier docs to read. At least that is the goal.
In addition to those changes, the support documentation will include a new designation, functional categories, which will be made up of a list of categories identifying the needs of people with disabilities.
Often when explaining the importance of a requirement, I’ll write a story about a person interacting with the page.
Howard worked in the steel factory since he was 16. After a long hard work life, he is looking forward to retirement and spending time with his family. Howard’s first great grandchild will be born soon and he wants to buy a present for the family. Howard has difficulty using a mouse due to years of abusing his hands. He can usually use the keyboard to navigate the internet. Howard finds a site for a local children’s store and picks the perfect gift. Using the keyboard he is able to select the gift, complete checkout, and arrange gift wrapping so the present is ready to go when he picks it up on the way to the baby shower.
This story illustrates the importance of making the site keyboard navigable. The functional categories sounds like a great starting point for creating these stories to help underscore the importance of making the site accessible.
2. Changing Accessibility Conformance Level Naming
Under the current WCAG model, conformance levels are A, AA, and AAA. These are clear for the folks in the industry, but clients are sometimes unsure of the distinction between these levels. To clarify, “A” is the minimum standard, “AA” is what all sites should really strive to achieve, and “AAA” is for the top tier, often with certain requirements.
These standards might require additional criteria and in some cases stricter versions of existing standards.
The new naming is much clearer and uses terms I’ve already been using to describe the purpose: Bronze, Silver, & Gold.
In addition to a change in naming convention, the criteria for each level will be upgraded as well. Therefore, the entry-level Bronze tier will be a bit stricter than the current conformance level, and will actually be closer to the AA criteria instead of A.
Additionally, there are some requirements regarding who is involved with the testing. For example, updates to the Silver and Gold testing may require users with disabilities do some of the testing.
These changes will require significant updates to current training, testing tools, and accessibility industry standards, but should make it much clearer what a conformance level really means.
1. Accessibility Outcome Rating Scale
Under the current model, the rating is pass/fail. There is no sliding scale. If the page being evaluated has 100 images and a single image is missing an appropriate alt tag description, it will fail at least one criteria. This is well and good, but I often find myself explaining that things were done really well and the site is actually very accessible but there are dozens of small fixes that make it look like a huge failure when it isn’t.
Under the WCAG 3 proposal the criteria will receive a rating scale. Here is the example table from the draft proposal:
Ratings for the outcome “Text alternative available”
| Rating | Criteria |
| 0 | Less than 60% of all images have appropriate text alternatives or there is a critical error in the process |
| 1 | 60% – 69% of all images have appropriate text alternatives and no critical errors in the process |
| 2 | 70%-79% of all images have appropriate text alternatives and no critical errors in the process |
| 3 | 80%-94% of all images have appropriate text alternatives and no critical errors in the process |
| 4 | 95% to 100% of all images have appropriate text alternatives and no critical errors in the process |
Under this scale, the example page with 1 out of 100 images without an appropriate text alternative would pass with a rating of 4. As an evaluator I’d make a note of the image that someone should fix, but the report would more accurately reflect the accessibility of the site as a whole.
These scales will also make subjective evaluations more objective by providing measurable goals, and it will allow developers to set improvement goals without feeling they have to fix 100% of the issue in one go. If the evaluation report shows a current rating for a criteria as “0” the developer team could make an initial goal of improving the rating to “1” following remediation steps then continue to improve until they reach the final goal of a fully accessible site.
Wrapping Up
It will take several years before we see a final version of WCAG 3. Seeing these initial improvements offers hope that the web will soon be a more welcoming place for all. It is our responsibility as web developers to make sure we are crafting websites which are inclusive and don’t create barriers or pain points for the people who use them. If you’d like to improve the accessibility of your website, please reach out to see how we at Reaktiv can help.
