E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Alastair Campbell
Date: Tue, Jul 22 2014 3:59AM
Subject: Must elements with onclick handlers be focusable?
No previous message | Next message →

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.

From: Patrick H. Lauke
Date: Tue, Jul 22 2014 4:21AM
Subject: Re: Must elements with onclick handlers be focusable?
← Previous message | Next message →

On 22/07/2014 10:59, Alastair Campbell wrote:
> 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"
[...]
> Do other people consider this a false positive?

It depends on the exact structures used. In general, it seems a very
facile simplification to generalise "if there's onclick it must be
focusable" ... it's not something that can be easily machine-tested, so
tools shouldn't pretend that they can.

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

From: Birkir R. Gunnarsson
Date: Tue, Jul 22 2014 6:20AM
Subject: Re: Must elements with onclick handlers be focusable?
← Previous message | Next message →

onclick events on non-focusable elements (along with or hover events
on focusable ones) can be one of the most significant barriers to web
accessibility, when the action is crusial to achieving the end user
goals.
Just to name a recent example. I was unable to contact Groupon via an
online feedback form because the only way to pop up their "contact us"
menu is by hovering the mouse over a link that when double clicked
does something completely different.
I also recently saw a banking website (not in the U.S. or Canada),
that implemented all its user actions as anchors with no href
attribute but attached onclick events, which completely prevents
keyboard-only end users from being able to carry out anything except
logging in.
My point is that these types of constructs, when the onclick event
does something significant or meaningful, are one of the worst
accessibility boo boos, so any audit, be it manual or automated, has
to be on the lookout for these types of issues.

So I support the need for them to always alert the end user of these
types of situations.
Whether they should automatically be flagged as violations necessarily
is a different matter altogether.
Basically, we have to ask ourselves, can we make these tools smarter?
Can they detect and interpret Javascript patterns and understand the
purpose of the onclick functionality?
Tall order, but it is conceivable that certain patterns of Javascript
could be recognized.
Cheers.
-B


On 7/22/14, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 22/07/2014 10:59, Alastair Campbell wrote:
>> 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"
> [...]
>> Do other people consider this a false positive?
>
> It depends on the exact structures used. In general, it seems a very
> facile simplification to generalise "if there's onclick it must be
> focusable" ... it's not something that can be easily machine-tested, so
> tools shouldn't pretend that they can.
>
> 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
> > > >


--
Work hard. Have fun. Make history.

From: Jonathan Avila
Date: Tue, Jul 22 2014 6:41AM
Subject: Re: Must elements with onclick handlers be focusable?
← Previous message | Next message →

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

From: Alastair Campbell
Date: Tue, Jul 22 2014 7:53AM
Subject: Re: Must elements with onclick handlers be focusable?
← Previous message | Next message →

Birkir R. Gunnarsson wrote:

> Basically, we have to ask ourselves, can we make these tools smarter?
> Can they detect and interpret Javascript patterns and understand the
> purpose of the onclick functionality?
>
>
I guess the point is that it can only "flag" them, they can't be confirmed
issues.

To detect this pattern, it would have to detect the onclick, work out that
the script forwards to a particular URL, and check if that link is
available to the keyboard user. Tall order indeed!

On the other hand, as Jonathan suggested: If you could provide an Xpath or
CSS selector for things to ignore for that issue, that would be a lot
easier.

-Alastair

From: Stanzel, Susan - FSA, Kansas City, MO
Date: Tue, Jul 22 2014 8:00AM
Subject: Re: Must elements with onclick handlers be focusable?
← Previous message | Next message →

Good morning Listers,

Can anyone point me to something which would tell me the proper way to fix such problems. I am now confused whether CSS or JavaScript is the right solution. We are getting WorldSpace and I am sure I will be asked how to fix such problems.

Susie Stanzel

From: Patrick H. Lauke
Date: Tue, Jul 22 2014 8:21AM
Subject: Re: Must elements with onclick handlers be focusable?
← Previous message | Next message →

On 22/07/2014 15:00, Stanzel, Susan - FSA, Kansas City, MO wrote:
> Good morning Listers,
>
> Can anyone point me to something which would tell me the proper way to fix such problems. I am now confused whether CSS or JavaScript is the right solution. We are getting WorldSpace and I am sure I will be asked how to fix such problems.

Just as there is no single pattern that can be recognised reliably,
there is also no single solution. In short, there has to be some way to
use the keyboard and also trigger the same behavior that would happen if
the user tapped with a finger/clicked with a mouse on a non-focusable
element with a click handler (note it doesn't necessarily have to be an
onclick attribute...it could be an event listener added programmatically
to the element, or even - if event delegation is used, such as in jQuery
etc - to a parent/ancestor only).

One solution *could* be to add tabindex="0" to the element in question,
making it focusable (but then also adding relevant role="..." attribute
and attaching any other default behavior expected for an element of that
role). Another may be to simply have another focusable element (which
may be a child element, or a completely separate element somewhere else
in the document) that does the same thing. Plus about 100 other
variations on this theme...

P

> Susie Stanzel
>
>

From: Birkir R. Gunnarsson
Date: Tue, Jul 22 2014 8:45AM
Subject: Re: Must elements with onclick handlers be focusable?
← Previous message | Next message →

There is no single magic solution to this problem, it depends on what
the onclick event does.
I like how Marco Zehe describes the problem an the basic elements of
the solution:
http://www.marcozehe.de/2013/04/24/easy-aria-tip-6-making-clickables-accessible/

But sometimes, when the onclick event triggers pop up menus other aria
properties such as aria-haspopup/aria-expanded need to be added to the
mix.

When the onclick event does not activate a link or a button the
recommendations may not apply and other methods need to be used to
address the specific issue.
Sometimes nothing needs to be done (such as in the instances described
on this thread).
Accessibility is an interesting field.
Cheers
-Birkir



On 7/22/14, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 22/07/2014 15:00, Stanzel, Susan - FSA, Kansas City, MO wrote:
>> Good morning Listers,
>>
>> Can anyone point me to something which would tell me the proper way to fix
>> such problems. I am now confused whether CSS or JavaScript is the right
>> solution. We are getting WorldSpace and I am sure I will be asked how to
>> fix such problems.
>
> Just as there is no single pattern that can be recognised reliably,
> there is also no single solution. In short, there has to be some way to
> use the keyboard and also trigger the same behavior that would happen if
> the user tapped with a finger/clicked with a mouse on a non-focusable
> element with a click handler (note it doesn't necessarily have to be an
> onclick attribute...it could be an event listener added programmatically
> to the element, or even - if event delegation is used, such as in jQuery
> etc - to a parent/ancestor only).
>
> One solution *could* be to add tabindex="0" to the element in question,
> making it focusable (but then also adding relevant role="..." attribute
> and attaching any other default behavior expected for an element of that
> role). Another may be to simply have another focusable element (which
> may be a child element, or a completely separate element somewhere else
> in the document) that does the same thing. Plus about 100 other
> variations on this theme...
>
> P
>
>> Susie Stanzel
>>
>>

From: Detlev Fischer
Date: Tue, Jul 22 2014 9:35AM
Subject: Re: Must elements with onclick handlers be focusable?
← Previous message | No next message

There can also be other situations where it can be advantageous to have elements respond to mouse and touch only and not put them in the focus order - even in constellations that are not nested as in Alastair's example. Think of redundant browse (back and forward arrow) buttons in image carussels - if the images (and their alt texts) itself can be traversed by tabbing, there seems to be little point in making those browse buttons keyboard-accessible, too. But others may disagree….

So I agree with Alastair that the occurrence of non-focusable elements with onclick handlers should not be automatically flagged as error (as others pointed out, this will need human inspection of context).

Detlev

On 22 Jul 2014, at 15:53, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:

> Birkir R. Gunnarsson wrote:
>
>> Basically, we have to ask ourselves, can we make these tools smarter?
>> Can they detect and interpret Javascript patterns and understand the
>> purpose of the onclick functionality?
>>
>>
> I guess the point is that it can only "flag" them, they can't be confirmed
> issues.
>
> To detect this pattern, it would have to detect the onclick, work out that
> the script forwards to a particular URL, and check if that link is
> available to the keyboard user. Tall order indeed!
>
> On the other hand, as Jonathan suggested: If you could provide an Xpath or
> CSS selector for things to ignore for that issue, that would be a lot
> easier.
>
> -Alastair
> > > --
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
Thedestraße 2
22767 Hamburg

Tel +49 (0)40 439 10 68-3
Mobil +49 (0)1577 170 73 84
Fax +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites