WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Must elements with onclick handlers be focusable?

for

From: Birkir R. Gunnarsson
Date: Jul 22, 2014 8:45AM

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 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
>>
>> -----Original Message-----
>> From: <EMAIL REMOVED>
>> [mailto: <EMAIL REMOVED> ] On Behalf Of Alastair
>> Campbell
>> Sent: Tuesday, July 22, 2014 8:54 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Must elements with onclick handlers be focusable?
>>
>> 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
>> >> >> messages to <EMAIL REMOVED>
>>
>>
>>
>>
>> This electronic message contains information generated by the USDA solely
>> for the intended recipients. Any unauthorized interception of this message
>> or the use or disclosure of the information it contains may violate the
>> law and subject the violator to civil or criminal penalties. If you
>> believe you have received this message in error, please notify the sender
>> and delete the email immediately.
>> >> >> >>
>
>
> --
> 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.