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/0038.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 Thursday, 18 February 2016 17:36:00 UTC