When navigating with the mouse NVDA reads text on a line up to the first link on a line and stops reading

[nvaccessAuto]

Reported by ddeangelis on 2012-03-13 16:34
In Mozilla Firefox and Internet explorer.

When using the mouse to hover over a given line NVDA stops reading the line if it contains a link withing the text. The NVDA home page contains several examples of text links within a given line of text on a web page. If I move the mouse cursor over the link it will be read, but the text following the link will not be read even if I move the mouse cursor over it. If I hover over the block of text following linked text NVDA reads the text proceeding the linked text.

It would be extremely helpful to have a setting to read the entire line calling out links with a selectable beep, verbal or no description and continuing to read the entire line.

I consider this to be a bug in the software as it disallows partially sighted individuals from reading websites using the mouse to hover over the text that is desired to be verbalized. This is a standard option in many screen readers. It is much more efficient for partially sighted individuals to navigate in this manner as opposed to using browse mode and keyboard navigation.

This issue exists in all versions after 2011.3. This issue was ovserved in both Windows XP and Vista.

[nvaccessAuto]

Comment 1 by 4RJames on 2013-11-13 14:54
In addition to links this happens any time there is something like a link such as dates. There are many times when I cannot read all the text due to this problem. It is also not always obvious when text is skipped. It was good to see this was already reported. It has been many months and would be greatly appreciated if it was fixed.

[bhavyashah]

Could we please have a sighted person using the mouse test and provide a status update for this issue? @feerrenrut @Qchristensen

[jcsteh]

I very much doubt there's been any change here. This should work as expected now in editable text boxes in Firefox (not sure about Chrome), as we use the rich text editing code to support this. Other than that, this doesn't work because browse mode doesn't contain enough information to support this kind of tracking, and supporting it without using browse mode would cause severe performance problems.

[coryj627]

This is still happening in HTML/rich text like an e-mail in Outlook or a rendered web-page in Firefox.

[Qchristensen]

The issue here is I think related to #3590 - I did a bit of testing on that one and wrote up a fairly long post describing all the symptoms some time ago, but it is good to have it linked here as well.

[josephsl]

Hi,

Almost six years later...

CC @Qchristensen, do you think it would be best to close this in favor of #3590 if it turns out we're dealing with the same (or similar) underlying issue?

Thanks.

[Adriani90]

@jcsteh I think this and #3590 might be positively affected by your PR #16912. Although this particular issue here feels like a duplicate of #15990. What do you think?

[jcsteh]

No, this will not be improved by #16912. #16912 fixes cases where even the current behaviour was broken; i.e. where reading sometimes stopped at a seemingly arbitrary point in the text before a link.

[jcsteh]

Implementation thought: Virtual buffers still don't contain sufficient information to enable this kind of tracking (character, word and visual line boundaries). Adding this to buffers isn't feasible and neither is reporting rich content without them. But what has changed more recently is that buffers now contain information which allows us to map from buffer offsets to IAccessibleText offsets and vice versa; see virtualBuffers.gecko_ia2.Gecko_ia2_TextInfo._getBoundingRectFromOffset and virtualBuffers.gecko_ia2.Gecko_ia2._getStartSelection. So, perhaps we could:

1. Hit test using IAccessible and IAccessibleText as we do now.
2. Expand using the code in MozillaCompoundTextInfo.
3. Convert the resulting IAccessibleText objects and offsets into virtual buffer offsets.
4. Report the content from the buffer using these offsets.

I have no idea how we'd plumb this, though. There are multiple layers of abstraction this violates and it'd likely require quite a lot of refactoring at the very least.

[Qchristensen]

I disagree with this being a duplicate of #15990 - that issue seemed to be a specific bug which is now marked as fixed in the latest alpha snapshots. Testing with aalpha-33085,f05f1c8f or NVDA 2024.3 Beta 4, I can still reproduce THIS issue - hover the mouse over the text of one of the comments with links in this issue and the issue reproduces - that it, it only reads the text up to the start of the issue.

Re #3590, they may be the same issue - perhaps @jcsteh can answer that? Certainly the change of element seems to be the common theme, but whether there is something unique about a hyperlink which wraps lines?

[jcsteh]

This is absolutely not a duplicate of #15990.

#3590 is less clear. I'd say parts of the behaviour there are a duplicate of one and parts are a duplicate of the other. I'd be inclined to have reporters reassess #3590 after the fix for #15990 is live in a release. But either way, #3590 will be irrelevant if this (#2160) gets properly fixed.