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

Status: RESOLVED FIXED

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

Description

[Adrian Roselli]

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

Comment 1

[Marco Zehe (:MarcoZ)]

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.

Comment 2

[James Teh [:Jamie]]

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.

Comment 3

[James Teh [:Jamie]]

(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.

Comment 4

[Michał Gołębiowski-Owczarek [:mgol]]

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

Bug 1494196 was fixed.

Was it? It's still open.

Comment 5

[James Teh [:Jamie]]

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.