1624958 - VoiceOver cursor is lost when container changes role

Status: NEW

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

Description

[Eitan Isaacson [:eeejay]]

STR:

1. Load https://a11ysupport.io/tests/html/html/role-attribute.html
2. Navigate to "Test 4" and follow instructions.

Result:
Firefox loses position and jumps to container accessible

Expected:
Cursor should go to "target text"

Comment 1

[James Teh [:Jamie]]

Fixing this ought to be fun. We re-create the subtree when the ARIA role changes, since it might change interfaces, descendants, etc. We can stop doing that, but there'll likely be a bunch of edge cases we need to deal with.

I wonder how much this actually occurs in the wild?

Chrome seems to re-create the element which changed its role only, leaving its subtree intact. I know there are cases which break with this behaviour. In this example, the table is broken after you press the button in Chrome, but not Firefox:
data:text/html,<div id="table"><div role="row"><div role="cell">hi</div></div></div><button onClick="table.setAttribute('role', 'table');">Change</button>

Side note: This is another reason to be glad you fixed bug 686400. :)

Comment 2

[Eitan Isaacson [:eeejay]]

I was confused when I saw this because I also assumed this is because of the subtree recreation. But the test site claims this works with Firefox on other platforms

Comment 3

[James Teh [:Jamie]]

NVDA has a virtual buffer and a virtual cursor. It has explicit code to deal with the node under the cursor disappearing which tries to restore the cursor position based on the offset relative to the deepest node which still exists. That code was written explicitly to deal with problems like this. I assume JAWS has the same.

Orca uses the Gecko caret, which would be unaffected by a role change.

In contrast, I imagine VoiceOver depends on references to actual objects.

Comment 4

[Marco Zehe (:MarcoZ)]

This is still reproducible. I also tested this in Chrome and Safari:

• Safari keeps the line, and as you go backwards, things seem to be as before. Once you reach the Reset Test button, then move forward, there suddenly is a group that wasn't there when I went backwards.
• Chrome/Edge keep their position, and just insert the region where it should be. But as Jamie indicated, this breaks with a table example, which he provided above.

Comment 5

[Eitan Isaacson [:eeejay]]

As long as we recreate accessibles on role change, this will be an issue.