I took an educational day today so I could learn a bit more about software accessibility, especially on Windows. It was time well-spent. It's a very interesting topic, and I learned an awful lot. I did a bunch of accessibility testing on the IDE and the framework in general, and found just where we are doing poorly. Then I devised a road-map of features that would bring us up to speed and make the product better. I ended up sending a 10 page email to the staff discussing the topic and giving reports and recommendations. LoL, I'm sure people will only read the intro and the conclusion, but that's ok, I still have all the knowledge in my head (and now it's documented too) and I'm just naggy enough of a person to make sure we're moving towards my goals and not away from them.
I'm not certain how interested anyone here is in software accessibility (aside from possibly Dr Scott, who I think would be interested in vision-related accessibility issues). Does anyone here care? Are there questions that anyone has about the topic? Anything people would like to discuss?
I figure I'll outline the tests that I ran because they should help you with your own applications.
1) Tests for people with physical impairment. Unplug your mouse, then launch your application and use it for real-world work. Any time you run into something that you can't do because you need the mouse is a bug. Anytime you run into something that's very hard to do (but not impossible) is an area you may want to improve. Remember -- the more ways you can access a piece of functionality, the more accessible your application is to people.
2) Tests for people with low vision impairments. Set the computer to high contrast mode by going to Start->Control Panels->Accessibility Options->Display->Use High Contrast. Then start your application. Look for any splotches of color. If some text is disabled, then it will be using color, but aside from that, you should mostly be seeing a much larger user interface with black and white (high contrast) UI elements. It may help to use the OS in high contrast mode before starting your application if you're unfamilar with the way proper high contrast applications are meant to look.
3) Tests for people with no vision (blindness). Get yourself a screen reader, or use the horribly limited but still functional Narrator application (Start->Programs->Accessories->Accessibility->Narrator). Start the reader up and navigate to your application, but do not launch it. Now comes the fun part -- turn the monitor off, press Enter (to launch your application) and try to use the application for real world work. If you find yourself lost at any point, then you have a bug. Again, if you're unfamiliar with how Narrator (or another screen reader) is supposed to behave, use it on the OS itelf to see what it does.
I was able to find issues in all three tests with the IDE and the framework. Some tests failed more horribly than others -- like the screen reader test. We flunked that one immediately because custom controls (of which the IDE has plenty) don't work with screen readers currently. But other areas we did pretty good with, such as keyboard accessibility. There were areas we need to fix, but there weren't that many of them.
Overall, I think the educational day was very well spent. I learned a lot of new things, I found a lot of great resources, it's resulted in some good discussions with other engineers on the topic.
If I had to pick one thing that I learned which surprised me the most, it's that failing to provide a VPAT for your product means that the gov't will not do massive deployments of your software. That's why you'll see a whole lot of Microsoft in the gov't -- they have VPAT docs for everything. Here is a VPAT template so you can see a bit more about what I'm talking about. Very interesting thing to learn!
This is quite an interesting topic. It seems like OS X has some very similar features to the ones you've been talking about, however in my brief tests my apps fail in the same way. The biggest flaw is my custom controls don't work properly like built-in controls. Do you care to write a tutorial on how to better implement canvas-based custom controls for universal access.
The thing which I would really like to implement is the 'full keyboard access' feature of OS X, where you can tab to all controls, and if it's a button or menu, push spacebar to replicate a click. I use this feature a lot, and I'm not even impaired in any obvious way!
I think the entire genre of topics (UI design, accessibility, usability, etc) are fascinating. If I were to do a Master's or PhD, this is the area I'd focus on.
From the discussion Joe and I had, it sounds like OS X has something close, but not as powerful as Microsoft's APIs. For example, with the MS APIs, you can describe pictures, multicolumn listboxes, state information (enabled vs disabled, etc), role, number of children, parent, keyboard mnemonics, etc. All sorts of great stuff. But it sounds like on the Mac, all you can do is speak the text (which is something we appear to not support).
I actually did write a small example on how to make a custom control that supports the keyboard properly. But I don't thikn I've come up with an all-out tutorial on the subject. You'll note that it doesn't really work as you'd want on OS X though since 1) It doesn't draw the focus ring for the Mac and 2) I don't know how to query whether full keyboard access is turned on or not.
Hi Aaron! How'd you guess I'd be interested in this topic? ;-) I teach visual perception and the application of its principles for diagnosing eye and visual disorders, as well as what people with visual disorders will perceive.
There's a several things to be aware of for people with vision impairments:
(1) The size of text. People with visual disorders will probably need larger text to account for losses of visual acuity.
(2) How easily items may be located in a window. People with visual field losses in the central field have more difficulty locating items because we rely on central vision for not only our optimal visual acuity, but also for fixation (aiming the eyes).
(3) Luminance contrast. People with visual disorders may have contrast sensitivity losses, and perceive objects as having lower contrast. They may not detect objects with low contrast, so boosting the contrast will help them. Boosting contrast also helps their visual acuity somewhat.
(4) Color vision losses. Sometimes with eye diseases there can be color vision deficits. In some ways these are like hereditary color vision problems, but the individual is even worse off because he/she has not had the time to learn to compensate for it. Different types of color vision losses will produce diferent color confusions. If you must use color in your display, consider offering an alternative grayscale display too.
(5) Color contrast. With color losses you can sometimes also have color contrast losses, so more saturated colors and bigger differences between colors will be helpful.
This is not an exhaustive list of vision problems, of course. There are also binocular vision problems and accommodative (focusing problems) that can be significant in people who use computers a lot, and attentional problems and eye movement problems that can occur with traumatic brain injury, strokes, etc. The key is simply thinking about how frustrating your program could be for somebody with vision problems and trying to compensate for it as best you can.
I'd be happy to discuss this further with anybody if they want to contact me.
I knew you'd have great things to contribute to the discussion. :-)
With regards to #1, how key of a factor is it to provide some sort of Increase/Decrease text function for an application? For example, with the RB IDE, is it enough to provide users with a preference to change the font and size of the code editor's text (along with colors for people with various color deficiencies)? Or is it better to provide some sort of functionality to make the entire UI (such as toolbars, etc) have larger text and icons?
With regards to #2, how much of an issue is visual variation between objects? Do people with "nervous" eyes have a hard time distinguishing between two objects that are similar in shape and size, and only vary by small degrees? I'm thinking along the lines of the difference between the New Class/New Class Interface/New Container Control toolbar icons in RB 2005.
Thanks for any enlightenment you can provide!
Most people with serious visual disorders will probably have software that will magnify the entire screen's contents for them. For those that don't, the text in every UI element would need to be larger. For that matter, icons may need to be enlarged (and have fewer small details) too.
I'm not sure what you mean by "nervous" eyes, but in general, the more distinctive each object is, the faster you'll locate it within a screen full of objects (and the more accurately you'll find it). If icons look very similar, they're more likely to be confused, which will slow you down. For someone with visual problems, this can be even more problematic.
Good point -- that's the reason for including Magnifier with the OS. I think it's quite important to have your graphics and text support the system metrics though, so if the user has set the system up for large fonts, you had better use them.
So, in your opinion, is there enough visual distinction between the icons in RB 2005 for things like Add Class/Interface/Container Control on the project items toolbar? Another question I have is whether it's a bad idea to reuse icons for similar concepts. For example, in the controls palette in the window editor, the ServerSocket, TCPSocket and UDPSocket all share the same icon. To me, that seems like a mistake since the icons are used to draw the attention so the user doesn't *have* to read the text. But when you make icons the same for items which are related, but siblings (not parent/child) you defeat the purpose to having the icons since now the user has to read the text to see what they're dealing with.
Hi Aaron. Sorry I took so long to respond - the medication I've been on since my surgery puts me to sleep a lot.
Basically, there's a trade-off between grouping icons by appearance to reflect their related functions vs. making them more distinctive to allow people to locate them faster and more accurately by visual search. I find the class, interface and container icons to be much too similar; they require extra time to tell them apart. GroupBox and ImageWell are similar, as are Placard and Rectangle. Forward vs. Backward (for control layering) are almost indistinguishable. The Socket controls don't differ at all, so reading the text becomes an absolute necessity.
How can you make related icons more distinctive yet still show their grouping?
1. Label the icons. For example, in the Socket control icons, maybe adding an "S" (Server), "T" (TCP) or "U" (UDP) to the icons might help to differentiate their functions.
2. This would work only for the control list: Make the control list hierarchical to group similar items.
3. The optimal way: An icon group that is currently depicted well is the database control group. These icons share the same basic disc-like structure, but have very distinctive extra pictures that make them easy to tell apart. You can use differences like this to make related icons more distinctive; that is, a common picture that groups them together by function, but with extra pictures that make each distinctive. The extra pictures can differ by shape (and the more different the shapes used, the better), location within the icon (top vs. bottom or left vs. right), and color. Dynamic controls might have dynamic icons (e.g., the timer could show the sand running).
Thanks for the great information! I appreciate your insights. :-)
You're welcome. This is the subject I teach and have conducted my research, so it's fun to talk about it. I'm also developing software to demonstrate visual perceptual phenomena and simple models of the visual system for my courses using REALbasic. If there's anything else vision-related you need to discuss, email me or write it here or let's talk at the next Real World.