Keyboard accessibility is vital, as many assistive devices emulate the keyboard. Using semantic HTML one can achieve an accessible User Interface (UI) with less code than non-semantic markup.
By managing and guiding focus with semantic HTML, developing an accessible UI is rather easy. Semantic HTML plays an important role in not only accessibility but SEO (Search Engine Optimization) as well. Although we are aware of it, it's often overlooked.
In September’s accessibility talk, Sarbbottam Bandyopadhyay shared the trade-offs of using semantic vs non-semantic markup with an everyday example. He also shared how to manage and guide focus. It was a brief presentation emphasizing the various aspects of keyboard accessibility. He concluded with a brief introduction to WAI-ARIA.
Sarbbottam is a frontend engineer, with more than 14 years experience. He currently works at LinkedIn. He is part of LinkedIn's core accessibility team, focusing primarily on web accessibility. He’s been involved with web accessibility since his Yahoo days.
Keyboard Accessibility is addressed in the “Operable” principle of the WCAG: Web Content Accessibility Guidelines.
Many users with motor disabilities rely on keyboard navigation. Using a mouse or trackpad can be difficult because it takes a lot of fine motor skills.
P - Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
O - Operable: User interface components and navigation must be operable.
U - Understandable: Information and the operation of user interface must be understandable.
R - Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
The WCAG 2 Quick reference guide has done an excellent job organizing and categorizing the POUR guidelines.
Many assistive devices emulate the keyboard
To be keyboard accessible, the website’s user interface must be navigable and operable via the keyboard. Arrows are used for widgets and groups; for example, radio groups or dropdowns.
Tab and arrow keys are used primarily to navigate.
Enter and space are the primary keys used to operate.
Most common issues:
Mouse only interaction:
This an interaction that can only be accessed using a mouse or pointing device. There is no way a keyboard user can access this functionality.
No focus indicator:
Focus indicators visually identify the current active element on the screen. The focus indicator is often suppressed using CSS. As a result, keyboard-only users are not being able to access content or know where they are on the screen.
Sarbottom has developed a Chrome extension, called Focus Indicator, which forces focus on active highlighted elements.
Focus indicator is the equivalent to mouse pointer, so,
'focus outline: none' is equivalent to
'cursor: none'. We wouldn’t use
'cursor: none', so we shouldn’t use
'focus outline: none'.
It is expected that a tab press will focus on the next visible element in a logical order. The tab order must be in sync with the visual order. When the tab order does not match a user’s expectations, it creates a cognitive overhead.
A keyboard user expects the actionable elements in a dynamic apps UI to be navigated by a subsequent tab press.
We can avoid these common issues and pitfalls
Use Semantic HTML
- It is not only important for accessibility, it is important for SEO.
- Semantic HTML allows the markup to be system, software, or machine interpretable.
- Using semantic HTML results in less code.
ARIA or WAI+ARIA (Accessible Rich Internet Application) is a set of additional HTML elements that enhance the accessibility of web content by providing extra information.
There are three areas of ARIA attributes:
- Role - defines what an element is or what it does.
- State - conveys the current state of the element.
- Property - adds additional information to an element, like relationship.
Note: The semantic information provided by ARIA attributes supersedes the native HTML semantics.
The first rule of ARIA is to not use ARIA.
Any subsequent tab press will focus the next focusable element, which enhances the keyboard user’s experience.
Guided Focus Management:
Guided focus management enhances the keyboard user’s experience. It allows the screen reader to read out the textual content of the focused container letting a visually challenged user be aware of UI updates. There are situations when the focus cannot be shifted from the context.
WAI-ARIA can be used to provide spoken feedback.
To wrap it up...
Get romantic with semantic and focus on focusing.
Links mentioned in the talk:
- Léonie Watson, "Design like you give a damn: Practical accessibility for web pros" at W3Conf 2013 - https://www.youtube.com/watch?v=vK1tlLOavvM
- WAI-ARIA menus, and why you should generally avoid using them - https://www.marcozehe.de/2018/09/22/wai-aria-menus-and-why-you-should-generally-avoid-using-them/
- Web Content Accessibility Guidelines (WCAG) Overview - https://www.w3.org/WAI/standards-guidelines/wcag/
- National Park Service - https://www.nps.gov/index.htm
- How to Meet WCAG 2 (Quick Reference) - https://www.w3.org/WAI/WCAG21/quickref/
- Focus Indicator Chrome Extension - https://chrome.google.com/webstore/detail/focus-indicator/heeoeadndnhebmfebjccbhmccmaoedlf
- Source Code Search Engine -
Drupal Accessibility Group
Join the Accessibility group on Drupal.org for hints, tips, discussions, and patch proposals to help make Drupal more inclusive.
Follow us on Twitter and use the hashtag #a11ytalks to follow the conversation.