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.
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.
[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.
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 !
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/