1950535 - Narrator doesn't report links when moving by word or character

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

STR:

1. Ensure Firefox UIA is enabled. Turn on Narrator.
2. Open: https://example.com/
3. Press control+end to move to the last line of the document. Narrator should say: "More information"
4. Press control+leftArrow to move to the previous word. Narrator should say: "permission"
5. Press control+rightArrow to move to the next word; i.e. returning to the start of the link.
   • Expected: Narrator should say: "link, More information"
   • Actual: Narrator just says: "More information"

This works in Edge.

I think (but haven't confirmed) that this occurs because ITextProvider::GetEnclosingElement in Firefox returns the text leaf, whereas in Edge, it returns the link. The documentation for GetEnclosingElement says:

Returns the innermost element that encloses the specified text range.

On that basis, what Firefox is doing is strictly correct: the text leaf is the deepest node. However, this Chromium code and this associated bug suggest that we need to return the link for Narrator regardless of what the UIA documentation says. 😒

Like Chromium, we should return the link if it only has a single text leaf as a child. We should do this for buttons too. If we're not doing this for MustPrune already, we should.

Strictly speaking, the IA2 -> UIA proxy doesn't reproduce this bug. However, while it does report the link, it is pretty unusable in trying to navigate after that, so I don't think this really counts as a noticeable regression given that navigation now works far more reliably.

Comment 1

[James Teh [:Jamie]]

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

Strictly speaking, the IA2 -> UIA proxy doesn't reproduce this bug. However, while it does report the link,

Other bugs with the proxy aside, I guess this is still a regression, so we shouldn't ship UIA without it being fixed.

Comment 2

[James Teh [:Jamie]]

Attachment: Bug 1950535: Exclude children pruned by MustPrune, as well as single text children of links, for UIA GetEnclosingElement.

Text children of links are (and should be) exposed in the UIA tree, but Narrator misbehaves when we return these from GetEnclosingElement.
Children of Accessibles for which MustPrune() returns true are not exposed in the UIA tree, so they shouldn't be returned by GetEnclosingElement.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b00d78bcd328
Exclude children pruned by MustPrune, as well as single text children of links, for UIA GetEnclosingElement. r=nlapre

Comment 4

[Norisz Fay [:noriszfay]]

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

Comment 5

[Ina Popescu, Desktop QA]

I've reproduced the issue in Nightly 137.0a1 (2025-02-25) on Windows 10 with the accessibility.uia.enable pref set to true:

• when pressing Control + End, Narrator announces "More information"
• when pressing Control + Left Arrow, Narrator announces "permission"
• when pressing Control + Right Arrow, Narrator announces "More"

In the latest Nightly 139.0a1 and Firefox 138.0b2, with accessibility.uia.enable set to 1, I observed the following behavior:

• when pressing Control + End, Narrator announces "link, More information"
• when pressing Control + Left Arrow, Narrator announces "Example Domain" (although "permission" appears to be focused)
• when pressing Control + Right Arrow, Narrator announces "link, More information"

Could you please confirm if this is the expected behavior?

Comment 6

[James Teh [:Jamie]]

• when pressing Control + Left Arrow, Narrator announces "Example Domain" (although "permission" appears to be focused)

It looks like another bug crept in here. :( That's not expected behaviour. However, this bug was about fixing the third point:

• when pressing Control + Right Arrow, Narrator announces "link, More information"

So, given that this is fixed, we're seeing the expected behaviour for this bug, but we do have another bug. Thank you for catching it. I'm not quite sure whether that's a regression from this one or separate. Either way, I'll need to deal with it separately.

Comment 7

[Ina Popescu, Desktop QA]

Thank you for confirming.
Verified as fixed in the latest Nightly 139.0a1 and Firefox 138.0b3 on Windows 10 where the initial issue described in Comment 0 is no longer present.