- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Fri, 8 Jul 2016 10:54:30 +0100
- To: Alastair Campbell <acampbell@nomensa.com>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
On 08/07/2016 10:01, Alastair Campbell wrote: > Gregg – if you are in doubt I would suggest asking someone involved in > the pointer-events group [1] which appears to be dedicated to creating > input-neutral JavaScript events. Note that I'm chair of that group, as well as a co-editor of the spec... ;) > Thirdly (and the minor point), would it be possible to refer to > ‘non-pointer’ things in a positive sense? I.e. say what it is rather > than what it isn’t? E.g. “Keyboard equivalent interfaces”. Possibly not, > it just doesn’t read well to keep saying “non-pointer”. In the note I added to the Pointer Events spec's intro https://www.w3.org/TR/pointerevents/#intro I call them "keyboard and keyboard-like interfaces" "In the first instance, authors are encouraged to provide equivalent functionality for all forms of input by responding to high-level events such as focus, blur and click. However, when using low-level events (such as Pointer Events), authors are encouraged to ensure that all types of input are supported. In the case of keyboards and keyboard-like interfaces, this might require the addition of explicit keyboard event handling. See WCAG 2.0 Guideline 2.1 for further details." My one concern with calling touch+AT "keyboard-equivalent" is that this scenario does not fire any actual "faked" keypresses, so technically not quite accurate. Then again, maybe this can be addressed in the glossary definition and handwaved/papered over, as it's really the end result (that it moves the accessibility focus/caret around) that matters here. 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 Friday, 8 July 2016 09:54:55 UTC