Closed Bug 1500958 Opened 2 years ago Closed 1 year ago

display: contents removes attributes from a11y tree (such as button)

Categories

(Core :: Disability Access APIs, defect, P2)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: aroselli, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36

Steps to reproduce:

Applied display:contents to a <button>, both with and without its role set to button.

Test page: https://s.codepen.io/aardrian/debug/KGBbQd
Test page: https://s.codepen.io/scottohara/debug/GYoBgZ/WPALYNWgeOJk

Essentially <button style="display:contents"> and <button role="button" style="display:contents"> both lost their button semantics.


Actual results:

The button is exposed in the Firefox accessibility inspector as a text leaf node, not a button.


Expected results:

It should be exposed as a button element with all appropriate nodes in the accessibility tree.

Related to (which focuses on list semantics): https://bugzilla.mozilla.org/show_bug.cgi?id=1455357#c32

Also related to (which focuses on role attribute): https://bugzilla.mozilla.org/show_bug.cgi?id=1494196
It looks like we haven't yet caught all cases where display:contents is dealt with. Possibly also related to bug 1500416, which landed today. I will take a look at this tomorrow.
Component: Untriaged → Disability Access APIs
Priority: -- → P2
Product: Firefox → Core
This is due to a couple of things:

1. button isn't in MarkupMap; we use layout stuff to create an accessible for <button>. In this case, there's no layout stuff, so no accessible. So, we need to move <button> into MarkupMap.
2. We only ever create accessibles for display: contents if the element is in MarkupMap. If it isn't in MarkupMap, we don't consider it at all, even if it has an ARIA role. That's covered by bug 1494196.

So, this bug should just fix 1) and 2) should be fixed in bug 1494196.
See Also: → 1494196
Status: UNCONFIRMED → NEW
Ever confirmed: true

(In reply to James Teh [:Jamie] from comment #2)

So, this bug should just fix 1) and 2) should be fixed in bug 1494196.

Bug 1494196 was fixed.

  1. button isn't in MarkupMap; we use layout stuff to create an accessible
    for <button>. In this case, there's no layout stuff, so no accessible. So,
    we need to move <button> into MarkupMap.

That was done in bug 1508935.

So, this is done. Closing.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

(In reply to James Teh [:Jamie] from comment #3)

Bug 1494196 was fixed.

Was it? It's still open.

Err, my bad. No, it isn't. However, the fix in bug 1508935 deals with both of the test cases for which this bug was opened, so I still think closing this was the correct action, despite my erroneous comment. Bug 1494196 remains open to deal with related (but different) problems.

You need to log in before you can comment on or make changes to this bug.