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

NEW
Unassigned

Status

()

defect
P2
normal
8 months ago
28 days ago

People

(Reporter: aroselli, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

8 months ago
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

Comment 2

8 months ago
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

Updated

8 months ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.