Focusable element has no keyboard trap via standard navigation - Expectation + add clarification

[giacomo-petri]

• Rule: Focusable element has no keyboard trap via standard navigation
• URL: https://www.w3.org/WAI/standards-guidelines/act/rules/a1b64e/proposed/
• Description:

  1. From Expectations:

     For each target element, focus can cycle to the browser UI by using standard keyboard navigation.

     Proposal:

     For each target element, focus can be moved away from that element using only standard keyboard navigation.

     I would suggest a better adherence with SC (2.1.2: No Keyboard Trap).

     • "focus can cycle to the browser UI" is related to the entire flattened tabindex ordered focus navigation scope, not to the single target element;
     • "focus can cycle to the browser UI" navigating on Safari with the TAB, focus moves from the last tabbable element to the body element, skipping the "Browser UI". On the contrary, navigating backward (SHIFT+TAB) focus can be moved to the address-bar. Anyway, the new proposal should avoid any confusion.

  2. From Applicability:

     This rule applies to any HTML or SVG element that is focusable.

     The definition of focusable, in particular the Exception

     Exception: Elements that lose focus during a period of up to 1 second after gaining focus, without the user interacting with the page the element is on, are not considered focusable.

     leads to having elements that are both focusable and not focusable.
     For example, looking at Failed Example 1 in the same rule, at page load both the first and last links are focusable, but when the button receives focus, due to exception, both are no longer focusable. So in this scenario, when focus is on the "button" element, we've just one "focusable" element within the page that is the button itself.
     I think the intent of the rule is to use elements that are part of the sequential focus navigation as target elements.

[tombrunet]

Decision during Aug 1 working session - Will handle Safari scenario of browser UI via an accessibility supports note

[tombrunet]

@giacomo-petri I opened #2209 as a draft PR while I address other issues. I think the support note handles the expectation issue.

Regarding the applicability, I think there's a related issue with the focus definition, but I don't think it affects the applicability here. You can focus that element via other means and focus will not leave the element, therefore it's still 'focusable'. If we narrow to just sequential focus navigation, then items with tabindex="-1" that are click focusable will be ignored, even though they could cause keyboard traps. An item that always loses focus as soon as it receives focus (modal bumpers / sentinels) isn't a concern, even though technically in the sequential keyboard navigation.