Description
When reading Wikipedia articles in Dictionary, Voiceover may repeat certain blocks of text multiple times.
When reading Wikipedia articles in Dictionary, Voiceover may repeat certain blocks of text multiple times.
In VoiceOver Utility > navigation, set the, "Mouse pointer," popup menu to, "ignores VoiceOver curser."
Comments
Very repeatable in Sequoia 15.2
I would like to add more details to this issue. While it is still present in Wikipedia articles, I'm seeing the same or similar issues while reading articles from most any web server. The cited workaround involving the mouse pointer is ineffective.
To reproduce, open any news article. For example, anything from NYTimes.com. Navigate to the article heading with VO+Command+H. Then press VO+A. Expected behavior: VoiceOver should read the article from the heading to the bottom of the HTML content. Observed behavior: Initially, VoiceOver seems to work as expected, but invariably VoiceOver jumps back to content it has already read. The result is that you might hear several paragraphs repeated.
I see the repeating on Wikipedia as well. Most wikipedia articles have a 2-column table near the top containing article summary information. I typically navigate to the last element of that table, then press VO+A to read the article content. Typically, VoiceOver reads the first paragraph of the article then jumps back and begins reading the table that I skipped past. It's also common for VoiceOver to jump to the footer section of each page, skipping the article content entirely.
These issues have been present for a significant amount of time and appear to be worsening rather than improving.
Yup
What Paul said.
This has been a thing for a depressingly long while now; I'd basically taken it as red (which is when you know things are bad). Unfortunately the only workaround I know of is the copy-and-paste trick; trying to browse the HTML content directly will eventually be incredibly frustrating and not worth it, just Google instead.
I'll agree with Paul, too, that this is by no means limited to Wikipedia; find a suitably long dictionary entry in a local dictionary and it's still a thing.
A question
Obviously this is happening in the dictionary, but is this happening in Safari off of webpages? For example, say I want to hit up Wikipedia for information on George Lucas, would I get the issue that Paul described above?
If that is the case, what a different browser other than Safari help at all?
Thanks in advance.
Specific to Dictionary App
There are sometimes problems in Safari that make navigating hard, like consistently reading Wikipedia summary boxes, but this repeated content problem is specific to the Dictionary app.
Both Safari and Chrome
I don't use the Dictionary app, so can't speak to that. I typically use Chrome to read Wikipedia entries, and typically use Safari for news articles. I experience these issues in both use cases. I use Safari because it has better reader view, but whether reder view is on or off doesn't make a difference.
George Lucas
I just reproduced the repeated reading issue with the George Lucas wikipedia page in Google Chrome. Steps to reproduce:
One. Open the page in Chrome.
Two. Press VO+Shift+T to jump to the universal summary table, 2 columns, 9 rows.
Three. VO+right into the table.
Four. VO+End to jump to the end of the table.
Five. VO+Right once to navigate out of the table and into the first paragraph of the article; it begins with Lucas's full name.
Six. Press VO+A.
Expected behavior: VoiceOver will read the entire article and will not read the 2-column table.
Observed behavior: After reading the article's initial paragraph, VoiceOver begins reading content from the 2-column summary table. After reading all content in the table, VoiceOver re-reads the initial paragraph of the article, then finally proceeds to read the subsequent article content..
Yikes
Yeah, I don't miss macOS ... I was hoping somebody would say that it worked fine on Chrome. Seems to be the usual answer when somebody tries something on Safari, and it fails miserably.
Sad to hear that even on Chrome, this bug exists.