Safari v15 on Mac. Busy, busy, busy
Since upgrading to Safari v15 on Mac, I encounter VoiceOver announcing "busy" much more frequently. My specific version is 15.0 (16622.214.171.124.4, 16612).
This doesn't seem to be a network issue. I have enough remaining low vision to see that a page has loaded and its content is displayed visually. Still, if I try to navigate the page with VoiceOver, I hear "busy" for every key press. If I try to refresh the page with Command+R I hear "busy". If I try to close the page with Command+W I hear "busy". If I try to turn VoiceOver off with Command+F5, I hear "busy".
If I Alt+tab away to another app, I can turn VoiceOver off, then return to Safari and try using the web page as a sighted person. This is much less feasible than it once was due to my nearly non-existent eyesight. However, it's an indication that the issue is specific to VoiceOver and not something broke within Safari per se.
Anyone else seeing this?
Yup. Same sthing here. Latest version of Safari. I don't know why it is doing this.
This issue seems to have been fixed in the latest release of Safari 15 (build 176126.96.36.199.2). This may apply to the Safari Technology Preview application as well but it has not been tested.
How do we update to this new version? The version 15 I mentioned in the O. P. came via Software Update, but no other updates are currently available.
Hi. I upgraded to Safari Version 15.0 (166188.8.131.52.4, 16612) on my Mac earlier today, and I've rebooted since. No problems so far.
Paul, try googling.
Or, rather than Googling, he could click on the clearly-marked link in the comment I posted regarding Safari's public release, which contains release notes and update instructions for the release of Safari 15. Here is that link again, just so there's no confusion and nobody has to Google anything: https://9to5mac.com/2021/09/21/safari-15-with-new-tab-design-now-availa…
Your post says the issue is fixed in build 17612. Is that a typo? There is no build 17612 as far as I can tell.
As I said in the original post, I'm on build 16612. This is where I first noticed the issue. It's still present, and software update doesn't offer me a newer version
For those of you not encountering the issue, note that it is sporadic. I don't get it on every web page, but I have encountered it often enough that it is significant.
I am a user of the macOS Monterey developer beta, so the version of Safari I am running may be a slightly newer build than what Apple has released to the public. Regardless, the public release of Safari that was made available this week may also contain whatever changes were required to fix the issue you and I have experienced, and that I have noticed as being resolved in the build I am running.
Ah. That makes sense.
On the subject of other things broken in Safari, I thought I would mention ongoing problems with being unable to follow some links.
In one common case, a link is embedded in paragraph text and has a word wrapping break right in the middle of the link, so that the first part of the link is at the right end of one line of text, and the rest of the link is at the left end of the following line of text. With VoiceOver open on that link, there's no way to open the link in another tab. You should be able to open the shortcut menu VO+Shift+M and select "open link in new tab". But in this case, that option isn't present. You can only follow the link normally.
The next scenario is more complicated, and I can only describe it by example. Go to the New York Times website nytimes.com. You will need to page down about eight screenfuls, but this is approximate based on your window size and the amount of content the NYT displays on any given day. But, once you do this and all the content has loaded, you should be able to find the problem using the Item Chooser VO+I and looking for the words Letter Box.
This takes VO focus to a sort of group control containing links to several interactive games. The problem is that there's no way to interact with this control, and as a result, no way to selectively follow one specific link. As a workaround, I can bring the mouse pointer to the control with VO+Command+F5, then invoke a mouse click with VO+Shift+Space. For me, this follows the crossword link, which is what I want, but I have the feeling your results will vary based on Safari window size. I think I'm just getting lucky that the mouse happens to land over the link that I want, and if it were a few pixels to the right or left, the mouse click would follow a different game link.
I hope Apple is reading this, because they need to know these problems don't occur in either Firefox or Chrome. They are driving blind users away from the flagship Apple web browser.
The first bug, in which the shortcut menu fails to provide an option to open in a new tab for links that split over line breaks, is not a problem when VoiceOver is disabled. Sighted users simply mouse to the link, right click, and open the link in a new tab. This is a long-standing VoiceOver issue that has existed prior to v14.
The second issue, in which the individual New York Times puzzle links are not accessible using Safari with VoiceOver, is not a problem when using Firefox or Google Chrome with VoiceOver. And, obviously, it's not a problem with VoiceOver disabled, as sighted users simply click on the game link. This is a fairly recent issue, since Safari v14. The New York Times HTML is related, as the problem has gone and returned at least once without a change to Safari. I suspect the New York Times is using HTML code that Safari doesn't fully support. I emailed information about this bug to Apple's accessibility team, and was told I should log it as a bug with the Github Webkit project. That was pretty much the last time I bothered to send a bug report to Apple's accessibility team.
The Apple accessibility team frankly gave you great advice; did you end up logging the bug like they asked? They have no control over WebKit, the browser rendering engine used in Safari, as that is an open source project. Thus, the best way to get accessibility bugs resolved in Safari, especially as they pertain to the rendering of Web pages, would be to file it in the issue tracker of the WebKit open source project, just as they suggested. The last sentence of your comment though leads me to believe you were expecting more from the Apple accessibility team in regards to software that is open source and community driven and software over which they have no direct control, but hopefully you still filed a bug with WebKit nonetheless so they can look into the two issues you reported here.