a problem with loading webpages in Safari
Submitted by Qball42 on Tuesday, September 17, 2013.
macOS and Mac Apps
Hello, I have been having a recurring problem with new webpages loading in Safari. Most of the time, when Safari is loading a new page, it will appear without me having to "interact with HTML content". However, on occasion (and more so lately) I receive either no feedback at all from VoiceOver when a new webpage is loading, or I just get an "HTML content" message. I would much prefer a new webpage just loading over having to guess or be stalled by periods of uncertainty. In VoiceOver utility, under the web category, and page loading tab, I have "move the VoiceOver to it when loading a new webpage" checkbox checked. This, I assume, should do the trick, but it is not always reliable. does anyone else experience this issue and, if so, is it a frustration at all? Are there any solutions I am overlooking? Any feedback you could give me would be appreciated.
Assuming you're running OS X version 10.8.4… This is an excess ability bug that occurs between voiceover and Safari. I recently spent a few weeks going back-and-forth with Apple accessibility about this issue… And they have finally admitted that this is indeed a bug in the latest version of mountain lion. I did a podcast about this issue about a month ago… And I will provide a direct link to it below. To avoid any confusion… I used to go under the moniker blue orb hence why I refer to myself as such in the podcast. This podcast will demonstrate the bug… As well as a couple of workarounds to help you deal with it while it is being fixed… Although Apple accessibility has assured me that this bug will no longer be present in OS X Mavericks. Here is the podcast. http://www.applevis.com/podcast/episodes/buzzing-around-bugs-safari-mac-voiceover Be well, Greg
Hello, Thank you for your help. I also looked at your comments in another thread, which I apologize for overlooking. The solutions you have discussed have all worked for me. I have one remaining question, though. Do the page loading settings in VoiceOver utility matter? Is there a way to configure them such that the probability of the bug appearing is reduced even more? I feel like I may be overlooking the obvious, but the checkboxes under that particular tab, to me, seem quite ambiguous. Regards, Qball
Good question… I just took a look at my voice over utility settings and it appears that the setting that allows the voiceover cursor to automatically move to the webpage as it's loaded is checked… But I still have experienced the bug multiple times in the past couple of days so it appears to have no effect. . I just turned on the setting that causes voiceover to automatically start reading the webpage to see if it has any effect on the bug. I will let you know what I find. Be well, Greg
Hello again… I know it has been a very short while since I have posted… But even with voiceover set to automatically start reading the webpage when it loads the bug still occurs. Keep in mind that I also still have the setting enabled that is apparently supposed to allow voice over to move directly to the HTML content and this has no effect… It appears that the page loading settings in the VoiceOver utility have no effect on whether this bug occurs or not.
Yes, that has been my experience as well. Thank you for trying that. I was hoping one of the settings in VoiceOver utility would help, but I suppose the best solution to hope for is the changes in Mavericks.
There is actually one more option for trying to override this bug... that is if you don't mind downloading some software... I have found that the original work arounds have provided enough of a solution for me at this point so I Haven't tried this but check out the thread I link to below. More specifically check out Robbert's comment... He offers another possible temporary fix... http://www.applevis.com/forum/os-x-mac-app-discussion/two-frustrating-safari-vo-bugs-anyone-else
Hello, I have just downloaded and installed the nightly build of webkit and the navigation works like a charm now, like it should be. My navigation is now as good as it can be so I strongly recommend this method over keep reseting safari.
For the record, I am using the current nightly bild of Webkit (r160618) on a 2013 MBA running 10.9 w/all updates and am experiencing the same issue detailed by the OP.
Hello, So do I and it's working right now. I am using 10.8 but I will keep on eye on it to see if it will stop working and, if so, try to guess the reazons. In the mean time are you openning it from doc or from the applications folder? If you could try openning it from both places and report if there are differences it'd be great. Let's keep in touch and try to figure a reliable way of using it. If you want my contacts let me know.
Hello, I have been looking closely a]at this stuff. I have set up my webkit to be available from the doc and I can confirm that every time I do open it from the doc I have the issue but when I open it from the applications folder my navigation just works as it should, without this issue. I ask everyone to try to open webkit or even safari from the applications folder and do check if the issue goes away… and if so we should post a tutorial to let everyone else know that this is the way to proceed.
Hi Splyt -- The issue exists for me whether webkit or safari are launched from the dock or the finder. I added today's nightly to the dock, launched it from there, and experience the same issue as detailed by the OP. For reference, I normally do all of my work, including app launching, through the finder and never touch the dock.
Hi guys! I'm still seeing this ever so often in Mavericks. I, as many others, have been back and forth with the accessibility team to try to get them to admit that this is a bug, and they finally confirmed this a while back. I haven't gotten to try the web-kit thing out yet, but there's one solution that kind of works for me... It's a workaround, alright, but it makes things just a little bit easier when this bug appears. What I do, is to put a hotspot, or what ever it's called in the english translation, on the html content in Safari. The easiest way, is just to stop interacting when you are in the web-content, cause then of course the VO focus is placed on the html-content. Then, hit VO+Shift+1 or what ever number you want to put the hotspot on. So when then at a later point when this bug again jumps up to bite you, you'll just have to hit e.g. VO+1 or the number you put the html-content hotspot on, and the beauty of it, is that it will automatically interact with the hotspot when you do that, and you'll be thrown directly into the web-content. Not a perfect solution, but it saves me a lot of time when this happens, to not have to arrow around in search for the html-content, and then have to interact. What I also have noticed, is that this only happens when the VO sound-effect to indicate that the page is done loading, never comes... Each time I open a neew link and the little ding comes, to tell me that the page is fully loaded, there's never a problem, and I wont have to interact. So this seems to me to be a issue with some pages sometimes stops loading at lets say 80 persent. That's when you'll have to manually interact. Or maybe the page has completed loading, but VO doesn't catch it... Who knows, cause I've not found some kind of progression bar in safari yet that will tell me how much of the page has currently been loaded. Perhaps it's there somwhere, but I can't find it... An extra tip, is to set up Safari as an individual activity in VO utility, and check the box to include hotspots in the activity. Then you'll have 10 hotspots to use for Safari alone, and there's many neat ways of using them there. I, for instanse, have set up the html-content on 1, iCloud tabs on 2, the back-button on 0, since the Cmd+left arrow shortcut to go back is broken in Safari for Mavericks, and I can't use Cmd+brackets to do it, cause I'm on a norwegian keyboard layout. So the brackets can't be accessed without using the option-key as a modulator, so that workaround sadly doesn't work for me... But that's for another post! :) Just thought I'd throw in my own findings in this discussion... :) Take care, everyone! Cliff
Hello, This is indeed the problem * for some reazon voiceover does not catch the page loaded event. This is why everytime you get the sound you are ok with the navegation,, because voiceover is notified that the new page is loaded, gets this event and lets you navegate in new page. In facct, at this time webkit works so good for me * cinse I open it from the application folder * that it will notify me of the load progression and play the sound whenever the page is 100% loaded. The main issue with safari not being able to recognize when the page is loaded is that it will put you in an inconsistent state letting you navegate half in the new page and half in the old one, which seens to be fixed whenever you uninteract and interact again with the page. I ask you to please download webkit and try it, openning from the doc and from the applications folder and say if it works for you. I am in os x 10.8 and I am curious to see if someone else gets this issue even in webkit, even openning it from the applications folder in 10.9 * we already know of one guy here who is having the issue. Marlon
I've noticed this too. I actually have a one-on-one session in a couple days with a trainer at the Apple store where my parents and I obtained my Mac Book Air. I have written down some questions to ask this trainer, and I can certainly ask him if he's ever seen this bug before. Whatever is causing this doesn't seem to be affecting anything else in Safari, at least from my standpoint. All other Vo commands seem to work as they should. Please note that I have only had my Mac for a little over a week, and it isn't fully registered yet. I must admit, I kind of rebelled when my parents told me that they had signed me up for on-site one-on-one training. Not because I have doubts as to the quality of said training, but because I have all these online resources available to me. There's another reason too, but it's unrelated to the discussion at hand so I won't go into it. But now that I've given this some thought, I'm glad my folks did what they did. I might learn something that isn't mentioned anywhere online, and I think it'll be good to discuss things with this trainer. But I'll also give a listen to the podcast mentioned here, as well as the other podcasts I've not yet checked out.
I must say, I am a little surprised that this is still a topic of discussion. Since my original post, I upgraded to Mavericks and the appearance of this bug, for me, has been extremely rare. Even when it does occur, I have ignored it and, for the rest of my browsing session, it never reappears. I just thought I should comment because I applaud Apple and their accessibility team for such an improvement in my personal experience. That said, I do hope that this problem can be eliminated entirely in the future, especially for those who are having more struggles with it than I am currently having or may have later on.
The podcast linked to here seems to be unavailable for some reason. But in any case, I did meet with that trainer and our session went great. He didn't seem to know about that Vo bug in Safari, but he did help me with some other issues. I might try out Webkit at some point, but a tutor of mine swears by Google Chrome. I've doon some research on this very site, and have found that Chrome does indeed work with Voiceover so I am going to try that browser out as well at some point. But in the meantime, I've found that pressing Vo + lowercase A is another workaround for the Safari issue. At least this has worked for me thus far, and I haven't had my Mac for very long.