Re: Keyboard accessible links without onclick or functioning href

+1

Katie Haritos-Shea
703-371-5545

On Jul 9, 2017 6:09 PM, "Patrick H. Lauke" <redux@splintered.co.uk> wrote:

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