Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review/explore keyboard shortcuts in rendered notebooks #13

Open
6 tasks
isabela-pf opened this issue Sep 13, 2022 · 1 comment
Open
6 tasks

Review/explore keyboard shortcuts in rendered notebooks #13

isabela-pf opened this issue Sep 13, 2022 · 1 comment
Labels
test 1: navigation Related to the first round of user testing with navigation emphasized

Comments

@isabela-pf
Copy link
Contributor

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

  • 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?)
@isabela-pf isabela-pf added the test 1: navigation Related to the first round of user testing with navigation emphasized label Sep 13, 2022
@tonyfast
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test 1: navigation Related to the first round of user testing with navigation emphasized
Projects
None yet
Development

No branches or pull requests

2 participants