Thread Subject: possible need for another provision

Return to this mailing list's archives

From: Jim Tobias
Date: Mon, Mar 26 2007 11:05 AM
Subject: possible need for another provision

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.

The question arose: is this issue the domain of the Documentation
Subcommittee? I think it
is.

Here is the current draft of 1194.41(b):

End-users shall have access to a description of the accessibility and
compatibility
features of products in alternate formats or alternate methods upon request,
at no
additional charge.

I would modify it thus:

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.

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

From: Whitney Quesenbery
Date: Mon, Mar 26 2007 12:35 PM
Subject: Re: 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

At 02:02 PM 3/26/2007, Jim Tobias wrote:

>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.
>
>The question arose: is this issue the domain of the Documentation
>Subcommittee? I think it is.
>
>Here is the current draft of 1194.41(b):
>
>End-users shall have access to a description of the accessibility and
>compatibility features of products in alternate formats or alternate
>methods upon request,
>at no additional charge.
>
>I would modify it thus:
>
>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.
>
>***
>Jim Tobias
>Inclusive Technologies
>+1.732.441.0831 v/tty
>+1.908.907.2387 mobile
>skype jimtobias
>
>

From: Jim Tobias
Date: Tue, Mar 27 2007 7:05 AM
Subject: Re: 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

From: Truesdell Nick
Date: Tue, Mar 27 2007 12:55 PM
Subject: Re: possible need for another provision

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

From: Jim Tobias
Date: Wed, Mar 28 2007 6:10 AM
Subject: Re: possible need for another provision

Nick wrote:
> 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?

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.

From: Tom Brett
Date: Wed, Mar 28 2007 6:35 AM
Subject: Re: possible need for another provision

Knowing how Government Help Desks operate I would concur that users of AT
would probably require admin rights to their system. This, however, could
cause major security headaches within the agency. Generally speaking user's
PCs are locked down so that little or no changes can be made to the system
without assistance from the Help Desk.

It would seem to me that accessibility would need to be weighed against the
agency security policy. In all likelihood security would win. That being
said perhaps there is a need to strengthen the provision that deals with
Help Desk support 1194.41(c).

The configuration changes that I have had to make to my own system to
accommodate AT is repetitive process. The Help Desk Technician will need to
be knowledgeable not only in the OS and its accessibility functions but also
the AT that is being used.

Tom Brett


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Truesdell
Nick
Sent: Tuesday, March 27, 2007 3:48 PM
To: TEITAC documentation and technical support subcommittee
Subject: Re: [teitac-documentation] possible need for another provision

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

From: David Poehlman
Date: Wed, Mar 28 2007 9:45 AM
Subject: Re: possible need for another provision

I usually win when I fight this.

On Mar 28, 2007, at 9:32 AM, Tom Brett wrote:

Knowing how Government Help Desks operate I would concur that users
of AT
would probably require admin rights to their system. This, however,
could
cause major security headaches within the agency. Generally speaking
user's
PCs are locked down so that little or no changes can be made to the
system
without assistance from the Help Desk.

It would seem to me that accessibility would need to be weighed
against the
agency security policy. In all likelihood security would win. That
being
said perhaps there is a need to strengthen the provision that deals with
Help Desk support 1194.41(c).

The configuration changes that I have had to make to my own system to
accommodate AT is repetitive process. The Help Desk Technician will
need to
be knowledgeable not only in the OS and its accessibility functions
but also
the AT that is being used.

Tom Brett


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Truesdell
Nick
Sent: Tuesday, March 27, 2007 3:48 PM
To: TEITAC documentation and technical support subcommittee
Subject: Re: [teitac-documentation] possible need for another provision

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