OK folks, this is hopefully it, the ultimate way to map the CapsLock key of your MacBook to be used as a NVDA or JAWS modifier key in a virtual machine running Windows.

The problem

The MacBook’s keyboard has no insert key. The insert key, however, is the main modifier key used by screen readers on Windows. This stems from the era where computers all still had big keyboards with number pads, and even laptops were still big enough that most of them had these.

In newer, tinier models, these have gone for good. Yes, there are possibilities to use external Bluetooth number pads, but hey, this is not really mobile, is it? 😉 These keyboards do, however, still have CapsLock keys. So why not use them? If you then switch your Windows screen reader to laptop layout, you get full functionality within a Windows VM.

I realize there are other solutions out there to re-map another key to the insert key within Windows by using tools such as SharpKeys. But I found these always conflicted with other keys, caused whacky behavior if VoiceOver was running on the Mac side still, etc. etc. So I was always on the look-out for a better solution.

Credit where credit is due

And heureka! I found it in a German FAQ article on TuKSuB. Thank you, Kamil, for putting this together! This article is based on, but not an exact translation of, Kamil’s entry. So here we go!

The prerequisites

For this to work, we need two freely available Mac tools: Karabiner (formerly KeyRemap4MacBook), and Seil (formerly PCKeyboardHack). Karabiner will map the CapsLock key to a VoiceOver key for us, and Seil will help us to use CapsLock as an Insert key in a Windows VM. Go ahead and download and install both tools now. They come with standard installation packages. We’ll use each tool in the following steps. Just make sure you install the right version for your operating system. Seil, for example, comes in different versions for OS X 10.11 El Capitan and 10.10 Yosemite plus 10.9 Mavericks.

Step 1: Remap CapsLock to a VoiceOver key

  1. Go to your Applications folder (Cmd+Shift+A), and launch Karabiner. On first launch, you will most likely be prompted that KarabinerAxHelper wants to use Accessibility features.
  2. Click the Open Preferences button, which will open to the Security/Privacy tab. Unlock the settings with your admin password, and enable the checkbox for KarabinerAxHelper in the Accessibility permissions table. Now, close System Preferences with Cmd+W.
  3. Press VoiceOver+M twice to reach the notifications area at the top right of your Mac screen. Karabiner inserted itself here. Use VoiceOver+Right and Left Arrows to find Karabiner and press VoiceOver+SpaceBar to activate. DownArrow to Preferences and activate again with VoiceOver+SpaceBar or Enter.
  4. The Preferences window opens to the Change Key tab. VoiceOver+RightArrow until you find the Remap Keys table.
  5. DownArrow in this table until you reach the row that reads „For blind users“. Press RightArrow to open that node.
  6. DownArrow once, and activate the checkbox for the now visible option „Use CapsLock as VoiceOver key“. The rest of that checkbox label gives a hint to what’s to be done for virtual machines, too, and we’ll get to that in a minute.
  7. Press Cmd+W to close this window.

Step 2: Change CapsLock key behavior in System Preferences

Now, we need to tell Mac OS X to leave the CapsLock key alone.

  1. Open the menu bar with VoiceOver+M, and DownArrow on the Apple menu to System Preferences.
  2. Tab to Keyboard and press VoiceOver+SpaceBar to open that settings panel.
  3. Make sure the Keyboard tab is selected, and at the bottom of the screen, find the Modifiers button and press it with VoiceOver+SpaceBar.
  4. In the Modifiers dialog, VoiceOver+RightArrow to the CapsLock popup menu, press VoiceOver+SpaceBar and select the option No Action. Press Enter to make the choice.
  5. VoiceOver+RightArrow onto the OK button and press it.
  6. Close the System Preferences with Cmd+W.

Step 3: Using CapsLock as the Insert key on Windows

Now, the last step is to use the Seil tool to map CapsLock to the Insert key when a virtual machine is running. Karabiner already hinted for us to do this when we checked the option to use CapsLock as a VoiceOver key above.

  1. From your Applications folder, launch the Seil application.
  2. Make sure the Setting tab is selected. Find the first table. In my case, it has 6 entries.
  3. DownArrow to find the Change the CapsLock Key option, and expand it by pressing RightArrow.
  4. DownArrow once more to a similar entry called Change the CapsLock key. Interact with the row and find the checkbox. Press VoiceOver+Space to check it.
  5. VoiceOver+RightArrow onto the column called KeyCode, and press VoiceOver+SpaceBar to edit this value.
  6. Change it to 110 from the default of 51, and press Enter to accept.
  7. Close the window with Cmd+W.

Step 4 only for El Capitan: Disable CAPS Lock as VoiceOver modifier in VoiceOver Utility

  1. Launch VoiceOver Utility by pressing Control+Option+F8 while VoiceOver is running.
  2. In the General category, change the popup for the VoiceOver modifier from “Ctrl+Option or CAPS Lock” to “Only Ctrl+Option”. This is new in 10.11 El Capitan, and VoiceOver sets the modifier to be both by default.
  3. Quit VoiceOver Utility.

If you don’t change this, the CAPS Lock key will cause erratic behavior when used inside virtual machines.

Step 5: Launch your virtual machine and test

In order to verify that this all worked, launch VMware Fusion or your virtualization software of choice, and launch your Windows VM. Verify that NVDA, JAWS or your other preferred screen reader can now use the CapsLock key. JAWS should immediately find it, and in my case, NVDA did, too. Note that you should not tell your screen reader to use CapsLock as a modifier key, but leave it on Insert instead. But you can use the laptop keyboard layout for better access to many commands.


Regular readers of my blog may remember my January 2014 shout out to Microsoft for implementing great accessibility in their Office Online offering. Later in the year, I also gave an overview over the accessibility in Google apps. Now, in late April 2015, it is time for an update, since both have made progress. We will also take a look at what has changed in Apple’s iCloud on the web suite, and I’ll introduce an open-source alternative that is ramping up to becoming more accessible.

Google apps

The Google apps suite for both free Gmail and paid Google Apps for Business accounts has grown enormously in functionality. And so have the accessibility features. No matter which are you look at, be it Docs with its wide variety of document navigation and collaboration features, Sheets with its ever more comprehensive spreadsheet editing and navigation abilities, or Slides, which allows a blind person to create full-featured slide shows. Gmail itself and Drive are also running very smoothly nowadays. Creating a Google Form to conduct surveys is also going very strongly.

One of the most remarkable facts about this is the enhancements to documentation the Google apps have received. Docs now has dedicated help pages for navigation, formatting, collaboration, and a huge list of keyboard shortcuts for all supported platforms. Take alone the Collaborating on a document with a screen reader, and just try a few things described in there with a friend, co-worker or family member. Each time I use these features, I am totally blown away by the experience.

Docs also introduced braille support and has by now expanded this to Firefox and screen readers as well. If you use it, you’ll get braille output (of course), but may lose some announcements that are available when braille support is not enabled. I have found that a combination of both modes works well for me: Non-braille mode for editing and collaboration, and braille mode for the final proof-reading.

The iOS apps have also made huge leaps forward. If you use an external keyboard with your iPhone or iPad, you have a similarly rich set of key strokes available to you that you have on the web. Compared to where these apps were a year ago, … Uh … forget it, there is no comparison. It’s like day and night!

On Android, the situation looks good as well, within, of course, the limitations that TalkBack still imposes on the users in general. Future versions may vastly improve this situation, let’s keep our fingers crossed! Until then, I suggest you look at the help documentation for Docs with Android.


Microsoft has also enhanced its accessibility features. Word Online, Excel Online, and PowerPoint Online work even better than when I wrote my first article. I found that the collaboration features don’t work as smoothly for me as they do with Google Docs, but because of OneDrive and Dropbox integrations, many tasks can be accomplished using the Office for Windows suite with all its features if the browser version falls short. The start page for accessibility in Office Online gives good pointers to articles with further information.

I also found that the Outlook.com web mailer behaves more like a web page than a real application in many instances. But of course, it has tight integration with Microsoft Outlook and Windows Mail in Windows, so again, if the web version falls short for you if you use these services, you can use the desktop versions.

The iOS versions also have seen great improveents for VoiceOver. The new kid on the block, Outlook for iOS, is getting frequent updates which usually also contain VoiceOver fixes.

And some good news for all the Mac enthusiasts out there: The Microsoft Office 2016 for Mac preview received an update on April 14, 2015 which, according to this support article, also contains VoiceOver improvements for Word, Excel, and PowerPoint. Outlook is also said to be accessible via a different support article on this.

I can’t say much about the Android versions of the Microsoft Office applications, and the official documentation channels haven’t revealed anything. If you have any experience, please let me know in the comments! Especially the MS Word for Android Tablet, and friends, are the interesting ones I think, since they are more feature-rich than the Office for Android phone app.


As much as Apple is great when it comes to accessibility in their hardware devices, including the latest new device category Apple Watch, as dismal is the situation with their iCloud.com offering. This thing just doesn’t have the fit and finish that the other products have. Yes, many buttons are now labeled, and yes, in Pages on the web, lines are read when you navigate them, as well as some other information. But the overall experience is not good. The keyboard focus gets lost every so often, and unpredictably, the interface is confusing and keeps stuff around that might, in a certain situation, not even be activable. This is nothing I can recommend to any screen reader user to use productively, even after some upgrades it received over the past year.

If you want, or have to, use iWork for iCloud, use the Mac or iOS versions. They work quite OK and get the job done.


And here’s the new kid on the block that I promised you! It’s called Open-Xchange App Suite, and is actually not quite as new in the field of collaborative tools. But its accessibility efforts are fairly new, and they look promising. Open-Xchange is mostly found in web mail providers such as the Germany-based Mailbox.org or 1&1, but also used internationally. Furthermore, anyone who runs certain types of Linux distributions as a server can run their own instance, with mail and cloud storage services. It also offers standards like IMAP and SMTP, CalDav for calendar sync, CardDav for contact sync, and WebDav for access to the files. It works in the MS Office formats, so is compatible with most, if not all, other office suites.

Its accessibility features on the web are on their way to becoming really good. They’ve still got some ways to go, primarily also in the way the keyboard focus handling works and how to get some tasks done really efficiently, but Mail, some parts of Calendar, Contacts, Drive, Text and the dashboard really work quite well already. It is nothing that compares yet to what Google is offering, but it comes close to the quality of what Microsoft is offering on the web, and definitely surpasses that in some areas.

This is definitely something to keep an eye on. I certainly will be watching its progress closely.

In summary

As of this writing, Google definitely comes out strongest in terms of accessibility and fit and finish when it comes to working efficiently with their apps. Granted, it takes some getting used to, and it requires that a screen reader user know their assistive technology and are willing to learn some keyboard shortcuts and familiarize themselves with certain usability concepts. But once that is mastered, Google Apps is definitely something I can whole-heartedly recommend for online collaboration. Furthermore, if you look at new features for commercial screen readers such as JAWS, you can see that they’re paying attention and improve their support for Google apps bit by bit where support is still lacking.

Microsoft is close behind, with some areas that are better accomplished in their desktop apps or on tablets rather than on the web.

Open-Xchange still has its bumps in the road, but is on a good way to becoming a viable alternative for those who can rely on their own infrastructure and want to go to a full open-source stack.

And for Apple, I recommend staying away from the web offering and doing all the office work in iWork apps for Mac or iOS. The web stuff is just too much of a hassle still.

This post was originally published in January of 2015, and has last been updated on April 10, 2015, with latest information on the mentioned problems in light of the OS X 10.10.3 and iOS 8.3 releases from April 8, 2015.

Over the past couple of days, a number of well-known members in the Apple community raised their voices in concern about Apple’s general decline in software quality. Marco Arment (former “Mr. Instapaper” and now “Mr. Overcast”) started out by saying that Apple has lost the functional high ground. John Gruber of Daring Fireball slightly disagrees, but says that Apple have created a perception that “Other people’s stuff doesn’t work, but Apple’s stuff doesn’t work, either”. And finally, Dr. Drang looks at the power of leverage in this context. And now, well, here is my take on the subject.

Some long-standing readers of this blog may recall this post I wrote in June of 2009 about my first experience using an iPhone. It was the first time I interacted with a touch screen device that was accessible to me as a blind user.

For several years to come, Apple would lead in terms of including accessibility features into both its mobile and desktop operating systems. Zoom had already been there when VoiceOver was introduced in iOS 3.0, and what followed were features for people with varying disabilities and special needs. Assistive Touch, which allows gestures to be performed differently, mono audio and integration with hearing aids, sub titling, audio description and other media accessibility enhancements, Guided Access for people with attention deficiencies, Siri, and most recently, Braille input directly on the touch screen in various languages and grades. Especially on iOS, VoiceOver and the other accessibility features received updates every year with every major release, and new features were added.

In the beginning, especially in Snow Leopard and Lion, Apple also did the same for OS X. It gradually also added many of the features it had added to iOS to OS X to keep them in sync. But ever since Mountain Lion, VoiceOver did not see much improvement any more. In fact, the lack of newly introduced features could lead one to the perception that Apple thinks that VoiceOver is done, and no new features need to be added.

But, and I haven’t said this for the first time on this blog, the quality of existing features is steadily declining, too. In fact, with the release of both OS X 10.10 “Yosemite” and iOS 8, the quality of many accessibility features has reached a new all-time low. AppleVis has a great summary of current problems in iOS 8. But let me give you two examples.

The first problem was so obvious and easily reproducible that it is hard to imagine Apple’s quality assurance engineers didn’t catch this, and that was on the iPhone in Safari, when going back from one page to the previous one with the Back button. When VoiceOver was running, I hadn’t found a single page where this simple action did not trigger a freeze in Safari and VoiceOver. This was in early betas of iOS 8, and it was only fixed in the 8.3 release released in April of 2015, roughly 10 months after the first iOS 8 beta was seeded to developers on the day of WWDC 2014.

The second example concerned using Safari (again) with VoiceOver, but this time on the iPad. Using Safari itself, or any application that uses one of the two WebView components, I was reliably able to trigger a full restart of the iPad at least twice a day, most days even more often. That caused all apps to quit, sometimes without being able to save their stuff, it interrupted work, and it left the iPad in a semi-unstable state that it was better to fully shut it down and restart it fresh. Update: This, too, was finally fixed in iOS 8.3. But it took quite a number of logs that I sent to Apple engineers before the problem could be fixed. But after I wrote the initial version of this post, in a concerted effort, this could finally be nailed down.

“Wait”, you might say, “this sounds like a problem from iOS 7 days, and wasn’t it fixed?” Yes, I would reply, it was, but it returned in full force in iOS 8. But mostly on the iPad. I think I’ve only seen one or two restarts on my iPhone since iOS 8 came out.

The first of these two examples is such low-hanging fruit that I, if I was working at Apple, would be deeply ashamed that this was around for so long. The second one was harder, but not so hard that an engineer sitting down for a day and using the device with VoiceOver enabled wouldn’t run into it.

But accessibility problems are not limited to VoiceOver alone. Web Axe posted a great summary about problems in other areas such as the default settings for paralax effects, button shapes and more. Go check it out for more information on those topics!

And now back to Yosemite. I again concentrate on Safari + VoiceOver, since this is where I spend a lot of my time. Support had regressed so badly in the initial 10.10 release and the first 10.10.1 update especially on dynamic pages that it was barely possible to use Facebook on Yosemite with VoiceOver. VoiceOver skipped over whole stories, lost focus, and did all sorts of other funky stuff. It took until the update to 10.10.2 on January 27, 2015, 3 months after the initial release, to at least largely address these problems. Moreover, editing in any form field on the web was so slow and double-spoke that it was not really possible to do productive work there. And if you had a braille display connected, you could expect it to drop out every few seconds when moving the cursor. The sounds VoiceOver made were the equivalent of plugging and unplugging a USB braille display every 3 to 4 seconds. These also were corrected in the 10.10.2 release. In fact this update is written in the MarsEdit blog authoring software, and using that hadn’t been possible with VoiceOver until 10.10.2.

All of these problems have been reported to Apple, some by multiple users. They were tweeted about publicly, and now I am reiterating over them again to show my support for Marco, John, and others who assert rightly that Apple has a real quality problem on their hands, which higher management seems to be quite thick-skinned about. Blinded by their own brilliant marketing or something? 😉

Apple does have a fantastic accessibility story. No other operating system I know has so many features for such a big variety of people built-in (speaking mostly for iOS now). But they’re on the verge of badly trumping that trust many people with disabilities put in them by delivering such poor quality updates that make it virtually impossible to take advantage of these features in full force. Especially when such basic functionality as I describe in Safari, and AppleVis summarize on their blog, are getting in the way of use every minute of every day now. And Apple really need to be careful that others may catch up sooner rather than later. On the web, the most robust accessibility is already being delivered by a different desktop browser/screen reader combination on a different operating system. As for mobile: Android is the lesser of the competition, even in its latest update, in my opinion. But Microsoft’s foundation is really solid in Windows Phone 8.1. They just need to execute on it much better, and they could really kick ass and become a viable alternative to Apple on mobile.

Fortunately, with the release of iOS 8.3, Apple finally came to their senses and included a big number of accessibility fixes and polish, which AppleVis summarizes in this blog post. Here’s to hoping that the rumors come true that Apple will be focusing a lot more on stability and polish in the iOS 9 update, expected to be in beta at around their developer conference later this year. I think the fact that iOS now has a public beta program, too, is a good sign for that, and it gives more people the opportunity to test and report problems early.

So here is my appeal to Tim Cook, CEO of Apple: Put action behind these words again! Go to these extraordinary lengths you speak of by not just cranking out new features that are half-baked, but make sure your engineers work on the over-all quality in a way that does not make your most faithful users feel like they’re being let down by your company! Because that is, exactly, how it feels. This trend started more strongly in iOS 7, and even worsened in iOS 8. And it has been with OS X even longer, starting in Mountain Lion and worsened ever since. Please, show us, our friends and family who started using your products because of our recommendations, and those of us who took a leap of faith early on and put our trust, our productivity, our daily lives in your products, that these are not just empty words and that that award you received actually means something beyond the minutes you gave that speech!


a caring, but deeply concerned, user