Pour Explained: O is for Operable Part 1
Tags: a11y, beginners, inclusion, webdev
Published: 2020-07-22 14:02:38

## __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](https://media.giphy.com/media/fMOg7lsJ8XrBm/giphy.gif)

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](https://media.giphy.com/media/JykvbWfXtAHSM/giphy.gif)

## __Guidelines:__ 
### __[2.1 Keyboard Accessible](https://www.w3.org/TR/WCAG21/#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](https://media.giphy.com/media/l2QEgfp0CB4Np0qUo/giphy.gif)
- 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:
      - `onblur="this.focus();	`
      - You can see how this works [Interactive Accessibility Keyboard trap examples](https://interactiveaccessibility.com/education/training/ex7.1.html)
      - For more examples on Keyboard traps you can find them at  [18F Accessibility Guide Keyboard access](https://accessibility.18f.gov/keyboard/#:~:text=This%20is%20an%20example%20of,back%20to%20the%20address%20bar.)

``` HTML
<input id="lastfour" type="text" value="" class="trap" onblur="this.focus();">
```

##### 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](https://www.w3.org/TR/WCAG21/#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](https://media.giphy.com/media/y8Mz1yj13s3kI/giphy.gif) 

##### 2.2.4 - Interruptions
__Level AAA__
Interruptions, such as alerts or page updates can be postponed by the user
![swiper no swiping](https://media.giphy.com/media/g4Ab7h4RsBCZG/giphy.gif)

##### 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](https://media.giphy.com/media/wMY3LjQQMqo5W/giphy.gif)
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.