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

On 19/08/2015 03:39, Jonathan Avila wrote:

> Mike, I am keenly aware of the flexibility of keyboard interfaces.
> However, what I have not done a good job doing is to explain why I feel
> we need a success criteria that needs to be more specific than just
> requiring keyboard operation through a keyboard interface on mobile.
> > My primary concern is that the current SC 2.1.1 can be met by providing
> keyboard access to web interactions by creating shortcut keystrokes and
> listening to key up and key down events.  While in theory this keyboard
> support should be sufficient for an interface – as I have explain in my
> prior posts – such a way for assistive technology such as speech
> recognition, screen readers, etc. on mobile devices to interact with the
> interface does not currently exist to my knowledge.
>
> Take for example a hypothetical knob on a webpage.  Without a screen
> reader I can turn that knob to specific settings.  As a developer I can
> implement keystrokes, let’s say control+1, control+2, etc. for the
> different settings.  I have met the letter of the success criteria by
> providing a keyboard interface through creating JavaScript shortcut
> keystroke listeners.  In practical reality though as a mobile screen
> reader user who does not carry around a keyboard I have no way to
> trigger those keystrokes.

Actually, it gets worse than that. As I noted previously, not all 
mobile/tablet devices with a paired keyboard actually send keyboard 
(keydown, keypress) events all the time.

In iOS, with a paired keyboard (but no VO enabled), the keyboard is 
completely inactive except when the user is in a text entry field or 
similar (basically, it only works in the same situations in which iOS' 
on-screen keyboard would be triggered).
When VO is enabled, the keyboard still only sends keyboard events when 
in a text entry field etc. In all other situations, every keystroke is 
intercepted by VO (and again, there is no mechanism to override this 
with role="application" or similar).
In short, for iOS you can't rely on anything that listens for 
keydown/keypress either.

In Android, the situations is more similar to what would happen on 
desktop (from what I recall at least...would need to do some further 
testing) in that the keyboard always works/fires key events. Not had a 
chance to test Windows Mobile with paired keyboard yet, but I suspect it 
works in a similar way.

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 Wednesday, 19 August 2015 07:04:26 UTC