Touch Issues in WCAG 2.2.1 keyboard trap

Background

This issue arose during the 3 March 2016 discussion of the Understanding text of Mobile 2.5.2 No Swipe Trap.

Rationale

• When assistive technology is turned on there are examples of navigating to an interactive element using a swipe gesture and not being able to use a swipe gesture to move focus away from the element.

• Using the Explore by Touch Feature to move focus away was insufficient to address the problem because AT users could miss portions of the content without knowing it.

• The Mobile Accessibility Task Force (MATF) has proposed a new success criterion 2.5.2 No Swipe Trap to address the issue.

• Since this issue is closer to being an edge case of the WCAG 2.1.2, members of MATF thought it was better served to update WCAG 2.1.2 to make it more technology neutral -- that keyboard trap was really a navigation trap.

• The issue with mobile swipe traps is better addressed as a failure of WCAG 2.1.2, if 2.1.2 were expanded beyond keyboard.

The MATF participants in the discussion felt that the issue was best served by updating WCAG 2.1.2 No Keyboard Trap to include swipe and touch gestures.

Recommendation

Update WCAG 2.1.2 from No Keyboard Trap to 2.1.2 No Navigation Trap.

Discussion

From the minutes of 3 March 2016 (edited for clarity and relevance)

Jon: I think we were trying to say is with the AT on is possible to get into a trap ... maybe it's swipe gestures that's the problem

Chris: it's not swipe gestures that's an issue, it's just focusing anything in any way ... you have to separate from the touch

Chris: if we remove swipe gestures from the equation, it is completely covered by 2.1.2 keyboard trap except some of those touch specific solutions. All of the issues we talked about are covered by keyboard trap. The problem is with a touchscreen you can do this touch navigation thing to get around some of these things. But we want to do is say hey that's not a solution because we have users who are still relying on keyboard

Marc: would we have to still keep it separate? There's no keyboard trap because if you have a touch screen on your desktop you can find a way out – is there one specific to mobile rather than adding into existing?

Chris: the way in which we need to separate it isn't creating a new criteria, but saying these keyboard traps or let's call them navigation traps – that touch to explore things that touch screens allow is not a solution ... take the word keyboard out of keyboard trap, call it navigation trap and how is the criterion different?

Jon: trying to make more strict – not just keyboard. Sometimes Explore by touch is not the optimal solution but maybe isn't going to happen very often, maybe it's an edge case

Kathy: do we have a failure under the keyboard trap? Keyboard is keyboard interface it doesn't mean the actual physical keyboard ... it looks like the WCAG extension maybe 2.1 rather than extension – we have to get away from thinking we necessarily need something altogether separate. If what we come down to saying is there's really nothing different except we want to assure certain things are done then maybe we can add something to the understanding of keyboard trap one to address mobile and then put the failure

Chris: that makes more sense to me

Jon: if that works, if we could do that that's fine with me – if we can enhance the current success criteria in the new version of WCAG by having a failure

Chris: It's not that there aren't mobile considerations, it's just that the mobile considerations can be expanded on what's already there ... completely generalize it – wording would become no navigation trap

Marc: generalizing 2.1.2 – I like the no navigation trap. I like the proposal Kathy did earlier

Chris: we can keep swipe out of the base text and examples, failures use swipe wording. Becomes a more general thing, more obvious about how that would apply

Kathy: we have a statement in the understanding right now referring to 2.1.2 no keyboard trap, if we document what we are talking about now we can use this as an example as to how we are going to do the extension ... if we work on in this meeting coming up with language about why it's different – Jon's point out if I the actual success criteria a little bit. It may not roll into 2.1.2, but at least we've documented why we've added it here – what is actually different are missing, why we need to change 2.1.2

Jon: I think as we document our concerns if it gets rolled into 2.1.2 that's fine later