Introduction
Any regular reader of this blog (both of you) would already know that I enjoy using a bunch of different products from Apple. I use an iPhone 5S running iOS/7, a Macbook Air running OSX/Mavericks with all of its updates, we have an AppleTV set-top box and we use an Apple TimeCapsule router. The first thing one notices when they get any of these devices is that their interfaces are 100% accessible in the iOS case and nearly 100% accessible on OSX right out-of-the-box. For this reason alone, Apple is by far the leader among mainstream companies trying to solve the problems of accessibility to people with vision and other print impairments. Apple continues to make its accessibility better with each release but, while it may be #1, Apple still has a lot of work ahead to be truly competitive with third party screen readers On the Internet.
Any user of a popular Windows screen reader (JAWS and NVDA) or even those with less popularity (Window-Eyes, SystemAccess, ChromeVox and Orca) will, for a variety of reasons, be entirely underwhelmed with the functionality of VoiceOver on a Macintosh with the Safari web browser.
This piece started as a bug report I wrote up for some contacts I have at Apple. For all intents and purposes, I have changed very little between the email I sent to friends there and this article. I’ve removed the names of some individuals who are not public figures, added a bunch of links and did a bit of other clean-up, removing some personal comments and such. This article is specifically about how VoiceOver works with Safari on OSX and may not be applicable in any way to iOS/7 or any other Apple products. Internet support, in my mind, is the single aspect of using a Macintosh with a screen reader that remains substandard which, as Apple is setting the standard in so many other areas, makes me sad.
My Specific Use Cases
It’s possible that each user has his or her own set of cases that are important to them. Like everyone else, I use the Internet for a lot of different things but, most importantly, I write a blog. My blog tends to use other Internet sites as source materials. Therefore, being able to copy and paste from sites is really important to me and,sometimes, when I go to a site and hit VO+ENTER to start selecting text, I hear the “scratching” sound and it actually selects text; sometimes, I just hear a ding and it refuses to select text using this method. On some occasions when the VO web site text selection facility doesn’t work, I can just use SHIFT+navigation keys and the text will be selected; on other occasions, I the only way I can select text on a web site is by doing a “select all,” copy and pasting the entire page into a text editor and finding the piece I’m looking for there. This is, in my mind, one of the worst problems with VO on OSX.
The Overall User Experience
Most other popular screen readers (JAWS and NVDA) and some less popular ones (Window-Eyes, ChromeVox, SystemAccess and Orca) allow the user to navigate around the page using only cursor keys as if in a word processing document. Originally, Orca’s FireFox support, also designed by the person who is now the lead UI developer for VoiceOver, functioned similarly to the VoiceOver design where arrow keys are virtually meaningless except when combined with a modifier key. Orca, not known for its tendency to be terribly competitive with other screen readers nor for its unpleasant user experience, took a step back and changed its UI design to be like JAWS, the screen reader that set the standard for Internet accessibility (if you disagree, I can provide a pile of links to actual testing scorecards that, quite objectively, demonstrate JAWS superiority in all of these areas including the WAI user agent guidelines). Apple, quite obviously, has infinitely more resources than does the Orca project (as far as I can tell, Orca has exactly one developer, Joanie Diggs, working part time on the effort) and can certainly make this happen.
Navigating on a Web Site
As far as I can tell, all other screen readers on general purpose computers (desktops, laptops) allow for single character navigation of a web page. In fact, all but Window-Eyes use the same standard set of keystrokes (h for next heading, t for next table, etc.) and, with all other screen readers, navigating a web page is profoundly more efficient. With NVDA (I don’t use JAWS), I go to a web page and hit “h” and I’m brought to the first heading, I hit “h” again and I’m at the next one and, if I follow that by typing a “t,” I then go to the next table and so on. With VO, I load a web page and, if I want to go to the next heading, I need to hit VO+u first to make sure it’s set for heading navigation and then either find the heading I’m looking for in the list box or, after setting the utility dialogue to headings, use VO+down arrow to find the next one and, then, when I want to find the table, I need to go back into the utility dialogue, change to tables and start over. Hence, finding the object I’m seeking requires far more keystrokes, requires far more cognitive processing, etc. but, worse, it makes switching from any other screen reader to VO much more difficult. I need to use OSX, iOS, Windows and GNU/Linux all nearly every day so anything that improves the similarity of screen readers is important based entirely in the HCI concept called “discoverability.”
On a personal use case note, I cannot tell you how many times I’ve been using VoiceOver, used Command+TAB to switch to another application, returned to Safari and found that I’m hitting the keystroke to go to the next object only to find that I had forgotten to set the granularity back to headings and hear something entirely useless like, “No more tables” which could have been avoided entirely if Apple would just implement the same sort of system as exists in the more popular Windows screen readers. Maybe I’m a bit of a stoner and, therefore, forget which granularity I had VoiceOver set to but I’m willing to bet that lots of other users make this mistake frequently as well. The rotor for granularity changes works reasonably well on iOS but changing granularity on OSX is unnecessarily cumbersome.
Correction: When I wrote the two prior paragraphs this morning, I did so in the absence of any awareness of the QuickNav Commander now available in VoiceOver. For all intents and purposes, if you go into the VoiceOver Utility (VO+F8 if you’re running VO), go to Commanders and select the QuickNav tab, you can turn on “Single character navigation” there and have an experience similar to that available in Windows screen readers. Back when I worked on JAWS, we had something of an unwritten rule, if we add a cool new feature, we made sure it was turned on by default in the next release of the screen reader so that users would find it right away. I don’t tend to read a lot of release notes and, until my friend and accessibility jock, Donal Fitzpatrick (@fitzpatrickd on Twitter) pointed this feature out to me, I didn’t know it was there. So, for all intents and purposes, you can ignore the two paragraphs preceding this one as, given this feature, they are just not true.
Performance and Time
VoiceOVer is ridiculously slow on “noisy” web pages (those with lots of objects). Go to this site about harmonica playing, search on a popular artist (Bob Dylan has a lot of stuff up there) and bring up the Item Chooser (VO+I) and count the seconds it takes to bring up the item chooser list box and, if you’re using the same 2012 model Macbook Air as me, you’ll see that this takes a little more than 7 seconds. Now, using NVDA on a cheap Windows laptop hit NVDA+F7 to bring up its analogue of Item Chooser and you will find that its list box is on the screen and talking in less than a single second. NVDA is also using cross application communication via an API to gather its data but, using caching and other performance enhancing techniques, it actually responds in a functional amount of time; in 2014, waiting 7 seconds for a computer to do anything other than downloading something big from an online source is simply absurd.
When, in September 1999, we at FS released JAWS 3.31, we used Jamal Mazrui’s EmpowermentZone web site as our favorite reference page. Jamal has something like 1700 links on the home page and, according to VO, it has 3789 objects in all. Back then, we were running on 60 mhz Pentium processors with megabytes of RAM and, then, JAWS 3.31 could load its object list dialogue on this page in about 20 seconds (compared with about 25 minutes using Window-Eyes). Just now, when I went into Safari to test this page, it took about 30 seconds for VO to load its item chooser on hardware more than a decade newer, using a quad-core system whose speed is measured in ghz, having thousands of times more RAM and so on. We solved this problem on Windows 98, effectively a 16 bit system; certainly, Apple can solve this problem now that much faster hardware is available.
The Broken Item Chooser
If a user hits VO+i to bring up the item chooser before a page has finished loading it will bring up the list box but, when one hits ENTER on an item, it will just ding and not bring the user to the point he had requested. VO seems to load all of its data much more slowly than any other screen reader (if I bring up the NVDA analogue of this dialogue by hitting the keystroke immediately after requesting a page, it appears immediately and is never out of sync with the rest of NVDA. I’m going to guess that this is a threading issue which are hard to fix but this bug has been present for years now, has been reported by me but I’m also certain that others also reported this problem to Apple.
For no reason apparent to anyone outside of Apple, it seems that the Item Chooser information isn’t cached anywhere. Hence, when one hits VO+i on the same page twice, VO takes as much time to build the list the second time as the first. If the page hasn’t changed, the Item Chooser information should all be present either in memory or cached on a disk and should, even given the other VO constraints, load virtually instantly the second time through.
What About “Clickable” Items?
When VO describes an item as a link, using VO+SPACEBAR will always open it. When, however, VO reports an item as being “clickable,” more often than not, VO+SPACEBAR does absolutely nothing and hitting VO+SHIFT+SPACEBAR to send a mouse click to the object works infrequently. I have my VO configurations set to have the mouse cursor follow focus and also try hitting VO+SHIFT+F5 to route the mouse cursor to the object I’m on but that seems to rarely work as well. [Note: while here in TextEdit, routing the mouse cursor works properly but, while using Apple Mail,, with my mouse cursor set to follow VO, I hit VO+SHIFT+F5 and wasn’t brought to the word i had just typed nor was I even brought to the edit area where I’m typing this but, rather, I clicked something on the Dock, a seriously bad outcome.]
Compared to JAWS
People who have read articles on this blog like “I Give Up” or “An Open Letter to Mark Riccobono” will know that I’m not just a user of Apple products but, based entirely on accessibility, I’m something of an advocate often recommending their hardware to other blind users. Now that Apple seems to have made iWork, their office suite, mostly accessible, the Internet is the only aspect of VoiceOver that I still don’t like much. Readers of this blog would have heard me say, “Apple has set the gold standard for out-of-the-box accessibility” which is true, for almost everything, except for the Internet. Online, JAWS remains the king with NVDA a close second. This is the one area where Apple really needs to do some massive improvements.
If I actually picked up the user agent guidelines and tested each item separately, I would find a ton more bugs. I would find a really big list of defects that one would not encounter if they used JAWS or NVDA. It’s pretty much the Internet access that causes me to use Windows to do most of my research and a lot of my writing these days. On all scorecards regarding screen reader functionality published online (I’m working on an article about these reports coming soon to this blog), JAWS remains the gold standard for using a speech interface to read the web. Apple may have set the bar for nearly everything else but, if Apple wants to be the best, they have a lot of work ahead of them.
The Object Model
VoiceOver arranges its web information by object but doesn’t also include a simpler navigation metaphor. Hence, as I wrote above, it uses a different system for moving from object to object so a separate keystroke is needed for each separate object. If a web site contains the sentence (including the links):
“Let’s compare the number of keystrokes necessary to read this sentence with JAWS, NVDA, SystemAccess, VoiceOver and a few other bits of access technology.”
an NVDA or JAWS user might read the entire sentence by issuing a single keystroke (a down arrow perhaps) but, with VoiceOver reading each object separately, one needs to issue a keystroke for each link plus each chunk of text separating such for a total of eight keystrokes to read a single sentence. Also, while doing a “read all” of an entire web page, the user will hear pauses caused by VoiceOver trying to add a tone for each link making the entire reading experience sound really choppy. This is massively inefficient for the users and should be corrected immediately.
The Interaction Model
When a user accesses a web site with JAWS or NVDA, the information is pretty much organized like a word processing document with all of the same keystrokes for navigating through such. With VoiceOver, Apple introduced a model that attempts to group chunks of a web site into larger blocks that a user can navigate between and, when they are in a place they want more detail, the users can “interact” with that portion of the web page. In theory, this system should allow for greater efficiency as it permits the user to easily jump past information in these groups.
Very unfortunately, though, the interaction model only seems to improve efficiency on tremendously well organized web sites and, more often than not, actually requires the user issue more keystrokes than in the “virtual buffer” model presented by most other screen readers out there. For a quick example of this, if you’re using a Macintosh running VoiceOVer to read this page, find the place where one can follow me on Twitter and you’ll notice that you need to interact (and, therefore, stop interacting when you’re done) with an item that contains very little actual information. With JAWS or NVDA, however, simply moving from line to line with arrow keys gets you everything you want.
In my experience, the interaction model causes far more efficiency problems than it solves.
Conclusions
This isn’t my most well organized piece and it gets repetitive in places. I wanted to show, however, how even Apple, the world’s leader in out-of-the-box accessibility, sill needs to continue improving. I’m certain that this item will gather me a bunch of comments (either public or privately through the contact form on this site) about other problems blind users encounter with VoiceOver on Macintosh. If you have other bugs to report, sending them to me may make for a future version of this article to be more comprehensive but, at the same time, I urge you to report any problems you encounter to Apples Accessibility email address so they may both know about the bugs but, also, they may understand just how many people are effected badly by defects and design flaws in their accessibility software.
Excelent post! I noticed many of the things you outline, back when I spent about a week playing with VoiceOver on a friend’s Mac. I assumed at the time that I was simply not aware of enough VoiceOver features and that my fifteen years as a Windows user was clouding my judgement. Your post sets me straight and tells me I was not imagining things. I hope it gets some traction with Apple Accessibility, and gives people a reason to pause and think about this before joining the cult of Mac. :)
Chris, how do you get on with Safari on iOS? I do most of my browsing on an iPhone these days, and at least on reasonably well organised websites with a decent heading structure, I generally find it quicker and more intuitive than browsing on my Mac or PC. I rarely bother with a computer these days except at work.
Hi Chris,
I am running the beta of Mac OS 10.10 and I am proud to say that the item chooser is much more useable now. Instead of getting a busy message immediately after issuing the command, voiceover says loading items and follows the message within half a second with the number of items currently loaded. At this point you can investigate the items in the list and voiceover continues to load items in the background as you arrow through the list of what is already present. My favorite way of using this feature is to hit VO I, then start typing the letters of the item that I want. If it does not appear immediately, the item will show up after a few seconds and in some cases, after an updated announcement of the number of items loaded by voiceover. In short, it is elegant and straight forward. I can only hope that the accessibility bugs elsewhere in Safari get ironed out before the final release. If anybody has a Mac that is not used for mission critical applications I would highly recommend downloading the beta and participating in the open test phase.
Having two modes like most windows screen readers is somewhat of a mess to implement. You need to keep them in sync and often, especially with Jaws, changes to the page will not get integrated into the virtual view until the user causes the virtual buffer to be rebuilt such as after a focus change occurs. Apple dispenses with virtual mode altogether and allows you to interact directly with the browser (mediated via the screen reader of course). Theoretically, this should give a better user experience, but I agree with most of the comments made in this article – it just feels clunky and unresponsive. I tried to switch to OSX a couple years ago. Had a nice iMac on my desk and plenty of time to use it, but gave up because surfing was just so much more efficient via Jaws on Windows. I even went the vmWare route and attempted to put windows on my mac, but got tired of trying to deal with key remappings etc.
Now, I will again have an iMac on my desk, and will be required to use it. I’ve been an IOS user for the past year and find it fairly decent and fun, but navigating anything but the simplest of pages via IOS is just painful! I hope that OSX 10 and two more years of VoiceOver development have changed things for the better. I commend Apple’s commitment to accessibility, and wish other mainstream vendors would take it as seriously as does Apple.
yosemite beta spoiler
s
p
o
i
l
]e
r
s
p
a
c
e
You can now also use the arrow keys to navigate web pages (that is, with quicknav off). Navigating this way isn’t as quick as if using the VO cursor, but it does make finding and selecting text on pages much easier as you can select much more precisely.
I am looking forward to your next post… your comments saying that JAWS works better on the web than NVDA definitely peeked my curiosity.
Thank you for another thought-provoking article, Chris. I have a question about the comparison of VO’s Item Chooser to NVDA’s Elements List: I wonder if VO’s Web Rotor (VO+U) might be a closer analog to NVDA’s Elements List.
While the Item Chooser displays a list of all items on the page, NVDA’s Elements list only shows headings, links & landmarks, as far as I can tell, thus making it comparable to a limited version of VO’s Web Rotor. If desired, the Web Rotor can be configured to show lists of 16 other element types in addition to the 3 shown by NVDA.
Using the Empowerment Zone website for reference, the Item Chooser on my 2013 Macbook Air running OS 10.9 takes over 20 seconds to display the list of 3800 items on that page, but if I configure the Web Rotor to display only headings, links & landmarks, I receive an instantaneous response showing lists of 39 headings, 1724 links and no landmarks. BTW, if I configure my Web Rotor to show all 19 available element types, I tend to find that it is the list of “Static Text” items that most often loads slowly.
Hi Chris,
I’ve been using a Mac since 2010. I to find that the web browsing experience could be improved. I really hate the way that voiceover in OS X reads when you’re reading a webpage like Wikipedia. I also wish that voiceover would tell you when the reader is available like an iOS. I feel the same about the way webpages read and iOS. I wish that’s how they read with voiceover in OS X. I’m also surprised that you didn’t mention shortcut such as control option command plus the letter you wish to use for your Web navigation such as age for heading, t for table, and so on. I’m not sure if always having to use control option command if I choose not to use quick nap bothers me or not. I definitely agree with what you said about text selection with OS X. That definitely needs to be improved. And if you want another webpage that makes voiceover go crazy in Safari, try this. http://speedof.me
It is an HTML5 speed test that by the way, happens to work just fine with iOS voiceover. I can’t comment on using item chooser or the web item rotor much because I’ve very rarely use those features a voiceover. And you made a comment about object navigation making it more difficult to navigate by sentences on a webpage. I would agree. By the same token, I wouldn’t mind Apple implementing that same object navigation in mail so that it would be easier to click links. I find what I have to do is hit control option command L until I find a link I wish to click on, and then press VO space to activate that link. I haven’t had too much of a problem clicking on clickable elements in a webpage. I to make voiceovers cursor follow the mouse cursor, and can normally just press VO space to click on a clickable element. I do sometimes have to add shift into the mix, but that works pretty reliably for me as well. Maybe I’m just not visiting the right webpages? LOL and one more thing I have noticed before I end this comment is the fact that live regions don’t seem to read as reliably as they do for orca and Firefox under Lenix. I would assume the same is true for in VDA and JAWS under windows as well, but I haven’t tested them. I found out a couple days ago that I would much rather use OS 10 voiceover to navigate the web, then narrator under Windows 8. Although, that could just be my lack of navigational skills under narrator. Anyway, I guess I have said my two cents. And yes, I know I lied about the live region comment being my last one in this comment. But this actually is, I promise. If this doesn’t make sense I apologize, because I’m creating this comment on my iPhone using dictate for most of this.
Hello Chris. Reading this has me a bit curious. I just got my first Mac computer last year for Christmas from my parents. Well actually, it was 2 days after Christmas and I was at the Apple store with my parents and a sister who was also looking to switch to VoiceOver from JAWS. But anyway, this is a mid-2013 Mac Book Air currently running Mavericks build 10.9.5 and the latest build of Safari. I must say I have not experienced all the problems you describe, but then again I have only stuck with a few things thus far on my Mac. I love the fact that one can just go up to a Macintosh computer and turn on accessibility right away. I think that’s a huge market win right there. I mostly use QuickNav in Safari and Google Chrome, and have had little to no difficulty. I mention Chrome because not long after I obtained this computer, a sighted friend and tutor of mine told me that he swears by Chrome, and I became rather curious. In addition, I had been following discussions on AppleVis regarding web browsing. Everything I’d read on there seemed to paint a very good picture of Chrome with VoiceOver, so that’s currently what I’m using as my default browser. I have to agree that it is a very nice experience. I had Chromevox for a short time, but I found it caused my machine to lag and also speech crashes began happening, so I removed Chromevox. But I have not used the Web Rotor or the Item Chooser much. I probably will as I grow more experienced, but for now I am just sticking with QuickNav. Regarding Apple’s default email program, I like it. I have, however, been experiencing an odd problem where sometimes messages refuse to delete. But I’ve been told that’s most likely a server issue. As for upgrading to Yosemite when it’s released to the masses, I don’t know. Perhaps I will down the road, and perhaps I will also install Windows on here one of these years. But for now I’m comfortable with what I’ve got, and there’s still a bit of learning ahead. Speech still cuts out and stutters here and there, and I’m wondering if perhaps humidity might be the cause of that. In closing, I want to say that my parents and I had a very positive experience with all store employees who assisted us.