Starting from Firefox version 111.0 and after its initial launch, a significant number of IAccessible Attributes are not returned
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox114 | --- | fixed |
People
(Reporter: aaclause, Assigned: Jamie)
References
Details
Attachments
(2 files)
Steps to reproduce:
- Enable NVDA screen reader (same result with JAWS).
- Launch Firefox and open this URL:
data:text/html,<div id="test" class="test">Test</div>
- Make sure you are in browse mode and use left/right arrow keys until 's' letter for example.
- Press NVDA+F1 and focus on "Developer info for navigator object" section, then "IAccessible2 attributes" value (at the bottom).
Actual results:
With Firefox {111.0, .., 114.0}:
- Initial launch (OK): 'margin-top:0px;display:block;tag:div;margin-right:0px;margin-left:0px;text-align:start;text-indent:0px;class:test;formatting:block;id:test;margin-bottom:0px;'
- Next launches (KO): 'tag:div;display:block;id:test;'
notes:
- Initial launch = right after installing Firefox.
- Prior to version 111.0, it worked as expected every time.
In other words, starting from Firefox version 111.0 and after its initial launch, a significant number of attributes are not exposed through the IAccessible2 API, such as the 'class' attribute.
Expected results:
Firefox should return all IAccessible Attributes consistently.
Reporter | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
This is due to the new caching architecture. Any attribute we expose now needs to be cached in the main Firefox process, which consumes memory as well as additional time to build the cache. The benefit is dramatically improved performance, but the downside is we have to be extra careful about what we cache.
As far as we're aware, none of the other attributes Firefox previously exposed are used for any actual functionality provided by any known accessibility tool.
What specific attributes do you require? Can you explain your use case?
Reporter | ||
Comment 2•2 years ago
|
||
(In reply to James Teh [:Jamie] from comment #1)
This is due to the new caching architecture. Any attribute we expose now needs to be cached in the main Firefox process, which consumes memory as well as additional time to build the cache. The benefit is dramatically improved performance, but the downside is we have to be extra careful about what we cache.
Thanks for your quick reply and explanations. :)
As far as we're aware, none of the other attributes Firefox previously exposed are used for any actual functionality provided by any known accessibility tool.
What specific attributes do you require? Can you explain your use case?
In my case, it is mainly the 'class' attribute that is missing.
In short, to improve UX on complex websites, the WebAccess NVDA add-on allows defining shortcuts to move, activate, and speak any element on the page. WebAccess uses the value attributes to locate the elements.
Is it possible to deactivate the new caching architecture in 'about:config' or any other way? For now, I'm restricted to using Firefox 110.01.1 or a Chromium-based browser.
Thanks.
Assignee | ||
Comment 3•2 years ago
|
||
You can disable the cache by going to about:config and setting accessibility.cache.enabled to false. However, you should be aware that this is no longer a supported configuration. We will soon start removing parts of the old architecture, which might cause breakage with the cache disabled. After that, the about:config preference will be removed entirely. Therefore, it is very important that we fully understand your use case so that we can continue to support it with the new caching architecture.
You note that it is "mainly" the class attribute. Are there others your add-on uses? Chromium doesn't offer many attributes beyond what Firefox offers now except the class attribute.
Reporter | ||
Comment 4•2 years ago
|
||
Thanks for this temporary workaround. :)
I confirm that the absence of the 'class' attribute is the most annoying.
Chromium also exposes other useful properties such as 'src' and 'text-align'.
Currently, WebAccess can use the following criteria to find a node:
- Tag (eg.: div, span, li, ul, input).
- Role (eg.: heading, link, button).
- class (value of a "class" attribute).
- id (value of an "id" attribute).
- States (eg. collapsed, has popup, focused).
- Image source (value of a "src" attribute).
Assignee | ||
Comment 5•2 years ago
|
||
I can look into caching the class attribute.
How often do you find src to be useful? Caching URLs for every image really isn't ideal for memory usage. This is what Chromium does, but I'd rather not do that unless we absolutely have to, as URLs can be quite long.
Reporter | ||
Comment 6•2 years ago
|
||
Hmm, I understand...
Unfortunately, we encounter several cases where the only way to identify an image is through its 'src' attribute. These images are mainly used for navigation purposes, such as returning to the homepage, the previous screen or the previous/next page.
Occasionally, I am tasked with working on web applications that are not very accessible and where it is very difficult to fix the issues at the source.
Assignee | ||
Comment 7•2 years ago
|
||
In these cases, isn't the URL of the link more useful? This is what NVDA uses in browse mode for unlabelled links inside images. Or are these images outside of links?
Would it be reasonable for your purposes to only cache the src attribute if there is no alt, title, aria-label or aria-labelledby attribute - i.e. if there is no name - and the image is not inside a link with a URL?
Reporter | ||
Comment 8•2 years ago
|
||
(In reply to James Teh [:Jamie] from comment #7)
In these cases, isn't the URL of the link more useful? This is what NVDA uses in browse mode for unlabelled links inside images. Or are these images outside of links?
Yes, sometimes I have images that are outside of links, such as clickable "span" tags...
Would it be reasonable for your purposes to only cache the src attribute if there is no alt, title, aria-label or aria-labelledby attribute - i.e. if there is no name - and the image is not inside a link with a URL?
Although I find it unfortunate that the behavior differs from Chromium-based browsers, it seems like a good compromise to me.
Comment 9•2 years ago
|
||
Yes, having access to the class attribute will be a huge help when scripting pages to make them more accessible. Using the NVDA object info is much faster than digging through the developer tools tree.
Assignee | ||
Comment 10•2 years ago
|
||
I had considered the developer debugging use case, but I figured we could deal with that using a hidden pref, rather than wasting memory caching classes for everyone always. However, it seems there are use cases outside of developer debugging, so a hidden pref isn't going to work so well.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 11•2 years ago
|
||
This is used by the Web Access NVDA add-on to identify and remediate some inaccessible elements on websites with accessibility problems.
It is also useful for developers using screen readers when trying to identify specific elements in the absence of semantics.
Assignee | ||
Comment 12•2 years ago
|
||
This is used by some clients to help remediate inaccessible images.
Comment 13•2 years ago
|
||
Comment 14•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/e4a549beba34
https://hg.mozilla.org/mozilla-central/rev/9ca1db7c862a
Comment 15•2 years ago
|
||
I can confirm that in Firefox Nightly 114.0b1 (20230503140026), when pressing NVDA+F1 on an element, the class attribute is now exposed again. I suspect images work, too, but so far haven't found one to try it on.
Reporter | ||
Comment 16•2 years ago
|
||
Thank you so much, @Jamie! :) The fix works perfectly for me.
(In reply to Marco Zehe (:MarcoZ) from comment #15)
I suspect images work, too, but so far haven't found one to try it on.
You can test the src
attribute like this:
- Open the following URL:
data:text/html,<p>Before <img src="test.jpg" class="c_img" /> after</p>
- Locate the image using the NVDA object navigation.
- Press NVDA+f1. You should get something like this:
IAccessible2 attributes: 'src:test.jpg;class:c_img;tag:img;display:inline;'
Updated•2 years ago
|
Description
•