RE: MATF Minutes 18 February 2016

> Purely from a "web content in browser" (rather than native apps) point of view, as swipes on the screen are intercepted by touchscreen AT, users will not be trapped in these sorts of carousels

I've been told about situations where there was a carousel with endless items in it and they were all swippable in the focus order and the screen reader user was instructed to use the explore by touch feature to touch below the carousel to get past it.  Thus, I think this situation is possible although hopefully not common.  

An unrelated but common keyboard trap can also occur with form validation.

And on a second related note -- I've had people tell me that there can't be keyboard traps on native apps - but iOS does in fact have a method to move the track and move VocieOver focus -- which could trap the swipe order if not explore by touch.

Jonathan

-----Original Message-----
From: Patrick H. Lauke [mailto:redux@splintered.co.uk] 
Sent: Thursday, February 18, 2016 12:36 PM
To: public-mobile-a11y-tf@w3.org
Subject: Re: MATF Minutes 18 February 2016

On 18/02/2016 17:16, Kim Patch wrote:

> <jeanne> 2.5.3 Single Taps and Long Presses Revocable: Interface 
> elements that require a single tap or a long press as input will only 
> trigger the corresponding event when the finger is lifted inside that 
> element. (Level A)
>
> jeanne: fixed numbers. Text of 2.5.3 posted in ... found thread of 
> email from Patrick. Found action item from Jan that he was going to 
> write it but he cann't now. Does anyone remember what we were going to 
> do with 2.5.3?
>
> <jeanne> Patricks' email thread
> https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Jul/003

> 8.html
>
> jeanne: should talk about this next week if no one remembers?
>
> detlev: need to review emails and someone shoudl dig through those and 
> draft something -- person may need to get in touch with patrick. 
> Should have one person take up task.
>
> chris: will take up

Also, if need be, happy to try and see if I can attend next week's meeting, if it'd help?

> <jeanne> Swipe gestures are useful for displaying new content. Giving 
> focus to new content via a swipe gesture also needs a gesture or 
> method to move focus back to the main content — either by swiping to 
> return or by informing the user of the method needed to return. These 
> methods must work with assistive technology. This success criterion is 
> the touch equivalent of WCAG 2.1.2 No keyboard trap.
>
> <jeanne> Example 1: Infinite scroll of content, where there is 
> additional content in the footer, but the user with assistive 
> technology (e.g. screenreader) cannot move focus to the footer and 
> therefore cannot read the footer content and may not even know that 
> the footer content exists. .

Isn't infinite scroll a problem that's more general, also affecting desktop keyboard/AT users?

> <jeanne> Example 2: An infinite carousel advances with a swipe gesture.
> The instructions indicate that a touch outside the carousel will exit 
> the carousel. The user can touch outside the carousel with assistive 
> technology (e.g. screenreader) turned on.

Purely from a "web content in browser" (rather than native apps) point of view, as swipes on the screen are intercepted by touchscreen AT, users will not be trapped in these sorts of carousels (in fact, most of the time, they'll have the opposite problem of not being able to actually advance/move around in the carousel, if the site simply did a "oh, this device supports touch events, so I'll just implement swipe gestures and remove any visible "<" and ">" arrows or similar to move in the carousel).

> <jeanne> Swipe gestures are useful for displaying dynamic content.
> Giving focus to dynamic content via a swipe gesture also needs a 
> gesture or method to move focus back to prior content — either by 
> swiping to return or by informing the user of the method needed to 
> return. These methods must work with assistive technology. This 
> success criterion is similar to WCAG 2.1.2 No keyboard trap.

And again, related to previous point: for web, as AT will intercept swipes, this boils down to making a regular control (like a button or
similar) that can receive focus and trigger the behavior, available, since touch AT users won't be able to actually execute swipe gestures that are then passed to the page's JS (unless they explicitly use a pass-through gesture).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com

twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Sunday, 21 February 2016 19:49:30 UTC