remove XUL elements support of picking up names from toolbaritem
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | fixed |
People
(Reporter: surkov, Assigned: surkov)
References
Details
Attachments
(1 file)
the feature was introduce in bug 237249 16 years ago to fix accessible for the address bar, 4 years ago the behavior was tweaked a bit to loosen the rules. Also it's worth to notice the rules apparently had use case by that time, see bug 1216478 comment 8.
Now it seems we have no consumers, it turns out that toolbaritems are just containers nowadays (https://searchfox.org/mozilla-central/search?q=%3Ctoolbaritem&case=false®exp=false&path=). So either they have complex content (which means all child accessible objects should take of their accessible names by their own) or they have a few elements which define their accessible names themselves.
On the other hand the feature looks cumbersome and I'd say it'd be nicer to fix each UI case by using ARIA (if we have those at all).
Also marking as blocking bug 1566674 since obviously this behavior is not applied to HTML elements, so we cannot replace <textbox> into <html:input> to make test_toolbaritem.xul passing. I suppose xul:textboxes from the test can be replaced on any XUL elements like xul:button, but if we can get rid of the rule all together, then it's worth doing so.
:gijs, as author of bug 1216478, could you do a sanity check of above-said? Do <toolbaritem> have tooltip these days and if so, then does any of them goes as accessible name to any of its children?
|
||
Comment 1•5 years ago
|
||
If this is only for <textbox> inside <toolbarpaletteitem>, it's worth noting that the urlbar or searchbar are using <html:input> now, so this code probably no longer applies in those places.
|
Assignee | |
Comment 2•5 years ago
|
||
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 3•5 years ago
|
||
(In reply to Tim Nguyen :ntim from comment #1)
If this is only for <textbox> inside <toolbarpaletteitem>, it's worth noting that the urlbar or searchbar are using <html:input> now, so this code probably no longer applies in those places.
A11y has a check for toolbaritem tag name only (not toolbarpaletteitem). I suspect however it was original intention to support textboxes inside toolbaritems, but it seems it was made generic on purpose. It's hard to tell now, Firefox UI has changed dramatically over 16 years, and I think we had the times when we relied on this generic behavior and the times when we didn't. Now we have bunch of toolbaritem containing a wild variety of the content, which looks like doesn't rely on that behavior.
|
||
Comment 4•5 years ago
|
||
(In reply to alexander :surkov (:asurkov) from comment #0)
the feature was introduce in bug 237249 16 years ago to fix accessible for the address bar, 4 years ago the behavior was tweaked a bit to loosen the rules.
Right, for Firefox itself, the behaviour was just "in the way" - I just made local/individual labels / accessible names take precedence over the label on the container.
Also it's worth to notice the rules apparently had use case by that time, see bug 1216478 comment 8.
That was all XUL add-ons, so that's no longer relevant. Webextensions can't add <toolbaritem>s, only <toolbarbutton>s (which wouldn't be affected), and in any case they're managed by our code so we can change them.
Now it seems we have no consumers, it turns out that toolbaritems are just containers nowadays (https://searchfox.org/mozilla-central/search?q=%3Ctoolbaritem&case=false®exp=false&path=). So either they have complex content (which means all child accessible objects should take of their accessible names by their own) or they have a few elements which define their accessible names themselves.
On the other hand the feature looks cumbersome and I'd say it'd be nicer to fix each UI case by using ARIA (if we have those at all).
Yeah, I concur.
Also marking as blocking bug 1566674 since obviously this behavior is not applied to HTML elements, so we cannot replace <textbox> into <html:input> to make test_toolbaritem.xul passing. I suppose xul:textboxes from the test can be replaced on any XUL elements like xul:button, but if we can get rid of the rule all together, then it's worth doing so.
:gijs, as author of bug 1216478, could you do a sanity check of above-said? Do <toolbaritem> have tooltip these days and if so, then does any of them goes as accessible name to any of its children?
I think it would be a fine idea to get rid of this, and I agree with your assessment that either there is no complex content (so why not label the inner item) or there's too much of it so labeling all of it by means of the container is wrong - so either way this no longer really makes sense, especially in an aria world where we can easily add non-visual labels for AT use.
|
||
Comment 6•5 years ago
|
||
| bugherder | ||
Description
•