Accessibility is not just for people with disabilities

Date:August 16, 2006 / year-entry #277
Orig Link:
Comments:    21
Summary:When the topic of accessibility comes up, most people think it's all about people with disabilities. While it's true that people with disabilities were the original target audience for accessibility, more recent developments have highlighted the value of accessible technologies to everyone. For one thing, making your program accessible means that test automation can manipulate...

When the topic of accessibility comes up, most people think it's all about people with disabilities. While it's true that people with disabilities were the original target audience for accessibility, more recent developments have highlighted the value of accessible technologies to everyone.

For one thing, making your program accessible means that test automation can manipulate your program in a uniform manner. They can enumerate the buttons, get text for them, press a button programmatically, and so on. Even if you don't use a standard button control but instead opt to go windowless, as long as you expose your controls via accessibility, test automation can find them.

Also, we saw how programs can use accessibility to retrieve text from the screen. I use this in my English/Chinese dictionary program to "pluck" text off the screen and paste it into the "translate this" box, where I can arrow through the sentence and have the program translate each word or phrase on the fly. (Rats, now you know where I'm going with the program.) And once I started using this feature, I discovered to my dismay how many of the programs that I use on a regular or semi-regular basis simply fail to support this simple task. Microsoft products have a much higher success rate, but even there the support is not 100%.

Finally, check out this screencast showing off Vista's speech recognition system. The "Say what you see" feature which Chris discusses at time code 8:52 needs to get the name of every element on the screen so it can take what you say and look for it on the screen. If your program doesn't expose these names, the "Say what you see" feature won't know what the user needs to say to click on your button, and users will say, "Harumph, why doesn't this program work with voice recognition? All my other programs do."

My secret hope is that "Say what you see" will finally be enough to prod people into taking accessibility seriously. Because it's not just for people with disabilities.

Comments (21)
  1. Neal C says:

    "and users will say, "Harumph, why doesn’t this program work with voice recognition? All my other programs do.""

    Personally, I find it more likely that they’ll say, "Harumph, why doesn’t voice recognition work with this program?  It works with all my other programs."

    The difference being, essentially, where blame gets placed.  It might not be MS’s fault, but I’m sure that many people will assume it’s a deficiency in the voice recognition rather than in the non-accessable program.

  2. Cody says:

    Back when I used to play on MUDs in high school, one of the players I knew was blind.

  3. Dewi Morgan says:

    For websites, accessibility also means "be nice to search engines trying to index your site".

    The increasing graphical compexity of systems and of web pages is something I personally despise, and not just because I’ve seen GUI-coding move from being 80% of the programming, testing, and code for an application to well over 99%. That’s less accessible for the programmer, and adding no extra utility for the user.

    Contrary to popular opinion, a "too-pretty" interface also makes the application less accessible and appealing to the end user: the overly-twee default XP theme is a case in point.

  4. Having worked with a few people with sight disabilities, I have had experience with some screen readers.

    They do a wonderful job with what they are given, but there is so much more that we (as developers) can do to make them work better.

    Unfortunately, many companies say "the <insert application here> is only for our use, in-house.  Don’t bother with the accessability stuff".


  5. Thomas says:

    Very true. As an example, my laptop has a feature where I can hold the middle button and then moving the mouse scrolls the window below the pointer instead of moving the pointer (IBM TrackScroll or something similar). This works very well with anything using the stock Windows controls, and works with varying amounts of success with other programs. As a couple of examples, Lotus WordPro ends up scrolling a page at a time as opposed to a few lines, and this doesn’t work at all with the contacts list in MSN Messenger (not singling MS out for blame here, there’s some just as bad open-source stuff). In both cases they’ve to a greater or lesser extent rolled their own scrollable window, and their own version doesn’t quite behave the same way as the system one.

    The point is that by ignoring the system components, they’ve lost all the functionality that is provided by them. Which is quite a lot – the stock edit control for example has full clipboard support. It’s one of my pet peeves with a lot of programs, including some major open source projects (e.g. GTK) – the stock control isn’t pretty, so rather than make it owner-drawn they roll their own which doesn’t have any significant extra functionality.

  6. Miral says:

    Accessibility requires COM, though.  And COM scares people.  And makes small children cry.

  7. silkio says:

    Cody … I still play Text-based MUDs. Hmm.

  8. Stu says:

    I suppose while we talk about speach reconition, I should mention that I predict *very* few people will use it.

    Apple have had speach recognition built into the Mac OS since way back in the 68k days. Nobody uses it. In OS X its been hidden away in System Prefs, but it used to be much more prominent.


    * Useless in an office environment. Too much ambient noise, getting worse the more people that use it.

    * Same in public places.

    * People feel embarrassed about talking to their computer. I remember reading a study on this somewhere, saying that unless people are alone in a room, they feel stupid talking to inanimate objects, even when they respond.

    * Speech is often inaccurate, especially with background noise, requiring people to say the same thing several times, hightening the embarrasment.

    So voice seems to be a feature that sounds godd in theory, but won’t take off, except for the visually impared.

    Another thing, relating to this thread, is that it should not be possible to automate some dialogs, for security reasons. Look at what has become of the "unsigned driver" box (which was a silly idea in the first place, implemented for economic reasons only).

  9. DriverDude says:

    "…the stock control isn’t pretty, so rather than make it owner-drawn they roll their own which doesn’t have any significant extra functionality."

    Back when WinXP was new, I knew some marketing folks wanted to use the XP look on their app on Windows 2000. They got designs from a graphics house and gave it to the devs, who laid out a UI pixel-by-pixel using their own controls.

    The result was completely non-accessible: all the buttons were graphics; no keyboard navigation or hot-keys; was the same size at all screen resolutions; didn’t follow the color scheme the user picked. It wasn’t even skinnable.

    But they didn’t care. It looked pretty.

  10. ctodx says:

    Time again I think for you to take another look inside the CTO’s brain to see what he’s considering for…

  11. I agree, accessibility support is very important and we’re investigating adding support for the VCL framework in Delphi. However, it’s unfortunate that MSAA isn’t better documented and rather than using brief pseudocode it would have been nice to see real world code and perhaps even an example. I’d love to see you discuss handling WM_GETOBJECT (my apologies if you’ve already discussed it before in which case link please <g>).


  12. ShyGuy says:

    > Accessibility requires COM, though.  And COM scares people.

    The fact that writing a driver with the DDK is easier than using COM in C++ might be a factor.

  13. Cody says:

    silkio, I’ve mostly eschewed my gaming origins for shooters.  I never loved the fantasy muds, and all the good Star Wars ones died, as far as I know.

  14. Wibble says:
    • Chirping "walk/don’t walk" signs and automatic BART train announcements help me even though I see fine.

      – Firefox type-ahead find was partly for accessibility, and I love it.  

      – LABEL tags keep me from having to navigate my mouse onto tiny checkboxes and radio buttons.

      – More "semantic" HTML sometimes helps both screenreaders and search engines use webpages effectively.  

      – More generally, you could argue that accessibility goes along with well-designed UI and code.  Joel Spolsky, dude that he is, offered "design for extremes" as a UI design principle.  A well-organized dialog composed of familiar widgets is good for screenreaders and for sighted folks.  The cause and effect here are debatable, of course.  

  15. denis bider says:

    OK folks… Perhaps I’m the only one who doesn’t get it, or perhaps the emperor indeed does not have any clothes.

    Leaving aside test automation case, where I can actually see how accessibility could be useful, implementing accessibility for the disabled really seems like a quite altruistic (read: economically unjustified) effort. It means increasing the effort that goes into development by X%, while increasing market reach only by a much smaller Y%, Y << X. So, leaving aside idealism and PR as motivation, why would any application developer want to invest in that? Increase the development expenses and thus the price EVERYONE has to pay for the same software?

    It seems to me a more efficient solution would be centralized rather than dispersed – i.e. a company catering specifically to make existing software accessible to the disabled, and charging extra money for a smart solution that solves that, instead of each developer having to go (or chosing not to go) to great lengths to make each individual program accessible.

  16. denis bider says:

    In general, Microsoft has a pretty bad record of offloading responsibilities that should be taken care of centrally onto application developers, at the expense of reliability and security.

    Cases in point – cooperative multithreading; and even nowadays, the general reliance of Windows on programs to be well-written, well-intended and well-behaved.

    Only in recent years has Microsoft realized that it DOES need to take responsibility and does need to start solving problems centrally, and the effect of these initiatives has been better security and reliability for everyone.

    Perhaps accessibility cannot be done without cooperation from programs. But yeah, right. Requiring programs to cooperate is the easy way out. Let the people who develop the accessibility feature instead do their job and create the accessibility infrastructure that won’t require any explicit cooperation, and then truly everyone will be satisfied.

    [Windows does cover accessibility automatically if you do things the “conventional” way. It’s if you decide to be “clever” — owner-draw controls, windowless controls — that you need to do accessibility work. It’s unclear how Windows is expected to be able to figure out that your circle with a greater sign on it means “Next”. -Raymond]
  17. Randy says:

    re: denis bider:

    It seems that many folks do not deal with various large corporations or governments that may require accessability features to qualify for the whole bid.  Thus, although the percent of users is small, the feature may be a qualification one and is necessary to actually qualify to bid the multi-million dollar job.  Without the support the large payday cannot come.

    I cannot imagine any construction company bidding to build a new post office without thoughts for ramps and such.  The same is true in some cases for software.

    Oh, and better testing support for better quality software can also be seen as bottom line addition as suport costs and bug fix costs drop.

  18. If ALL versions of developer stadio included a very good GUI testing tool that could be used for both unit and system testing of UI and depended on the accessible technologies.  Developers would start to support accessible technologies in all new code just so they could test it without having to spend hours with a mouse!  

    If the testing tool is not free and in ALL versions of developer stadio, it is unlikely it will get used enough to make a difference.

    Just think if all comp Sci students were expected to use such a tool on there third year projects, it would soon spread.

  19. AndyB says:

    I believe there are websites that will check your pages for accessibility ‘errors’. How many sites havn’t been tested and passed with these is rather large. I doubt desktop developers would make as much use of a tool as the web devs do wth theirs.

    The best way to test is to send the app to a disabled user and see what they make of it.

  20. Hidayat says:

    it doesn’t depends on website it depends on webbrowser …

  21. Few days back I had an interesting case where one of our customers wanted to switch the ribbon programmatically,

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index