Re: Keyboard accessible links without onclick or functioning href

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