According to SVG Accessibility API Mappings, an SVG element which has title or desc element must be exposed.
https://w3c.github.io/svg-aam/#include_elements
Previously, we didn't expose <g> elements at all even if they had a title/desc, and we unconditionally exposed some other SVG elements even when they didn't.
This removes the Dev Tools A11y Panel code which explicitly allowed unlabelled descendants of role="img" <svg> elements, since we don't create descendants if they don't have a label now anyway.
The associated tests had to be tweaked as well, since now we don't create unlabelled descendants.
Original patch by Takeshi Kurosawa.
Differential Revision: https://phabricator.services.mozilla.com/D77763
According to SVG Accessibility API Mappings, an SVG element which has title or desc element must be exposed.
https://w3c.github.io/svg-aam/#include_elements
Previously, we didn't expose <g> elements at all even if they had a title/desc, and we unconditionally exposed some other SVG elements even when they didn't.
Original patch by Takeshi Kurosawa.
Differential Revision: https://phabricator.services.mozilla.com/D77763
A casualty of this is the ability to change listed attribute names on the fly.
I think this is the right choice in general and doesn't seem to affect VO.
If we run into a case where it does we should reconsider.
Differential Revision: https://phabricator.services.mozilla.com/D77341
Previously, to get the column headers for a cell when there weren't explicit headers, we walked over all previous cells in the column looking for headers.
For large tables with thousands of rows, this was very expensive, particularly when Windows screen readers rendered virtual buffers, fetching headers for all cells.
To speed this up, we now lazily cache the previous column header for each cell.
We even cache whether there is no previous header, since that is quite common and we don't want to pointlessly walk in that case.
Subsequent cells utilise the cached values (if any) for prior cells.
We don't store the cache on individual TableCellAccessibles because that would require us to walk all cells to invalidate the cache, even if few or no cells had cached values.
Instead, we store the cache as a hash table on the TableAccessible.
This way, we can just clear the cache whenever a column header is added to the tree.
We invalidate the cache whenever a column header is bound to its parent.
We don't need to invalidate the cache for removals because we instead just ignore defunct Accessibles in the cache.
Differential Revision: https://phabricator.services.mozilla.com/D76106
These tests insert a <browser> into the DOM via tabbrowser, and
immediately try to get a hold to the underlying document right after.
However the a11y tree is constructed after frame construction, and with
bug 1584935 there's no longer a guarantee that it gets done in time
without these explicit flushes.
Note that I couldn't reproduce these failures locally, so take the
diagnostic with a grain of salt, but I believe it's accurate and that
this is the right fix.
Differential Revision: https://phabricator.services.mozilla.com/D75715
The code in mozAccessible SubRole was actually never executed for inputs, so the SearchField sub role was never set. Moved the implementation to mozTextAccessible. Also reenabled the tests from bug 1634373, which now pass.
Depends on D73308
Differential Revision: https://phabricator.services.mozilla.com/D73735
When an Accessible is removed, the AccGroupInfo for its siblings is marked dirty.
However, when AccGroupInfo::Update is called, it previously didn't clear mParent, which is used for the NODE_CHILD_OF relation.
This meant that if the conceptual group parent was removed and there was subsequently no conceptual parent, NODE_CHILD_OF would return an incorrect (potentially dead) Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D73776