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

Modifier keys? #16

Open
minorninth opened this issue Feb 25, 2016 · 7 comments
Open

Modifier keys? #16

minorninth opened this issue Feb 25, 2016 · 7 comments
Assignees
Milestone

Comments

@minorninth
Copy link

Here are some examples of real-world shortcuts implemented by existing web apps:

  • 'C' to compose a new message in Gmail/Inbox
  • Ctrl+Shift+C to do a Word Count in Google Docs
  • Shift+A to "reply all" in Yahoo Mail
  • 'L' to like the current story on Facebook
  • '/' to focus the search box on Twitter
  • 'C' to create an issue on GitHub

It doesn't sound like any of these apps could switch to accesskey, because accesskey only supports the browser modifier keys.

Is there any reason accesskey couldn't be expanded to support key combinations with modifier keys explicitly, like Shift+A or Ctrl+Shift+C?

@chaals
Copy link
Owner

chaals commented Feb 25, 2016

The only barrier here is what people are willing to implement in browsers.

The spec could, and IMHO should, support requesting specific modifier keys - or bare keys, which are obviously more convenient for most users most of the time.

The first step would be to fix the bug in most browsers that means if there is more than one character as the value of the attribute, then it is not recognised at all.

The second step, which I think is pretty trivial would be to define a microsyntax for such modifiers.

Similarly, I would be happier if accessKeyLabel returned a defined microsyntax that could be parsed, rather than the HTML5 situation of "user agents can describe the accesskey label however they like, so it cannot be parsed reliably".

chaals pushed a commit that referenced this issue Feb 26, 2016
- editorial tweaks
- link issues #15 and #16
- clarify when direct activation should or should not happen
@minorninth
Copy link
Author

I defined such a microsyntax in the aria-keyshortcuts spec, maybe consider borrowing some of that text?

@chaals
Copy link
Owner

chaals commented Feb 29, 2016

I was planning on copying the DOM specs for the most part, so yes…

@chaals
Copy link
Owner

chaals commented Jun 2, 2016

Yep. I'm going to say that browsers must understand - and use - the DOM UI Events syntax for describing keys.

@chaals chaals added this to the June 2016 milestone Jun 2, 2016
@chaals chaals self-assigned this Jun 2, 2016
@Krinkle
Copy link

Krinkle commented Jun 20, 2017

@chaals Sorry if this is not the right, place. I repeatedly see this desire for the label to be parseable. I don't oppose that, but I'm curious why this is so important, and specifically why it is important for this property to be parseable (as opposed to a new getter optimised for machine-readability as opposed to human-readability). Is there a particular use case you have in mind?

@chaals
Copy link
Owner

chaals commented Jun 20, 2017

@Krinkle I am quite happy for it to optimise for machine-readability - that's the critical requirement, since then it is possible to present to the user in a localised and appropriate form.

The sceneario I have in mind is the application presenting the shortcut to the user, e.g. in help documentation or some configuration system. The point is that this should work effectively, rather than having the author trying to cover all the possible cases, or doing something fragile (and not really good) like user-agent sniffing and then guessing.

@Malvoz
Copy link

Malvoz commented May 21, 2018

Not trying to ruin all the fun here, but multiple modifier keys sounds pretty inaccessible to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants