WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: screen reader announcing clickable

for

From: Aaron Cannon
Date: Sep 14, 2016 3:30PM

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