This post talks about how I implemented an accessible combobox widget, and all the hoops I jumped through.
The biggest hoop was the W3C ARIA community screws up on ARIA 1.1 combobox specs. ARIA 1.2 has a fix, but it is still in working draft.
Without knowing this, I went ahead to implement 1.1 combobox. It was costly to realize that screen readers have poor support for ARIA 1.1 comboboxes and I later had to switch to ARIA 1.2.
If you are building combobox / autocomplete like widgets and care about accessibility, this post can help you learn what’s ahead.
Many UI widgets have problems if you reason it from the angle of web accessibility.
Hover-and-expand menu is one example. Because the top level element is a link, users expect link behaviours. But we also have a submenu to fly out when users hover the mouse.
Essentially, we are mixing a link and a menu button. Because of this, it’s awkward for keyboard and screen reader (e.g., NVDA) users. Do you expect to activate a link or see a submenu when you press
There are some workarounds, but we should avoid such a design in the first place. …
If you are fixing the accessibility (aka. a11y) issues of an existing site, and seeing a widget like below:
(Image source: https://ca.puma.com/)
Now answer this question: Which design pattern is this widget using?
Why is the question important? Because different widgets has different requirements on keyboard interactions, tag properties, states, etc.!
For example, you should be able to use the Space key to activate a dropdown if it is a menu, but there is no such key requirement for a listbox.
Another example: If a menu has submenu, your implementation should support left / right arrow keys to navigate to the submenus. …