WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Must elements with onclick handlers be focusable?

for

From: Jonathan Avila
Date: Jul 22, 2014 6:41AM

Alistair, this is a good question and one that we have to weigh the cost of before making a decision. In our Accessibility Management Platform (AMP) we have a type of automatic violation called a "guided automatic" violation. These are potential violations that the automated checker finds but these violations are not marked as failures unless a human specifically marks them as a failure.

Use of onclick is a significant barrier and use without other events signal a very highly likelihood that there would be an accessibility issues. So if these were not flagged by a checker then all of them would need to be located manually and tested manually. With guided automatic violations the human doesn't need to locate all of these as the checker has already done that. Thus, the tester only need manually validate them. This saves time and if you were manually testing you'd have to check all of them too.

When we consider automatic testing we try to work smarter and not harder -- that is, we try to find potential issues that are likely to be accessibility issues and warn the tester. Occasionally some items are indicated as automatic failures that are not but the effort to test these is less than the amount of work to manually locate and inspect all of the items without an automatic check. Platform's such as AMP can also detected issues that occur across pages or identify issues that are likely to be global issues across a site. Being able to identify issues that are global or patterns is a key feature we use to efficiently audit web pages. The amount of testing that is needed is very large compared to the human resources that are available and thus we need to find the correct balance between automated/semi-automated tools and human inspection to effectively and accurately validate web accessibility.

Good accessibility checkers will also allow you to filter out certain XPaths and/or update tests. For example, organizations can update their own AMP tests and in this case you could ignore elements with onclick that have descendants that have an onclick coupled with a device independent handler.

Jonathan

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Alastair Campbell
Sent: Tuesday, July 22, 2014 6:00 AM
To: WebAIM Discussion List
Subject: [WebAIM] Must elements with onclick handlers be focusable?

Hi,

I've been using a lot of tools recently, for obvious reasons[1], and quite a few seem to over-report this issue:
"Elements with onclick handlers must be focusable"

However, there seem to be quite a few situations where this is not an issue. For example, if this is a shortened version of the HTML markup:

<div>
<h2><a href="valid/page.html">Heading of story</a></h2> <img alt="nice description src="image.jpg"> <p>Excerpt from the story.</p> </div>

If you then use JavaScript to make the whole div clickable based on the heading-link, that is a nice feature that increases the hit-area dramatically, and prevents making multiple links to the same target.

IMHO the keyboard experience is no different, and can be better as you can make the whole box visually different as you tab through.

Do other people consider this a false positive?

-Alastair

1] http://www.accessibilityassociation.org/content.asp?contentid=183

PS. I know that in HTML5 you could wrap the whole thing in a link, but that breaks down if you then have a different link in the paragraph, but it's fine with JavaScript.