E-mail List Archives
Thread: screen reader announcing clickable
Number of posts in this thread: 18 (In chronological order)
From: Brandon Keith Biggs
Date: Wed, Sep 14 2016 12:09AM
Subject: screen reader announcing clickable
No previous message | Next message →
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 ADDRESS 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.
> > > > >
From: Nick Allan
Date: Wed, Sep 14 2016 12:36AM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
Thanks for that. I thought that would be the case.
Nick
From: Paul Collins
Date: Wed, Sep 14 2016 12:43AM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
Hi Nick,
Without being able to see the code and how the click handler is
implemented, I am assuming the click event is bubbling up the dom tree to
the parent DIV, when the paragraphs are clicked.
If so, it would be worth looking into the following two Javascript DOM API
events and how JAWS deals with them:
event.stopPropogation:
https://developer.mozilla.org/en/docs/Web/API/Event/stopPropagation
event.preventDefault:
https://developer.mozilla.org/en/docs/Web/API/Event/preventDefault
Hope that will be of some help, feel free to ask more questions!
Cheers,
Paul
On 14 September 2016 at 16:09, Brandon Keith Biggs <
= EMAIL ADDRESS REMOVED = > wrote:
> 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 <Nick.Allan@visionaustralia.
> org>
> 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.
> > > > > > > > > >
> > > > >
From: Moore,Michael (Accessibility) (HHSC)
Date: Wed, Sep 14 2016 7:56AM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
This is very common. Many web "applications" and services have a click event attached to the body element which makes screen readers announce everything on the page a "clickable" a noisy nuisance to screen reader users but something that in interaction with people who depend on screen readers for access is that it is just that a noisy nuisance. What is much worse for these users is when the actual controls do not have accurate roles, accessible names or actions that will respond to keyboard events. These are real barriers to accessibility.
Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
From: Jamous, JP
Date: Wed, Sep 14 2016 8:22AM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
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
**************************************************
From: Dominic Capuano (gmail)
Date: Wed, Sep 14 2016 12:45PM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
Nick;
Are you able to remove the event from the upper level div?
Dominic Capuano
= EMAIL ADDRESS REMOVED =
(h)(401) 726-2551
From: Wee, Kim (MNIT)
Date: Wed, Sep 14 2016 12:48PM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
Wondering if this is a web page or an eLearning module displayed in the browser. I ask because I have found this same issue with eLearning modules created in Captivate and published as HTML5
KIM WEE | Webmaster and Accessibility Coordinator
MN.IT Services @ Education
651-582-8548 (w) | = EMAIL ADDRESS REMOVED =
Information Technology for Minnesota Government | mn.gov/mnit
From: Lucy Greco
Date: Wed, Sep 14 2016 1:53PM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
telling users to set there verbosaty to not speack the event is the rong
thing in every sence of the word. if a user sets there verbosaty to not
speak these events they will miss the times its a reel clickable event so
its got to be used with care and make sure only the item that is clickable
is speaking it lucy
Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces
On Wed, Sep 14, 2016 at 11:48 AM, Wee, Kim (MNIT) < = EMAIL ADDRESS REMOVED = >
wrote:
> Wondering if this is a web page or an eLearning module displayed in the
> browser. I ask because I have found this same issue with eLearning modules
> created in Captivate and published as HTML5
>
> KIM WEE | Webmaster and Accessibility Coordinator
> MN.IT Services @ Education
> 651-582-8548 (w) | = EMAIL ADDRESS REMOVED =
> Information Technology for Minnesota Government | mn.gov/mnit
>
>
From: Aaron Cannon
Date: Wed, Sep 14 2016 3:30PM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
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 ADDRESS 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
>
> **************************************************
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
From: Aaron Cannon
Date: Wed, Sep 14 2016 3:34PM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
The stopPropagation and preventDefault methods can only be called once
an event handler has been fired. Unfortunately, the screen reader
makes the determination of what it thinks is clickable long before
this happens, so I'm afraid that these methods aren't likely to be of
much help.
Aaron
On 9/14/16, Paul Collins < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Nick,
>
> Without being able to see the code and how the click handler is
> implemented, I am assuming the click event is bubbling up the dom tree to
> the parent DIV, when the paragraphs are clicked.
>
> If so, it would be worth looking into the following two Javascript DOM API
> events and how JAWS deals with them:
>
> event.stopPropogation:
> https://developer.mozilla.org/en/docs/Web/API/Event/stopPropagation
> event.preventDefault:
> https://developer.mozilla.org/en/docs/Web/API/Event/preventDefault
>
> Hope that will be of some help, feel free to ask more questions!
>
> Cheers,
> Paul
>
> On 14 September 2016 at 16:09, Brandon Keith Biggs <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> 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 <Nick.Allan@visionaustralia.
>> org>
>> 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.
>> > >> > >> > >> > >> >
>> >> >> >> >>
> > > > >
From: Jim Homme
Date: Wed, Sep 14 2016 5:04PM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
Hi,
This issue could be somewhat controversial. I know that hearing the word clickable is annoying, confusing, or both, to screen reader users, but there could be a compromise solution. Usually, when developers use this technique, in my experience at any rate, they intend for the user to click anywhere on a web page except some area, possibly to close it, for example. This behavior benefits people with motor disabilities and older people who can use a mouse, but not as accurately as a young person with good hand-eye coordination. The compromise may be to only make the page exhibit the bubbling behavior when the desired situation occurs. We screen reader users tend to be vocal and get lots of attention, and many times for god reason, but we are in the minority of people who would like to have their version of web accessibility.
Jim
=========Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O
From: Paul Collins
Date: Wed, Sep 14 2016 7:11PM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
Hi Aaaron
Thanks, that's a very good point - Interesting to know that because the
event has been delegated by the parent div, therefore JAWS decides that all
child elements now have a click event assigned.
If you are still struggling to solve it, It would be good to look at the
code and to get an understanding of why and how the click event is being
applied to the div, as there might be a few solutions and it's might be
down to the limitations of what you can change in your codebase, Nick.
Thanks,
Paul
On 15 September 2016 at 07:34, Aaron Cannon < = EMAIL ADDRESS REMOVED = >
wrote:
> The stopPropagation and preventDefault methods can only be called once
> an event handler has been fired. Unfortunately, the screen reader
> makes the determination of what it thinks is clickable long before
> this happens, so I'm afraid that these methods aren't likely to be of
> much help.
>
> Aaron
>
> On 9/14/16, Paul Collins < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi Nick,
> >
> > Without being able to see the code and how the click handler is
> > implemented, I am assuming the click event is bubbling up the dom tree to
> > the parent DIV, when the paragraphs are clicked.
> >
> > If so, it would be worth looking into the following two Javascript DOM
> API
> > events and how JAWS deals with them:
> >
> > event.stopPropogation:
> > https://developer.mozilla.org/en/docs/Web/API/Event/stopPropagation
> > event.preventDefault:
> > https://developer.mozilla.org/en/docs/Web/API/Event/preventDefault
> >
> > Hope that will be of some help, feel free to ask more questions!
> >
> > Cheers,
> > Paul
> >
> > On 14 September 2016 at 16:09, Brandon Keith Biggs <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> 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 <Nick.Allan@visionaustralia.
> >> org>
> >> 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.
> >> > > >> > > >> > > >> > > >> >
> >> > >> > >> > >> > >>
> > > > > > > > > >
> > > > >
From: Moore,Michael (Accessibility) (HHSC)
Date: Thu, Sep 15 2016 8:38AM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
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)
From: Aaron Cannon
Date: Thu, Sep 15 2016 8:47AM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
Hi Mike.
Yes, agreed. Definitely a difficult undertaking, to say the least. :)
Aaron
On 9/15/16, Moore,Michael (Accessibility) (HHSC)
< = EMAIL ADDRESS 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)
>
>
From: Tim Harshbarger
Date: Thu, Sep 15 2016 10:00AM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
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
From: Jamous, JP
Date: Thu, Sep 15 2016 10:05AM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
I second Tim and add that any objects that will have onclick must have a role associated with them that identifies the type of object it should be.
<div role="button" onclick="ClickMe();">
Check out your rewards
</div>
**************************************************
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
**************************************************
From: Dominic Capuano (gmail)
Date: Thu, Sep 15 2016 3:10PM
Subject: Re: screen reader announcing clickable
← Previous message | Next message →
Kim;
I observed this Adobe Captivate as well and suggest possible solutions here:
https://www.linkedin.com/pulse/adobe-captivate-9-everything-clickable-even-dominic-capuano?trk=prof-post
Dominic Capuano
= EMAIL ADDRESS REMOVED =
(h)(401) 726-2551
From: Nick Allan
Date: Thu, Sep 15 2016 10:50PM
Subject: Re: screen reader announcing clickable
← Previous message | No next message
Hi all
Thanks everyone for the info on this. I've gotten the developer to remove the click event from the parent div, so in this particular case the issue has been resolved, but I'm seeing this more and more though.
Nick