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