1676344 - Tables with an intermediary block frame element confuse VoiceOver.

Status: VERIFIED FIXED

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

Description

[Marco Zehe (:MarcoZ)]

Found while investigating Google Drive, see bug 1676339. Steps:

1. Open data:text/html,<div role="table"><span style="display: block;"><div role="row"><div role="cell">Cell 1</div><div role="cell">Cell 2</div></div></span><span style="display: block;"><div role="row"><div role="cell">Cell 3</div><div role="cell">Cell 4</div></div></span></div>.
2. Investigate this with VoiceOver.
   • Expected: VoiceOver should read all four cells in both rows.
   • Actual: VoiceOver announces that this is a table with two rows and two columns, which is correct, but then only reads the first row and then cannot move any further to the second row.

Google Drive inserts an intermediary block frame element between the table and table rows using its c-wiztag which is some prorietary JavaScript framework thing. However, the above test case reproduces the bug the same way.

The same is true for some level deeper, between the table cells and table row. The consequences here are not as severe, though, only causes a lot of groupings that one has to go into and out of with VoiceOver.

Comment 1

[Marco Zehe (:MarcoZ)]

Jamie, I was thinking that such block level elements in such particular cases could be treated like presentational accessibles. We do have our own boundaries because of the table rows anyway, so stripping these from the a11y tree does sound like a reasonable measure, or would you disagree?

Comment 2

[Marco Zehe (:MarcoZ)]

Attachment: Bug 1676344 - Treat TEXT_CONTAINER accessibles between tables and table rows, as well as table rows and cells, as presentational, r?jamie!

Comment 3

[Marco Zehe (:MarcoZ)]

Attachment: Bug 1676344 Part 2: Add a Mac test for correct table properties for a table with intermediary hyperTexts, r?morgan

Depends on D96532

Comment 4

[James Teh [:Jamie]]

It's not unreasonable, but it's worth noting that while this would fix this particular case, it doesn't fix the underlying problem, which is that VoiceOver (or is it our Mac implementation?) can't handle intermediate Accessibles in tables. So, for example, if you add tabindex="-1" to those block spans, we absolutely shouldn't treat those as presentational... but that'll still break VoiceOver. And while you can argue an author shouldn't use tabindex="-1" in such a silly place, there are other ways an Accessible might be forced here; e.g. a scrollable area or a title attribute.

I'd be interested to know what Chrome and Safari do for this case:
data:text/html,<div role="table"><span tabindex="-1" style="display: block;"><div role="row"><div role="cell">Cell 1</div><div role="cell">Cell 2</div></div></span><span style="display: block;" tabindex="-1"><div role="row"><div role="cell">Cell 3</div><div role="cell">Cell 4</div></div></span></div>
Chrome on Windows does expose Accessibles for the spans in this case.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3de7612b6c50
Treat TEXT_CONTAINER accessibles between tables and table rows, as well as table rows and cells, as presentational, r=Jamie
https://hg.mozilla.org/integration/autoland/rev/ef4c4a545e35
Part 2: Add a Mac test for correct table properties for a table with intermediary hyperTexts, r=morgan

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/3de7612b6c50
https://hg.mozilla.org/mozilla-central/rev/ef4c4a545e35

Comment 7

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Reproduced the issue with Firefox 84.0a1 (20201110220109) on macOS 10.12 and STR from comment 0.
The issue is verified with Firefox 84.0b3 (20201119195818) on macOS 10.12. All the cells are readable using VoiceOver.