New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NVDA repeats the word "clickable" several times in a row before just saying what the item is. #7430
Comments
While this certainly isn't a new discovery and I don't believe this is the first time it has been reported either, can @jcsteh, @feerrenrut and @LeonarddeR please take a look? |
Problem:
Explanation:
Possible fixes:
|
Choosing a solution: Report clickable only for nodes which effectively contain only textThe most ideal solution theoretically. The problem is that for technical reasons, we can probably only do this if the node is within the current line; i.e. we wouldn't report clickable if the text spanned multiple lines. That might be a problem for long link-like things or clickable paragraphs. Report clickable only when entering the outermost elementVery clear, simple, unambiguous. However, with the rising prevalence of clickable on high ancestors, I'm not sure how useful this would be; you might just get "clickable" once at the start of a big region and then never again. Disabling reporting of clickable by defaultClear and simple. Clickable is going to be inaccurate in at least some use cases no matter what we do. However, users might not know when they need to enable it. It will also probably be unpopular, especially since other screen readers report clickable. Report clickable for any text without enclosing semanticsIf click handler is on a high ancestor, clickable will get reported for almost all "text" on the page. I don't think this is a reasonable option given that this pattern is becoming more common. Collapsing clickablesSuffers from asymmetry/ambiguity; doesn't eliminate multiple clickables interspersed with other semantics. |
@feerrenrut What's the difference between Chrome/Firefox here? Is Firefox filtering out clickables through the tree if they are only set on the parent? I think the solution that would match the Firefox behavior, either as fix in Chrome or NVDA, would be the prefered one. This is what users might expect already from Firefox usage and in my experience in Firefox it works fine. |
@bramd, in short this also effects Firefox. One of the first steps for resolving this issue is to provide a full set of examples to exercise all the known use cases. I have updated the description of this issue with a sample that demonstrates the problem. |
Chrome here. We currently have an issue open to address this issue, and can expose things like Firefox does, or however the community agrees we should do it. One thought was that we continue to expose the click action on the root of a subtree with a click handler, and expose a different action, like "click-descendant" for the subtree descendants. In any case, we want to fix this on our side as well. |
The issue of repeating the word "clickable" several times is, in particular, something which can be duplicated and observed with Google Chrome. I'm using Chrome V63.0. |
@amirsol81 please try in Chrome Canary. This should be fixed now. Sorry for the annoying bug :) |
I think it is wrong to assume that everything with a click listener on it is going to be meaningful to the user, and that it should be announced. I have code that looks for clicks on elements that are not a fly-out menu, and when it receives them it closes the fly-out menus. 99% of the clicks do nothing, because most of the time those menus aren't open. I have several other utility click handlers on the same complex page that are not really there for overt interaction in the way clicking a button is. I even have something that records all clicks or keypresses on all elements, in order to determine when a focus outline should be drawn for certain element types (only when a keypress happens right before the focus, similar to how OS X handles focus rings natively). IMO, the only things that should be announced as clickable are things that are focused, and not all their ancestors. |
This same thing is happening to me. I'm using a screen reader for accessibility testing, and half of the items say "clickable" 6-8 times before announcing what the item is. Some of these items are NOT clickable. That's the weird thing. |
I have seen at least 3 people (in a limited setting as well) use competitors screen readers instead of NVDA because of this. This needs fixed badly, or removed. It quite literally is losing us users by the dozens. |
I agree with @derekriemer’s assessment. If people have to turn the feature off because it’s incredibly disruptive, it might as well not be there. At the very least, I recommend disabling the announcement by default until it’s fixed. Let users enable it if they so wish. There are several sites where I can find a good use for this feature but don’t use it because it’s too disruptive in other places.
|
I am one of those who have to use other screenreaders summtimes to get
around this
…On 12/04/2018 06:24 a. m., Derek Riemer wrote:
I have seen at least 3 people (in a limited setting as well) use
competitors screen readers instead of NVDA because of this. This needs
fixed badly, or removed. It quite literally is losing us users by the
dozens.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#7430 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/API6eX6L01kw6VcfQr5vq7RbZ462tv5Sks5tn0dwgaJpZM4OgEi6>.
|
Interesting. I am not visually impaired, but I downloaded a screenreader because I am a UX designer who is trying to design with accessibility in mind! This has been frustrating for ME, and I have the visuals to go along with it so I can "cheat" if I have to. I can't imagine how obnoxious and confusing this would be for my users who are actually seeing impaired. I have turned off the feature, but I can't guarantee that my users do. JAWS is so expensive; I hope NVDA continues to improve for the sake of the many people out there using screen readers. Note -- I also like Mac's screen reader, which is much more intuitive and includes helpers. There is still a huge learning curve for navigating using a keyboard + screen reader, regardless of the software. |
In some pages, NVDA repeats the word clickable several times before saying what the clickable item is. Something like: "clickable clickable clickable clickable clickable clickable clickable clickable click here to begin."
For example: go to
my.snhu.edu
. From the top of the page, pressf
to go to the next form field.NVDA uses the word "clickable" eight times in the course of saying I landed on an edit box that is titled: "search this site." This is, I am sure, because of bad web design, but NVDA should cope with this and not say the word "clickable" more than once per item, and never for form controls, at least, it seems obvious that a button or text field is clickable, this is how one interacts with them.
Edit
Since I am not able to reproduce this via
snhu.edu
site, consider the following example (paste into the address bar in Firefox or Chrome):data:text/html,<p>text before the clickable div</p><div onClick=";"><div onClick=";">This is some text before the button <br /><button>foo</button></div> bar</div><p>This is the paragraph</p>
f
to jump to the button.Actual behaviour:
Chrome
Firefox
The text was updated successfully, but these errors were encountered: