Thread Subject: Re: possible need for another provision

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Truesdell Nick
Date: Tue, Mar 27 2007 12:55 PM

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?


Nick Truesdell
Information Technology Accessibility Center - ITAC
Information Resources Accessibility Program - IRAP
Desk: 202-283-5536
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Tobias
Sent: Tuesday, March 27, 2007 10:01 AM
To: 'TEITAC documentation and technical support subcommittee'
Subject: Re: [teitac-documentation] possible need for another provision

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 my proposed re-draft of 41(b):

"End-users and technology managers shall have access to a description of
the accessibility and compatibility features of products, including how
to install, configure, and activate them. These descriptions shall be
available in alternate formats or alternate methods upon request, at no
additional charge."

that 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.




***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Whitney Quesenbery [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, March 26, 2007 3:13 PM
> To: TEITAC documentation and technical support subcommittee
> Subject: Re: [teitac-documentation] possible need for another
> provision
>
> To add to Jim's email:
>
> 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).
>
> Whitney

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University