RE: Keyboard accessible links without onclick or functioning href

It seems that the links, as described, being incompatible with most screen readers due to the lack of a click event handler, fail item 1 of the definition of “accessibility supported” in WCAG 2.0. That is, they aren’t meeting 2.1.1 in an accessibility-supported way. The definition reads:



“The way that the Web content technology<https://www.w3.org/TR/WCAG20/#technologydef> is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s)<https://www.w3.org/TR/WCAG20/#human-langdef> of the content, […]”

From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
Sent: Monday, July 10, 2017 10:40 AM
To: Jonathan Avila <jon.avila@levelaccess.com>; WCAG <w3c-wai-gl@w3.org>
Subject: Re: Keyboard accessible links without onclick or functioning href

Jon,
I do think that WCAG 2.0 allows custom links, but as you know the bar is high to address all of the needs for users. This feels like an “accessibility supported” question.

If I invent  way to include a link in a page I need to address keyboard support, mouse/pointer support, and name/role/value at least. Naturally, if I go this route I will need to be paying much closer attention to how the variety of user agents handles these, including in combination with AT, and I lose a lot of the built-in support for anchor elements in HTML.

At first glance, this seems most related to the “keyboard support with AT” SC proposal concept.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk


From: Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>>
Date: Sunday, July 9, 2017 at 15:26
To: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Keyboard accessible links without onclick or functioning href
Resent-From: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Resent-Date: Sunday, July 9, 2017 at 15:26

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?

Best Regards,

Jonathan


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________