W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2015

Re: Event Listeners Accessibility Question

From: Patrick H. Lauke <redux@splintered.co.uk>
Date: Wed, 16 Dec 2015 20:15:56 +0000
To: w3c-wai-ig@w3.org
Message-ID: <5671C67C.4020708@splintered.co.uk>
On 16/12/2015 19:39, Jim wrote:
> Hi,
> I'm looking at a situation in which there is an event listener on the
> body of an HTML document, that allows the user to click anywhere
> outside a document section and close it. That event is causing screen
> readers to report clickable all over the document. I have taken the
> position that wherever clickable is reported, that the element fails
> for 2.1.1. That doesn't seem reasonable to me, though, because that
> may cause items to repport that they are clickable, when they are not
> actually controls. How should this kind of thing be reported on from a
> testing viewpoint, and how should the developer fix this?

I wouldn't personally say it's a hard failure of any particular SC, but 
a quirk of current AT implementation. I suspect that this would also 
happen for sites that use event delegation, which is a recommended and 
recognised technique for handling events on large documents (instead of 
binding 100s of events to individual elements, you rely on event 
bubbling, register only a single event on an ancestor, then disambiguate 
in the JS by checking the original target of the event). As such I'd say 
it's non-ideal behavior on the part of screen readers to report 
everything as being clickable.

If this were part of an audit, I'd note it in the report, but there's no 
straightforward solution short of NOT using event delegation or similar 

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 Wednesday, 16 December 2015 20:16:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 December 2015 20:16:29 UTC