Safari and WebKit Applications Can Become Unresponsive When Using VoiceOver

Can anyone provide a website where this issue can be re-produced? Apple Accessibility Team has sent me asking for a list of those sites.

Based on reports from many users, one of the major challenges in providing reproducible steps to Apple is that the "Safari not responding" behaviour seemingly occurs spontaneously and sporadically.

In my own experience, I've visited web pages dozens of times with no issues, only to have VoiceOver suddenly freeze on a page I've used many times before. There seems to be no consistent pattern to when or why the freezing occurs. A page that triggered it yesterday may work fine today.

The randomness and unpredictability of the freezing is one of the most frustrating aspects of the bug. Just know that it can happen on any page, simple or complex, and that may have worked fine before.

Of course, I would love to hear from anyone who does have web pages where this behaviour can be consistently reproduced, as a list of sites would help Apple engineers investigate further.

I still had some residual eyesight when I first encountered this issue. It's worth noting that, when the bug is encountered, VoiceOver doesn't prevent sighted users from interacting with the website content. Links work, scrolling works, form fields can be filled out, all using keyboard and mouse. However, any VoiceOver navigation commands are ignored.

Check out websites like MSNBC.com and CNN.com. Also YouTube can sometimes reproduce this. You can also check out gaming websites. If their are a crapton of videos and animations and other dynamic content, it can reproduce this issue.

HTH.

For those regularly experiencing this bug and in contact with Apple about it, if you haven't already, it may be helpful to capture a sysdiagnose while a webpage is unresponsive. This could give engineers a snapshot into the activity of the Mac as the issue is happening, which could, at least in theory, point to a specific cause of this behavior. To do this, when you hear the announcement that "Safari is not responding," press Control-Option-Command-Shift-Period. If you're running a beta version of macOS, you should get a notification offering to start a feedback report once the file has been created, or you can locate the file manually whether you're running a beta or not in Finder by choosing Go > Go to folder (or pressing Command-Shift-G) and typing "/private/var/tmp" without the quotes.

I have been contacted by Apple, and in the first instance they asked for logs to be reported to them along with time stamps. I have already done this. In the second instance, they requested to send them list of websites of where the issue can be triggered. I explained to them a rather weird issue when this issue happens, that the activity monitor demonstrate high power consumption by VoiceOver, the only way to reduce that to normal is to switch VoiceOver off then on, the same procedure to get the power consumption by VoiceOver to normal is also useful to get rid of the Not Responding Safari message. Now this makes sense that I observed when the issue happens my Mac uses more energy and I can confirm this as the percentage of available power is lower 1% each two to four minutes, even if no work at all is done with the Mac. Also this high consumption power is not reported in the power status in the Status Menu. So it seems that even the OS is not aware of what is happening. Now Apple has the logs and has every tiny bit of details, they should sort this out.

Ctrl-Option-Command-Shift-dot (i.e., the key to press with the modifiers held down is the full stop, period, character)
This is especially useful to those in the beta program, but anyone can run it.

Without this kind of detail, Apple's developers probably won't be able to reproduce and fix the bugs.

Over in the "we deserve better" thread, you can find my bug report posted as a comment. I cited the problem URL as one of their own Apple Support pages. But as we all know after two years of discussion, it can happen, or not happen, pretty much anywhere.

Now that's what I call "continuity". 🫢

Hey guys, fancy finding y'all here. On one of the other threads, somebody mentioned keeping the touchpad commander on with headings and flicking down when Safari goes on holiday. I'll be jiggered if that doesn't seem to work. I've tried it twice so far on seemingly never-ending freezes. Of course, now I've jynxed it.

I just sent my first sysdiagnose off. I don't hold out much hope, given the comment above that the OS doesn't seem to know it's happening and Apple's requirement to be provided with a site where it happens consistently. My "To reproduce:" line to them suggested assigning someone to actually use VO on a regular basis and listen for the profane outbursts from down the hall.

Hi everyone. I just successfully registered on the WebKit website as suggested in another thread on here. It looks to be pretty accessible with VO, but a bit daunting for a non-programmer like myself. I'm wondering if any of you are aware of a beginners' guide anywhere? Having said all that, I have now again switched my default web browser to Chrome and am going to keep it that way at least for the time being. For me Safari on the Mac is misbehaving only some of the time, and again it seems to occur at random intervals. But I will definitely start sending sys-diagnose files to Apple and see what happens. I believe Dean Hudson from Accessibility is a VO user.

So... Bearing in mind that I can reproduce this, and just did, literally a dozen times in fifteen minutes, it seems as if, on my machine, pressing *any* VO key that tells VO to reconnect with the accessibility API gets Safari unstuck. That's just a surmise; but, when Safari checks out, pressing VO+command+h or even just VO+right gets things back on track for me. Looking forward to others' experiences. I feel pretty stupid, honestly. I'm going to say that this is a recent behavior, since I know I've pounded away at every possible key combination for like ten years whenever it stops responding, and the issue itself has gotten way, way longer and more ubiquitous for me lately. Maybe the bug is multi-causal and what I'm doing works around one manifestation of it but won't work for other types of instances in the end. Either way, it doesn't let Apple off the hook. In fact, I just gave myself a warm fuzzy at the thought of Apple software engineers suspended on hooks.
Spitballing here, but I wonder if it has to do with VO trying to wolf down too much from the API on page load under some mysterious circumstance, but telling it to grab a particular smaller element unclogs it. Do I know what I'm talking about? No, no I do not.

Agreed. I've had success using any VO command (such as jumping to header with VO+H) to break the deadlock. Safari/VO snaps back to life half a second after the keypress. That being said, I've seen a wide range of severity for this issue over the years, from mild to my system being completely unresponsive while VoiceOver and Safari go smoke a cigarette.

Also, when pressing something like VO+H to jump to a header, note that even if it does break the deadlock, the VO+H command itself is ignored - To jump to a header, you must press VO+H a second time. You might think I'm nitpicking, but it's clearly still a bug, even if this workaround were effective 100% of the time, which I suspect it isn't.

And the most important thing to remember is that Safari works fine for sighted users with a mouse. They load a page and it's immediately responsive. We should experience the same behavior.

Just upgraded to Sonoma. It seems that the Quick Nav behavior and settings have changed. Just before I upgraded, I have been using quick Nav by toggling it on and off with left and right arrow keys. Now That doesn't seem to work. If I perform a VO Find, and try to type text in the search box, the single key navigation activates. Previously I could use VO Find and then go directly to single key navigation for tables and heading using T or H. now that is not functioning as before. Does anyone know how to restore the behavior of the arrow keys for Quick Nav single key?

Unless I read the topic wrong, but the latest comment below mine from @Brian Wooten is not related with this bug.

I believe that there are more than one issue at play here. The instances in which Safari doesn't respond to accessibility requests don't seem to be a VoiceOver issue because I've noticed them while testing Vosh as well, and when using both screen-readers at the same time I've experienced situations in which only one of them was receiving accessibility responses while the other was being informed that the action could not be completed (which both VoiceOver and Vosh interpret as a timeout). However I have also experienced instances in which VoiceOver takes over the keyboard and stops passing keystrokes to applications for some reason, stating that the active application is not responding and preventing any kind of keyboard interaction with the system. In the first case, turning VoiceOver off and back on seems to solve the problem but only temporarily, as after a while the second issue will manifest itself, and the only way to turn VoiceOver off without having to wait when the second issue happens is by using the accessibility shortcut (Command + 3x TouchID).

Also, contrary to many people here, I never actually stopped experiencing this, and at least to me it usually happens when I close a tab.

While typing this I had an idea that might help: browse the web a while on a virtual machine until the issue is triggered,, suspend it, and send it over to Apple. The only problem with this idea is that virtual machines tend to be huge, but if one manages to compress the suspended virtual machine enough to send over Feedback Assistant then Apple will have something that they can actually diagnose, and since it's a virtual machine snapshot they have as many opportunities as they want to debug the problem.