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

Finish drafting section "Discernable and Predictable Keyboard Focus" #217

Open
mcking65 opened this issue Dec 13, 2016 · 7 comments
Open

Finish drafting section "Discernable and Predictable Keyboard Focus" #217

mcking65 opened this issue Dec 13, 2016 · 7 comments

Comments

@mcking65
Copy link
Contributor

@mcking65 mcking65 commented Dec 13, 2016

The section Discernable and Predictable Keyboard Focus is incomplete.

This section may benefit from examples and images, potentially on a separate example page.

@mcking65 mcking65 added this to the 1.1 PR milestone Dec 13, 2016
@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Feb 21, 2017

affect vs effect:

  1. Authors need to manage events that effect the currently active element
    should be:
    Authors need to manage events that affect the currently active element

  2. browsers move focus to the body element, affectively causing a loss of focus within the user interface.
    should be:
    browsers move focus to the body element, effectively causing a loss of focus within the user interface.

@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Feb 21, 2017

devistating should be: devastating

@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Feb 21, 2017

The beginning of paragraph 4.4 needs to start with a capital letter...
in composite widgets
should be:
In composite widgets

@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Feb 21, 2017

Need a lowercase i for the word "in" in the following phrase:
except In Mac OS

@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Feb 21, 2017

In section 4.5, note that tabindex=-1 is actually focusable with a mouse click as well as with javascript.
This can take people by surprise, so probably should mention it, i.e.:
tabindex="-1"
The element is not included in the tab sequence but is focusable with element.focus().
should be:
tabindex="-1"
The element is not included in the tab sequence but is focusable with the mouse or element.focus().

For reference, here's tabindex in the HTML spec: https://www.w3.org/TR/html51/editing.html#the-tabindex-attribute
"Positive numbers specify the relative position of the element’s focusable areas in the sequential focus navigation order, and negative numbers indicate that the control is to be unreachable by sequential focus navigation."

@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Feb 21, 2017

4.6.2 change "scrolled" to "scroll" in the following sentence:
Move the visual focus indicator and, if necessary, scrolled the active element into view.

@mcking65 mcking65 modified the milestones: 1.1 Rec, 3Q17 Working Draft Oct 11, 2017
@mcking65 mcking65 removed this from the 1.1 APG Release 4 milestone Aug 14, 2019
@0ddfell0w
Copy link

@0ddfell0w 0ddfell0w commented Jan 21, 2021

Looking at this section in the context of deciding where to apply user focus under the following circumstance

  • A toast message appears with buttons inside (a dismiss button, maybe an action)
  • There's not an obvious best place to place user focus after they dismiss the snackbar
  • The most recently active element in the background is no longer on the page (say you just deleted the last item in a list, and the snackbar is confirming that final deletion)

Where do we recommend putting focus?

This section seems to suggest that we should not allow focus to drop to the body. I can imagine recommending that we focus a nearby element, and certainly an element with a visible focus indicator, but do we have an opinion on whether we should choose, say, the previous interactive element in the focus order? The next interactive element in the focus order?

One of the nice things, in many browsers, about dropping focus, is that the browser will handle where focus go (but in doing so, will often violate the advice in this section)

Any guidance would be much appreciated!

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

Successfully merging a pull request may close this issue.

None yet
4 participants