- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Sun, 9 Jul 2017 23:08:17 +0100
- To: w3c-wai-gl@w3.org
On 09/07/2017 20:26, Jonathan Avila wrote: > Historically I have considered links that are keyboard accessible via > onKeyUp or similar mechanism but lack an onclick or working href to be a > failure of accessibility standards. These links are often mouse > accessible as well via a onMouseUp or similar events. These links don’t > work in browser mode with some screen readers unless the enter key is > sent through as typically screen readers programmatically call the click > event or issue some events that appear to be a click. Because of this I > would consider this a lack of accessibility support and potential device > intendent event handling with other assistive technology as well. > Speech input users likely have similar issues and can activate the link > via the keyboard or with a mouse grid but perhaps not with some other > standard commands for activating links by voice such as “click link”. > > As you know – WCAG 2 didn’t address device depend accessibility – but > rather only requires keyboard accessibility – not even mouse access. > This is an issue that has come up with some of the proposed success > criteria for WCAG 2.1 – but I’m not sure they fully address it as it’s > more of a programmatic activation without relying on a keyboard interface. > > Do others see this as a current violation of WCAG 2 – if not – is there > a need to address this in some of the proposed pointer requirements for > WCAG 2.1 or beyond? I originally tried to bring some of these aspects into the MATF work (when I felt the remit should be slightly extended beyond just "mobile" but instead to try and cover various input aspects more holistically). At least part of what you're mentioning above is present in the proposed Pointer SC https://github.com/w3c/wcag21/issues/59, Keyboard with AT SC https://github.com/w3c/wcag21/issues/62 (see in particular the "Techniques" part), and to a lesser extent, Touch with AT SC https://github.com/w3c/wcag21/issues/63 and Concurrent Input Mechanisms SC https://github.com/w3c/wcag21/issues/64 I agree that currently it feels that WCAG 2.0 2.1.1 would allow completely custom keyboard interfaces to pass - interfaces where there are no "real" links or buttons, but where the site/app simply tries to intercept keyboard presses arbitrarily. For instance, I could build something that listens for all key events on the body element (and use lots of behind-the-scenes code to handle a sort of virtual focus that visually highlights certain elements, and fires the correct functionality when user presses ENTER based on where my self-managed virtual focus is etc)...this would pass 2.1.1 as I can use the keyboard, but would not provide anything that works for keyboard+AT users unless the whole site/app is also set into role="application" mode (to make it work on Windows screen readers) or similar extra hacks. And add the fact that on touch devices, users aren't always able to bring up the on-screen keyboard at will (it will only appear when they're in an input or similar widget that accepts text input), so arbitrary keystrokes cannot be fired. This is even true in certain cases for actual physical external keyboard - in iOS, the external keyboard will not generate JavaScript key events unless the user is in a situation where the on-screen keyboard would normally be shown (i.e. a text input or similar). So even in this case, despite the physical keyboard, listening to arbitrary keystroke events won't work for these users. And as you mention, there is still the assumption that mouse/touch will just work, so there's no matching "must work with Pointer Inputs" SC. It is assumed that authors will make it work with these, and that only keyboard is the problem. There is an argument that things built not to work with mouse/touch will affect all users, not just PWD disproportionately, of course. But then it could be an easy SC to pass if it's the base assumption and reality. I'd say it's worth looking at the proposed MATF SCs again, and if you/we feel strongly about these scenarios, see if there's more of an appetite to push for them / modify the proposed SCs to better convey these aspects. 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 Sunday, 9 July 2017 22:08:52 UTC