Re: Rough draft of some success criteria for a extension guideline "Touch accessible"

On 18/08/2015 17:44, David MacDonald wrote:
> I would be uncomfortable with punting the gesture issue and just rely on
> keyboard, just because its hard to solve.

Not hard, just technically unsolvable for authors. They have zero 
control over gestures being intercepted by AT (for web content at least).

> I've tested several apps for large corporations where they worked fine
> with VO off, but with VO on large parts of the functionality didn't work.

And again, it may simply be impossible for authors to solve the gesture 
issue at all. So making sure they design the apps to also work with 
keyboard/keyboard-like interfaces (including sequential access, such as 
the swipe left/right with VO to move the VO focus) would solve this, 
while simply requiring them to make gestures work even when AT is in 
operation won't, if they don't have any means of doing that.

> For me, it's not really "mobile" if it can't be done while on the move,
> if there is a requirement for a keyboard. You have to find a table, sit
> down, and treat the device like a laptop.
>
> It's early days of mobile AT and its the wild west. But let's try to put
> our heads together and find a solution that:
>
> - allows users of mobile AT get the information while standing, while on
> a moving bus, etc...
> -that puts some requirements on authors, but not crazy ones
> -that helps set in motion a convergence of AT for mobile on
> functionality etc...

Again, it's good to look at use cases, but the reality is: authors can't 
control gesture handling. So let's focus on requiring alternatives to 
purely gestural interfaces.

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 Tuesday, 18 August 2015 17:00:07 UTC