1686123 - When display:contents is set, accessibility tree ignores table/tr/td/th semantics

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[brandon]

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

Steps to reproduce:

Repros on FF 84.0.2 on Windows 10
Pen: https://codepen.io/brandonthomas/pen/OJRwLpz

Create table (or similar element with semantics)
Inspect to switch to accessibility tree debugger

Actual results:

There are no semantics preserved within the accessibility tree.
TDs display as text leafs.

Expected results:

All semantics should be preserved and accessibility should work as expected. Without this semantic HTML is somewhat pointless.

Work around: specify aria values on all elements (not ideal).

Comment 1

[Peter Magyari (Desktop QA)]

I was able to reproduce the issue on Firefox 84.0.2 and Firefox Nightly 86.0a1 on W10 and MacOS as well.

I'm going to set a component in order to get the dev team to review this issue.
Feel free to set it to a more appropriate component if this doesn't seem like the most suitable one.

Thank you for reporting!

Comment 2

[James Teh [:Jamie]]

I'm narrowing the scope of this to just cover table/tr/td/th, since we've already done the core work to make display: contents expose semantics. Many elements do already get the right semantics. Any remaining problems (like tables) need to be addressed specifically; they're not something we can generalise.

Looking briefly, the start of our problems is here, where we only fall back to ARIAGridAccessibleWrap if we have a primary frame (which we don't for display: contents):
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/accessible/base/MarkupMap.h#453
We have similar checks for tr and probably td. We should also allow fallback where there is no frame.

Or we could just treat this as one more reason to push forward on the work to avoid relying on the layout engine for tables altogether.

Comment 3

[brandon]

Any news to share on this issue?

Comment 4

[James Teh [:Jamie]]

Attachment: Bug 1686123: Fall back to ARIAGrid*Accessible for HTML table/tbody/thead/tr/td/th elements with no frame.

display: contents means there is no frame, which means we can't use HTMLTableAccessible.
However, we can (and should) use ARIAGridAccessible in this case.

Comment 5

[James Teh [:Jamie]]

Refactoring tables to not depend on layout altogether is not likely to happen in the short term, but the interim solution turned out to be a fairly quick patch, so I went with that.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ceb6a73484ea
Fall back to ARIAGrid*Accessible for HTML table/tbody/thead/tr/td/th elements with no frame. r=morgan

Comment 7

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/ceb6a73484ea

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.