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.
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:
Press the selected button
Turn on Full Keyboard Access (needed for the other shortcuts)
Switches the keyboard focus to the menu bar so you can navigate menus
Switches the keyboard focus to the dock so you can navigate the dock
Switch between windows
Select the active window's toolbar
Highlight a palette
Switch tab behaviour between "All controls" and "Just lists and text fields"
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.
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 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.
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.
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.
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:
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.
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!
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
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.
I totally agree with your main point about accessibility being important and underestimated by many.
At least for standard controls it seems that Cocoa provides a reasonably good environment for developers to get accessibility right already. In many cases the effort needed to do things technically right is not huge.
I am not sure, however, about things like custom controls. Digging into the AX APIs seems to take quite a bit of dedication with little in advice and useful (non-trivial) examples being available. That’s certainly the point where I gave up :( In case you master this, be sure to write it up.
At least for the visually impaired I’d be hesitant to laud OS X unless you’re prepared to add the qualifier ‘in English’ to every statement. OS X being fully localised remains one of Apple’s PR lies.
So, for me, it translates into:
- By the beginning of 2009, I will ship my first app.
- By the end of 2009, all the apps I produce will be fully accessible
Quick overview of how my product is accessible today:
KO: The UI available to VoiceOver users should be as user friendly as the visual UI
KO: All UI elements should have titles and/or descriptions
OK: All custom controls should provide full keyboard access
OK: There should be a clear and logical order to navigating UI fields with the keyboard
OK: Every part of my application should be reachable without the mouse
3 out of 5 passed. Not to bad for a yet to be released app!
@ssp: Yeah, the information outside of Apple on accessibility is a little thin, but I’m hoping to change that be giving details about all my accessibility work that I’ll be doing this year.
As for the localisation, OS X is actually very good for accessibility in several languages. While it only ships with English speech synthesisers, you can buy additional voices from 3rd parties to handle foreign language support and already has localisations for Spanish, French, German, Italian, Dutch, Japanese, and Chinese .
@Guillaume: Sounds like a good start. Quite a lot of applications are already quite a way down the road to full accessibility and a huge chunk of the remaining work is relatively easy stuff. Good luck in passing the remaining 2!
The fact that you ‘can’ (which I read as a liberal interpretation of ‘have to’) buy the voices for non-English languages from other companies in addition to the OS pretty much makes my point that OS X does not come fully localised, doesn’t it?
[And your captcha makes me type truth to send this message, so it _must_ be true…]
I’m thrilled to read this pledge and challenge and I hope many Mac developers take you up on the challenge!
I run the ATMac website which covers Apple product accessibility for all disabilities - not just visual impairments - and I’d be thrilled to support you in any way that I can. If you think it would be appropriate to extend the challenge to other disability groups, that would be a bonus but I realise what you’ve already posted is a huge undertaking for most people.
I’ll publicise this challenge on the blog (probably Monday) and I’d be happy to act as a “repository of knowledge” for programmers struggling with access API issues. There’s already Apple’s accessibility mailing list, but having a forum where people could post non-trivial examples or perhaps be an index to other places online where people post examples in their own blogs?
Let me know what you think would be helpful and I’ll do my best to make it happen.
I’m rickybuchanan on Twitter - probably easiest to connect there.
The irony of the CAPTCHA making it impossible for some with disabilities to post comments is… could I suggest Akismet?
@Ricky: I’m going to be starting blogging about accessibility issues on a fairly big developer site soon so hopefully I’ll be able to get the message out to more developers.
Of course, the big problem with accessibility is that it’s hard for those who don’t have first hand experience with disabilities to really know what is really needed. I’m as new to doing accessibility as most other devs so any help in the right direction is greatly appreciated!
I’ll also be working to make my site more accessible so I’ll look into changing the captcha too.
@Martin: I suggest you contact/join the MacVisionaries mailing list (currently hosted as a Google group). Largest VoiceOver users mailing list - you’ll find tons of VoiceOver users willing to give advice and to alpha/beta test stuff and give feedback on accessibility. Also some low vision users and other disabilities represented there although not many.
There’s also some devs who work on assistive technology on that list - they may be interested to partner with you?
For other resources check out my links page at http://atmac.org/resources/links/ also - mostly aimed at accessibility users but some may be relevant.
We have been developing assistive technology software for the Mac for over 10 years (and now working on that too for the iPhone) and very much support this initiative.
While some of our applications pre-date the accessibility API and were designed not to require it, many of our more recent programs use the accessibility API as a client to offer greater accessibility to our users. If your program fully supports the Accessibility API, software like ours does not only help vision impaired users, but can also work more effectively for people with reading impairments or physical impairments.
For those needing some inspiration before setting out on the “make my program fully accessible” mission, watch some of the videos here http://www.frontiersofat.com and you will have a good idea of why that mission is worth any minute you spend on it.
VoiceOver is a great way to explore the accessibility of your software, but using it in full is not trivial due to the many keyboard commands (though this might help http://images.apple.com/accessibility/voiceover/pdf/VoiceOver_Keyboard_Color20080912.pdf). Luckily, Apple provides two great developer tools that can help you identify accessibility problems. Check out Accessibility Inspector and Accessibility Verifier, which are part of the developer tools. These tools are very easy to use and make it easy to identify many of the common accessibility glitches and also make it easy to check whether you correctly fixed them.
@David: I’ve just watched all those videos. I have to admit that I had a similar idea about disabilities as most people before watching them: that you can’t really do a huge amount. Watching those videos has opened my eyes. Seeing people with motor diseases doing design work or playing games just as well as a fully able person really is amazing.
Also, thanks for the link to that keyboard command sheet. I was actually trying to work out all the hotkeys last night so that’s really helpful (and also shows how many I missed).
The American Foundation for the Blind, as part of fulfilling its mission (“Expanding possibilities for people with vision loss”) has established a specialized consultancy, AFB Consulting, to work with organizations to assure that their products, services, websites and intranets are fully usable by people with disabilities.
AFBC provides its clients with confidential expert evaluations of their products and services (including but not limited to software, hardware, websites, Intranets, appliances, and devices) both for accessibility-compliance and for usability. I invite you to bookmark http://www.afbconsulting.org for a detailed description of our varied services including work with Adobe, Cisco Systems, Marriott, & Otis Elevator. I believe that an M3-AFB Consulting Accessibility Partnership would provide your company with responsive, knowledgeable and highly credible expert support in the very specialized and fast-changing areas of accessibility and usability. We see several ways that our skilled technical professionals, many of whom are living with disabilities themselves on a daily basis, can support the efforts of your development department. Teaming with AFB Consulting represents a unique opportunity for your team to outsource much of the specialized work (e.g., user testing) necessary to assure the accessibility and usability of the applications you are developing.
Please feel free to contact me at your convenience.