Almost Ready! WCAG 2.2 is one small step away from being officially done!

View non-AMP version at deque.com

A new version of the Web Content Accessibility Guidelines (WCAG) is almost ready. WCAG 2.2 should be finalized in August 2023. This is a minor version update. If you are already familiar with WCAG 2.0 and/or 2.1, you probably have a number of questions. And we’ve got up-to-date answers!

• Why isn’t WCAG 2.2 ready yet? What is taking so long? The W3C’s timeline is for WCAG 2.2 to be final August 31, 2023. Why is it still not ready?  Because creating an update to the accessibility standard for the world (even a “minor” version update) is complex and requires research, testing, revisions, and consensus votes.
• Will WCAG 2.2 be backwards compatible with WCAG 2.1 and 2.0?
  • Mostly Yes!
    • WCAG 2.0 and WCAG 2.1 are still valid and very useful standards. WCAG 2.2 will add 9 new requirements to what is already in WCAG 2.1 and WCAG 2.0
    • For the first time, in the history of WCAG:
      • One requirement is planned to be removed
        • 1.1 Parsing is being removed in WCAG 2.2. Why? Because 4.1.1 Parsing was originally adopted to address problems that assistive technology had directly parsing HTML. Assistive technology no longer has any need to directly parse HTML. So parsing problems either no longer exist or are addressed by other criteria. Because this criterion no longer has utility it is being removed.
        • While 4.1.1 will remain in WCAG 2.1 and 2.0, a note will be added to clarify that 4.1.1 automatically passes for anything built with HTML.
          • See the pull request for the new draft note in 4.1.1 Parsing in both WCAG 2.1 and 2.0 :
            • “This Success Criterion should be considered as automatically met for any content using HTML. Modern browsers all have automatic error correction for parsing errors, and issues such as incorrect states or names due to a duplicate ID, or missing roles due to inappropriately nested elements are covered by different Success Criteria. This criterion can therefore be ignored as being redundant. It no longer provides any benefit to people with disabilities in itself and should not be enforced or required for accessibility.”
          • Reminder, until this pull request is fully approved and merged, anything about it could still change.
• Will WCAG 2.2 continue to use the WCAG 2.1 / 2.0 A, AA, and AAA conformance levels? WCAG 2.2 will still use the same A/AA/AAA conformance levels
• Is WCAG 2.2 ready to be used today by the general public? Almost! WCAG 2.2 is so close to final, that there should be no significant changes now. But it isn’t done until it is done.
• Is WCAG 2.2 ready to be explored today by accessibility adventurers? Yes! This is the perfect time for accessibility enthusiasts to get to know the new Success Criteria proposed for WCAG 2.2. Why? You can get a head start on identifying how these new requirements will impact your digital content.
• When will WCAG 2.2 become a legal requirement? Some countries may begin to consider adopting WCAG 2.2 after it becomes a final official recommendation. Remember, WCAG 2.2 is still not final and won’t be final until at least late August 2023. Rest assured that no country is going to make WCAG 2.2 a legal requirement before it is final (and some countries may take years to adopt the latest version of WCAG).
• How many more stages are left before WCAG 2.2 becomes final? There is just one more approval step left. For the nitty gritty details, see the process explanation at the end of this article.

What is WCAG?

The Web Content Accessibility Guidelines (WCAG) have been the standard for digital accessibility the world around for over two decades. Before the end of August 2023, the W3C hopes to publish version 2.2 of WCAG. WCAG 2.2 will add several new success criteria focused on extending requirements for users with low vision, cognitive impairments, and limited fine motor skills.

Meet the Proposed New Success Criteria

The WCAG 2.2 proposal currently has nine new success criteria. The list of new success criteria, as of the Proposed Recommendation version published on July 20, 2023, are:

1. 1. 4.11 Focus Not Obscured (Minimum) (Level AA)
   2. 4.12 Focus Not Obscured (Enhanced) (Level AAA)
   3. 4.13 Focus Appearance (Level AAA)
   4. 5.7 Dragging Movements (Level AA)
   5. 5.8 Target Size (Minimum) (Level AA)
   6. 2.6 Consistent Help (Level A)
   7. 3.7 Redundant Entry (Level A)
   8. 3.8 Accessible Authentication (Minimum) (Level AA)
   9. 3.9 Accessible Authentication (Enhanced) (Level AAA)

Focus Not Obscured

Persona Quote: “Hey, stop hiding my keyboard focus!”

These two success criteria will help sighted users who depend on a keyboard to navigate a web page by making sure the component and its focus indicator aren’t overlapped by other content. For example, sticky headers, cookie popup and non-modal dialogues may cover up the part of the page that has current keyboard focus. The level AA requirement says that at least some of the element with focus is visible. At level AAA all of the component and its focus indicator must be visible.

Focus Appearance

Persona Quote: “Where in the world is my keyboard focused?”

This AAA success criterion will require a clearly visible “focus indicator” that shows the current point of focus of the keyboard. Sighted users who depend on a keyboard to navigate the web page will be able to visually tell where their keyboard focus is. This goes beyond the existing 2.4.7 Focus Visible requirement in that it defines a minimum size of the focus indicator and a minimum contrast of 3:1. It also goes beyond the existing 1.4.11 Non-text Contrast requirement by requiring a minimum size of the focus indicator and a minimum contrast between the focused and unfocused state.

Quick aside:  It is worth noting that at one point, 2.4.13  Focus Appearance was being proposed at Level AA but was marked “at risk” because of concerns from the wider stakeholder community.  At this time 2.4.13 Focus Appearance has been moved to Level AAA.

Dragging Movements

Persona Quote: “Errrrrgh!  I can’t do this drag and drop!  I need another way to do this!!!”

Drag and drop actions require a fairly precise motion and the ability to keep pressure on the mouse button or touch screen without accidentally releasing. This can be challenging for some folks with motor disabilities. That is why this new success criterion requires that drag and drop not be the only way that an action can be achieved using a single pointer (such as a mouse or a finger touch).

Target Size (Minimum)

Persona Quote: “I need buttons big enough so that I can press the right one!”

Activating a small button on a touch screen is a challenge for many people, but especially for people who struggle with fine motor skills in their hands. This is equally true when using the mouse or some other pointer device. This success criterion sets a minimum distance that two interactive elements can be away from each other to reduce the chance of people accidentally activating the wrong element. This new success criterion 2.5.8 Target Size (Minimum) will give us a AA requirement based on 24 CSS pixels. You can also still use the 2.5.5 Target Size (Enhanced) requirement based on 44 CSS pixels, which was added in WCAG 2.1 at level AAA.

Consistent Help

Persona Quote: “Help!  I can’t find how to get help on this web site!”

This success criterion makes it easier for users who need help to be able to find it. This requirement states that when a help feature (such as contact information or a self-help option) is available on multiple pages of a website, it must appear in the same relative place on each of the pages where it appears. This requirement will enable some people with cognitive disabilities to be able to get the help they need to complete their intended task.

Redundant Entry

Persona Quote: “Don’t make me enter don’t make me enter the same info twice the same info twice.”

Some forms require the user to input the same information more than once, for example a shipping and billing address. Completing redundant forms can be straining for some users, especially those with motor disabilities or cognitive disabilities. This success criterion requires that forms either avoid redundant entry or make it easy to reuse data already entered.

Accessible Authentication

Pesona Quote: “I have dyslexia. Typing 2nd factor authentication codes by hand is very hard, sometimes even impossible for me. When I can copy the code sent to my mobile device and paste it (instead of hand typing it), or better yet just tap the code on my mobile device, I can successfully log in!”

Logging into a website or app can be a struggle. People forget their passwords, and transcribing authentication codes sent to your phone into the page can be prone to error. This success criterion requires that authentication must be possible without such cognitive tests, for instance, by allowing users to copy and paste their password from a 3rd party password management tool. This requirement will help people with motor disabilities or cognitive issues including memory, dyslexia, dyscalculia and more.

What’s Next?

The W3C plans to publish the final official version of WCAG 2.2 before the end of August 2023. There is still a final approval vote and process that must be met. The exact timing of when the consensus approval vote will be achieved at the W3C on this important international standard is not easy to predict.

We will let you know when WCAG 2.2 is actually finished and stable as soon as we’re confident about the official release date.

Generally Deque adds support for a new version of WCAG within a month after the new standard hits final RECOMMENDATION status.  But if there are last minute revisions made by the W3C that require system changes, it can take up to a quarter. Internally, Deque has been preparing for WCAG 2.2 for months. We’ve even offered https://dequeuniversity.com/ as an implementation proof that meeting WCAG 2.2 A/AA is really possible. axe-core is one-step ahead, already providing a new WCAG 2.2 rule as of Fall 2022. We also plan to add new rules for WCAG 2.2, in intelligent guided tests in axe DevTools.

*Extra Credit Info for Accessibility Process Geeks

Continue reading if you want to know the nitty gritty details of how a Candidate Recommendation becomes an official/final Recommendation.

Let’s look at all 5 of the major stages and some of the important activities at each of the remaining stages:

1. 1. First Public Working Draft (FPWD) published
      • MUST encourage early and wide review.
   2. Revised Public Working Draft(s) (WD) publish zero or more
      • MAY publish additional drafts based on input.
   3. Candidate Recommendation (CR) formerly known as Last Call Working Draft
      • must document how adequate implementation experience will be demonstrated,
      • must specify the deadline for comments, which must be at least 28 days after publication, and should be longer for complex documents,
      • must show that the specification has received wide review, and
      • may identify features in the document as “at risk”. These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.
   4. YOU ARE HERE! Proposed Recommendation (PR) call for review – A formal request for approval of the technical standard by the W3C Advisory Committee.
      • must be at least 28 days after the publication of the Proposed Recommendation and…
      • must show adequate implementation experience except where an exception is approved by the Director,
      • must show that the document has received wide review,
      • must show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have been formally addressed,
      • must identify any substantive issues raised since the close of the Candidate Recommendation review period by parties other than Advisory Committee representatives acting in their formal AC representative role,
      • may have removed features identified in the Candidate Recommendation document as “at risk” without republishing the specification as a Candidate Recommendation.
   5. W3C Recommendation (REC) published
      • The decision to advance a document to Recommendation is a W3C decision.
      • The standard has reached full maturity. It is a formal Recommendation from the W3C.