- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Mon, 18 Jul 2016 10:00:28 +0100
- To: public-mobile-a11y-tf@w3.org
On 18/07/2016 09:47, Alastair Campbell wrote: > Patrick H. wrote: >> No if the touch interface relied on detecting swipes, it would fail >> proposed 2.1 since it can't be operated using all non-pointer interfaces >> (adding keyboard events would allow traditional keyboard controls, but >> wouldn't do anything for touch+AT scenario) > > Ah, so a finger isn’t a pointing device? ;-) Once you're using touch+AT, the fact that you're using a finger is irrelevant. That's a characteristic of the input mechanism. It's the AT that's interpreting the finger/touch. What the *content* sees are not touches, but high-level events (yes, touch events ARE fired for compatibility reasons, as are mouse events, but when using touch+AT the user is NOT "pointing" at x/y coordinates on the screen - barring touch-to-explore, which is more of a fallback navigation mechanism) > In my head the JS events types fall into categories of mouse, keyboard, touch and higher-level (e.g. focus/blur). > With mouse & touch counting as ‘pointer’ events. > > I had thought that web-content could include features using mouse, keyboard & touch events that are missed if you use touch+AT. > Is there no gap there? > > Hopefully this isn’t me being dumb, but even if it is then it’s a trap others might fall into, and worth considering in terms of wording. > > Cheers, > > -Alastair > -- 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 Monday, 18 July 2016 09:00:49 UTC