A recent few posts about accessibility in the Cappuccino web framework got me thinking, how well do my applications fare in terms of accessibility? The answer: OK.

Of course OK isn't good enough. The Mac is a platform the prides itself on user interface, yet it seems it isn't quite as good as we might think. I'd spent no time thinking about accessibility in my applications, and while they were more accessible than I was expecting, there is still a lot of work that needs doing. So I thought I'd check how some other popular applications work with accessibility and what can be done to improve accessibility on the Mac as a whole.

Using VoiceOver and Keyboard Navigation

The first thing to do is explain how to use VoiceOver and navigate your application with the keyboard. Let's use iTunes to try with. With standard keyboard navigation you can easily enough move between the search field, song list and source list and can click on the various buttons with the mouse. But obviously this isn't going to be enough for someone who is visually impaired or who has a motor disability to make full use of iTunes.

To turn on VoiceOver you can go to System Preferences > Accessibility, or just hit Command-F5. Now you will see a black border around one of the UI elements. This is the currently selected item. You can navigate the UI using control-option and one of the arrow keys. Just move around and see how you can how access the full UI, especially take note of what VoiceOver is saying on the various buttons.

Quick Tip: To navigate HTML content, hit control-option-A when the HTML view is selected. This will start reading the full site. You can now use control-option and the arrow keys to navigate the HTML

Below is a table containing some useful shortcuts for navigating the UI from your keyboard, even without VoiceOver selected:

Now try your own app and see how it fares; odds are it won't do too well. But you aren't alone. Here are a how well a few popular Mac apps work with accessibility.

Coda

For the most part Coda isn't too bad, but one pretty serious bug. It seems to cause VoiceOver to be unable to move around the UI if you switch between Local and Remote views in the source list, stating that it is "busy".

Coda also highlights the most common accessibility flaw: Image Buttons.

As you can see, the descriptions of these buttons aren't very, well... descriptive. These are the most common problem, yet also the easiest to fix and can make a world of difference.

OmniOutliner Pro

OmniOutliner Pro has a huge failing. There's no way to navigate to the inspector using just the keyboard. The standard Control-F6 command doesn't work. This means that you have to use the mouse in order to move to an inspector. And when you have moved to an inspector, there is no way to move between those inspectors without again using the mouse. This is a shame as the rest of the application works pretty well with VoiceOver.

MarsEdit

As with most applications MarsEdit is fairly good, but far from perfect. In the post window there is no way to navigate to the Categories table. You can just about get it to highlight with VoiceOver, but it won't let you navigate it. Besides this though the post window is pretty good. The same goes for the main MarsEdit window, besides the image buttons with no descripdtion it has no major flaws.

Delicious Library 2

Again, Delicious Library 2 suffers from image buttons with no descriptions. But by far the biggest problem is the main display view. They keyboard navigation is great, I can move all around my books and CDs and DVDs using my keyboard. But I'm getting no feedback about what the currently selected item is. As I switch items it would make sense for it to read out the names of those items so I know where I am.

The Challenge

So I did come at those from the perspective of someone who hasn't got a disability (well I need glasses and have mild RSI but I can use my computer without needing any real help). What I consider "pretty good" may still not be too good for a disabled user. But what is obvious is that there is a lot of work that needs to be done. We all take so much care and pride in our visual UIs that we don't think enough, or really realise that there are other UIs that people need. Most of us wouldn't ship a shoddy, half baked UI but the fact is that we are all doing that.

So I thought I would challenge my fellow Mac developers to do something that I am pledging to do here and now:

"By the end of 2009, all the apps I produce will be fully accessible"

What do I mean by "fully accessible"? Well, I take it to mean the following points:

• The UI available to VoiceOver users should be as user friendly as the visual UI
• All UI elements should have titles and/or descriptions
• All custom controls should provide full keyboard access
• There should be a clear and logical order to navigating UI fields with the keyboard
• Every part of my application should be reachable without the mouse

Of course there are some caveats. Some applications cannot be easily made accessible. Photoshop for example would be nearly impossible to make fully accessible to visually impaired. But it is conceivable that someone who is unable to use the mouse could draw. OS X does provide methods for controlling the mouse cursor with the keyboard, but with some inventive thinking certain classes of drawing application could be made much more accessible.

Accessibility For All

Making your application Accessible can also offer great advantages in other areas. Tools such Instruments and Automator use the accessibility APIs for recording UI actions to perform back. This can help you as a developer with debugging and your users with automating your application. And if you or your users want more flexibility, making your application accessible opens up the possibility of creating UI scripts in one of the various supported scripting languages.

There are also other potential applications of accessibility. Those of you from pre-OS X days will remember the old Mac Help system that could guide you through performing an action by highlighting the relevant parts of the UI and even performing the actions for you. There's no reason why that shouldn't be possible in an OS X app. Imagine how much documentation writing and support time you could save by being able to have your application show users how to use it!

But...

Of course there will be some questioning the value of doing this. They realise it's a nice gesture, but they don't see the return on investment:

"But I don't know anyone with a visual disability" - I don't know any starving african children or anyone dying from cancer, doesn't mean I shouldn't care. Because you don't personally know someone with a problem, doesn't mean nobody has that problem.

"I've never received any support requests asking me to improve accessibility" - That doesn't mean there aren't those out there wanting better accessibility. Consider that someone might use your app, find it's not accessible and just give up on it. They're not going to waste time sending you an email when they can't see if your app is even worth their time and money.

"Sounds like a lot of work, I'm not sure if it'd be worth the time" - Making your applications completely accessible may take a lot of work, but you can do a huge amount in just a few hours just using Interface Builder. Going through and making sure you controls all have accessibility titles and descriptions, linking your UI elements together properly, making sure the accessibility hierarchy is usable. All these are small tasks that don't take too long and can improve your accessibility a huge amount. You don't even have to do all the accessibility stuff in one version, split it over several versions.

"But I can't make my application accessible for blind people" - Don't think that accessibility is just for blind people. Being visually impaired doesn't mean you can't see, just that you have trouble seeing. There are also other forms of disability that need accessibility such as hearing disabilities and motor disabilities. And on top of this, keyboard navigation can appeal a lot to power users who have no disabilities at all

In Conclusion

Unless we experience something or are affected by something personally, we usually don't care about it as much as we know we should. Try closing your eyes and doing something. Odds are you'll end up opening your eyes for a peek at some point. You're lucky to be able to do that, some people can't.

I've not got a disability that limits my ability to use the computer and don't personally know anyone with one, but I do have a strong sense that we should all be treated equal and have equal opportunities. When we can do something to help someone else and it is very cheap or very easy to do, then we should do it. Making accessible applications can be very easy and not take too much time, but can make a world of difference to some people.

Over the coming months I'll be posting my experiences in making my applications fully accessible so you can learn from what I've found out. We've already made the Mac the platform with the best visual UIs, let's make it the platform with the most accessible UIs.

Apple's Accessibility Developer Page

(10) Comments