aria-practices icon indicating copy to clipboard operation
aria-practices copied to clipboard

Finish drafting section "Discernable and Predictable Keyboard Focus"

Open mcking65 opened this issue 9 years ago • 7 comments

The section Discernable and Predictable Keyboard Focus is incomplete.

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

mcking65 avatar Dec 13 '16 00:12 mcking65

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 avatar Feb 21 '17 16:02 carmacleod

devistating should be: devastating

carmacleod avatar Feb 21 '17 16:02 carmacleod

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

carmacleod avatar Feb 21 '17 16:02 carmacleod

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

carmacleod avatar Feb 21 '17 16:02 carmacleod

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 avatar Feb 21 '17 17:02 carmacleod

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.

carmacleod avatar Feb 21 '17 18:02 carmacleod

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!

0ddfell0w avatar Jan 21 '21 19:01 0ddfell0w