WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: screen reader announcing clickable

for

From: Aaron Cannon
Date: Sep 15, 2016 8:47AM

Hi Mike.

Yes, agreed. Definitely a difficult undertaking, to say the least. :)

Aaron

On 9/15/16, Moore,Michael (Accessibility) (HHSC)
< <EMAIL REMOVED> > wrote:
> Thanks for the explanation Aaron. I thought that I had read something
> similar before. That being the case, that the broad click handler includes
> logic that determines what exactly was clicked and how to respond to it
> would mean that to determine whether or not to report an object as clickable
> the screen reader would need to be able to parse the JS click handler and
> then either set of a directory of which objects were actually actionable and
> report those. I suspect that this would be very difficult technologically,
> may be blocked by browser security features, and would probably result in
> major performance and stability issues...
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of Aaron Cannon
> Sent: Wednesday, September 14, 2016 4:31 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] screen reader announcing clickable
>
> Hi.
>
> I don't believe that this behavior is a bug in either Jaws or NVDA.
> Here's the problem. One of the more common accessibility issues,
> particularly on more dynamic pages, is developers failing to use links or
> buttons when they should. Instead, what they'll do is just make a div or
> span clickable via JavaScript. So it seems quite natural that screen reader
> manufacturers would assume that when something has a click listener on it,
> it should be announced as clickable.
>
> The problem with this approach, as others have noticed, is that just because
> something has a click handler on it, that doesn't necessarily mean that it
> responds to clicks. What many JavaScript frameworks do is put a click
> handler on a single parent element, so they can capture any clicks that
> happen inside it. When they receive a click on that handler, they can then
> check to see if the child element that was actually clicked on should do
> anything in response. The reason, as I understand it, that frameworks do
> this, is because the more click handlers you add to the DOM, the less
> performant some browsers become.
>
> I suppose that screen readers could try to use some smarter heuristics to
> try to figure out the difference, but it's certainly not an easy problem.
>
> Aaron
>
> On 9/14/16, Jamous, JP < <EMAIL REMOVED> > wrote:
>> Nick,
>>
>> I tested this bad boy heavily using JAWS and NVDA back in July. It is
>> not related to the browser rather to the screen reader. You'll know why
>> soon.
>>
>> Onclick and onmouseover fire up this annoying message. JAWS handles it
>> one way in IE and a different way in Firefox. NVDA on the other hand,
>> does not discriminate against onclick. It reports it in both browsers,
>> but it would not report the onmouseover in IE. Only in Firefox.
>>
>> I might have gotten the above reversed, that's because it has been a
>> while.
>> However, if you do this test, you will notice the same behavior.
>>
>> The issue here is that both screen readers replicate the events down
>> the markup tree. So any P elements within the div element are reported
>> as clickable by screen readers. In reality if you click on them with a
>> regular mouse, they do nothing. That is another definite evidence that
>> it is related to screen readers and not browsers.
>>
>> Again, I might have the above reversed because I have my test results
>> on another PC. I pulled the above from memory. I do want to report
>> this to Freedom Scientific soon. Personally, I don't appreciate paying
>> for SMAs and not getting a good product.
>>
>> What I don't like about this announcement is that not all screen
>> reader users are as advanced as most of us are. They may not know how
>> to set the verbosity level. Additionally, it is incorrect feedback
>> from the screen reader.
>>
>>
>>
>>
>> **************************************************
>>
>> Jean-Pierre Jamous
>> Digital Accessibility Specialist & Developer UI Accessibility Team
>>
>> SME for EBN Include
>> Digital Accessibility Specialist & Blind and Visually Impaired Expert
>>
>> The only limitations in life are those we set for ourselves
>>
>> **************************************************
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>> Behalf Of Brandon Keith Biggs
>> Sent: Wednesday, September 14, 2016 1:09 AM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] screen reader announcing clickable
>>
>> Hello,
>> The clickable element means that everything inside it will be
>> clickable. It doesn't matter if anything is attached to it, it is
>> clickable. I'm not sure if there is any way for a screen reader to
>> recognize if something happens when an element is pressed, but I doubt
>> it. If that clickable didn't show, a screen reader user would never know
>> anything in that element was clickable.
>> The only way to get rid of this is to just wrap the part that will get
>> a click in a clickable div and remove the event from higher up the tree.
>> Thanks,
>>
>>
>> Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
>>
>> On Tue, Sep 13, 2016 at 8:59 PM, Nick Allan
>> < <EMAIL REMOVED> >
>> wrote:
>>
>>> Hi all
>>> I'm doing some testing on a web page where a section has paragraphs
>>> of text that all announce clickable when you arrow through it using
>>> jaws.
>>> There is a div a few levels up in the dom that has a click event
>>> attached to it according to firebug in firefox.
>>> I assume this is why the text is saying clickable. Is there any
>>> method to stop a screen reader announcing clickable other than
>>> verbosity settings in the screen reader? clicking on the text doesn't
>>> actually do anything.
>>>
>>> Any suggestions would be welcome.
>>>
>>>
>>>
>>>
>>> Nick Allan
>>> Specialist Support
>>> Vision Australia
>>> 454 Glenferrie road
>>> Kooyong Vic. 3144
>>> P: 1300 84 74 66
>>> www.visionaustralia.org<;http://www.visionaustralia.org>;
>>>
>>>
>>> [http://www.visionaustralia.org/images/default-source/
>>> Email-signature-banners/digital-accessibility-toolkit.
>>> jpg?Status=Temp&sfvrsn=4]
>>> <http://www.visionaustralia.org/business-and-
>>> professionals/digital-access-consulting/accessibility-toolkit>
>>>
>>> Vision Australia's Accessibility Toolkit - Resources to help
>>> businesses understand and implement digital accessibility
>>> www.visionaustralia.org/ accessibilitytoolkit
>>>
>>> ABN: 67 108 391 831 ACN: 108 391 831
>>>
>>> Vision Australia, supporting people who are blind or have low vision
>>> to live the life they choose. This email (including its attachments)
>>> is confidential and may contain legally privileged material or
>>> personal information. If you are not a named addressee you must not
>>> use, disclose, copy, disseminate or print the email or any
>>> information in it. If you have received this email in error please
>>> notify us immediately and delete the email and any copies. Vision
>>> Australia is not responsible for any changes made to a document other
>>> than those made by Vision Australia or for the effect of the changes
>>> to the document's meaning. Vision Australia accepts no liability for
>>> any damage caused by this email or its attachments due to viruses,
>>> interference, interception, corruption or unauthorised access.
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > http://webaim.org/discussion/archives
> > > > > >