WCAG 2.2 GRAVEYARD (SC 3.2.7)

Before WCAG 2.2 was finalized, I wrote articles on a few of the upcoming changes. Among them, was an article on Success Criterion 3.2.7: Visible Controls.

I didn’t know it at the time, but it was already at death’s door, and would be voted out of WCAG 2.2 about six weeks later.

So, what was it, why didn’t it make it, what lessons can we learn from it, and why should implement it anyway? That’s what we’ll cover in this article.

What was SC 3.2.7?

We’ll cover Success Criterion 3.2.7 and what it means in plain language.

Why isn’t it in WCAG 2.2?

Using an example, we’ll go over the challenges this criterion had among the WCAG contributors that lead to its demise.

Lessons learned

We’ll cover lessons we can take away from this criterion and its unfortunately exclusion from WCAG 2.2.

Why and how do we meet SC 3.2.7 anyway?

We should implement what SC 3.2.7 was attempting to address. I’ll show you why we should and how.

Conclusion

Links

Here’s the text of Success Criterion 3.2.7: Visible Controls:

Where receiving pointer hover or keyboard focus triggers user interface components to be visible, information needed to identify that user interface components are available is visible, except when:

– The information needed to identify the user interface components is available through an equivalent component that is visible on the same page or on a different step in a multi-step process without requiring pointer hover or keyboard focus;

– The component is provided specifically to enhance the experience for keyboard navigation;

– A mechanism is available to make the information persistently visible;

– Hiding the information needed to identify the component is essential.