WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: screen reader announcing clickable

for

From: Tim Harshbarger
Date: Sep 15, 2016 10:00AM

I personally think they should just remove the feature or turn it off by default.

If I recall correctly, when JAWS and other screen readers initially added the feature, it was in response to situations where developers were adding click events to spans and divs to have them behave like buttons and links. However, when developers started creating more complex widgets with javascript (like treeviews,) they started using the technique more frequently where the event listener was placed on the parent element (instead of adding event listeners to every element inside the parent element.)

I suspect screen reader users hear "clickable" so much now (and it so frequently doesn't mean anything) that the information just adds to the noise of the page. It would probably be better just to remove the feature while providing screen reader users a feature that allows them to click on whatever element the screen reader is focused on. Most of the time, the spans and divs being used for something like a link or button provide some indication that they are actionable through their wording. That still isn't as good as explicitly providing a button or link. However, it is understandable that AT vendors would want to add features to their AT that help users with the large amount of inaccessible content that is out there.

Thanks,
Tim

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Aaron Cannon
Sent: Thursday, September 15, 2016 9:47 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] screen reader announcing clickable

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