Turn off clickable announcements by default

[mfairchild365]

Currently, NVDA has clickable announcements turned on by default and can be turned off in settings. JAWS changed (a year or so ago?) and turned off clickable announcements by default.

I get feedback fairly regularly from developers, testers, and end-users that the clickable announcements are distracting at best. I'm wondering if it makes sense for NVDA to turn them off by default.

Sorry if this has already been suggested and discussed. I couldn't find a record of it.

[feerrenrut]

There is some background on #13262, however please don't comment there since the core of that issue is different.

In short it's a trade-off between:

• Over-verbosity
• Ensuring NVDA users are aware of click handlers on pages that don't use semantic markup.
• Informing web developers they are doing something wrong (if something is announced clickable, and shouldn't be, either don't add a click handler or mark the element as role=presentation or role=none), if this was not the default option, how many web developers would notice.

[mfairchild365]

Thank you, @feerrenrut.

This isn’t comprehensive, but in my experience most NVDA users that I personally know, turn off the setting because they don’t find it useful. Some are so annoyed by NVDA’s clickable announcements that they have switched to JAWS. Again, that’s just my personal experience and should be taken with a huge grain of salt. Is there any data on the larger user base?

For web developers, I’ve found that the clickable announcements are more of a distraction than helpful. In many cases, even when the developer uses the correct semantics, clickable announcements are still made. This usually boils down to the developer attaching the JavaScript event listener to an ancestor element, in the name of code reuse, and taking advantage of the browser’s event bubbling feature. For example, there might be an accordion. There is a single click event listener attached to a div that wraps the entire accordion. That listener contains the logic to expand or collapse each section. Rather than attach a unique event listener to each of the 10 buttons in the accordion, the dev attaches a single listener to the container for the entire accordion. Then, when anywhere in the accordion is clicked, the event bubbles up to this listener, which has logic to ignore clicks on anything but the buttons to expand/collapse sections of the accordion. When developers test the experience of this with NVDA and find the clickable announcements, they will often spend hours trying to figure out what they did wrong, only to find out that they didn’t do anything wrong. Then, they learn to ignore these announcements in the future.

Additionally, many accessibility consultants that I know simply ignore these announcements when auditing sites because they are usually a false positive and don’t directly map to WCAG by themselves.

Again, this is just my personal experience as an accessibility coach/consultant working with many NVDA users and development teams. I may be missing the larger picture, but I wanted to bring it up for discussion.

[feerrenrut]

Hi @mfairchild365, no we don't have hard data on usage of the option. We are averse to collecting data on users. Having the feature enabled by default is about discovery, once the user knows the option is there, they can turn it off.

As for the developer perspective you outlined, that is exactly what is covered in #13262. The situation of putting an event listener / onclick on a parent element without intending that subtree to be considered clickable is an authoring error, use role=presentation or role=none to declare that element as non semantic.

There may be a tipping point where encountering sites with useful click handlers on an unexpected elements becomes rare enough that we can reconsider the default. Given that well authored sites with judicious use of role=presentation for top-level click handlers, CAN provide a good experience, I think that the threshold to reconsider the default behavior is quite high.

[mfairchild365]

That’s a reasonable stance. Thank you for sharing your perspective; it has helped me to understand the issue better!

I don’t think developers are generally aware of the impact that role=none has on this and how it impacts clickable announcements. The aria spec doesn’t explicitly cover this scenario (of clickable announcements), and event bubbling like this can be used on elements where use of role=none would be inappropriate (a <table> for example). I’ll have to mull this over a bit more.

[feerrenrut]

Yes, the element with the clickable must not have other semantics, the extra information will be lost to AT users. If implemented in a top level <div>, wrapping a <table> then the click events will still bubble up.

If you encounter any situations where this doesn't work well, please share them.

I think this is definitely a matter to be clarified in the spec / authoring guides etc.

[Adriani90]

cc: @scottaohara especially the last comment is relevant.

[scottaohara]

I’m not sure why I specifically am being cc’d. If there is an issue or PR to file against a spec, I don’t need to be the one to do it?

[Adriani90]

Ah sorry for that, could you help us in finding the right people for this then?

[scottaohara]

no worries. i just wasn't part of the original conversation so i wasn't exactly sure what the expectation for this was upon this being in my notifications this morning.

having read through the issue a few times now, 'm not entirely sure what is being suggested to be put into a spec? Is this more author guidance that might be appropriate for MDN or the ARIA authoring practices? Is the idea here that one of the ARIA specs would call out this use case as a way to mitigate 'clickable' divs? if so, i'm unclear on how that would make sense to put into a spec - ways to handle a specific screen reader's output?

Is this even just information that NVDA could document for developers? E.g., as a wiki here on github? i'm sure there are many issues that get filed by developers that just don't realize what they're encountering is a feature and not a bug. tldr; i'm not exactly sure where to direct this right now cause i'm still unclear on what the appropriate end goal should be.

[Adriani90]

Yeah after giving it more thoughts and reading more concentrated I think you are right this is not really a spec but rather an authoring guidance. Like, role=none or role=presentation on elements with no further sematic can suppress the "clickable" announcement for a screen reader. I also think this guidance is missing entirely, there are a lot of places out there having clickable elements which are not really interactive, indicating that the web author did not really have a clear understanding on how to handle the clickable "atribute" in an accessible way.

@jcsteh maybe this is something better suited for MDN indeed. What do you think?

[Adriani90]

After reading the keyboard accessibility guideance in MDN it feelds like there is enough practical guidance in regard to clickable elements, which should alway be interactive and focusable. See
https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Keyboard

This being said I am closing this issue as invalid. If web authors misuse the property of clickable for anything else which is not interactive or cannot be focused with the keyboard, then it is rather a web authoring issue and not NVDA's fault.