Safari v15 on Mac. Busy, busy, busy

Member of the AppleVis Blog Team
Forum
macOS and Mac Apps

Since upgrading to Safari v15 on Mac, I encounter VoiceOver announcing "busy" much more frequently. My specific version is 15.0 (16612.1.29.41.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?

Options

Comments

Submitted by Justin on Tuesday, September 21, 2021

Yup. Same sthing here. Latest version of Safari. I don't know why it is doing this.

Submitted by neosonic2 on Tuesday, September 21, 2021

This issue seems to have been fixed in the latest release of Safari 15 (build 17612.2.4.1.2). This may apply to the Safari Technology Preview application as well but it has not been tested.

Submitted by PaulMartz on Tuesday, September 21, 2021

Member of the AppleVis Blog Team

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.

Submitted by Bruce Harrell on Tuesday, September 21, 2021

Hi. I upgraded to Safari Version 15.0 (16612.1.29.41.4, 16612) on my Mac earlier today, and I've rebooted since. No problems so far.

Paul, try googling.

Joy!

Bruce

Submitted by neosonic2 on Tuesday, September 21, 2021

In reply to by Bruce Harrell

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.

Submitted by PaulMartz on Tuesday, September 28, 2021

Member of the AppleVis Blog Team

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.

Are we sure that the items you detailed in your post are bugs specific to VoiceOver? As I'm sure you know, the Web is a very complicated environment with different tools, frameworks, programming languages, accessibility standards, etc. Thus, it could very well be that these issues are a result of the programming used in each specific case, i.e. the specific HTMl tags and their attribute values. Are these issues reproducible in other browsers on macOS besides Safari? Are they reproducible using screen reading software and Web browsers on Windows? If you're a programmer, have you looked at the HTML (and possibly JavaScript) code underpinning the areas you outlined to see if it could be rewritten to be more accessible? If at all possible it may be wise to reach out to the developers of the specific Websites with which you were experiencing trouble, and perhaps reach out to Apple at the same time, as right now there's not enough information in your post to categorically state whether the issues you are encountering are a result of a VoiceOver problem or a Web development problem.

Submitted by PaulMartz on Tuesday, September 28, 2021

Member of the AppleVis Blog Team

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.