Re: Proposal: expanding/modifying Guideline 2.1 and its SCs (2.1.1, 2.1.2, 2.1.3) to cover Touch+AT

Hi everyone,

I joined this email list just after the lengthy discussion, I won’t re-hash but there are just three quick (new) points:

Firstly, I’ve followed the development of the different JavaScript-events (from keyboard, mice and touch) at a cursory level, but I know Patrick has done many deep-dives on this and I would defer to his understanding of how the different input scenarios work on the web.

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. I remember thinking when ‘touch’ events started appearing that this could be a difficult development for accessibility, but combining mouse & touch into “pointer” events appears to be the solution. Using the higher-level events like focus/blur/click also helps make interfaces more robust to different scenarios.

Secondly, in principle I agree with updating the SCs as Patrick suggested, the more input-neutral we can make the normative language the more robust it will be long term.
If it is impossible to update the keyboard SC, then I would propose adding something in the ‘Robust’ section (4.x) that basically says “Anywhere we say keyboard, check it works on touch or other new devices to”. However, that will look like we should have just updated the SCs.

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”.

Cheers,

-Alastair

1] https://www.w3.org/2012/pointerevents/


--

Alastair Campbell

www.nomensa.com
follow us: @we_are_nomensa or me: @alastc