No Keyboard Trap [a1b64e] - note and Fail Ex 1

[kengdoj]

Question about the Expectation for the rule for no keyboard trap:

For each target element, focus can cycle to the browser UI by using standard keyboard navigation. Note: Cycling back to the browser UI can be done both by moving forward through the tab order and by moving backwards.

Does the expectation require moving forward and backward or either forward or backward to pass?

The SC requires "focus can be moved away" (and does not specify in both directions):

Success Criterion 2.1.2 No Keyboard Trap (Level A): If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

There seems to be difference in browsers and OS for Failed Example 1:

• I tested on Chrome/Firefox/Edge + Windows: I am able to tab forward and move focus away from the button to the browser. I cannot move focus away from the button when going backwards.

• A colleague tested on Chrome + Mac: focus could not move away from the button in either direction.

• Whether the link gets focus is also inconsistent in different browsers.

[carlosapaduarte]

Discuss possible solution with CG:

• Clarify that it needs to move away forward (using unmodified keys). Add expectation that if you're only able to move away with modified keys then the user needs to be notified about it
• Update failed example 1

[carlosapaduarte]

Resolution:

• update example 1 to ensure it works everywhere
• clarify that it only needs to be able to move away from the trap, irrespectively of moving forward or backward