tonyfast
commented
1 year ago i think keyboard navigation is ready to enter the scope of things.
for a while, i've baked accesskey into the accessible template. the accesskey is a spec and implementation. when defined, browser/os dependent modifier keys can be used to focus or click the element. accesskeys have a lot of problems, but they are a cheap way to get keyboard navigation.
aria-keyshortcuts is a specification for keyboard shortcuts to access an interactive or non-interactive element. there is no implementation that comes with defining aria-keyshortcuts, we'll have to implement them.
we can use both aria-keyshortcuts and accesskey within reason. all of these values should be configurable by the end user and there should visual label for the shortcuts.
its worth noting that NVDA and JAWS announce these attributes in focus mode.
Problem and context
This issue comes from our user testing round 1: navigation. Multiple participants relied on keyboard shortcuts or other keyboard-centered commands to complete tasks throughout the test. Because of this, some participants asked if there were shortcuts they should be aware of when navigating—whether for ease of use or to beware of unexpected behavior. Neither test hosts had a confident answer for this! There was no sign of existing shortcuts interfering, but it is a question worth exploring.
This may additionally be good information for future rounds of user testing, as a part of tasks to complete or to test conflicting inputs.
Possible solutions
At this point, the problem requires exploration. I have no sense of any solutions when we don't know the problem fully.
Acceptance criteria
This issue can be closed when we investigate the following tasks and decide what next steps, if any, we want to take on this topic.
Tasks to complete