Thursday, March 3, 2011

Responsibility for Windows Application Accessibility

When an assistive technology (AT) user discovers an application that is inaccessible in some way, they will generally hold one of two parties responsible: the AT developer or the application developer.

In the Apple world, the application developer is generally responsible for ensuring accessibility. Users don't tend to complain to Apple when an application is inaccessible; they complain to the application developer. More often than not, this is correct. An accessibility framework has been provided to facilitate application accessibility and Apple's assistive technologies utilise this framework, so it's up to the application to fulfil its part of the bargain.

In contrast, in the Windows world, the AT developer is generally held responsible. In the past, before there were standard, fully functional accessibility frameworks, I guess this was fair to some extent because application developers had no way of making their applications accessible out-of-the-box. As a result, AT developers worked around these problems themselves through application specific scripting and hacks. However, Windows has had standard rich accessibility frameworks such as IAccessible2 and UI Automation for several years now. Therefore, this is no longer an acceptable justification. Despite this, the general expectation still seems to be that AT developers are primarily responsible. For example, we constantly receive bug reports stating that a certain application does not work with NVDA.

Some might argue another reason for this situation is that application developers have previously been unable to test the accessibility of their applications because of the high cost of commercial ATs. With the availability of free ATs such as NVDA for several years now, this too is no longer an acceptable excuse.

So why is this still the case in the Windows world? If it's simply a ghost from the past, we need to move on. Maybe it's due to a desire for competitive advantage among AT vendors, but the mission of improving accessibility and serving users as well as possible should be more important. If it's resultant to poor or incomplete support for standard accessibility frameworks, ATs need to resolve this. Inadequate or missing support for accessibility in GUI toolkits is probably part of the problem. We need to work to fix this. Perhaps it's because of a lack of documentation and common knowledge. In that case, the accessibility/AT industry needs to work to rectify this. Maybe there just needs to be more advocacy about application accessibility. Are there other reasons? I'd appreciate your thoughts.

Whatever the reasons, I believe it's important that this changes. Proprietary solutions implemented for individual ATs are often suboptimal. Even if this wasn't the case, implementing such solutions in multiple ATs seems redundant and wasteful. Finally, the more applications that are accessible using standard mechanisms, the more users will benefit.

2 comments:

  1. Don't conflate "complaining to" with "blaming". Users will try to contact the party that they think is most likely to be able to do something about the problem. For instance, they might complain to an AT vendor because they think others will, too, and that the AT vendor will then have more clout. Or they may be reporting a problem to both, in the hopes that one or the other will solve the problem.

    There is plenty of responsibility for accessibility to go around; the user is unlikely to know exactly whose "fault" it is. In fact, that can be hard to determine for anybody. Some things can only be solved by a cooperative effort by all the parties, application, platform, and AT, and it may turn out to be a little of this and little that.

    Rather than focusing on the "responsibility" for the flaw, effort should be put into figuring out how best to get reports of problems to someone who can do something about it, whether it's fixing it or finding the person who can. Because that can have a happy ending.

    ReplyDelete
  2. @sbourne: There's certainly some truth to what you say about the distinction between complaining and blaming. However, my experience has been that many users start with the AT vendor requesting that the AT "support" an application, rather than going to the app vendor and requesting that the application be made accessible. In many cases, as long as the app uses the standard frameworks, it should just work.

    I'm certainly not saying that ATs have no responsibility at all; that's far from the truth. If an AT doesn't support something properly in a standard framework, the AT vendor needs to fix that. An AT vendor also needs to cooperate with app vendors to help them make an app accessible or in cases where it is difficult to determine where the fault lies.

    Nevertheless, I think there is still a real focus on ATs implementing specific, proprietary support for specific apps. Even Microsoft Office, perhaps one of the most popular application suites, doesn't actually implement support for standard accessibility frameworks in many major places, so ATs have to use proprietary APIs. This has become far too common and I think it is a terrible situation.

    My aim here isn't to start blame games, but rather to encourage discussion that might hopefully make overall optimal, out-of-the-box accessibility more common.

    ReplyDelete