SC2-1-2-no-keyboard-trap-non-standard-navigation (Updated)

[annethyme]

---

name: No keyboard trap non-standard navigation
group:

• SC2-1-2-no-keyboard-trap-standard-navigation
• SC2-1-2-no-keyboard-trap-non-standard-navigation (current)

description: |
This rule checks if the user is advised on a method for non-standard keyboard navigation to navigate through focusable content on a web page without becoming trapped in any element.

success_criterion:

• 2.1.2 # No Keyboard Trap

test aspects:

• DOM Tree

authors:

• Dagfinn Rømen
• Geir Sindre Fossøy
• Malin Øvrebø
• Shadi Abou-Zahra
• Carlos Duarte
• Anne Thyme Nørregaard
• Stein Erik Skotkjerra

---

Test procedure

Applicability

The rule applies to any HTML or SVG element on a web page that is focusable and reachable through sequential focus navigation where focus cannot cycle to the browser UI by using standard keyboard navigation.

Expectation 1

For each target element help information is visible on the page and exposed to assistive technologies or can be navigated to from within the keyboard trap.

Note: As per Success Criterion 2.1.1 Keyboard the help information should be accessible through a keyboard interface. This however is the test subject for another ACT rule.

Expectation 2

The help information explains how to cycle to the browser UI, or on how to get to a point from where it is possible to cycle to the browser UI, using standard keyboard navigation.

Expectation 3

For each target element focus can cycle to the browser UI by using the method advised in the help information.

Note: Cycling back to the browser UI can be done both by moving forward through the tab order and by moving backwards. It is not possible to fulfil this expectation by using browser specific shortcuts to return to the browser UI.

Assumptions

• The WCAG success criterion applies to all content where focus can be moved to through keyboard navigation.
• It is not possible to use unmodified arrow or tab keys, or other standard exit methods to move focus away.
• The focus order in keyboard navigation is cyclical, not linear, meaning that the focus order will cycle to the first/last element when it moves away from the last/first element.

Accessibility support

There are no major accessibility support issues known for this rule.

Background

• https://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-trapping.html
• https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G21

Test Cases

Passed

<!-- Keyboard trap with help information in a paragraph before, and where the method adviced works -->

<script>
var trapOn = false ;
</script>

<p class="target">Press the Esc-key to Exit</p>
<a id="link1" href="#">Link 1</a>
<button id="btn1" class="target" onblur="(function(e){trapOn=true; document.getElementById('btn2').focus();})(event)">Button 1</button>
<button id="btn2" class="target" onkeydown="(function(e){ if (e.keyCode === 27){trapOn=false;document.getElementById('link2').focus();}})(event)" onblur="(function(e){ if(trapOn){document.getElementById('btn1').focus();}})(event)">Button 2</button>
<a id="link2" href="#">Link 2</a>

<!-- Keyboard trap with help information within the trap, and where the method adviced works --> 

<script>
var trapOn = false ;
</script>

<a id="link1" href="#">Link 1</a>
<button id="btn1" class="target" onblur="(function(e){trapOn=true; document.getElementById('btn2').focus();})(event)">Button 1</button>
<p class="target">Press the Esc-key to Exit</p>
<button id="btn2" class="target" onkeydown="(function(e){ if (e.keyCode === 27){trapOn=false;document.getElementById('link2').focus();}})(event)" onblur="(function(e){ if(trapOn){document.getElementById('btn1').focus();}})(event)">Button 2</button>
<a id="link2" href="#">Link 2</a>

Failed

<!-- Keyboard trap with no instructions  -->

<script>
var trapOn = false ;
</script>

<a id="link1" href="#">Link 1</a>
<button id="btn1" class="target" onblur="(function(e){trapOn=true; document.getElementById('btn2').focus();})(event)">Button 1</button>
<button id="btn2" class="target" onkeydown="(function(e){ if (e.keyCode === 27){trapOn=false;document.getElementById('link2').focus();}})(event)" onblur="(function(e){ if(trapOn){document.getElementById('btn1').focus();}})(event)">Button 2</button>
<a id="link2" href="#">Link 2</a>

<!-- Keyboard trap with instructions that doesn't give advice on the method for proceeding -->

<script>
var trapOn = false ;
</script>

<p class="target">Go to the next element</p>
<a id="link1" href="#">Link 1</a>
<button id="btn1" class="target" onblur="(function(e){trapOn=true; document.getElementById('btn2').focus();})(event)">Button 1</button>
<button id="btn2" class="target" onkeydown="(function(e){ if (e.keyCode === 27){trapOn=false;document.getElementById('link2').focus();}})(event)" onblur="(function(e){ if(trapOn){document.getElementById('btn1').focus();}})(event)">Button 2</button>
<a id="link2" href="#">Link 2</a>

<!-- Keyboard trap with help text, where the method adviced doesn't work --> 

<script>
var trapOn = false ;
</script>

<a id="link1" href="#">Link 1</a>
<button id="btn1" class="target" onblur="(function(e){trapOn=true; document.getElementById('btn2').focus();})(event)">Button 1</button>
<p class="target">Press the Esc-key to Exit</p>
<button id="btn2" class="target"  onblur="(function(e){ if(trapOn){document.getElementById('btn1').focus();}})(event)">Button 2</button>
<a id="link2" href="#">Link 2</a>

Inapplicable

<!-- Not a keyboard trap (interactive element) -->

<a id="link1" href="#">Link 1</a>
<button id="btn1">Button 1</button>
<button id="btn2">Button 2</button>
<a id="link2" href="#">Link 2</a>

[gianwild]

Just saw this and I have seen components that can be only exited through a space key – not sure if you want to include this as a possible means of escape or deliberately require that this method is advised to the user.

[nitedog]

Success Criterion 2.1.2 says "unmodified arrow or tab keys or other standard exit methods" - what do you consider "other standard exit methods" to be? We thought of:

• ESC key
• Enter and space sometimes used to active action, and thereby release focus

It is indeed debatable whether the latter can be considered "standard exist method".

[gianwild]

I agree – it is debatable whether enter or space are standard exit methods, but we should specify whether they are or not. The only others that probably need to be mentioned as not acceptable would be delete and backspace…

[WilcoFiers]

I don't think this applicability section is objective:

• What is a "component"?
• What does it mean to "focus into" a component?
• What is "not possible", by what method are you supposed to test this?
• What is "focus out of"? Focus to other elements on the page? What if there are none, or what if they are taken out of the focus order as soon as you focus into the component?

I think this applicability section is too broad. You may want to create two rules in a rule group instead, one for a standard exit method, and one for a non-standard exit method.

[nitedog]

• The term "component" comes from the SC itself.
• The SC says "focus can be moved to" and "focus can be moved away from" -- is this any better?
• The sentence continues to say "by using...", but I agree this could be reworded.
• See above -- "focus can be moved away from" is what the SC says.
• Yes, there are two rules here: R1 and R2 -- this is about non-standard exit methods.

Suggested rewording for applicability: All components on a web page where focus can be moved through keyboard navigation, but where focus cannot be moved away from the component by using arrow keys, ESC key, TAB key, Shift+TAB or Enter key.

[geirsf]

Updated format

[annethyme]

Dagfinn, Geir Sindre and Anne started updating the rule to match #67. Changes made to Applicability and Expectations, but the update is not finished yet.

Old Test Procedure:

Applicability

The rule applies to all HTML elements and subsections of HTML elements on a web page where focus can be moved to through keyboard navigation.

Expectation 1

Help information is available explaining how to move focus away from the element using a keyboard.

Expectation 2

The help information can be accessed using a keyboard.

Expectation 3

The method advised in the help information allows the user to move focus away from the element using a keyboard.

[WilcoFiers]

Looks much better. I'll take a closer look when it goes into PR, but on the surface I think this is solid.

[geirsf]

Added Testcases

[DagfinnRomen]

Changed description.

Old description: If it is not possible to navigate through all content on the web page with a keyboard without becoming trapped in any component, the user should be advised on the method for moving focus away from the component.

[annethyme]

Included the description of the test cases as comments in the html of the test cases to align with other rules where we have done the same.

[annethyme]

Aligned wording on test case comments with Expectations.

[annethyme]

@geirsf, if we choose to update the Applicability for #67 as suggested, this rule needs to be updated too.

[geirsf]

@annethyme I have updated the Applicability

[annethyme]

Made into pull request: #142