Apple Releases macOS Sonoma 14.4.1 With Fixes for USB Hubs, Java Crashes, and More

Navigation is still very slow and causes much delay on many web pages, for example on YouTube when you browse through your subscriptions feed with VO-right arrow.
Can anyone confirm this?

I don't expect any accessibility-related changes in 14.4.1, and I haven't encountered any so far.
However, I am finding 14.4 to be an improvement. For example, some of the navigation and table-related problems previously experienced with VoiceOver are no longer present. In particular, VoiceOver is no longer erroneously reporting the end of a table while navigating, which used to prevent reading of subsequent table rows.

Yeah. Double point updates usually has little to do with accessibility. Intrestingly enough the bug with applevis subject field with VO not announcing when we move by arrows? This exact bug happened on getsupport apple when I was contacting them for accessibility. I reported that to them. The employee says he will pass it to the appropriate team. Like it's happening on their own website which is wild. For those interested monaco editor in safari is still completly unusable, so use chrome or something else for dev.

Has anyone gotten the audio captcha without doing anything? I use a survey site, that usually you have to click on the get audio challenge. This one is already done for us. If you want the survey site, or another one i use with your phone, both free, contact me off here.

During installation, when the computer reboots and VoiceOver restarts, VoiceOver's volume is set painfully loud. Anyone else hearing this, or is it just my 2018 Mac Mini?

I noticed this when I upgraded to 14.4. But I just experienced it again with 14.4.1 and reported it to Apple, as this is dangerous and could damage users' hearing.

Maybe using the system speakers, it's simply loud. But if you value your hearing and use a pair of in-the-ear earbuds or headphones, remove them before you upgrade.

Yes, I can still reproduce Safari sluggishness on web pages with lots of content.

Here's my favorite test case. And if you go to that page and think performance is fine, then VO+U open the web rotor, arrow to headings, press End to go to the last heading, select it, and then try navigating around a little. Good luck.

I've had the loud volume bug in recovery and setup for a while. A temporary fix is turning VoiceOver off and on again, then it'll go to a normal-ish volume, but it's not ideal. You can also still adjust with the voice rotor

Oh. I have a much better solution than turning the volume down. I jump up from my chair, yank out my earbuds, and scream epithets so foul that decorum prohibits me from repeating them here in this respectable community.

Unfortunately, by time I remove my earbuds, the damage has already been done. That's why this is a serious bug. It can inflict pain and cause physical damage without warning. Apple needs to fix this before they get slapped with a lawsuit.

I have a brand spanking new MacBook Pro equipped with the M3 Max Processor, 64 GB of RAM and I cannot use Safari at all, except for 5 minutes or so, then all I get is "Safari Not Responding. I'm honestly within a hair's breath away from taking it back to the Apple Store and see if I can get my $$$$ back! It's pretty bad when the default browser that is most compatible with Voiceover is 3 shades of useless. I do a lot of accessibility testing and it is necessary to have a browser that works well with Voiceover to gather a baseline experience with a site. Unfortunately, Voiceover, is still rather dodgy with other browsers. I've found the experience with Chrome to be a bit buggy, but once you know what Chrome is throwing into the mix, it's fairly easy to sift that out -- especially if you are testing the same site or web application on a regular basis. If anyone has any suggestions for browsers that work with Voiceover as well as Safari used to, I'm open to new options.

Good to know that I am not alone with the sluggishness in Safari. However, the behavior described by Jeff is not reproducible on my M2 Pro Mac.

@Jeff: Can you put some examples together where I can test and verify your experience?

I got almost a little excited reading the above that my problem with tables would be resolved, but sadly it doesn't seem to have changed.

This is when you filter a table client-side (possibly by hiding rows) and voiceOver is then unable to navigate the table.

I can't remember where I put my reference html file to check that, but logging into AWS and trying to search for CloudWatch logs and the problem is very much alive.

Paul, I did everything I could, i didn't get the not responding message. Running a Mac M1 with a touch bar. Also as for the volume, I use the earpods, I can't find my airpod, it bounced off my foot somwheres. When the comp restarts, I don't hear anything except it from the speakers not the earbuds themselves. Also, it used to display progress. Now we get the lovely "Installer has no windows, ding!" :)

Hey Siobhan. I'm using wired earbuds in my Mac Mini audio jack. I wonder if that makes a difference. But here's what I experienced: Start the installation. After a bit, the Mac reboots. When it comes back up, VoiceOver starts with the announcement, "Installer Progress." And that announcement is so loud it's probably still echoing off the Rocky Mountains of my beautiful state of Colorado. Once I turn the volume down a bit and try to nav around, that's when I hear, Installer has No Windows." So, we're on the same screen, but we're not experiencing the same volume issue.

As for SNR, I haven't mentioned it in this thread. Is still around, but for me at least, it's much less of an issue than it used to be.

More common these days is loading a page and getting zero feedback that the page has loaded, no announcement of the page title, no satisfying audio sound that we've come to associate, like Pavlov's dogs, as a loaded page. I routinely experience this with the main AppleVis page. I click my favorite, or type AppleVis into the address bar, then crickets, even though the page is fully loaded.

Sonoma has done nothing to improve Google Drive and Docs. If anything, they're more challenging to use in Safari than ever. I'm not even sure how to organize the bug report. My previous desktop QT recording of Drive navigation issues seems to have been relegated to /dev/null, so I'm not inclined to invest time in what would now be a much lengthier and more involved screen capture of the many issues I routinely encounter with Docs and Sheets.

In spite of the woes, I'm getting work done, which is great, because lately I've been busier than a one-handed chef in a pizza factory.

is criminally bad. Sighted people can enjoy macos and use their favorite industry standard microsoft office apps but voiceover users are stuck with pages on mac or go to windows. Excel is the most accessible, for docs sheets and slides... everyone who read the shortcut lists will agree that these are only accessible on paper, should a new term be invented something like ax for accessibility experience or uax, google will receive a -10/10. on mac, command ctrl shift to go to the table and then cmd ctrl v and b for previous/next columns!? On windows we don't care, in fact I always thought google docs was almost 100% accessible on windows as nvda and I guess jaws perfectly handel the ultrasmartedit field and we can just go in brows mode and hit t to go to the table and... all the usual web commands in fact work! For windows if I were to use google shortcuts first I'd have to assign other than alt-ctrl-n for nvda, then do alt-ctrl-n, then alt ctrl-h, much like talkback two times gestures, to go to the next heading... For previous heading, first go in us keyboard layout as with the french canadian one ctrl alt p inserts ¶. And no tall these steps you have to figure them out yourselfe. Google for their mac shortcuts still say to do ctrl option tab before each menu access like ctrl option f as they don't know or don't tell that you can/must just assign vo key to capslock, but then we could also blame apple hear for such a poor keyboard ergonomics.
Anyways. I tend to appreciate even more accessibility since I have my mac, we are really in a comfort zone on windows despite some people's opinion there on applevis. Mac is... DIFFERENT in every and 95% of the times bad way possible. But I still giltfully enjoy using Pages so :(

Has anyone noticed this? I don't know if it's a long standing buggy behaviour of VO but I noticed that voiceover is kinda stuck sometimes in system password fields (non-web)? Like we can't do vo left/right arrow and tab works only sometimes?

I get the feeling I was smart to stick with Ventura. Am I wrong?

I've noticed that tab and VO+arrow often fail to move focus out of a password field. I've found that VO+Shift+up arrow sometimes helps (as if we're interacting with a group). Other times, I result to using the web rotor or item chooser.

Here's my list of favorite password field issues.
1. Password fields never appear on the VO+U web rotor form fields menu.
2. Keychain autofills your password everywhere except pretty much any Apple website, such as store.apple.com. Hard to miss the irony.
3. If you tab through controls, then once you fill in your password, tab and VO+Arrow might not move you out.
4. Password fields disable NumPad Commander, so if you nav with NumPad 4 and 6 while focus is in a password field, you erroneously enter the digits 4 and 6, causing your login to fail.

Safari is in such disrepair that I wonder if Apple plans to repeal and replace it, much like Microsoft did with Internet Explorer.

While I'm making my list of favorite issues, let me attempt to summarize what doesn't work in Safari with VoiceOver when using Drive, Docs, and Sheets.

1. In Drive, use J and K to navigate the list of files. You might hear "list box," "list box loading," or "More info (Option + right arrow)". But what you won't hear is the name of the file. You need to press VO+F3 to get that.
2. Don't press J and K too quickly. Otherwise, VO focus doesn't keep up with Drive focus, and VO+F3 reads the name of the wrong file.
3. Assuming you can find the Doc or Sheet you're looking for, open it. It's a coin toss whether VoiceOver focus lands in the Doc or Sheet content. Half the time it's in some empty text field, and there's no way to quickly move focus to the content, not that I can find. Best workaround is to close the window, toss some salt over your left shoulder, and try again.
4. If you've got a Doc open, try reading by word with Option+Right Arrow. Before each word, you'll hear "zero width space". Shakespeare becomes "Zero width space to, zero width space be, zero width space or, zero width space not, zero width space to, zero width space be." Now read backwards with Option+Left Arrow and notice that the issue is not present.
5. In Sheets or Docs, open the list of file history and try to restore to an earlier version. This is something you just have to try, because it's too enigmatic for me to comprehend where things go wrong.
6. Back in Drive, my whipping boy. Try to move or copy a file to another location. The web dialog will not let you move focus to the list of folder locations.

If I tried to record all this in a QT video, I'd waste an entire afternoon. As it is, I already want the last ten minutes of my life back.

Thanks for listening. Sometimes it just feels good to talk. But if I ever whine too much, don't hesitate to tell me to shut up.

When I sleep at night, I dream of Mavericks.

Paul,

Any chance the reading by word with left and/or right arrow is affected by having keyboard commander active?

Also a word of advice if you use external media that's formatted in ExFAT. Sonoma doesn't seem to handle it super well after transitioning the particular file system handling service to User Space, at least in my case, Ventura does better on that front so I had to roll back.

While I certainly understand your issues and frustrations and 101% share those, and you made me laugh for 3-5 minutes, keep in mind that google themselves recommend using chrome for all their apps. And unfortunately for us blind folks on macos, although voiceover handel chromium very poorly, it still work and docs for me is actually ... functional? but for their crappy shortcuts. Trust me, you don't want, can't use, gmail standard view. Well on ventura you couldn't period. You either had to reduce the message list to 10 per page, or ... use apple mail client app, no matter the browser you had, as VO would keep saying Safari/Chrome/Edge does not respond. Apple, at least for my device, did a real improvement in the safari bug, which shouldn't have been there or patched very quickly in the first place but we could give them a fraction at least of the credit where credit is due. As for gmail standard view with 100 messages per page, now on safari since a certain version of sonoma, it works actually, voiceover doesn't crash. But after the 8-9th message with down arrow, voiceover, sometimes work normally, sometimes says listbox when up-down arrow, or yet sometimes says listbox after 8th-9th messages in the list for no apparent reason or predictible behaviour as to why and when. In chrome, at least until now, I have non of these problems, and x actually works as intended there, selecting messages and doing bulk action on them.
I am not defending safari or apple at all, they have earned the award of the worst desktop screen reader, or at least the most difficult to use, and I tried a lot of them except any of android, but did speakup, tdsr on mac, orca on debian and ubuntu with mate, accessible coconut (which is mate, but a distro I saw never mentioned on this website so give it a try I don't like the concept but linux unfortunately needs something as the os community don't give a shit about accessibility), vinux4, vinux5 (horrible) at its time, and some old images of horalux which was there like in 2005 or so.
Anyway. I never tried drive on web as I just installed the desktop app and regreted it during this horrible status bar bug around sonoma 14-14.2 or something like that. That's why I am so interested about the ipad, if ios apps can work there it'd be awesome especially for basic note taking stuff at college. Like word there can't be worst than on mac right?
PS: has nothing to do with the topic, but I bought my mac after the reddit apollo dramma (saddest thing of the year and one of the least effective online protest I've ever seen in my life)but for nostalgia how was apollo on macos? I was so close to purchase this app in march 2023 and was already considering buying mac and seeing the bennifit of this wonderful client...

How serious this issue is and its cause? Like I have windows and mac as my daily drivers everyday and I often tend to format my drives to exfat for compatibility issue, are there any workarounds? Don't think we have another option than exfat for compatibility mac-windows do we?

Thanks TheBllindGuy07. For the longest time, my problems with Chrome were twofold. One, VoiceOver couldn't navigate large tables. Two, I wrote a script to make it easier to deal with comments in Google Docs, and the script only worked with Safari.

Based on your comment above, I took another look. Problem one has vanished with current Chrome and Sonoma. Just a minute ago, I navigated a table with 134 rows.

Then I played around with Drive and Docs and encountered none of the issues I described above with Safari. Google Chrome was a snappy browser. I even tried my rubik's cube page that reproduces sluggishness in Safari. The sluggishness is greatly reduced in Chrome.

It might finally be time for me to accept that Safari will never be fixed. It might finally be time to move to Chrome.

Hi Brian. Keyboard Commander has nothing to do with the "zero width space" issue I described in Docs. When my right hand is on the arrow keys, my left hand is on the left option key, not the right.

Oh it's good news if they have finally fixed the problem with long tables. My other problem with Chrome was that it had more focus problems than Safari (I know that hardly seems possible). For example, I'd read articls and get shunted to the top and be going round in circles. It's possible that's connected to the table bug maybe. (Do sites still use tables for layout in 2024? I guess some are bound to). It did struggle with some aspects of Bitbucket (like getting stuck in someone's name and being unable to get past). I'll start using it again in earnest and see how it is. I'd love to be able to use it in place of Safari. That would also open the door to Edge as a proper alternative with its lovely read aloud feature.

I get so downbeat about some of threse bugs that I'm usually totally amazed when they suddenly get fixed.

I was using Chrome yesterday and noticed it wouldn't read our the options inside a select dropdown. I've definitely had that elsewhere but it was just silent, so I had to randomly choose something move back and forth and check if it was the right thing. In Safari it was fine. This particular example was an Angular site I had developed so I know it was a real select list and not some dodgy thing with divs or whatnot.

I personally think the only real way forward is to use both and flip between them as and when problems occur. Don't think I have ever had a Chrome Not Responding before.

how good (in compareason) the web browsing experience is on ios versus the mac.

Mr. Grieves, Yes I've seen some issues in Chrome where VoiceOver refuses to read drop down menu entries. You are spot on when you say the best solution is to use both.

In my case, my ExFAT drives simply took a looong time to mount, if they mounted at all. However, if you Google "Sonoma" together with "ExFAT" you'll notice a fair amount of people having issues with slow mounting, drive corruption etc. which wasn't encouraging to me.
I'm not sure if the issue is resolvable, but all the fixes I read did not work for me.
Regarding your second question, I guess NAS, cloud synchronisation or third party NTFS software might be ways to go, though they aren't ideal. Also, ExFAT isn't journaled, so it's easily corrupted. If you use it for backup, you might be better off with APFS or possibly HFS+ if it's a HDD, and then have a separate drive or partition for moving data between mac and Windows in ExFAT.
I read up on ExFAT recently in connection with this, and it's made me reconsider using it for longterm storage. I mirror my external drives to the cloud with BackBlaze, but I think I'll reformat to a journaled file system for external data storage, and then move data between MacOS or Windows with one of the methods above.
Do let me know if you find an even better solution😊

Best
M

I use rsync over ssh to transfer files between my Mac and Linux machines. The same would work for Windows systems. On the Mac side, it's available in HomeBrew. Another option would be to enable the SMB server on one of the machines.
I use an external drive only for backup purposes, as well as some USB flash memory devices to boot operating systems for rescue or installation.

I have tried, but the update isn't even appearing for that long if at all. This despite VoiceOver speech prompting me that System Settings has one update. I'm going to try it out with Braille, but is anyone else experiencing this? I admit it could be due in part to the fact that I haven't done a backup for a good while. But that is due to an issue with my external hard drive, which I plan to try and resolve hopefully in the coming week or so.

The update worked for me via the normal method in System Settings. If you can't update this way, there's a command you can enter in the Terminal to perform the update. I can't remember the command details, but a Web search should find them.

Ah yes, Rsync or SMB are excellent ideas - thanks for those!

best
M

I'm not convinced this is fixed. I was battling away with quite a simple but big table in Chrome and it refused to go down beyond the bottom of the page. I switched to Safari and it had no trouble. (Something I don't say very often).

On the other hand, I was trying to add a comment to Jira in Safari. It really struggles, particularly with lists for some reason. If you try to skip words in a list it just talks gobbledegook. And it doesn't speak the last couple of characters in a list item. So I went in and added the missing characters in, only to find when I saved it they had double up. But it was impossible to find them when editing in Safari. And it kept telling me that words were misspelled when they weren't. So I tried in Chrome and it seemed to work fine.

If you haven't already discovered this, the issue with not being able to navigate a full table in Chrome seems to occur when the table is too long to display in full within the browser window. Movement of VoiceOver focus appears to be limited to the visible portion of the table. To work around this issue, try using the "Zoom Out" option (Command + Minus key) to reduce the size of the web page content to the smallest possible. This should allow more rows of the table to be displayed on the screen, enabling VoiceOver to navigate the full table.

It's ridiculous that this is necessary, but it does offer a workaround in many cases until this is resolved 🤷‍♂️

Yeah, thanks - I forgot that worked. I've just got used to abandoning ship when I encounter large tables in Chrome. I think the zoom out workaround only goes so far. I had hoped that Paul was right and it was now fixed, but sadly not in my case.

Hello. I just wanted to come back here and say that the update finally installed on my end. I was actually in the process of connecting to a Zoom event with Hadley, which I ended up not having time for anyway. But it's all good now.

I just checked again. A 110-row table in Chrome posed no problem for me. This used to break as you described, but no more. Once I've navigated into the table, I can VO+Down for as many rows as I want. I can also press VO+End to jump to the last cell. I have not tinkered with the web page zoom level. Sorry, man, I wish it worked for you.

I disaggree for the zooming method. You can just do page down and it will scroll one screen/page up, making visible the rows below. Chrome, with microsoft word (and it's the only positive point on macos of that app) paging through text actually works with page up/down. Vo page up/down only seems to work in slider such as the brightness one in control centre. Very usefull, apple. What is a page as described in your guide and even with vo k? Anyway

I had previously given a website, a rubik's cube website, that demonstrates the sluggishness issue. However, I am currently working with a website that makes the cube website look like child's play.

The website in question is myidentifiers.com, the Bowker website for ISBN book numbers. I'm attempting to associate a new book with an ISBN. As I fill in the ISBN information, Bowker dynamically adds more radio buttons and checkboxes. At this point, the page has several thousand form fields. Each VO+Arrow literally takes several seconds. Finding controls by navigating is simply not an option. And of course all the work I need to do is at the bottom of the page where the problem is most noticeable. And of course there is no option to save my work and come back in a different browser.

It'ss a bit like chopping vegetables. You don't know you've sliced off your finger until it's laying on the cutting board, and at that point, the damage has already been done. In the same way, here I am on this website with a broekn Safari browser, and there's nothing I can do about it but muddle through.

Apple needs to fix this bug immediately.

Does reader view affect VO's responsiveness?

interesting comments here and elsewhere on the sluggishness in Safari. I've been trying to delve a little into this. @Paulmartz: Thanks for supplying the examples. Your most recent one is mind-blowing in how it causes Safari to demonstrably slow down.

I'm not convinced that this only manifests itself at the bottom of large pages. I subscribe to a private forum on my favourite football team and when the page has large-numbers of comments, the browser/VO combo is disastrous. The structure of the page is somewhat unusual in that the forum posts are all located in an expanded tab-panel. The sluggishness is observable from about half-way down the post-listing within the tab panel, however once one comes back up the hierarchy to the content following it, the behaviour returns to normal.

This begs the question: is the sluggishness caused by the breadth of the DOM (document Object Model) or its depth, or other salient aspects I haven't figured out yet. I just think it's interesting that for portions of this large page the behaviour is fine, but for others it is disastrous. I'm running an Intel MacBook Pro 2019, with a 4TB internal HD and 64GB of memory. This spec should be more than adequate, one would have thought, to browse a simple webpage.

I found a solution. Clicking "submit" worked. It told me the form was incomplete, but saved it and allowed me to come back in via Chrome, where everything was lightning fast.

FYI, I reported this issue to accessibility@apple.com citing that rubik's cube website as an example, and they promptly said they reproduced it and would forward it on.

Bruce, reader view is typically for articles, and in my experience, twenty or thirty HTML paragraph elements won't trigger this bug. Think hundreds or thousands of radio buttons, checkboxes, labels, pulldown menus, form fields, images, and short little text snippets. From a software perspective, imagine a loop in the VoiceOver code. Everytime you navigate, VoiceOver iterates over all preceding HTML elements. The further down the page you go, the more time VoiceOver spends looping. That's my theory.

I think at this point we need more than bug per bug report solution. Voiceover code must be rewritten from the ground up or undergo at most a heavy inspection by today standards. Do you know that even on 14.4.1 stable if you open the ican tld list .txt *PLAIN* text file which is only about 9k characters long if you are unlucky enough you can trigger Safari does not respond? This is pathetic. Oh @paul terminal and ncursus is horrible so... Nope, terminal doesn't work either in contrast to what apple clearly says in their doc. Text editing is horrible, apple can really be proud to break what is considered to be universally the most accessible if not accessible by design thing on macos. Web navigation is much smoother on ios..... I will throw this here so I am not attemptd to get lazy, an oevrall accessibility report with all its bug and especially which goes beyond voiceover of about 40+ pages long, listing all the new and especially older intelorable bugs must be written, developers like the vosh guy should heavily contribute to it, with screen shots and old feedback IDs which were closed but never acknowledged or corrected... As I said, these are especially hard to believe and to deal with for windows users for who plain text is often the last, and easy resource when they view or edit content. I talked to this to a friend of mine who is a former employee at apple and who had a mac, he was... traumatized. . Think of this battle between microsoft and apple blaming each other for who should do the dirty work of making microsoft office actually usable on mac with voiceover. Who is penalized? Us the end users. In 2024, qt, which is a well known standard in the industry, is not supported at all with voiceover. Chromium support is still horrible. Mathml is good but so cluncky that with large expressions it becomes too complicated to just remember where we are at in that expression. Voiceover doesn't announce superscripts or subscripts in pages, either via speech or via braille. Scrolling, the equivalent of hitting page up/down on windows in any text area or website, is impossible without the trackpad and even then it's too slow to be worth it. Examples are countless. I come from windows. Things like editing text and knowing if the comma (or any symbol) is at the end of the previous word but the screen reader announces it when the cursor is at the next one were inimaginable to even think about. Why option down bring the cursor at the end of the paragraph and option up at the beginning at the previous one? Okay, we can do, control, option, shift, fn, and down/up arrow. Five keys combination to replace two. Or three with capslock but you see my point. Read the reddit posts of the guy who is working on vosh in r/swift. His findings shows how accessibility is just broken at the core of macos. We must stand up and show to apple where they are wrong.
I hoepe soon, despite my study, I can actually come on applevis with a separate topic which will be more than agitating the crowd for nothing and, ... well, something more concrete or at least a real action plan of it.

Sadly you are quite right. The problem is that Apple doesn't really seem to have a handle on it. They may fix one thing over here but it breaks two over there.

What we need is something that is stable at its core, and something that can be properly tested using automation to prove that changes aren't breaking existing things. If Apple just release VoiceOver 2, it's only worthwhile if they learn the lessons and can ensure that it can be maintained properly.

I don't get the impression that anyone at Apple really understands how VoiceOver works now. I bet their developers aer scared stiff about changing anything at all.

Trying to use the Mac as a serious work machine with VoiceOver puts me at such a big disadvantage compared to my sighted peers. I am already at a disadvantage because personally using audio instead of sight is much, much more difficult for me. But to have all the crap that macos puts on top of that is just crazy. Things that I shouldn't have to give a second thought to suddenly become complicated tests of perseverance and I'm constantly having to double check everything in case I've been fibbed to by my screen reader.

One thing I found recently - I use Jira at work which is is both largely accessible for a lot of things and also maddening to use. I wondered why my tickets kept getting a weird status - I'd mark them as Done but when I went back they were set to On Hold or something. And then I tried again and sometimes - maybe just under half the time - it will lie to me. I change status and use up and down and it will say "Development to Done, press up and down to change values press enter to select" and because it takes so long to say that I've usually pressed enter. But if I wait it then says "Development to Monitor. Development to On hold" or something as if it is three options in one and I have no idea what it is doing. So just the simple act of marking a ticket as Done is taking me about 10 times longer than it would if I could see. And I don't think there is any single thing that I do that doesn't have some element of this about it.

Who knows if this particular example is Safari, VoiceOver, Jira itself or someone jabbing a voodoo doll of me with a big pin, but in any case these things don't make me feel professional and don't ever get fixed.

I've said this before but I don't quite understand why AI isn't being used for QA. Why do we only use AI for the things that are enjoyable anyway? I can write code myself. I can write my own emails. But as a new developer I would likely be completely incapable of knowing the ramifications of changing something in the VoiceOver codebase particularly given the billions of permutations that all the different configuration options.

So I thought I would just create a basic html page with no styling or scripting, with a table in it and 800 rows, with 5 columns. Each cell just has text with the col and row number in it.

In Chrome, I navigate to table, then start using vo+down to go down the first column. Once I get to about row 30, it jumps up to the top of the second column. If I do the same in Safari it keeps going down.

Chrome tells me there are 800 rows. If I vO+end it says end of table but I can't seem to navigate up from there.

If I go to the first cell and use down without VO it will go right to the next column, and once I get to the last one it goes down to the next row. And I can use this to get beyond row 30, but it means going past every single column so takes 5 times longer. I'm guessing for more complex tables this would take even longer.

I also tried opening up item chooser and jumping down to row 36. This took me there and I could then go down a few rows before it jumped me to the top again.

I had a look in VO Utility and there are a couple of options for tables under Web but they didn't make a difference. I'm sure there are some other table options in there somewhere eh to control whether the table headings are spoken but I can't immediately find them and have run out of time. I'll maybe do some more digging.

I should also say I tried with and without a table header row.

So, to summarise, I don't know why it works for you! I presume you are on the stable release channel for Chrome and not using a beta?

I'm wondering if your issue has something to do with what sort of cursor or fous tracking you are using, such as VO only, or moving with cursor, or having the mouse follow your focus or what. Have you experimented with your tracking settings?

I'm on the release version of Chrome. It worries me that you still see this issue and I don't. Bugs that go away by themselves come back by themselves.

I have felt for years now that Apple either has no automated regression testing or simply ignores the thousands of failures that certainly must appear with the approach of each release.

Quality, schedule, and resources cannot all be inflexible. One must give. And resources are often fixed - you can't simply hire a thousand engineers at the drop of a hat. Apple is left with a choice between schedule and quality. We know how regular their schedule is.

Quality must suffer as a consequence. As a release deadline looms, Apple can either kill a new feature, or opt to not fix bugs. But with schedule and resources fixed, they can't do both.

Well it was worth a try, but I messed around with the cursor options and nothing seemed to make a difference.

I found the other table options I was looking for yesterday - they were under Verbosity then Announcements. But just about speaking the header as you move across columns and I got rid of the header to simplify things anyway.

I'm clinging to the hope that Paul has maybe got hold of a newer version of Chrome than me. Possibly they release newer versions in the US before the UK?? I'm on Version 123.0.6312.107 (Official Build) (arm64). OK maybe a bit optimistic but you never know.