An Overview of WCAG’s Fourth Principle: Robust

1 guideline. 3 success criteria (including 2 Level A conformance. 1 Level AA conformance). And a few ever-changing techniques that are sufficient, advisory, or a failure. As I pointed out in my Perceivable principle, Operable principle, and Understandable principle reviews, these stats are just one way the World Wide Web Consortium’s (W3C) “Robust” principle within the current Web Content Accessibility Guidelines (WCAG)  2.1 recommendation can be broken down.

Introduction

On that note, I’ll introduce you to WCAG’s fourth and shortest principle: Robust. This short, and likely understated, principle boils down to creating flexible content and interfaces so that everyone can access your website now, and in the future, in ways and methods you can’t plan for. Technology gets updated, outdated, and revived quickly in the 21st century. We, as developers, can’t plan for everything, but we can make strides to be forward-thinking with our code.

The fourth Web Content Accessibility Guideline‘s says: “Content must be robust enough that it can be interpreted by by a wide variety of user agents, including assistive technologies.” This is a generally defined idea, leading up to more objective goals (success criteria) and techniques.

This principle offers us suggestions and insights to successfully make our websites flexible and more inclusive, inviting more people to interact with it in a way that maybe different than our own. “Robust” models a way for us to be considerate of people who think differently, move differently, and perceive differently than ourselves. No matter the physical and cognitive differences among us, everyone should still be able to use your website with very few hurdles.

Guidelines

To dig a little deeper, how can we ensure that everyone can understand the services and information we have to offer? Step down a level, from subjective to objective, via its guideline and success criteria. The one Robust guideline says that your entire webpage should be:

  • compatible

Success Criteria

Digging deeper, we find this guideline offers its own goals (success criteria) to target common accessibility problems. To sum up the 3 goals that the criteria are aiming for:

  • markup should be parsable (valid and complete)
  • a name, role, and value should be assigned (to custom elements)
  • status messages about changes or alerts should be announced, even without focus on that element

I encourage you to check out all the success criteria, now that you are more confident in understanding the guideline within the fourth principle. Additionally, read How to Meet WCAG, which is add value to your understanding and clear techniques that help you visualize how to meaningfully apply what you’ve learned.

Conclusion

Regardless of how you take your next steps, I hope you’re becoming more confident to dive into WCAG documentation and its supplemental materials and guides to help you better understand web accessibility. I can’t emphasize enough that, despite all the technical specs, taking a moment to empathize with people who have different levels of abilities than your own is so important. Ask yourself, “How could my website prevent a person with a visual, hearing, physical, or cognitive impairment from entering in and walking away with what they came for?” In the end, it’s the empathizing and relating to your wider audience that will make your accessibility efforts a success, rather than all the vast technical memorization and compliance, in which you devoted your time.

An aside

This is Day 10 of my 100 Days of Accessibility journey to learn all things web accessibility. The best way I retain information is to share with others, so I spent my “study” time today writing this post to advance my knowledge, and yours, too.

As an aside resource that I’m currently reading, Form Design Patterns by Adam Silver (Smashing Magazine) is reinforcing my assimilation of the Robust principle. I’ve only read through his first form pattern about registration forms, but it reinforces the importance of semantic markup. Clear markup benefits all users.

An Overview of WCAG’s Third Principle: Understandable

3 guidelines. 17 success criteria (including 5 Level A conformance. 5 Level AA conformance. 7 Level AAA conformance). And several ever-changing techniques that are sufficient, advisory, or a failure. As I pointed out in my Perceivable principle and Operable principle reviews, these stats are just one way the World Wide Web Consortium’s (W3C) “Understandable” principle within the current Web Content Accessibility Guidelines (WCAG)  2.1 recommendation can be broken down.

Introduction

On that note, I’ll introduce you to WCAG’s third principle: Understandable. As stated earlier, it has several components, so to speak, but it all boils down to giving everyone the opportunity to successfully understand the content and interfaces on your website. No matter a person’s education, native tongue, or prior experiences, your website should be relatively easy to understand when they read text, interact with form controls, or perform an interactive task.

The third Web Content Accessibility Guideline‘s says: “Information and the operation of user interface must be understandable.” Of course, this is a generally defined idea, leading up to more objective goals (success criteria) and techniques.

This principle offers us suggestions and insights to successfully make our websites more inclusive, inviting more people to interact with it in a way that maybe different than our own. “Understandable” models a way for us to be considerate of people who think differently, move differently, and perceive differently than ourselves. No matter the physical and cognitive differences among us, everyone should still be able to understand your website with very few hurdles.

Guidelines

To dig a little deeper, how can we ensure that everyone can understand the services and information we have to offer? Trail down through the levels within this principle, from subjective to objective, via its guidelines and success criteria. The Understandable guidelines say that your entire webpage should:

  • be readable
  • be predictable
  • include input assistance for forms

Success Criteria

Digging even deeper into those 3 guidelines, we find each guideline offers its own goals (success criteria) to target common accessibility problems. Rather than writing out all 17 criteria, which could be blog posts in and of themselves, I’ll sum up a few of the guidelines to include some goals that the criteria are aiming for:

  • define a language for the whole page; and parts of the page when different languages are used
  • help people understand complex information with summaries, expanded abbreviations and definitions, or other simplified text alternatives
  • keep your labels and input interactions consistent and predictable
  • offer help text for forms to help prevent input errors
  • clearly point out input errors and how to resolve them

I encourage you to check out all the success criteria, now that you are more confident in understanding the guidelines within the third principle. If that page still looks too intimidating, try reading How to Meet WCAG, which is more approachable and provides clear techniques that help you visualize how to meaningfully apply what you’ve learned.

Conclusion

Regardless of how you take your next steps, I hope you’re becoming more confident to dive into WCAG documentation and its supplemental materials and guides to help you better understand web accessibility. I can’t emphasize enough that, despite all the technical specs, taking a moment to empathize with people who have different levels of abilities than your own is so important. Ask yourself, “How could my website prevent a person with a visual, hearing, physical, or cognitive impairment from entering in and walking away with what they came for?” In the end, it’s the empathizing and relating to your wider audience that will make your accessibility efforts a success, rather than all the vast technical memorization and compliance, in which you devoted your time.

An aside

This is Day 9 of my 100 Days of Accessibility journey to learn all things web accessibility. The best way I retain information is to share with others, so I spent my “study” time today writing this post to advance my knowledge, and yours, too.

As an aside resource that I’m currently reading, Form Design Patterns by Adam Silver (Smashing Magazine) is reinforcing my assimilation of the Understandable principle. I’ve only read through his first form pattern about registration forms, but it reinforces the importance of input controls being predictable and reinforced with clear labels, help text, and error prevention. In the end, it benefits all users to make forms better!

As an aside code experiment to reinforce “Understandable”, and a chance try some code new to me, I put into action W3C’s H62 technique: Using the ruby element to assist with pronunciation.

Day 8: WCAG Understandable

It’s Friday! And I’ve managed to balance my time just enough to dedicate to study for a week straight. I’m trying not to bounce around too far afield, so I’m back at studying WCAG, acknowledging I’m past the halfway point.

At this point, I’m gaining a lot more confidence in myself and the hope of passing this test. I should interject that I’ve been actively learning about web accessibility over the past year and a half just through Googling, applying that mindset to every project I touch, and listening to accessibility experts.

Things I accomplished

What I learned today

  • No guidelines or success criteria were appended to the Understandable principle within the WCAG 2.1 update.
  • I’ve found that many of these success criteria are well-applied across the web. At least in web projects I’ve collaborated on.
  • I found one app on my iPhone that is inaccessible, but at least they tell on themselves in a “secret message for screen readers” and recommend a different app. (Spoiler: it’s Libby, and they recommend using Overdrive instead)

Day 7: Learning VoiceOver on iOS

While I’m learning about how how some users perceive and operate pages, I think it’s a good time to start diving into some of the assistive technology (AT) that people use. A week ago I had a more cut and dry approach to the WAS Body of Knowledge, as seen on my Google calendar, but now I’m discovering a more natural overlap of ideas as my own curiosity grows and I attempt to apply these ideas in a useful and concrete way.

To start, I spent time with Apple’s VoiceOver (VO) on my iPhone. Why this particular AT first? Honestly, I needed it during work today to test and share with others. Secondly, it’s one I have the least familiarity with. It’s hard to go against how I normally use my iPhone! Yet, enough motivation and time has slowly brought me around and made me also think more on how this AT can lend itself to benefiting everyone in the screen-less world we are presumed to be heading into.

Things I accomplished

  • Successfully navigated my iPhone using VoiceOver without looking at the screen or giving up too easily out of frustration.
  • As part of my bi-weekly duties at work, wrote a short accessibility blurb meant to introduce librarians, archivists, and museum staff to VO on iPhone (not yet published at the time I’m writing this).

What I learned today

  • VO has a screen curtain mode that turns the screen off, while the functionality continues. This offers added privacy or could save battery power. Careful! I scared myself, not being able to toggle my screen back on. Fortunately, I’d practiced navigating beforehand and listened my way through Settings to turn VO off, which resolved the issue. Phew!
  • Practiced at least 5 ways to interact with my iPhone using VO:
    Gesture Desired Behavior
    Swipe down with 2 fingers Start reading continuously (from this point on)
    Tap with 2 fingers Stop reading
    Rotate both thumbs in sync (like a dial) Scroll through rotor for list settings and navigation options.
    Tap with 1 finger Select item
    Double-tap with 1 finger Choose item or activate button
  • I can comfortably listen to VO at a speed of 60%.

Food for thought

  • It seems to me the visually impaired have to sacrifice a bit more of their privacy just to accomplish what people, who don’t use screen readers, can accomplish on a daily basis (everything is read aloud).
  • Imagine if all of us practiced using VO. There could be benefits to not looking at your screen at every task, giving verbal commands for tasks, and gaining empathy and insight into how others interact differently with the same world.
  • I actually appreciated listening to, as opposed to looking at, some things. For instance:
    • small icons are often problematic for me to see, but VO suddenly brought clear definition to emojis and indicators that I may have only guessed at before,
    • I could listen to my email as I walked on my break, and still keep alert for what was around me, and
    • I could perform some tasks on my phone, without looking the screen lighting up the whole room, while my son drifted off to sleep tonight.

How you can learn to use VoiceOver on iOS

An Overview of WCAG’s Second Principle: Operable

5 guidelines. 29 success criteria (including 14 Level A conformance. 3 Level AA conformance. 12 Level AAA conformance). And many ever-changing techniques that are sufficient, advisory, or a failure. Just as I pointed out in my Perceivable principle review, this is just one way the World Wide Web Consortium’s (W3C) “Operable” principle within the current Web Content Accessibility Guidelines (WCAG)  2.1 recommendation can be broken down. And yet, the documentation that follows is even more massive! Though, looking at it by the numbers can leave one feeling intimidated, exhausted, and uninspired to learn the golden standard of web accessibility, there are better ways to break down the docs into chunks.

Introduction

On that note, I’ll introduce you to WCAG’s second principle: Operable. As stated earlier, it has many components, so to speak, but it all boils down to giving everyone the opportunity to successfully navigate each part of your website via the technology of their choosing. For instance, I navigate the web mostly with my mouse, sometimes in unison with my keyboard, when skipping from page to page, link to link. Additionally, my fingers do the walking (nod to the old school yellow pages) when I’m on my smartphone and zipping through sites. However, there are many people who solely use their keyboard to navigate the web. Additionally, all of us rely on clear wayfinding to get from one place to another online.

The second Web Content Accessibility Guideline‘s says: “User interface components and navigation must be operable.” This is a generally defined idea, leading up to more objective goals (success criteria) and techniques.

This principle offers us suggestions and insights to successfully make our websites more inclusive, inviting more people to interact with it in a way that maybe different than our own. “Operable” models a way for us to be considerate of people who think differently, move differently, and perceive differently than ourselves. No matter the physical and cognitive differences among us, everyone should still be able to navigate your website without hurdles.

Guidelines

To dig a little deeper, how can we ensure that everyone can access the variety of services and information we have to offer? Trail down through the levels within this principle, from subjective to objective, via its guidelines and success criteria. The Operable guidelines say that your entire webpage should:

  • be keyboard accessible
  • allow enough time for viewing
  • be considerate of people with seizures or other sensitive reactions
  • be navigable
  • consider various modes of device input

Success Criteria

Digging even deeper into those 4 guidelines, we find each guideline offers its own goals (success criteria) to target common accessibility problems. Rather than writing out all 29 criteria, which could be several blog posts in and of themselves, I’ll expand upon the guidelines to include some goals that the criteria are aiming for:

  • every part of your page can be accessed by keyboard alone, yet no part of the page should trap that keyboard user within itself
  • visitors should have some control over animation and timed sessions
  • use of animation (during interaction) and flashing should be regulated
  • visitors need a point of reference to understand where they are, and ways to jump past repetitive content
  • allow visitors to easily operate web apps and site functionality with other input methods other than a keyboard

I encourage you to check out all the success criteria, now that you are more confident in understanding the guidelines within the second principle. If that page still looks too intimidating, try reading How to Meet WCAG, which is more approachable and provides clearer techniques that help you visualize how to meaningfully apply what you’ve learned.

Conclusion

Regardless of how you take your next steps, I hope you are becoming more confident to dive into WCAG documentation and its supplemental materials and guides to help you better understand web accessibility. I can’t emphasize enough that, despite all the technical specs, taking a moment to empathize with people who have different levels of abilities than your own is so important. Ask yourself, “How could my website prevent a person with a visual, hearing, physical, or cognitive impairment from entering in and walking away with what they came for?” In the end, it’s the empathizing and relating to your wider audience that will make your accessibility efforts a success, rather than all the vast technical memorization and compliance, in which you devoted your time.

An aside

This is Day 6 of my 100 Days of Accessibility journey to learn all things web accessibility. The best way I retain information is to share with others, so I spent my “study” time today writing this post to advance my knowledge, and yours, too.

I’d also like to note another resource that I’ve recently tapped into. I’ve started reading Form Design Patterns by Adam Silver (Smashing Magazine) in the hopes of learning how to make accessible and usable forms on pages that I design and develop. As an added note, I’m reading it on my Kindle Paperwhite because it is more accessible to me in that format, which allows me to enlarge the print, control lighting (no glaring white background or overwhelming backlighting), and read without distractions. Flexible formats are a wonderful thing for everyone!

An Overview of WCAG’s First Principle: Perceivable

4 guidelines. 29 success criteria (including 9 Level A conformance. 11 Level AA conformance. 9 Level AAA conformance). And so many more sufficient, advisory, and failure techniques that are ever changing. This is just one way the World Wide Web Consortium’s (W3C) “Perceivable” principle within the current Web Content Accessibility Guidelines (WCAG) recommendation can be broken down. But, wait, there’s so much more documentation to follow! However, looking at it that way can suddenly leave one feeling intimidated, exhausted, and uninspired to learn even just this small segment of the golden standard of web accessibility.

Sadly, I get the impression that many web developers, such as myself, feel this way when referring to this documentation. We go in, quickly find what we need, and get out as quick as possible before the abyss of text and jargon overwhelm us. Or, we find a non-normative siteto help us understand the documentation and never once visit the normative documentation (there’s nothing wrong with that, by the way).

I’m not here to judge you, but rather I am on a long road to better understand the whys and hows of web accessibility, so that I can become a better developer, designer, and person. On that journey, I can only hope to impart some of what I’ve gained and inspire you to take your own journey, no matter the length.

Introduction

On that note, let me introduce you to the principle labelled as Perceivable. As stated earlier, it appears to have a ton of components, so to speak, but it all boils down to giving everyone the opportunity to access your application and content by the sense that is dominant for them. For instance, ironically, I rely heavily on my vision to pull in information around me (though I’m visually impaired), but supplement with hearing and touch to fill in the gaps. Lucky me, in such a visually dominant world we live in. Virtually, I have to enlarge print, zoom into pages, and minimize business on the page (yay, for Reader View!). However, I recognize that not everyone is like me. There are people who rely heavily on hearing or touch to interact with their environment. Additionally, there are others who can see much better than I can. And, yet, we all live in the same world, trying to access the same Internet.

The first Web Content Accessibility Guideline‘s says: “Information and user interface components must be presentable to users in ways they can perceive.” Take note, this is just the general idea with goals that is more objectively defined in the success criteria and techniques.

To me, this principle offers us some low hanging fruit to successfully make our websites more inclusive, inviting more people in, who arrive with a different means to interact than our own. Whether someone sees (visual, screen), hears (audio, screen reader), or feels (Braille output) in order to read a blog, buy a plane ticket, or learn a new skill, it shouldn’t matter. They should still be able to partake in all those things.

Guidelines

To dig a little deeper, how can we ensure that everyone can access the variety of services and information on the web? Trail down through the levels within the principle, from subjective to objective, via their guidelines and success criteria. The Perceivable guidelines say that content and components should:

  • provide text alternatives
  • have specific considerations for time-based media (audio and video)
  • be adaptable through structure and formatting
  • be distinguishable in various contexts

Success Criteria

Digging down further into these 4 guidelines, we find each guideline offering it’s own criteria to target potential accessibility issues. Rather than writing out all 29 criteria, which could be several blog posts in themselves, I’ll expand upon the guidelines to include what some of the key criteria are aiming for or why:

  • provide text alternatives to items that aren’t text already (non-text), therefore, giving your users the ability to access information through their chosen medium or format
  • couple video and audio, whether live or pre-recorded, with text (captions, transcript) or audio (audio description)
  • allow for diverse user choices that may affect your design and define clear connections between content on the page; this includes flexible screen orientation, defined input types, and using semantic HTML
  • ensure all content is “visible”, whether it’s providing good color contrast, appropriate foreground and background audio contrast, or creating more white space between text and elements on a page.

I encourage you to check out all the success criteria, now that you are more confident in understanding the guidelines within the first principle. If that page still looks too intimidating, try reading How to Meet WCAG, which is more approachable and provides clearer techniques that help you visualize how to meaningfully apply what you’ve learned.

Conclusion

Regardless of how you take your next steps, I hope you are less afraid to dive into WCAG documentation and its supplemental materials and guides to help you understand web accessibility. Despite all the technical specs, take a moment to sit back and empathize with people who have different levels of abilities than your own. Ask yourself, “How could my website prevent a person with a visual, hearing, physical, or cognitive impairment from entering in and walking away with what they came for?” In the end, it’s the empathizing and relating to your wider audience that will make your accessibility efforts a success, rather than all the vast technical memorization and compliance, in which you devoted your time.

An aside

This is Day 5 of my 100 Days of Accessibility journey to learn all things web accessibility. The best way I keep information in my brain is to share with others, so I spent my “study” time today writing this post, so that I could better assimilate the information in a more permanent way, while offering you a step forward into understanding web accessibility a little better.

If you’re trying to learn more about web accessibility, you don’t have to do anything as extravagant or dramatic as I’m doing. Today I just discovered Learning A11y, which provides a list of resources to help you get started learning. We’re all headed for the same destination here, but our learning styles and journey may vary.

Day 4: WCAG Operable

Moving onto the second WCAG principle: Operable! 1.5 hours dedicated to studying today.

Things I accomplished

  • Read through all the Operable guidelines, success criteria, and sufficient techniques.
  • Added to my WCAG 2.1 POUR spreadsheet to include Operable.
  • Started drafting a blog post to sum up the perceivable principle as though I were explaining its what, why, and how to developers. Coming soon!

What I learned today

  • SC 2.2.2: “For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it” Carousels, I’m looking at you! I’ve never thought to create a hide option. Something to explore further, since it only makes sense to me to provide that kind of flexibility to users.
  • Guideline 2.5: Input Modalities. This was completely new to me! Of course, all those guidelines were added as part of the WCAG 2.1 upgrade, so I imagine that’s why. Admittedly, I’ll need to read about these more in-depth, as I’m not quite finding an immediate application to projects I’ve worked on in the past.
  • My undeveloped opinion: it would seem to me that 2.5.5 Target Size would be a no-brainer (in usability) and not nice-to-have AAA conformance level. I mean, it really benefits everyone (mobile users), right?

Making progress

Though I’m only two principles into WCAG, I’m actually surprised how much I already know and have applied in my web design/development work over the last 5 years. It goes to show that the best way to learn this stuff is working with others who know it, apply it, and care about it. It also hasn’t hurt to lurk in conversations about web accessibility on Twitter, Slack, and listserv emails. Those two factors have helped me advance forward, alongside the fact that I have close friends and family with various disabilities, who have helped me relate to the challenges many people face when navigating online.

Day 3: WCAG Perceivable, Part 2

Time spent studying today: 1 hour. Again, another weekend day that I successfully allotted time for study. I’ve been through three rounds of 100 Days of Code, a 9-month course on Udacity, and one round of 100 Days of A11y. I’m no stranger to dedicating time, figuring out a process, and sacrificing blocks of time I could’ve spent with family. However, I’ve seen what I can accomplish and how I can progress, so that gives me some confidence in continuing to put time aside to prepare in-depth for this challenging exam.

Things I accomplished

  • Closely read through all of the perceivable principle’s success criteria
  • Memorized the 4 guidelines under the perceivable principle:
    • Text alternatives
    • Time-based media (audio, video)
    • Adaptable
    • Distinguishable
  • Added to my POUR spreadsheet to include more techniques

What I learned today

9 out of the 29 success criteria in the first WCAG principle are Level A. It’s like reading, “these are just the basics, folks, which gets you almost a third of the way there”. Yet if they’re so basic, why aren’t all web designers and developers trained to meet the bare minimum to create websites that are better for everyone? Is it really so much to ask for alternative text for images, captions for video, or volume controls for audio?

Other new-to-me tidbits:

  • Logos and brand names are exempt from Contrast criterion (SC 1.4.3) and Images of text (SC 1.4.5).
  • Captions and images of text are exempt from the new Resize Text criterion (SC 1.4.4).
  • There’s a suggestion for appropriate audio contrast when it comes to foreground and background noise (see SC 1.4.7)

Day 2: WCAG Perceivable, Part 1

Day 2… a weekend day, which can make it harder to make time to set aside for studying. I did it, though, spending roughly an hour and a half working through documentation, mulling over only part of the first WCAG principle, and working toward visualizing the different guidelines, success criterion, and techniques. I didn’t get as far as I would’ve liked either, yet this is the deepest work I’ve ever done at combing through the WCAG docs.

Things I accomplished

  • Read through the Perceivable principle in WCAG 2.1 documentation (normative and non-normative).
  • Started a spreadsheet to visualize relationships between principles, guidelines, success criterion, and techniques. Specifically I mapped out the perceivable principle.
  • Discovered techniques that failed to meet criterion within the perceivable principle.
  • Dug into helpful solutions to common situations (satisfactory techniques) via W3C’s “How to Meet WCAG 2.1“. Seriously, this resource is extremely helpful for all those situations I’ve had to figure out how to be more inclusive, and the documentation is there to back up my decision when I have to present it to my team!

What I learned today

In the process of trying to memorize guidelines and success criterion, I reinforced the image of the layers that exist within WCAG:

Additionally, looking closer at each criterion helped me to identify the additions made to WCAG 2.0’s first principle:

  • Orientation
  • Identify input purposes
  • Identify purpose
  • Reflow
  • Non-text contrast
  • Text spacing
  • Content on hover or focus

When reading through the description about text alternatives, I ran across a concept new to me: “simpler language” is considered a text alternative under Guideline 1.1. Also, there are some identified exceptions to the text alternative guideline. Those exceptions apply to:

  • controls or input fields
  • time-based media
  • tests/exams
  • specific sensory experiences
  • CAPTCHA
  • decorative images or typography

Day 1: Initialization and WCAG Introduction

And here I go! To start off my journey to earn my Web Accessibility Specialist certification, I had to get myself in gear, get organized, and just start.

Things I accomplished

  • Launched this WordPress blog to make myself accountable to commit daily to web a11y study.
  • Set up a Google Calendar to keep myself on track to complete 80% of study materials by March 10, 2019, and beyond to April 3rd, when my exam happens (see my “How to Succeed” widget.
  • Read through WCAG 2.1 introduction non-normative).

What I learned today

Pyramid with 4 Principles as the foundation, 13 Guidelines, Success Criteria, and, lastly, Techniques.

  • WCAG layers of guidance include:
  • WCAG 2.1 updated 2.0 to be more inclusive of:
    • users with cognitive or learning disabilities,
    • users with low vision, and
    • users with disabilities on mobile devices
  • 17 new success criteria were appended to WCAG 2.0:
    • 1.3.4 Orientation (AA)
    • 1.3.5 Identify Input Purpose (AA)
    • 1.3.6 Identify Purpose (AAA)
    • 1.4.10 Reflow (AA)
    • 1.4.11 Non-Text Contrast (AA)
    • 1.4.12 Text Spacing (AA)
    • 1.4.13 Content on Hover or Focus (AA)
    • 2.1.4 Character Key Shortcuts (A)
    • 2.2.6 Timeouts (AAA)
    • 2.3.3 Animation from Interactions (AAA)
    • 2.5.1 Pointer Gestures (A)
    • 2.5.2 Pointer Cancellation (A)
    • 2.5.3 Label in Name (A)
    • 2.5.4 Motion Actuation (A)
    • 2.5.5 Target Size (AAA)
    • 2.5.6 Concurrent Input Mechanisms (AAA)
    • 4.1.3 Status Messages (AA)
  • An overhaul of WCAG is coming in a few year. In the meantime, 2.1 is the current recommendation, and 2.2 will be recommended shortly after that, before the new changes happens.