You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Agree upon which rendered notebook methods/interfaces we want to include
Review each method/interface and create a list of comprehensive shortcuts for each
Cross-reference with relevant shortcuts in similar user experiences (like shortcut competitive analysis?)
Cross-reference with common shortcuts in supported browsers, OSs, or assistive tech
Put this info somewhere to be saved—could be on this issue
Decide on next steps we want to take with this information (ie. Is this to be used in future user testing? Does it have conflicts with browser or OS or assistive tech commands? Does it require another fix?)
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: