Firefox makes VoiceOver read all non-interactive elements as clickable
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
People
(Reporter: petyr.veliki, Unassigned)
References
Details
Attachments
(5 files)
Firefox.VoiceOver.all.elements.clickable.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0
Steps to reproduce:
Open a page that has element with click event listener and non-interactive elements inside.
Exapmle JS Fiddle - http://jsfiddle.net/7vamtqdx
Actual results:
When we navigate through the non-interactive elements - VoiceOver says "clickable" on all of them - titles, paragraphs, tables, etc.
Expected results:
Firefox should not make VoiceOver say "clickable" on non-interactive elements.
(On other browsers this doesn't happen.)
|
||
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 2•5 years ago
|
||
There is a conceptual problem with this. Because VoiceOver and Firefox are technically correct. You can click on the paragraph, and it will bring up the alert. I just tried it. So, this paragraph, although normally non-interactive, is clickable. And thus, a screen reader should notify the user of that fact. There are web applications where authors do this. I am not saying this is good practice. It isn't. It is the world wild web. But it is, for all intents and purposes, clickable. So, since you made the paragraph interactive by putting a click listener on its container, it is clickable, interactive, whatever. So, no bug here. Closing as WONTFIX.
BTW: Windows screen readers indicate these normally non-interactive elements as clickable, and therefore interactive, too.
|
Reporter | |
Comment 3•5 years ago
|
||
Event delegation is pretty common way of handling events nowadays. Probably I didn't provide a good enough example.
Please, take a look at this js fillde: https://jsfiddle.net/zhn76vt2/
Here we are listening for click events on the div with id "wrapper" - but we react to click on only the ones we are interested in. This is the way-to-go nowadays and the standard way the most famous frontend libraries and frameworks use, even behind the scenes - like React or Angular.
So - on Firefox we have the same behavior as before:
https://postimg.cc/MnY4D4ZP
While on Chrome and Safari the browser correctly recognizes which element is actually interactive/clickable:
Safari: https://postimg.cc/DSC6mKwT
Chrome: https://postimg.cc/Pvkz0X2m
Can you please take a look and at least consider it.
|
||
Comment 4•5 years ago
|
||
Yeah, Marco and I discussed it. This is a legit bug, and event delegation is common enough that folks encounter it. The solution would mean reworking how we advertise actions on accessibles, but it is worth keeping open.
|
||
Updated•5 years ago
|
On Mar 19, 2024 I'm still seeing this issue. It reads "li" elements as clickable, along with headers, paragraphs, spans, pretty much most non-clickable elements.
Please reconsider addressing this bug. Thank you :)
Firefox Quantum - 123.0.1 (64-bit)
All text elements (minus headers) on Youtube's page are marked as "clickable" when they clearly aren't clickable.
All text elements (minus headers) on Twitter's page are marked as "clickable" when they clearly aren't clickable.
Even the MDN website has text that's marked as "clickable" which is clearly not clickable
It sounds like the team has agreed this is a bug, and I'd like to provide my (and my team's) 2 cents!
This issue at hand may be more a problem with Voiceover, and I think there's some responsibility on how Firefox handles markup + javascript.
As developers, when I think of making a website accessible, I think less of "how does the javascript interact with this element" and more of "what is the best HTML element I can use to describe my intent".
What it appears to me is that Firefox decides "because there's a click handler, we need to let the user know this is clickable". I understand it's impossible to control for every single developer use case because some people don't care/need to care about accessibility and use divs everywhere. Divs with click handlers, paragraph tags with click handlers, buttons without click handlers.
But the onus (IMO) shouldn't be on the browser to code defensively, but rather on the developer to use proper semantics. Because of this, I don't think any browser should look at the javascript on an HTML element to better describe it to the screen reader, but rather, the onus should be on the developer to use proper HTML tags / aria tags / etc.
Attached are prominent websites such as MDN, Youtube, and Twitter who are also experiencing VO reading text elements as "clickable". Our hypothesis (without spending a ton of time) is that many popular frameworks (or maybe even analytics libraries) will attach handlers to the document/body/html/etc, and by proxy, all elements in that page are children with click handlers, including div/paragraph/list items/etc.
Thank you for reconsidering this issue. I understand this is no easy fix and I appreciate your time!
|
||
Updated•8 months ago
|
|
||
Comment 10•8 months ago
|
||
Filling in some details on the history of this behavior in WebKit and VoiceOver, as I contribute to both, and was actively a part of similar discussions on the Apple side 5–10 years ago when the behavior changes in WebKit.
- It's an intentional design of VoiceOver that it speaks "clickable" on elements that are clickable but don't use one of the expected clickable roles, like link or button. This is because web devs often add a click handler (e.g. to a div) without fixing up the accessibility.
- It's all a common web pattern that people use event delegation on the document body (or less-commonly the html root element) and route handlers through the event target.
These factors led to VoiceOver announcing "clickable" for most elements on event-delegated web applications, so we decided that WebKit should ignore the "clickable"-ness when events were delegated on the body. This change solved 99%+ of the false positives. There are occasional false positives where handler are added to a ~widget group container, but those are less common.
If you have additional heuristics or other proposals you decide on to improve this further, please do propose them.
|
|
||
Comment 11•8 months ago
|
||
TLDR: The easy fix is to not expose these to the AX API when the events are register on the body element. Leave them clickable when registered on descendant nodes.
|
|
||
Comment 12•8 months ago
|
||
Actually, we made another much more recent heuristic update: require cursor: pointer;
https://github.com/WebKit/WebKit/pull/50546
|
|
||
Comment 13•8 months ago
|
||
Some more history in case it's helpful: https://bugs.webkit.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&component=Accessibility&f0=OP&f1=OP&f2=component&f3=CP&f4=CP&j1=OR&list_id=12630068&o2=substring&query_format=advanced&short_desc=clickable&short_desc_type=allwordssubstr&v2=Accessibility
|
|
||
Comment 14•8 months ago
|
||
Apologies for the clarity-reducing typos in my first comment. I don't see a way to edit and correct them. Looks like the original changes were 10–12 years ago.
|
|
||
Comment 15•4 months ago
|
||
Related: potential behavior standardization. https://github.com/w3c/html-aam/issues/599
Description
•