-
-
Notifications
You must be signed in to change notification settings - Fork 634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mouse Tracking Glitch: Wrapped Hyperlinks #3590
Comments
It would really help if we knew what text unit resolution was used when this was reported. Anyway, this is probably quite hard to reproduce for blind users |
There are a couple of issues here, and it also varies between browsers. To test, I threw together a test page and just uploaded it on another domain I had easy access to: http://22point.com.au/random/test.html I wrote three lines of text, one plain text, then a paragraph break, then another long line with a long link in the middle, then a BR linebreak, and finally another long line. Exact results depend on your zoom, so I set my zoom such that the two plain text lines fill two lines each, and the link takes up one full line and a part line either side. In Firefox, with text unit resolution left at the default "paragraph" OR changed to "line", the results are the same:
With Text unit resolution set to Word, hovering over any plain text word, NVDA reads that word (as expected). However, hovering over any part of the link on either line, NVDA reads "This" - the first word in the link. Set to "character" is essentially the same behaviour - NVDA reads that current character on any plain text, but "T" on any part of the link. In Chrome, with text unit resolution at Paragraph:
WIth text unit at Line:
With text unit at word or character: the first word (or character) of the current block of text (plain or link) is read. Once I updated the document, to the current version (with the paragraph and line break) I can't get mouse tracking to read reliably at all? It will often read the first or last lines, but then just reads the document name and goes silent. Microsoft Edge seems to ignore text unit resolution and just reads the whole paragraph of text of the current type regardless. Internet explorer also seems to ignore text unit resolution:
So a bit inconsistent and not ideal. |
This inconsistency would be good to fix, but I think this would be a fairly time consuming bug to fix. I am going to label this as |
@Qchristensen, @feerrenrut I guess this is still reproducile? I am fully blind so unfortunately I cannot test it but with #9064, #8572 and other recent PRs I think the priority for this issue could be higher now. |
Yes this is still reproducible with the latest alpha and also NVDA 2018.4rc1 |
This is still reproducible in 2019.2rc1 and being reported by users. |
I've had another user report this against 2020.4 still, who also added that the same happens with formatted text such as bold or italic text. |
This is still an issue in 2023.2. It seems to occur in Chromium-based browsers and apps. Chrome and Edge exhibit this behavior, as does an app like Discord. Firefox does not have this issue. This is a paragraph, and this is a span element inside of the paragraph. The spand text will break the mouse tracking reading, regardless of text resolution setting. And in code:
Narrator and JAWS do not have this issue on Chromium-based applications and browsers. |
Reported by kumajuannazhi on 2013-10-20 19:43
There are times, visually, where a long hyperlink is wrapped between two or more lines. There are others, in which there is a line of text that is almost completely static, but for a hyperlink at the very end that wraps down to the next line.
When using Mouse Tracking with NVDA in the first case, it only reports the first line of the link, though it can be manipulated to read the whole link, once, if you feign an attempt to left-drag the link to another part of the window. However, if you try to drag it again, it only reads the first line as you replace your cursor over it, and simply goes silent once you begin the drag.
In the second case, NVDA will speak the plain text before the link, as expected, but it'll stop just before the link. When this happens, the same issue happens with the link when you put your cursor over it, as did in the first situation; except when you point to the wrapped portion of the link on the next line, it still reports the first line without reading the wrapped part. Also, it fails to read any plain text after the wrapped portion of any multiline link.
The text was updated successfully, but these errors were encountered: