WTF are Accessible Design Patterns?
Although elements that are natively keyboard accessible should be used when possible, there are times when HTML falls short and custom "widgets" are necessary. Complex menus, sliders, dialogs, tab panels, etc. must all be built to support keyboard and screen reader accessibility.
Widget behavior expectations
- For more complex widgets there are expectations by keyboard and screen reader users as to how these specific widgets will behave and can be navigated
- Interactions must be intuitive and predictable
- Events triggered by mouse clicks should also be able to be triggered via keyboard
- The state of the widget should always be clear
References
- https://www.w3.org/TR/wai-aria-practices-1.1/#aria_ex
- https://inclusive-components.design/
- https://a11yproject.com/patterns/
- https://webaim.org/techniques/keyboard/
Instructor: [00:00] While if you search for accessible design patterns or accessible interaction patterns on the Web, you may find a number of guides, but the W3C's Authoring Practices is really the authoritative source for design patterns for accessible widgets.
[00:17] If you go to their ARIA practices or Authoring Practices Guide and go to the section on design patterns in widgets, you will find listed a number of UI widgets. You may need to read the description of each to see if what they have defined matches the UI functionality that you're building.
[00:37] Once you've located a design pattern that matches what you're looking to build, you find defined a description of the widget, and the parts that make up the widget. They list some code examples for how to implement the widget and these are typically in vanilla HTML, CSS, and JavaScript.
[01:00] They will define the expected keyboard interaction behavior, so specific keys for this widget are expected to have certain behavior. They list which ARIA attributes or roles should be added to which parts of the widget and various states or properties those attributes should have for which use cases.
[01:28] Typically following all of the requirements defined a design pattern will ensure that that widget is going to be as accessible as possible, and should be compatible with both assistive technology devices as well as keyboard-only users.
I also agree that focus on the tittle sometimes is a much better user experience than focusable elements.
Thank you! And to back up my assertion here's why I think that focusing on the title can be a better experience in some scenarios: https://www.gatsbyjs.org/blog/2019-07-11-user-testing-accessible-client-routing/
Amazing, I also agree that focus on the tittle sometimes is a much better user experience than focusable elements. Thank you very much for this !