WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Must elements with onclick handlers be focusable?

for

From: Detlev Fischer
Date: Jul 22, 2014 9:35AM

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