Day 58: Identifying A11y Issues for Keyboard Users

Published on 27 Jan 2019

• journal
• resources
• review
• was
• issues
• testing
• wcag

Through studying WCAG (Guideline 2.1) and other web accessibility documentation and articles, I know that keyboard navigability and interoperability is important for a wide variety of users. Some important ideas to focus on when creating websites and keeping keyboard accessibility in mind:

• Actionable elements (links, buttons, controls, etc.) must receive focusable via keyboard (WCAG SC 2.1.1);
• All focusable elements need a visible border or highlight as a focus indicator (WCAG SC 2.4.7);
• Logical (expected) tabbing order is set up appropriately (WCAG SC 2.4.3);
• No keyboard traps, like poorly developed modals, have been created (WCAG SC 2.1.2).

The best way to test for keyboard accessibility? Test with a keyboard! It's one of the easiest and cheapest ways to find out if you're blocking someone from accessing your content. Critical (yet basic) keys to use:

• Tab
• Enter
• Spacebar
• ▲ ▼ ◄ ► (arrow keys)
• Esc

If any of those keys fail you when it comes to expected behavior for controls and navigation, it's time to start digging into the code and figuring out what's preventing that expected and conventional behavior.

That being said, I've started looking at section two of the WAS Body of Knowledge to fill in any gaps I have about identifying accessibility issues, starting with interoperability and compatibility issues. I've had a lot of practice checking for keyboard accessibility due to its simplicity, but I leave no stone unturned when it comes to studying for this exam and making sure I'm not missing more gaps in my web accessibility knowledge.

• Browsed through W3C's Tools and Techniques page again.
• Read Keyboard Access and Visual Focus (W3C Easy Checks).
• Practiced testing for keyboard accessibility on a familiar site.

Today I didn't learn much more on top of what I knew already, since I've had a lot of practice checking for keyboard accessibility due to its simplicity. However, I leave no stone unturned when it comes to studying for this exam and making sure I'm not missing more gaps in my web accessibility knowledge. Plus, I'm always eager to take the opportunity to advocate for keyboard testing as a reminder to designers and developers that not everyone uses a mouse and even well-written code can produce a different experience than initially expected.

One thing I did learn:

I'll have to watch out for this one I audit other sites, since I have not created a drop down with that type of behavior yet, myself.