这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@kloots
Copy link
Contributor

@kloots kloots commented Nov 2, 2017

This PR is a proof of concept and aims to extend focus-ring support to ARIA controls requiring managed focus.

Goals for this approach were

  • Opt in: only extend this support to ARIA controls requiring managed focus; existing heuristics with respect to when the focus-ring class is applied to native HTML controls remain unchanged.
  • Scalable: support any keyboard or programmatic focus styling as required by the developer implementing the control AND support both types of focus management: managed tabIndex or use of aria-activedescendant
  • With-the-grain: shouldn't introduce any new or non-standard attributes or practices

* @return {Boolean}
*/
function keyIsValid(e) {
var keyCode = e.keyCode;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

e.keyCode is deprecated. Use e.code instead.
See https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind. As Rob pointed out, KeyboardEvent.code is not supported in Internet Explorer.
Thanks for the heads up @robdodson.

@robdodson
Copy link
Collaborator

robdodson commented Jan 17, 2018 via email

@robdodson
Copy link
Collaborator

I think I'm going to close this, though I definitely appreciate the work put into it.

My thinking on this is that any control, if interacted with using a keyboard, should probably show focus states. I can't off the top of my head think of one where you wouldn't want this?

For keyboard shortcuts that move focus to an interactive control, you probably want a :focus-visible to match on that control. Otherwise you can end up with a very mysterious focus state as this gif demonstrates (mouse clicking the button moves focus to the other control which is activated with spacebar, but there's no clear indicator that this is happening).

click

For keyboard shortcuts that move focus to a new region in the page, like into a sidebar or modal window, I think you want a focus navigation start point API (today browsers do this but developers can't call it). This would let you avoid the annoying tabindex=-1 trick just to move the focus start point, and you wouldn't need to keep applying outline: none to those non-interactive regions. My hope is over the next quarters we can start to spec out and polyfill focus navigation start point.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants