Day 68: How to Fail the Bare Minimum of WCAG Operable

Published on 06 Feb 2019

• journal
• was
• operable
• specifications
• wcag

Yesterday I got a head start on looking through the Level A conformance fails within WCAG's perceivable principle. To keep that momentum going, I'll be traversing through the other "bare minimum" recommendations to make sites mostly accessible with minor challenges. Today my sights were set on Operable.

• Read Operable success criteria (Level A) failure techniques on How to Meet WCAG 2 site.
• Mapped success criteria to failures of those criteria that I’ve encountered or read about.

There are 14 bare minimum (Level A) success criteria recommended by W3C in order for websites to be operable (keyboard, mouse, touch, voice, switch). That's almost half of Operable's success criteria! These success criteria are, as follows:

• 2.1.1 Keyboard
• 2.1.2 No keyboard trap
• 2.1.4 Character key shortcuts (new in WCAG 2.1)
• 2.2.1 Timing adjustable
• 2.2.2 Pause, stop, hide
• 2.3.1 Three flashes or below threshold
• 2.4.1 Bypass blocks
• 2.4.2 Page titled
• 2.4.3 Focus order
• 2.4.4 Link purpose (in context)
• 2.5.1 Pointer gestures (new in WCAG 2.1)
• 2.5.2 Pointer cancellation (new in WCAG 2.1)
• 2.5.3 Label in name (new in WCAG 2.1)
• 2.5.4 Motion actuation (new in WCAG 2.1)

When these fourteen operable success criteria are met, it enables people who use assistive technology and adaptive strategies to access, navigate, and interact with your static and dynamic content.

SC 2.1.1 Fail: Several projects I've worked on have implemented hover-only focus styling effects or tooltips/pop-ups that excluded keyboard users.

SC 2.1.2 Fail: Modals can be tricky to create. When the keyboard user has no way to close the modal (Esc or Tab to close button) and get back to the content, this SC doesn't pass.

SC 2.1.4 Fail: Creating single-character keyboard shortcuts without giving the user control to deactivate or change those shortcuts can greatly affect keyboard and speech input users.

SC 2.2.1 Fail: I am guilty of the client-side meta redirect! I know now that setting a timer of any kind requires extra consideration for people who need more time to make decisions and understand what's going on. There is no user control in this situation.

SC 2.2.2 Fail: Carousels, the bane of my existence, can easily fail this success criteria if it doesn't have a pause, stop, or hide mechanism. It's taking choice away from any user. Additionally, it makes content less perceivable by people with visual or cognitive disabilities.

SC 2.3.1 Fail: I've seen video ads, fixed a web page, that are not only distracting, but have a flashing when its trying to grab a users attention. If the contrast is high and lasts more then 3 flashes, it's a fail. Not only does it fragment attention for people with cognitive disabilities, but could create a severe reaction for people with photosensitive seizure disorders.

SC 2.4.1 Fail: No additional links are provided to skip repetitive content or navigate to different regions of the page. This creates an exhaustive experience for keyboard users tabbing through that web page.

SC 2.4.2 Fail: This is a current issue I'm battling. A web page doesn't have a unique title or descriptive title that identifies the pages purpose or intent.

SC 2.4.3 Fail: I've seen some bad tabindexing, which ruins the relationship between keyboard (or screen reader) navigation and understanding content's logic.

SC 2.4.4 Fail: This is a recent fail I've found in a recent accessibility audit. An image is linked, but there is not alternative text given to that image to let a screen reader user know what it's purpose is.

SC 2.5.1 Fail: Custom complex gestures (requires multiple touch points) for touch devices is difficult for people with motor disabilities and those who use assistive technology that cannot equate these actions.

SC 2.5.2 Fail: No room for touch error was enabled. People with visual, cognitive, and motor disabilities could suffer from accidental button activation or disorientation when inadvertently taken to another part of the site.

SC 2.5.3 Fail: Visible linked text is different from a hidden accessible name (i.e. title or aria-label), which becomes an unknown hidden voice command for people who use speech input to operate controls and navigate the webpage. It also confuses understanding of content for screen reader users.

SC 2.5.4 Fail: No alternative means of control activation other than device motion (e.g. shaking or tilting) is available. This can exclude people with motor disabilities.

This was a lot to digest in under two hours. However, these base recommendations are so critical in order for people with disabilities (and everyone else) to be able to operate, navigate, understand, and appreciate a site and its services. I cannot afford to glaze over them, but rather advocate for at least this bare minimum in sites I collaborate on.