Documentation:Workarounds
How can we encourage vendors to document compatibility issues, work arounds or other issues?
This topic was kicked off by Jim Tobias (March 26)
In today's General Interface Subcommittee call, we had an extended discussion about how to make sure that accessibility features and compatibilities are easy enough to discover and activate. That is, how do we guarantee that an end user or sysadmin can find the needed feature and install/configure/activate it.
Some of these may have to do with workarounds, AT compatibility, etc., in pretty fine detail. For example, a particular piece of software may work with a given screen reader except for a few conditions. The VPAT may not be the best tool for communicating about that in detail. Getting this information out to the user or sysadmin may be crucial in making the product actually accessible (instead of theoretically accessible).
We heard clear concerns as well, however, that in some cases some of this information may be proprietary, such as when it involves the specific technology implementations used by the vendor.
Comments and feedback
March 26 - Whitney Quesenbery
One of the points that was raised in the conversation was that we can't expect vendors to create documentation for how their product works with specific AT. I'd like to challenge that a little bit.
Product manufacturers often provide software application notes that describe how to connect their product to other products. For example, early HP LaserJet 4 documentation packages included notes on using the printer with several popular word processors. Note that they didn't document each and every word processor on the market - I'm sure the decision was based on numbers of users (market potential) or how many technical support calls they thought they could avoid by providing the information up front.
These notes often filled the gap during the time when new features of the product or operating system were possible, but not yet well known. Isn't that exactly where we are?
Having said all this, I'm not sure how to draft a requirement (or even a "should" guideline).
March 26 - Jim Tobias
Whitney raises the valid point that companies frequently document interoperability, and that they do so to reduce the support calls they would otherwise receive. If that's a driver, then making the sale in the first place would be even more powerful a driver. That's the role we want accessibility to play, so adding a provision about AT interoperability and accessibility features makes sense.
Note that in the proposed re-draft of 41(b) the agency is still the burdened party. This gives agencies leeway as to how to come into possession of AT interoperability information. They can request them as part of market research, require that they be delivered as part of the procurement if the bid is successful, and probably through other mechanisms.
To reply to Terry's point that the VPAT permits such information, I agree that it does. However, the VPAT does not require the information, nor is it usually found in any level of specificity that would be useful in reviewing the implementation issues and comparing products. I'm sorry if I appear to bash the VPAT sometimes. One dissatisfaction I have about it is that many companies know much more about the accessibility and compatibility of their products than they put in their VPAT. I'd like to remedy that situation without undercutting vendors' ability to market their products and preserve their intellectual property. That may mean re-engineering the VPAT, but this provision does not insist on that.
To me, delivering complete accessibility and compatibility information after the sale is more valuable than delivering incomplete information before the sale.
March 27 - Nick Truesdell
This looks good to me with one sticking point: the proposal references end-users. Generally speaking the act of tweaking IT, AT, or both is a task that only employees in a technical support would have the system privileges to perform. Could perhaps the description of accessibility features of a product be separated out from the configuration/activation of such features?
March 27 - Jim Tobias '
I'm reluctant to add this kind of language because it complicates the text and because it's not always clear what the user can do, is authorized to do, etc. If the user doesn't have technical privileges to change some admin setting, nothing in my proposed draft gives them that power. But it's better to have a user have the info so that he/she can show it to the sysadmin and explain the purpose of the change, than to give it only to the sysadmin who may then ignore it.
