Pour Explained: O is for Operable Part 1

stories_of_ren

⚡️Ren⚡️

Posted on July 22, 2020

Pour Explained: O is for Operable Part 1

Principle 2 -- OPERABLE

UI components that feature interactive capabilities and navigational components MUST be operable.

Reading through the WCAG guidelines to learn the operable guidelines was for me was the hardest to understand language wise. This is also probably why it took me so long to write this post. In other words I had re-read each Guideline and success criterion a couple of times with extended look up time. Like that wording, in that order, what does that even mean!

I don't get it at all

So before we begin down the operable trail, let's revisit a few things.

  • Levels:
    • A, AA, AAA
    • Many entities try to maintain a level AA compliance, because it is achievable as well as meaningful. Maintaining just a level AA compliance is still falling short in being accessible and inclusive.
    • Every guideline success criterion is necessary to at least some users with disabilities, so don't ignore level AAA compliance.

Now Let's make all functionality available from a keyboard with our success criteria!

Neil deGrasse Tyson, Let's do this

Guidelines:

2.1 Keyboard Accessible

All functionality must be keyboard accessible. Essentially the user needs to be able to navigate the website via the keyboard. Commonly using the Tab key to jump from element to element as well as using actionable keys such as the arrow keys & return. Likewise, this includes Keyboard like inputs as well, because not everyone that doesn’t use a mouse uses a keyboard.

Success Criteria:

2.1.1 - Keyboard

Level A
All functionality needs to be able to be accomplished by the keyboard unless function can't be accomplished in any known way, ie Freehand Drawing.

Page-specific shortcut key codes and access keys ( access keys SHOULD be avoided) DO NOT conflict with existing browser or screen reader shortcuts. (screen readers tend to have a lot just fair warning)

2.1.2 - No Keyboard Trap

Level A
Pitfall

  • Absolutely No Keyboard Traps…
    • What is a keyboard trap? Well it’s a hole of an input, something that won’t allow you to move forward or backward once you’ve tabbed into it. It’s sad and lonely here and I can’t escape.
    • And example of the keyboard trap is adding something like this to your input:
<input id="lastfour" type="text" value="" class="trap" onblur="this.focus();">
Enter fullscreen mode Exit fullscreen mode
2.1.3 - Keyboard (No Exception)

Level AAA
To be fully accessible ALL PAGE FUNCTIONALITY SHOULD be available using the keyboard.

2.1.4 - Character Key Shortcuts

Level A
Newly added in WCAG guidelines 2.1
If keyboard shortcuts include printable character keys the user MUST have the ability to:

  • Disable the key command.
  • Change the defined key to a non-printable key (ctrl, alt, opt, etc).
  • Only Activate the shortcut when the associated UI component is focused.

2.2 Enough Time

You MUST provide your user enough time to read and use the content.

  • Having a timeout in conjunction with an actionable item is problematic, but can be avoided in multiple ways.

Success Criteria:

2.2.1 - Time Adjustable

Level A
If the page has a time limit:

  • Options are provided to adjust, turn off, or extend the time.
    • This is not a requirement for a real-time event. (ie an auction site like eBay)
    • This is not a requirement for a time limit over 20 hrs
2.2.2 - Pausing, Stop, Hide

Level A

  • Provide a way to pause, stop, or hide automatic moving, blinking, or scrolling UI elements such as carousels, marquees, or animations that last >5 seconds.
    • The exception is only if the movement, blinking, or animation is essential.
  • Provide a way to pause, stop, or hide auto updating UI elements (ie news tickers, chats, ect)
    • The user should be able to manually control timing of the updates.
    • The exception is only if the movement, blinking, or animation is essential.
2.2.3 - No Timing

Level AAA
Let’s get wild here…
All content and functionality have NO TIME LIMITS
Oprah

2.2.4 - Interruptions

Level AAA
Interruptions, such as alerts or page updates can be postponed by the user
swiper no swiping

2.2.5 - Re-authenticating

Level AAA
If the Auth session expires, the user can re-authenticate and continue without losing any data from the current page.

2.2.6 - Timeouts

Level AAA
A user MUST be warned of any inactive period that could result in a loss of data unless the data is preserved for more than 20 hours when a user doesn’t take any action.

Thank you
Thank you so much for taking this journey of learning more about accessibility with me. Be on the lookout for part two, which will cover 2.3-Seizures & Physical Reactions, 2.4-Navigable, and 2.5-Input Modalities. I am sorry this took a while to post and I will try even harder to get part 2 out asap.

💖 💪 🙅 🚩
stories_of_ren
⚡️Ren⚡️

Posted on July 22, 2020

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related