Has anyone else noticed VoiceOver failing to read words, phrases, or entire sentences while composing and reviewing an email message in the native Mac Mail client? Arrow back over the text and VoiceOver reads it correctly. I've been on Sequoia for over a week. The problem is sporadic and rare, but it has happened often enough that I know I'm not hallucinating.
Comments
Crickets
Wow. No one else is seeing this. I guess I'll play around with some settings and see if I can make it go away.
Skipped words/phrases/lines
Paul,
I'm seeing this also. It seems to be partly related to the QuickNav bug listed in the bug tracker, at least for my use case. If I turn QNav off and back on again, it stops for a bit. If I use only full VO Nav mode, it rarely happens. I had to turn off "Always allow typing in text areas" to get QNav to work at all.
Note: for me, it is happening most in Plain Text documents in TextEdit. Though it seems to get worse and expand with use. I currently have QNav set to use Arrow keys only, Single Key is off. Note 2: It gets so bad at times that I gave up typing/word proc on my MB Air M2 and went back to my old MB Air 2017 Intel to do my word processing. Waiting for an update/fix.
In case this helps.
Thanks Nicholas
Any possiblity it's voice related? I primarily use Alison. I'm trying Alex today to see if it makes a difference.
I almost never use quick nav. I generally encounter this while composing an email. I use VO+left and right arrow to review a paragraph at a time, or up and down arrow to review a line at a time. This is almost always no problem. But occasionally, VoiceOver fails to announce chunks of text, which it reads just fine when I navigate back over it. It is not reproduceable at all.
I also see something similar in Scrivener when arrowing through characters. Some characters are skipped. Very infrequent and also not reproduceable.
Possibly related, in Scrivener, I make heavy use of VO+Shift+PageUp and Down to read by paragraph. In Sequoia, sometimes this fails to read the final few paragraphs in a document. Unlike the other issues, this Scrivener paragraph issue is very reproduceable. Seems to have something to do with whether the last paragraph in the document has a final carriage return or not.
If anyone else is seeing anything like this, please contribute to the discussion. I'd like to formulate a bug report.
TextEdit and voices
After a few hours of composing text in TextEdit with the Alex voice, I can confirm this issue occurs regardless of voice. And that's three apps, Scrivener, Mail, and TextEdit, that are exhibiting this behavior.
I'm surprised more people haven't mentioned this. Or maybe it was discussed in the Sequoia beta thread that I haven't read.
Skipping content and QNav weirdness possibly related?
Paul,
I haven't tried different voices yet, though maybe I should. My experience when it skips seems similar to yours.
* Going down by paragraphs jumps over one or more paragraphs without saying anything, but going up through same reads/reveals them all.
Same happens when using 'Navigation' mode.
Mine does not occur if using Sentences mode, or Line mode, but this needs more intensive testing.
* Also, another strange glitch possibly related; if I type one line of text, then press Return to drop down a line and type another on next line; Paragraphs mode will ignore the carriage return and read both lines as one whole paragraph, even though they are not.
However, if I put a blank line between the two lines, then it reads each as its own paragraph. Expected behavior should be; encountering a carriage return should signify the end of a paragraph, blank lines between should not be needed and never were before Sequoia.
This last Paragraph wierdness only seems to occur in plain text documents, possibly only in TextEdit?
Turning QNav mode off/on using left/right arrows simultaneously seems to correct the skipping menace, but does nothing for the carriage return disconsideration.
* One final QNav hiccup, using the Rotor function (Up/Right or Up/Left arrows) in QNav does not interface with the Rotor, random single characters are spoken instead. Until turning off QNav and back on again brings the Rotor back.
Some of these may be unrelated to the skipping phrases nemesis, but when QNav is being quirky the skipping seems to be worse. From my limited testing, the turn off/on with left/right arrows seems to help both temporarily. Alas, the issues return all too quickly.
Skipping over content may be only one symptom of a larger code issue?
I'll test a bit more without QNav and see what continues. I'll post again if pertinent.
Thanks for your efforts in this!
PS. using Alex.
TextKit versus TextKit 2
I wonder how much of these problems is related to TextKit2. From this article it seems clear that maybe Scrivener's issue might stem from continuing to use TextKit, which they are doing because TextKit2 is still not ready for prime time.
TextKit versus TextKit 2
I wonder how much of these problems is related to TextKit2. From this article it seems clear that maybe Scrivener's issue might stem from continuing to use TextKit, which they are doing because TextKit2 is still not ready for prime time.
TextKit1 or 2
Paul,
I tested this textkit2 possibility on my M2:
In textEdit Settings I made sure "Wrap to page is checked.
Then in a plain text document I also used the Format menu and chose "Wrap to Page."
Both these settings made no difference. All issues above are still present.
After no joy, in Settings, I'm going to play with the auto formatting of plain text, to see if it helps or defaults TextEdit back to textkit1. Currently I'm trying the Open and Save format "UTF16." If that seems associated with textkit2, I'll try dropping it to "UTF8" instead.
I'll let you know the outcome either way, possibly later today.
Thanks for that link, it may well be the scoundrel. Personally, it seems the skipping could be a result of the paragraphs recognition mode not functioning correctly. Since the mail client does not use plain text format, and plain text in TextEdit makes little difference, it may be boiling down to the recognition methods that the underlying text engines are using.
I have gone round and round with Apple on the use of "plain text" files for several years. They seem to try and involve stylizations into areas that should be left alone , as their format designates. There's a reason why people use "plain" text, to focus on content rather than form. Introducing form into these areas kind of defeats the intire purpose of "plain" text. At least in my universe.
I'll post more when I get time to test further.
Thanks again for your efforts here!
I've always found mail flaky…
I've always found mail flaky so expect issues with it. Sometimes you can read with just arrow keys, other times you have to drill down, other times it doesn't read anything at all and you have to bounce about a bit until if finds focus. Like most of apples own apps for mac and accessibility, it's crap. Music, podcasts, TV, Mail, Pages... the list goes on, it's convoluted hard to understand hard to use, and given little thought.
So, I'd not noticed it as my mind just added it to the pile of poor work on mac.
Mac blows.
Text skipping
Paul,
Alright, I did some more investigation into textkit 1/2 and TextEdit formats. It seems that UTF 16 and UTF 8, as with any specific formats will simply constrain which text apps can open/use them. I was hoping I could find a cause in the auto format setting by changing it to an open format. This did not pan out and if anything, caused additional issues.
Also with the additional glitches that may or may not be involved, it doesn't seem from my small amount of investigation so far, that the "formats" of file are a cause. I also looked some for reports/issues with the text insertion cursor, both with its movement through the flow of text and with having paragraphs recognized. I found no general issues with any of this for sighted non-VO users. There were only the specific use case scenarios involving 3rd party apps that are not mainstream. Though it was not a thorough searching.
Considering all this, I am thinking it is 'only' a VO glitch, possibly with the way it specifically interacts with the underlying text engines, depending on document formats. From my brief investigation, sighted users are not reporting this obvious of glitching interaction with TextEdit or Mail. I didn't find any reports of people having the i-beam cursor skipping over entire sections during normal usage. Those who were reporting issues with proprietary apps, like writing and layout apps, were not posting about multiple paragraphs being conglomerated
To test it with more definite content I made a new plain text file and typed the following:
1. Number 1.
2. Number 2.
3. Number 3.
4. Number 4.
There are no blank lines between, but a carriage return after each. Then I moved VO above the set and tried different rotor modes to move down through them. When using QNav to change the rotor to paragraphs, other QNav glitches aside, if I move down quickly then VO speaks the top line and nothing else, because it just skipped over the remaining lines.
If I slow down my movement rate just a little, it speaks the first line then skips several, but sometimes speaks the last line, sometimes not.
In Paragraphs mode, if I move down to the first line and don't touch anything, it pauses between each, but reads them all in sequence as if they are all one paragraph; which they are not.
If I put a blank line between each, it reads each individually, one for each press of down arrow key, but does not read the empty lines in between, as if white space is being ignored for vocalization.
Note: my results above apply mostly when using QNav with Arrow Key Navigation only turn on. Single key is off in VO Utility, and "Always allow typing in text areas" is unchecked.
At this point I am at a loss as for defining the issue or finding a work around, besides not using QNav at all. When I turn it off completely and use only full command navigation (Control-Option held down), it occures only occasionally. Though when it does, it still seems to be centered on the interpretted use of paragraphs. And the occurrence seems to become worse over time. Although, without being able to pull them apart and examine their code base, I can only guesstimate.
Not sure if any of this helps you when filing a report to Apple, but maybe it helps some? If I can define it better with more testing, I'll send a report to accessibility@apple.com as well.
If you want me to test something specific, let me know. I have not tested this much with rtf or html yet.
For now, I'm heading back to my MB Air 2017.
Nicholas
MacOS version?
Ollie, for me, this was a distinct degredation in behavior between Sonoma 14.6.1 and Sequoia 15.1. But I also changed from a 2018 Mac Mini to a 2024 Mac Mini.
Nicholas, what MacOS are you running on your Macbook Air? Please confirm whether the text flakiness we've been discussing is limited to Sequoia.
Re: Mail is Flaky
I have to agree with the fact that the native mail app on Mac OS has gotten a bit flaky. I used to be able to read a message and reply to it when necessary, and then go right to the next message in the list. VoiceOver would announce each message as I came to it, and I'm pretty sure this was the case with speech or Braille. Now, VoiceOver speech is skipping messages and I have to therefore read them out of order. While not a show-stopper for me, I think this should be looked into. I honestly haven't had much time to use my NLS eReader lately, but I'm probably going to take it with me to my parents' place when I am back there for TurkeyDay and will see how this performs with Braille. I believe that's the only issue I've encountered thus far. I've not done much in the way of word processing on here as of late, and all my journaling--or most of it--is done using Safari since the platform which I use is so accessible right out of the box. All righty then, I'm off to pick up my other hearing aid.
MacOS version?
Paul,
Mac OS 15.1.1
MacBook Air M2, 8 gig RAM, 256 Gig SSD.
Off the shelf condition.
No interface altering apps installed, nothing that changes the Finder, Mail app or TextEdit.
No apps loading on Startup. No 3rd party extensions, nor Safari plugins.
Only default apps allowed to stay in background.
I agree that the Mail app is flaky. Also, I don't remember having this issue before they changed the Commanders into Commands. This is where the QNav rotor issues appeared, also when the skipping became more pronounced. At least it seems that way from my own use case, which is mostly Safari and TextEdit. I use Mail app only 2 or 3 times a week. .
Hope this helps.
Move to start of line failure
When changing a file name, Command+Left Arrow sometimes fails to move to the start of the file name.
Twice now, I've tried to change the name of a file in Finder. I press Enter to edit the name, arrow around, make changes, no problem. Then I press Command+Left Arrow to move to the start of the file name, and it takes me back one word, but no further, as if I'm already at the start of the file name. I have to left arrow past a couple of characters first. After that, Command+Left Arrow jumps all the way back.
This is some pretty crazy stuff.
Feedback Assistant issue filed
FB16064649. I don't know what Apple can do with this. It's not reproduceable. They'll just have to use VoiceOver for a while to see it.
Direct further discussion to this bug tracker thread
AppleVis bug tracker thread.