One of my favorite parts of accessible web development is coding of interactive components. In a nutshell, any action a user can take with a mouse needs to be possible somehow using a keyboard and screen reader.
How screen readers overlap with keyboard access
While keyboard support is a foundational part of developing accessible interactions, it’s also important to know how ARIA factors in. Will a blind screen reader user know your toggle button has a menu associated with it, and whether it’s open or closed?
<button data-toggle="dropdown" onclick="toggleProfileDropdown()"> Menu </button> <ul id="profile-link-list" hidden> <li><a href="/profile" />My profile</li> <li><a href="/settings" />Settings</li> <!-- more links here... --> </ul>
toggleProfileDropdown function could effectively expose or hide the neighboring list of links for keyboard functionality. However, it has no initial accessibility information to indicate its state or hint at the presence of an associated element.
By including a couple of well-supported ARIA attributes as well as keyboard focus management, this little dropdown could be much more usable all-around:
<button aria-expanded="false" aria-haspopup="true" data-toggle="dropdown" onclick="toggleProfileDropdown()"> Menu </button>
This is just one example of the techniques you'll learn in the full Testing Accessibility workshop series!