Add automatic details relationship to anchor positioned content
Categories
(Core :: Disability Access APIs, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox145 | --- | fixed |
People
(Reporter: eeejay, Assigned: eeejay)
References
Details
(Whiteboard: [anchorpositioning:m2])
Attachments
(3 files)
| Assignee | ||
Comment 1•3 months ago
|
||
There are three functions that select and determine valid details
relationships.
- nsCoreUtils::GetAnchorForPositionedFrame and nsCoreUtils::GetPositionedFrameForAnchor
These query layout and determine that there is only a single target
referencing and anchor and vice versa. We need to do this check in
layout because the a11y tree doesn't give us the full picture. For
example, one of two targets could be aria-hidden and it should make the
relationship with between the anchor and other target invalid.
- LocalAccessible::GetAnchorPositionTargetDetailsRelation
This uses the functions above to get the target of an anchor, retrieve
its accessible and check that there are no explicit relationships
defined on the anchor (or details relationship for the target).
- nsAccUtils::IsValidDetailsTargetForAnchor
This checks the a11y tree structure to make sure this is a valid
relationship. This is written to run also remotely so we don't need
to recalculate and cache relations on each tree mutation.
Updated•3 months ago
|
| Assignee | ||
Comment 2•3 months ago
|
||
This allows us to calculate relations remotely when more than one
relation source is at play. For example, a details relationship will be
determined in order of priority: aria-details, commandfor, popover.
Knowing the relation source remotely allows further filtering. For
example, a popover relation should not be valid if the target is a
sibling of the button. We should determine that remotely instead of
recalculating and sending a new relation cache on each tree mutation
that might change the relation.
It also allows us to provide something like details-from in the
accessible attribute to let ATs know what the source of the relationship
is and for it to determine presentation.
The one sticking point in this change is that determining reverse
relations is less straightforward and requires us to interrogate each
target candidate to see if the relationship is mutual. This is because
relationship sets can be fully or partially "eclipsed" by a higher
priority source on the potential target.
For example:
<button id="toggle" commandfor="popover" command="toggle-popover" aria-details="details">toggle1</button>
<button id="show" commandfor="popover" command="show-popover">show</button>
<dialog id="popover" popover>popover</dialog>
<div id="details">details</div>
The cached stored reverse relationship for "commandfor" on "popover" is
both "toggle" and "show", but the direct details relationship of "toggle" is "details".
So the calculated DETAILS_FOR of "popover" should just be "show".
| Assignee | ||
Comment 3•3 months ago
|
||
The change notification here is a bit stilted.. we need an explicit
notification when removing targets or anchors immediately before reflow
so we can collect associated frames and update the relations on their
associated accessibles.
When anchors/targets are added, we need to wait till after reflow in
order to get the frames that are resolved.
Updated•3 months ago
|
Comment 6•3 months ago
|
||
Backed out for causing bustages at DocAccessible.cpp.
Backout link: https://hg-edge.mozilla.org/integration/autoland/rev/09de143215a13a22dcb2cd53d4ed1dfb60480c82
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
https://hg.mozilla.org/mozilla-central/rev/4544c8e0eda1
https://hg.mozilla.org/mozilla-central/rev/7aaaa4514127
https://hg.mozilla.org/mozilla-central/rev/2ba84268f8ac
https://hg.mozilla.org/mozilla-central/rev/8bbd7e06665e
Updated•2 months ago
|
Description
•