Thread Subject: Re: AT Interoperability

Return to this mailing list's archives

From: Hoffman, Allen
Date: Tue, Aug 14 2007 10:50 AM
Subject: Re: AT Interoperability

Gregg wrote:

"1) Does this provision require that software actually work with
assistive technology?"

No. That is the end goal, but not the specific requirement for this
provision from my reading.





Gregg continued:

"2) Or does it only require that information be provided that AT could
work with?"

Yes. From my reading.





Gregg continues:

"3) Could someone sell something to the government that met this
provision - but where there was no assistive technology available for
one or all disability groups? "



Yes. The government needs to identify business needs that extend to
this situation I believe.







Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

From: Peter Korn
Date: Tue, Aug 14 2007 11:25 AM
Subject: Re: AT Interoperability

Hi Gregg,

We have more or less come to the consensus that we don't want to write
specific provisions for assistive technologies (e.g. requiring that AT
purchased by the government must implement support for platform
accessibility services, let alone any API that any application chooses
to invent and use). Unless that changes, we cannot insist that AT and IT
must work together. Further, we cannot tell IT that it has the sole,
unshared burden of working with AT.

I feel this provision is nearly the best that is possible within those
constraints. Pushing IT to use platform accessibility services where
they exist (and by implication encouraging platforms to define and
promulgate such services) will go a long way to improving AT-IT
interoperability.

But at AT and IT typically come from different companies, there is no
way one can control the other. And since government-wide regulations
like 508 must be technology neutral, 508 itself cannot say "your IT must
work with the Gregorian Screen Reader". Individual agencies can (and
do!) do that, but that is part of how they define their business need.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> I can't tell from the current language.
>
> 1) Does this provision require that software actually work with
> assistive technology?
>
> 2) Or does it only require that information be provided that AT could
> work with?
>
> 3) Could someone sell something to the government that met this
> provision – but where there was no assistive technology available for
> one or all disability groups?
>
> Thanks
>
>
> Gregg
>
> ------------------------
>
> Gregg C Vanderheiden Ph.D.
> Professor - Depts of Ind. Engr. & BioMed Engr.
> Director - Trace R & D Center
> University of Wisconsin-Madison
> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>
> DSS Player at http://tinyurl.com/dho6b
>
> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>
> <http://trace.wisc.edu:8080/mailman/listinfo/>
>
> ------------------------------------------------------------------------
>
>

From: Hoffman, Allen
Date: Tue, Aug 14 2007 11:30 AM
Subject: Re: AT Interoperability

Thanks Peter, you summarized this better than I and I concur with all of
it.



Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Tuesday, August 14, 2007 1:21 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] AT Interoperability

Hi Gregg,

We have more or less come to the consensus that we don't want to write
specific provisions for assistive technologies (e.g. requiring that AT
purchased by the government must implement support for platform
accessibility services, let alone any API that any application chooses
to invent and use). Unless that changes, we cannot insist that AT and IT
must work together. Further, we cannot tell IT that it has the sole,
unshared burden of working with AT.

I feel this provision is nearly the best that is possible within those
constraints. Pushing IT to use platform accessibility services where
they exist (and by implication encouraging platforms to define and
promulgate such services) will go a long way to improving AT-IT
interoperability.

But at AT and IT typically come from different companies, there is no
way one can control the other. And since government-wide regulations
like 508 must be technology neutral, 508 itself cannot say "your IT must
work with the Gregorian Screen Reader". Individual agencies can (and
do!) do that, but that is part of how they define their business need.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> I can't tell from the current language.
>
> 1) Does this provision require that software actually work with
> assistive technology?
>
> 2) Or does it only require that information be provided that AT could
> work with?
>
> 3) Could someone sell something to the government that met this
> provision - but where there was no assistive technology available for
> one or all disability groups?
>
> Thanks
>
>
> Gregg
>
> ------------------------
>
> Gregg C Vanderheiden Ph.D.
> Professor - Depts of Ind. Engr. & BioMed Engr.
> Director - Trace R & D Center
> University of Wisconsin-Madison
> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>
> DSS Player at http://tinyurl.com/dho6b
>
> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>
> <http://trace.wisc.edu:8080/mailman/listinfo/>
>
> ----------------------------------------------------------------------
> --
>
>

From: Debbie Cook
Date: Tue, Aug 14 2007 12:05 PM
Subject: Re: AT Interoperability

OK I'm extremely concerned about this proposal. Concern is greater because,
at the same time, it is proposed to reduce the Functional Performance
Criteria to something lokie philosophy rather than requirement applicable to
all.
So, taken together with the proposal for interoperability, it really does
appear to me that products which could theoretically have AT support but
don't, would be equally compliant with those that have AT support. Where is
the incentive there? More important, where is any accessibility? I really
fail to see how the end user gains from this.
I could live with the concept of the API being adequate if the final test
would be the FPC. But that appears to be going away or significantly
weakened based on discussions at General.
So, my concern remains that products which are not accessible to consumers
with disabilities will pass with equal status as those which are. And
agencies, woh may lack the expertise to discern all the nuances will
purchase those that do not as readily as those that do.
This is a pretty fundamental change in the construct of Section 508 with
huge implications.
----- Original Message -----
From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, August 14, 2007 10:20 AM
Subject: Re: [teitac-websoftware] AT Interoperability


Hi Gregg,

We have more or less come to the consensus that we don't want to write
specific provisions for assistive technologies (e.g. requiring that AT
purchased by the government must implement support for platform
accessibility services, let alone any API that any application chooses
to invent and use). Unless that changes, we cannot insist that AT and IT
must work together. Further, we cannot tell IT that it has the sole,
unshared burden of working with AT.

I feel this provision is nearly the best that is possible within those
constraints. Pushing IT to use platform accessibility services where
they exist (and by implication encouraging platforms to define and
promulgate such services) will go a long way to improving AT-IT
interoperability.

But at AT and IT typically come from different companies, there is no
way one can control the other. And since government-wide regulations
like 508 must be technology neutral, 508 itself cannot say "your IT must
work with the Gregorian Screen Reader". Individual agencies can (and
do!) do that, but that is part of how they define their business need.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> I can't tell from the current language.
>
> 1) Does this provision require that software actually work with
> assistive technology?
>
> 2) Or does it only require that information be provided that AT could
> work with?
>
> 3) Could someone sell something to the government that met this
> provision – but where there was no assistive technology available for
> one or all disability groups?
>
> Thanks
>
>
> Gregg
>
> ------------------------
>
> Gregg C Vanderheiden Ph.D.
> Professor - Depts of Ind. Engr. & BioMed Engr.
> Director - Trace R & D Center
> University of Wisconsin-Madison
> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>
> DSS Player at http://tinyurl.com/dho6b
>
> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>
> <http://trace.wisc.edu:8080/mailman/listinfo/>
>
> ------------------------------------------------------------------------
>
>

From: Gregg Vanderheiden
Date: Tue, Aug 14 2007 12:10 PM
Subject: Re: AT Interoperability

I'm sorry

That turned the question around.

Software and OSs also come from different companies. And the government
would never buy and OS that did not run the software they want to use.

Only asking for the same model here.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Tuesday, August 14, 2007 12:21 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] AT Interoperability
>
> Hi Gregg,
>
> We have more or less come to the consensus that we don't want
> to write specific provisions for assistive technologies (e.g.
> requiring that AT purchased by the government must implement
> support for platform accessibility services, let alone any
> API that any application chooses to invent and use). Unless
> that changes, we cannot insist that AT and IT must work
> together. Further, we cannot tell IT that it has the sole,
> unshared burden of working with AT.
>
> I feel this provision is nearly the best that is possible
> within those constraints. Pushing IT to use platform
> accessibility services where they exist (and by implication
> encouraging platforms to define and promulgate such services)
> will go a long way to improving AT-IT interoperability.
>
> But at AT and IT typically come from different companies,
> there is no way one can control the other. And since
> government-wide regulations like 508 must be technology
> neutral, 508 itself cannot say "your IT must work with the
> Gregorian Screen Reader". Individual agencies can (and
> do!) do that, but that is part of how they define their business need.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > I can't tell from the current language.
> >
> > 1) Does this provision require that software actually work with
> > assistive technology?
> >
> > 2) Or does it only require that information be provided
> that AT could
> > work with?
> >
> > 3) Could someone sell something to the government that met this
> > provision - but where there was no assistive technology
> available for
> > one or all disability groups?
> >
> > Thanks
> >
> >
> > Gregg
> >
> > ------------------------
> >
> > Gregg C Vanderheiden Ph.D.
> > Professor - Depts of Ind. Engr. & BioMed Engr.
> > Director - Trace R & D Center
> > University of Wisconsin-Madison
> > _<http://trace.wisc.edu/>_ FAX 608/262-8848
> >
> > DSS Player at http://tinyurl.com/dho6b
> >
> > If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
> >
> > <http://trace.wisc.edu:8080/mailman/listinfo/>
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> >

From: Gregg Vanderheiden
Date: Tue, Aug 14 2007 12:35 PM
Subject: AT Interoperability

I can't tell from the current language.



1) Does this provision require that software actually work with assistive
technology?

2) Or does it only require that information be provided that AT could work
with?

3) Could someone sell something to the government that met this provision -
but where there was no assistive technology available for one or all
disability groups?





Thanks




Gregg

------------------------

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at http://tinyurl.com/dho6b

If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

<http://trace.wisc.edu:8080/mailman/listinfo/>

From: Gregg Vanderheiden
Date: Tue, Aug 14 2007 12:40 PM
Subject: Re: AT Interoperability

Not sure I understand Allen.



Are you saying that products for which there is no AT should qualify as
"accessible via AT" as long as there is an API?



So if the government had two systems -

- one supported by AT

- the other with no AT available - but it had an API

both would pass 508 and the government could buy and deploy them even though
they could not be used by employees with disabilities that needed AT?



You mention - business need. But if you don't have a person with that
particular disability in your agency right now (or in that position) - then
you wouldn't have a business need and the position would then not be doable
in the future. No?



Maybe I am misunderstanding you. Can you clarify?



Thanks




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: Tuesday, August 14, 2007 11:37 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] AT Interoperability

Gregg wrote:

"1) Does this provision require that software actually work with assistive
technology?"

No. That is the end goal, but not the specific requirement for this
provision from my reading.





Gregg continued:

"2) Or does it only require that information be provided that AT could work
with?"

Yes. From my reading.





Gregg continues:

"3) Could someone sell something to the government that met this provision -
but where there was no assistive technology available for one or all
disability groups? "



Yes. The government needs to identify business needs that extend to this
situation I believe.







Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Tuesday, August 14, 2007 12:06 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: [teitac-websoftware] AT Interoperability



I can't tell from the current language.



1) Does this provision require that software actually work with assistive
technology?

2) Or does it only require that information be provided that AT could work
with?

3) Could someone sell something to the government that met this provision -
but where there was no assistive technology available for one or all
disability groups?





Thanks




Gregg

------------------------

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at http://tinyurl.com/dho6b

If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

<http://trace.wisc.edu:8080/mailman/listinfo/>

From: Peter Korn
Date: Tue, Aug 14 2007 1:00 PM
Subject: Re: AT Interoperability

Hi Debbie,

What specifically do you propose?

You wrote "it really does appear to me that products which could
theoretically have AT support but don't, would be equally compliant with
those that have AT support." What does "have AT support" mean? That a
single assistive technology vendor has taken the time to reverse
engineer the product to make their AT work with it? 3 AT vendors? One
in each AT area? And in all of these cases, what has the IT product
done - other than be popular enough to get the attention of AT vendors -
in order to make itself work with AT?

Here are the constraints as I see them:
1. We must have criteria that are testable; we don't know how to test
"usability" (in any field, let alone accessibility)
2. We cannot require party A (e.g. industry) to guarantee the
functionality from a product from party B (e.g. AT) that it doesn't control
3. We want to improve AT-IT interoperability, and move the AT/IT
industry away from their history (by necessity) of reverse engineering
for access and to supported techniques for access

Do you disagree with these constraints?

As has been discussed in the General SC and in other places, the FPC as
written aren't testable. It was also noted several times (including on
the General SC call earlier this week) that agencies don't try to test
against the FPC - the direction is to use the technical provision, and
only go to the FPC when a product isn't covered by the technical
provisions. As such, I don't see a change in implementation in what we
are doing (clarify that the FPC aren't testable); rather it is a formal
recognition of the reality of application. As such, we can deal with
the situation more explicitly, and move to test what can be tested.

To your question about "where is the incentive?" I see this language as
providing three incentives:
1. Incentive for IT to use platform accessibility services, or some
other means "...to cooperate with AT..."
2. Incentive for a platform to define such services
3. Incentive for AT to use this information - because it has been
called out

Perhaps These incentives could be made stronger. But please note that
AT as long said that they want this kind of information, that it makes
their lives easier if they have it, and that they use it where they can.

The language also makes a very clear and unambiguous enumeration of the
minimum information IT should provide to AT. We have never had that before.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> OK I'm extremely concerned about this proposal. Concern is greater because,
> at the same time, it is proposed to reduce the Functional Performance
> Criteria to something lokie philosophy rather than requirement applicable to
> all.
> So, taken together with the proposal for interoperability, it really does
> appear to me that products which could theoretically have AT support but
> don't, would be equally compliant with those that have AT support. Where is
> the incentive there? More important, where is any accessibility? I really
> fail to see how the end user gains from this.
> I could live with the concept of the API being adequate if the final test
> would be the FPC. But that appears to be going away or significantly
> weakened based on discussions at General.
> So, my concern remains that products which are not accessible to consumers
> with disabilities will pass with equal status as those which are. And
> agencies, woh may lack the expertise to discern all the nuances will
> purchase those that do not as readily as those that do.
> This is a pretty fundamental change in the construct of Section 508 with
> huge implications.
> ----- Original Message -----
> From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
> To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, August 14, 2007 10:20 AM
> Subject: Re: [teitac-websoftware] AT Interoperability
>
>
> Hi Gregg,
>
> We have more or less come to the consensus that we don't want to write
> specific provisions for assistive technologies (e.g. requiring that AT
> purchased by the government must implement support for platform
> accessibility services, let alone any API that any application chooses
> to invent and use). Unless that changes, we cannot insist that AT and IT
> must work together. Further, we cannot tell IT that it has the sole,
> unshared burden of working with AT.
>
> I feel this provision is nearly the best that is possible within those
> constraints. Pushing IT to use platform accessibility services where
> they exist (and by implication encouraging platforms to define and
> promulgate such services) will go a long way to improving AT-IT
> interoperability.
>
> But at AT and IT typically come from different companies, there is no
> way one can control the other. And since government-wide regulations
> like 508 must be technology neutral, 508 itself cannot say "your IT must
> work with the Gregorian Screen Reader". Individual agencies can (and
> do!) do that, but that is part of how they define their business need.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>> I can't tell from the current language.
>>
>> 1) Does this provision require that software actually work with
>> assistive technology?
>>
>> 2) Or does it only require that information be provided that AT could
>> work with?
>>
>> 3) Could someone sell something to the government that met this
>> provision – but where there was no assistive technology available for
>> one or all disability groups?
>>
>> Thanks
>>
>>
>> Gregg
>>
>> ------------------------
>>
>> Gregg C Vanderheiden Ph.D.
>> Professor - Depts of Ind. Engr. & BioMed Engr.
>> Director - Trace R & D Center
>> University of Wisconsin-Madison
>> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>>
>> DSS Player at http://tinyurl.com/dho6b
>>
>> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>>
>> <http://trace.wisc.edu:8080/mailman/listinfo/>
>>
>> ------------------------------------------------------------------------
>>
>>

From: Peter Korn
Date: Tue, Aug 14 2007 1:10 PM
Subject: Re: AT Interoperability

Hi Randy,

The "consensus" I was referring to was that we weren't going to require
AT to support an API, or make any other explicit requirements on AT in
Section 508. This was something I understood was particularly important
to ATIA. What I see you saying now, below, is that you hope to be able
to change the wording of Section 508 to place a requirement on AT (you
wrote: 'Someday, I hope we will be able to change the wording of Section
508 to say something like "AT and IT products must conform to the
ABC123XXX interoperability standard".'). Doing that would essentially
mean that AT that didn't conform to your theoretical ABC123XXX
interoperability standard could NOT be acquired by agencies under 508.

You also wrote (below): "Section 508 doesn't have to tell the AT and IT
industries /how/ they should cooperate - only that it is necessary. Let
the two industries work it out from there." Section 508's testable,
technical provisions have to include a "how". Otherwise they aren't
testable. An agency can't know whether a product did or did not meet
the provision. In the non-testable FPC we can note that cooperation
"should" happen. But agencies cannot test against something like that
(how does an agency know whether cooperation happened or not? how much
cooperation is sufficient for a test? what about AT and IT that work
together even though no formal cooperation occurred)?

One thing I argued for was that we enumerate a set of sufficient
techniques for each platform, where we would be able to say something
closer to your "conform to the ABC123XXX interoperability standard" -
specifically we could identify that on Windows, Macintosh, and UNIX, the
defined platform accessibility services are XXX, YYY, ZZZ, and
implementing support for them is sufficient (but not the only way) to
meet this standard. We should further have a means of adding to that
list over time.

That route was objected to on multiple grounds. But without something
like that, and without a formal recognition that Section 508 must apply
to AT, and without placing a formal burden on AT to work with IT (if we
place a formal burden on IT to work with AT), then I don't see what more
we can do here.


What, specifically, do you suggest we do for this revision of 508?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> I'm sorry, but I don't concur.
>
> I may have missed the meeting where the "consensus" Peter refers to
> was reached, but this definitely is not the way AT sees things. If
> you remove the the requirement for IT to actually work with AT, then
> what's the point? You will end up with IT products that meet Section
> 508, but that people with disabilities still can't use.
>
> We agreed that we can't make lists of AT products that IT must be
> compatible with, nor can we create an API as part of Section 508. But
> that doesn't mean we're saying interoperability between AT and IT is
> not a requirement. Until we have actual technical interoperability
> standards that we can point to and test against, references to the
> interaction between IT and AT must necessarily remain vague. But that
> vagueness should not be extended to the point where IT is only
> required to design what they consider to be an interoperability
> gateway, but not be required to ensure that their products actually
> work with AT.
>
> Someday, I hope we will be able to change the wording of Section 508
> to say something like "AT and IT products must conform to the
> ABC123XXX interoperability standard". But until that technical
> standard(s) exists, all we can do is express the notion in general
> terms that AT and IT must work together, but not spell out how that is
> done. From AT's standpoint, we hope it is done through mutual
> cooperation between AT and IT companies, through developing standards,
> and through the prodding of laws such as Section 508 that should
> encourage (not discourage) such cooperation. Section 508 doesn't have
> to tell the AT and IT industries /how/ they should cooperate - only
> that it is necessary. Let the two industries work it out from there.
>
> -Randy Marsden
> Assistive Technology Industry Association (ATIA)
>
>
> On Aug 14, 2007, at 11:22 AM, Hoffman, Allen wrote:
>
>> Thanks Peter, you summarized this better than I and I concur with all of
>> it.
>>
>>
>>
>> Allen Hoffman -- = EMAIL ADDRESS REMOVED =
>> <mailto: = EMAIL ADDRESS REMOVED = >; v: 202-447-0303
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> <mailto: = EMAIL ADDRESS REMOVED = >
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
>> Korn
>> Sent: Tuesday, August 14, 2007 1:21 PM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] AT Interoperability
>>
>> Hi Gregg,
>>
>> We have more or less come to the consensus that we don't want to write
>> specific provisions for assistive technologies (e.g. requiring that AT
>> purchased by the government must implement support for platform
>> accessibility services, let alone any API that any application chooses
>> to invent and use). Unless that changes, we cannot insist that AT and IT
>> must work together. Further, we cannot tell IT that it has the sole,
>> unshared burden of working with AT.
>>
>> I feel this provision is nearly the best that is possible within those
>> constraints. Pushing IT to use platform accessibility services where
>> they exist (and by implication encouraging platforms to define and
>> promulgate such services) will go a long way to improving AT-IT
>> interoperability.
>>
>> But at AT and IT typically come from different companies, there is no
>> way one can control the other. And since government-wide regulations
>> like 508 must be technology neutral, 508 itself cannot say "your IT must
>> work with the Gregorian Screen Reader". Individual agencies can (and
>> do!) do that, but that is part of how they define their business need.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>
> Randy Marsden
> President, Madentec Limited
> Tel: 780-450-8926 Ext. 223
> Fax: 780-988-6182
> = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>
>
>
> ------------------------------------------------------------------------
>
>

From: Hoffman, Allen
Date: Tue, Aug 14 2007 1:20 PM
Subject: Re: AT Interoperability

I have to disagree with this.

I believe Section 508 does need to more clearly define what cooperation
and interoperability between IT and AT means, when possible. Debbie
Cook's point about this potentially being problematic if functional
performance criteria are weakened significantly is valid also. I
support creating more clear AT/IT interoperability requirements that are
incremental, E.G. vendors can meet portions and those who meet more get
more points at evaluation time, and then applying that principle to IT
vendors for all IT products including platforms, software applications,
and AT. This implies that, for example, platform vendors should be
evaluated upon the availability of accessibility services, applications
evaluated upon inclusion of accessibility services for At and from the
platforms they support, and AT evaluated against usage of, or equivalent
alternate provisioning of such services as an interoperability equation.
Agencies need to consider their particular business needs for specific
interoperability with specific AT as they must, but unclear requirements
to "work together" are not measurable in my opinion, and won't get used
at evaluation and selection time well.

So, what gaps would fill this in for the web/software to provide a real
continuum?

1. We need a standard to indicate the platforms must provide
"accessibility services", that allow them to meet our interoperability
requirements.

2. We should consider adding a software AT standard that requires use
of such platform accessibility services when available, or equivalent
facilitation of such information.

Finally, when we say programmatically determinable, that may be AT, but
does not have to be.

Let me provide an example as illustration.

Agency needs to procure an item which is a combination of platform and
application:

Vendor 1 meets platform standards, and application meets application
requirements, but there is no At that meets requirements for this
platform. The seller of the "solution" would then respond to all three
sets of requirements. In this simplistic case would get 2 of 3. The
product fails several functional performance criteria because the AT
doesn't get them there.

Vendor two fails platform standards, fails application requirements, but
passes At requirements because some very specialized At exists to
provide this level of access for one group via equivalent facilitation.
They would get 1 of 3, but the FPC might be higher and evens out.

Vendor three meets all standards and gets 3 of 3 and meets the FPC, so
wins.

This situation is exactly why the "best meets" language is in the
standard in subpart A, do allow agencies to have some leeway to select
the items that do in reality do what is needed, which is work for people
with disabilities. I don't believe there is a simple way to
specifically require that IT work with AT without some generally agreed
upon foundation of roles and responsibilities in the chain.







Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

From: Debbie Cook
Date: Tue, Aug 14 2007 1:35 PM
Subject: Re: AT Interoperability

While I don't think that AT should control IT nor should IT control AT, I do
believe both ought to be expected to comply with reasonable requirements and
constraints. The fact that AT has necessarily reverse engineered itself in
order to work with it does not mean it should be the desired practice of the
future. But the fact that is has had to do this and presumably will continue
to do so is indication that AT compatibility has to somewhere be considered
in the notion of compliance. I think we have to start with the original
intent of section 508. It was not to develop a protocol (although one would
be needed) it was to provide equal access to information for employees and
customers with disabilities. So, while I totally agree that AT cannot run
the show as it were, compatibility with it has to be factored into this
equation somewhere. The bottom line is that two products, one that works
with AT that is likely to be used, and one that does not work with any
available AT, cannot be equally compliant with respect to section 508.
When an agency purchases E&IT that is aledgedly compliant with 508, they
must have a reasonable assurance that when customers and employees with
disabilities come along to use the IT in question, they should be able to
have access to those functions. We can spend a lot of energy on all the
definitions of access etc. but eventually this is all a smoke screen for the
real issue. Will people be able to use, in some comparable form, the
products developed and purchased by the federal government. If we know it's
not compatible with any AT, and we can't reasonably arrange an AT to reverse
engineer itself for compatibility, then compliance serves no one.
All I'm asking for is to have the end user factored into this somehow so
that agencies will know the difference between E&IT that meets a set of
standards, no matter how good those standards are, but for which there is no
way to access the product for some set of individuals who may need that
access.
----- Original Message -----
From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, August 14, 2007 11:57 AM
Subject: Re: [teitac-websoftware] AT Interoperability


Hi Debbie,

What specifically do you propose?

You wrote "it really does appear to me that products which could
theoretically have AT support but don't, would be equally compliant with
those that have AT support." What does "have AT support" mean? That a
single assistive technology vendor has taken the time to reverse
engineer the product to make their AT work with it? 3 AT vendors? One
in each AT area? And in all of these cases, what has the IT product
done - other than be popular enough to get the attention of AT vendors -
in order to make itself work with AT?

Here are the constraints as I see them:
1. We must have criteria that are testable; we don't know how to test
"usability" (in any field, let alone accessibility)
2. We cannot require party A (e.g. industry) to guarantee the
functionality from a product from party B (e.g. AT) that it doesn't control
3. We want to improve AT-IT interoperability, and move the AT/IT
industry away from their history (by necessity) of reverse engineering
for access and to supported techniques for access

Do you disagree with these constraints?

As has been discussed in the General SC and in other places, the FPC as
written aren't testable. It was also noted several times (including on
the General SC call earlier this week) that agencies don't try to test
against the FPC - the direction is to use the technical provision, and
only go to the FPC when a product isn't covered by the technical
provisions. As such, I don't see a change in implementation in what we
are doing (clarify that the FPC aren't testable); rather it is a formal
recognition of the reality of application. As such, we can deal with
the situation more explicitly, and move to test what can be tested.

To your question about "where is the incentive?" I see this language as
providing three incentives:
1. Incentive for IT to use platform accessibility services, or some
other means "...to cooperate with AT..."
2. Incentive for a platform to define such services
3. Incentive for AT to use this information - because it has been
called out

Perhaps These incentives could be made stronger. But please note that
AT as long said that they want this kind of information, that it makes
their lives easier if they have it, and that they use it where they can.

The language also makes a very clear and unambiguous enumeration of the
minimum information IT should provide to AT. We have never had that before.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> OK I'm extremely concerned about this proposal. Concern is greater
> because,
> at the same time, it is proposed to reduce the Functional Performance
> Criteria to something lokie philosophy rather than requirement applicable
> to
> all.
> So, taken together with the proposal for interoperability, it really does
> appear to me that products which could theoretically have AT support but
> don't, would be equally compliant with those that have AT support. Where
> is
> the incentive there? More important, where is any accessibility? I really
> fail to see how the end user gains from this.
> I could live with the concept of the API being adequate if the final test
> would be the FPC. But that appears to be going away or significantly
> weakened based on discussions at General.
> So, my concern remains that products which are not accessible to consumers
> with disabilities will pass with equal status as those which are. And
> agencies, woh may lack the expertise to discern all the nuances will
> purchase those that do not as readily as those that do.
> This is a pretty fundamental change in the construct of Section 508 with
> huge implications.
> ----- Original Message -----
> From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
> To: "TEITAC Web/Software Subcommittee"
> < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, August 14, 2007 10:20 AM
> Subject: Re: [teitac-websoftware] AT Interoperability
>
>
> Hi Gregg,
>
> We have more or less come to the consensus that we don't want to write
> specific provisions for assistive technologies (e.g. requiring that AT
> purchased by the government must implement support for platform
> accessibility services, let alone any API that any application chooses
> to invent and use). Unless that changes, we cannot insist that AT and IT
> must work together. Further, we cannot tell IT that it has the sole,
> unshared burden of working with AT.
>
> I feel this provision is nearly the best that is possible within those
> constraints. Pushing IT to use platform accessibility services where
> they exist (and by implication encouraging platforms to define and
> promulgate such services) will go a long way to improving AT-IT
> interoperability.
>
> But at AT and IT typically come from different companies, there is no
> way one can control the other. And since government-wide regulations
> like 508 must be technology neutral, 508 itself cannot say "your IT must
> work with the Gregorian Screen Reader". Individual agencies can (and
> do!) do that, but that is part of how they define their business need.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>> I can't tell from the current language.
>>
>> 1) Does this provision require that software actually work with
>> assistive technology?
>>
>> 2) Or does it only require that information be provided that AT could
>> work with?
>>
>> 3) Could someone sell something to the government that met this
>> provision – but where there was no assistive technology available for
>> one or all disability groups?
>>
>> Thanks
>>
>>
>> Gregg
>>
>> ------------------------
>>
>> Gregg C Vanderheiden Ph.D.
>> Professor - Depts of Ind. Engr. & BioMed Engr.
>> Director - Trace R & D Center
>> University of Wisconsin-Madison
>> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>>
>> DSS Player at http://tinyurl.com/dho6b
>>
>> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>>
>> <http://trace.wisc.edu:8080/mailman/listinfo/>
>>
>> ------------------------------------------------------------------------
>>
>>

From: Brad Hodges
Date: Tue, Aug 14 2007 1:40 PM
Subject: Re: AT Interoperability

Greetings:

I echo these concerns. Such a fundamental shift is not acceptable.



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie
Cook
Sent: Tuesday, August 14, 2007 2:02 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] AT Interoperability

OK I'm extremely concerned about this proposal. Concern is greater
because,
at the same time, it is proposed to reduce the Functional Performance
Criteria to something lokie philosophy rather than requirement
applicable to
all.
So, taken together with the proposal for interoperability, it really
does
appear to me that products which could theoretically have AT support but

don't, would be equally compliant with those that have AT support. Where
is
the incentive there? More important, where is any accessibility? I
really
fail to see how the end user gains from this.
I could live with the concept of the API being adequate if the final
test
would be the FPC. But that appears to be going away or significantly
weakened based on discussions at General.
So, my concern remains that products which are not accessible to
consumers
with disabilities will pass with equal status as those which are. And
agencies, woh may lack the expertise to discern all the nuances will
purchase those that do not as readily as those that do.
This is a pretty fundamental change in the construct of Section 508 with

huge implications.
----- Original Message -----
From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, August 14, 2007 10:20 AM
Subject: Re: [teitac-websoftware] AT Interoperability


Hi Gregg,

We have more or less come to the consensus that we don't want to write
specific provisions for assistive technologies (e.g. requiring that AT
purchased by the government must implement support for platform
accessibility services, let alone any API that any application chooses
to invent and use). Unless that changes, we cannot insist that AT and IT
must work together. Further, we cannot tell IT that it has the sole,
unshared burden of working with AT.

I feel this provision is nearly the best that is possible within those
constraints. Pushing IT to use platform accessibility services where
they exist (and by implication encouraging platforms to define and
promulgate such services) will go a long way to improving AT-IT
interoperability.

But at AT and IT typically come from different companies, there is no
way one can control the other. And since government-wide regulations
like 508 must be technology neutral, 508 itself cannot say "your IT must
work with the Gregorian Screen Reader". Individual agencies can (and
do!) do that, but that is part of how they define their business need.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> I can't tell from the current language.
>
> 1) Does this provision require that software actually work with
> assistive technology?
>
> 2) Or does it only require that information be provided that AT could
> work with?
>
> 3) Could someone sell something to the government that met this
> provision - but where there was no assistive technology available for
> one or all disability groups?
>
> Thanks
>
>
> Gregg
>
> ------------------------
>
> Gregg C Vanderheiden Ph.D.
> Professor - Depts of Ind. Engr. & BioMed Engr.
> Director - Trace R & D Center
> University of Wisconsin-Madison
> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>
> DSS Player at http://tinyurl.com/dho6b
>
> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>
> <http://trace.wisc.edu:8080/mailman/listinfo/>
>
>
------------------------------------------------------------------------
>
>

From: Randy Marsden
Date: Tue, Aug 14 2007 1:45 PM
Subject: Re: AT Interoperability

I'm sorry, but I don't concur.

I may have missed the meeting where the "consensus" Peter refers to
was reached, but this definitely is not the way AT sees things. If
you remove the the requirement for IT to actually work with AT, then
what's the point? You will end up with IT products that meet Section
508, but that people with disabilities still can't use.

We agreed that we can't make lists of AT products that IT must be
compatible with, nor can we create an API as part of Section 508.
But that doesn't mean we're saying interoperability between AT and IT
is not a requirement. Until we have actual technical
interoperability standards that we can point to and test against,
references to the interaction between IT and AT must necessarily
remain vague. But that vagueness should not be extended to the point
where IT is only required to design what they consider to be an
interoperability gateway, but not be required to ensure that their
products actually work with AT.

Someday, I hope we will be able to change the wording of Section 508
to say something like "AT and IT products must conform to the
ABC123XXX interoperability standard". But until that technical
standard(s) exists, all we can do is express the notion in general
terms that AT and IT must work together, but not spell out how that
is done. From AT's standpoint, we hope it is done through mutual
cooperation between AT and IT companies, through developing
standards, and through the prodding of laws such as Section 508 that
should encourage (not discourage) such cooperation. Section 508
doesn't have to tell the AT and IT industries how they should
cooperate - only that it is necessary. Let the two industries work
it out from there.

-Randy Marsden
Assistive Technology Industry Association (ATIA)


On Aug 14, 2007, at 11:22 AM, Hoffman, Allen wrote:

> Thanks Peter, you summarized this better than I and I concur with
> all of
> it.
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
> Korn
> Sent: Tuesday, August 14, 2007 1:21 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] AT Interoperability
>
> Hi Gregg,
>
> We have more or less come to the consensus that we don't want to write
> specific provisions for assistive technologies (e.g. requiring that AT
> purchased by the government must implement support for platform
> accessibility services, let alone any API that any application chooses
> to invent and use). Unless that changes, we cannot insist that AT
> and IT
> must work together. Further, we cannot tell IT that it has the sole,
> unshared burden of working with AT.
>
> I feel this provision is nearly the best that is possible within those
> constraints. Pushing IT to use platform accessibility services where
> they exist (and by implication encouraging platforms to define and
> promulgate such services) will go a long way to improving AT-IT
> interoperability.
>
> But at AT and IT typically come from different companies, there is no
> way one can control the other. And since government-wide regulations
> like 508 must be technology neutral, 508 itself cannot say "your IT
> must
> work with the Gregorian Screen Reader". Individual agencies can (and
> do!) do that, but that is part of how they define their business need.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.

Randy Marsden
President, Madentec Limited
Tel: 780-450-8926 Ext. 223
Fax: 780-988-6182
= EMAIL ADDRESS REMOVED =

From: Randy Marsden
Date: Tue, Aug 14 2007 1:50 PM
Subject: Re: AT Interoperability

That was not the point I was making (but nice try) :-)

My point is that a technical interoperability standard doesn't exist
today. And yet we are trying to come up with something that is
"testable" for interoperability in Section 508. In my opinion, you
can't have one without the other. That's why we are all having such
difficulty with this issue.

My suggestion for something better is that until a generally accepted
technical standard exists, leave it the way it currently is: simply
state that IT should work with AT. Is that vague? Yes. Will it
require interpretation at the agency level? Yes. Is that anything
new? No.


-Randy


On Aug 14, 2007, at 1:04 PM, Peter Korn wrote:

> Hi Randy,
>
> The "consensus" I was referring to was that we weren't going to
> require
> AT to support an API, or make any other explicit requirements on AT in
> Section 508. This was something I understood was particularly
> important
> to ATIA. What I see you saying now, below, is that you hope to be
> able
> to change the wording of Section 508 to place a requirement on AT (you
> wrote: 'Someday, I hope we will be able to change the wording of
> Section
> 508 to say something like "AT and IT products must conform to the
> ABC123XXX interoperability standard".'). Doing that would essentially
> mean that AT that didn't conform to your theoretical ABC123XXX
> interoperability standard could NOT be acquired by agencies under 508.

From: Hoffman, Allen
Date: Tue, Aug 14 2007 1:55 PM
Subject: Re: AT Interoperability

Randy:

I believe testable interoperability standards are available and in place
now--based upon platforms, and we have boiled them down in our
interoperability provision. This is true at least for the platform,
application, and then At areas.




Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

From: Peter Korn
Date: Tue, Aug 14 2007 2:00 PM
Subject: Re: AT Interoperability

Randy,

I'm sorry, but I don't understand what *specifically* you are recommending.

Right now the draft FPC is not testable, and agencies have told us they
don't even try to test it. If we go back to the original FPC which says
"support for AT", then we have something we can test, and with the "AT
Interoperability" provision, we have a specific testable set of
behaviors for IT to do.

Would that satisfy you?

Or, when you say "leave it the way it current is", you mean have no AT
Interoperability provision at all (no enumeration of what IT must
provide at a technical level to AT)?

Or, do you mean we have the current draft FPC, but make it clear that it
is not intended to be a testable provision.


We are trying very hard to come to a close on draft language to send to
the Access Board. In order to move the discussion forward, we need to
be discussing *specific* language suggestions. Otherwise we get nowhere.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> That was not the point I was making (but nice try) :-)
>
> My point is that a technical interoperability standard doesn't exist
> today. And yet we are trying to come up with something that is
> "testable" for interoperability in Section 508. In my opinion, you
> can't have one without the other. That's why we are all having such
> difficulty with this issue.
>
> My suggestion for something better is that until a generally accepted
> technical standard exists, leave it the way it currently is: simply
> state that IT should work with AT. Is that vague? Yes. Will it
> require interpretation at the agency level? Yes. Is that anything
> new? No.
>
>
> -Randy
>
>
> On Aug 14, 2007, at 1:04 PM, Peter Korn wrote:
>
>> Hi Randy,
>>
>>
>> The "consensus" I was referring to was that we weren't going to require
>>
>> AT to support an API, or make any other explicit requirements on AT in
>>
>> Section 508. This was something I understood was particularly important
>>
>> to ATIA. What I see you saying now, below, is that you hope to be able
>>
>> to change the wording of Section 508 to place a requirement on AT (you
>>
>> wrote: 'Someday, I hope we will be able to change the wording of Section
>>
>> 508 to say something like "AT and IT products must conform to the
>>
>> ABC123XXX interoperability standard".'). Doing that would essentially
>>
>> mean that AT that didn't conform to your theoretical ABC123XXX
>>
>> interoperability standard could NOT be acquired by agencies under 508.
>>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>

From: Peter Korn
Date: Tue, Aug 14 2007 2:30 PM
Subject: Re: AT Interoperability

Hi Debbie,

> While I don't think that AT should control IT nor should IT control AT, I do
> believe both ought to be expected to comply with reasonable requirements and
> constraints.

OK. This to me sounds like a suggestion to define some interoperability
layer (which for technical reasons would have to be platform-specific),
and then insist that both IT and AT support it (your "comply"
statement). If AT doesn't do this, then the AT would not meet 508,
correct? The AT-IT interoperability provision that we have now goes as
far as we know how to do this in a technology/platform-neutral fashion,
and places the burden solely on IT to provide that information.

> The fact that AT has necessarily reverse engineered itself in
> order to work with it does not mean it should be the desired practice of the
> future. But the fact that is has had to do this and presumably will continue
> to do so is indication that AT compatibility has to somewhere be considered
> in the notion of compliance.

I'm sorry, but here I disagree. Actual, tested compatibility with
specific AT isn't compliance to a standard. It is compliance to a
specific version of specific AT on a specific platform. If/when that AT
changes, it potentially throws my application "out of compliance". E.g.
one version of JAWS had pretty good support for Java. A later release of
JAWS introduced bugs that broke that support for Java. So one day Java
is "compliant", and then the next it isn't, with *no* change in Java.
How can this be right?

> I think we have to start with the original
> intent of section 508. It was not to develop a protocol (although one would
> be needed) it was to provide equal access to information for employees and
> customers with disabilities. So, while I totally agree that AT cannot run
> the show as it were, compatibility with it has to be factored into this
> equation somewhere.

We are absolutely factoring AT compatibility "into this equation
somewhere". The FPC purpose makes this clear, and the AT
Interoperability provision spells it out. What we don't do is make AT
compatibility testable, because we don't know how to do that.

> The bottom line is that two products, one that works
> with AT that is likely to be used, and one that does not work with any
> available AT, cannot be equally compliant with respect to section 508.
> When an agency purchases E&IT that is aledgedly compliant with 508, they
> must have a reasonable assurance that when customers and employees with
> disabilities come along to use the IT in question, they should be able to
> have access to those functions.

There is no way we can do this if we place no requirements under 508 on
AT. If AT is free to do whatever it wants, free to support/not support
any application, platform, API, etc. that it wants, then there is now
way that 508 can be a testable tool to provide reasonable assurance of
access via AT.

We either decide to place requirements on AT, or we go as far as we
possibly can shy of that (with the concerns that you have stated
remaining in place). I believe that the AT Interoperability provisions
do exactly that - the push IT applications as far as can be testable
pushed given those constraints.

> We can spend a lot of energy on all the
> definitions of access etc. but eventually this is all a smoke screen for the
> real issue. Will people be able to use, in some comparable form, the
> products developed and purchased by the federal government. If we know it's
> not compatible with any AT, and we can't reasonably arrange an AT to reverse
> engineer itself for compatibility, then compliance serves no one.
> All I'm asking for is to have the end user factored into this somehow so
> that agencies will know the difference between E&IT that meets a set of
> standards, no matter how good those standards are, but for which there is no
> way to access the product for some set of individuals who may need that
> access.
>

Again, can you propose specific language that addresses these concerns,
and that meets the constraints we are operating under?


I want to point out that at least this Industry representative
recognizes the importance of AT, and because the AT industry has not
found enough of a market/demand/whatever on Solaris and UNIX systems in
general, we have been developing our own AT for our platform. We have a
screen reader that is increasingly offering the kinds of efficiency and
productivity functionality that blind users have come to enjoy with
commercial Windows AT products (custom scripts in the screen reader for
things like e-mail and web browsing and creating/reading office
documents). We have an on-screen keyboard AT that offer an efficient
single switch interface for controlling applications that in my opinion
exceeds similar functionality in Windows AT offerings. And we are
bundling a dynamic text entry application that allow someone who can
only move their eyes to type at 35+ words per minute (into our office
suite, into e-mail, etc.). Oh, and we do this all through a set of
"accessibility services" that are a superset of those specified in the
AT Interoperability draft provision.

As Sun is now also an AT vendor, speaking with that hat on I strongly
believe that addition of the AT Interoperability provision will be a
powerful tool in our discussions with companies that develop software to
run on Solaris (and UNIX in general) - it will be the primary litmus
test for whether they are doing their part to support AT. E.g. when
Adobe updates their PDF Reader for Solaris, agencies will look to see
whether PDF Reader exposes all of the required information via the
Solaris accessibility services. If Adobe Reader does this, it is highly
likely that it will work with our screen reader Orca. And I would
certainly like Adobe to test with Orca; but I wouldn't claim that any
problems found are solely Adobe's responsibility to fix.


Sorry, I'm getting a bit long-winded here. I understand your desire to
have some collection of language/provisions in 508 such that we could
guarantee that IT that complies with that language automatically works
with the AT either in hand or immediately purchasable at the agency.
But I don't see how we can actually do that. And please note, the
existing 508 provisions we've been apply for the last years didn't do so
either.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> ----- Original Message -----
> From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
> To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, August 14, 2007 11:57 AM
> Subject: Re: [teitac-websoftware] AT Interoperability
>
>
> Hi Debbie,
>
> What specifically do you propose?
>
> You wrote "it really does appear to me that products which could
> theoretically have AT support but don't, would be equally compliant with
> those that have AT support." What does "have AT support" mean? That a
> single assistive technology vendor has taken the time to reverse
> engineer the product to make their AT work with it? 3 AT vendors? One
> in each AT area? And in all of these cases, what has the IT product
> done - other than be popular enough to get the attention of AT vendors -
> in order to make itself work with AT?
>
> Here are the constraints as I see them:
> 1. We must have criteria that are testable; we don't know how to test
> "usability" (in any field, let alone accessibility)
> 2. We cannot require party A (e.g. industry) to guarantee the
> functionality from a product from party B (e.g. AT) that it doesn't control
> 3. We want to improve AT-IT interoperability, and move the AT/IT
> industry away from their history (by necessity) of reverse engineering
> for access and to supported techniques for access
>
> Do you disagree with these constraints?
>
> As has been discussed in the General SC and in other places, the FPC as
> written aren't testable. It was also noted several times (including on
> the General SC call earlier this week) that agencies don't try to test
> against the FPC - the direction is to use the technical provision, and
> only go to the FPC when a product isn't covered by the technical
> provisions. As such, I don't see a change in implementation in what we
> are doing (clarify that the FPC aren't testable); rather it is a formal
> recognition of the reality of application. As such, we can deal with
> the situation more explicitly, and move to test what can be tested.
>
> To your question about "where is the incentive?" I see this language as
> providing three incentives:
> 1. Incentive for IT to use platform accessibility services, or some
> other means "...to cooperate with AT..."
> 2. Incentive for a platform to define such services
> 3. Incentive for AT to use this information - because it has been
> called out
>
> Perhaps These incentives could be made stronger. But please note that
> AT as long said that they want this kind of information, that it makes
> their lives easier if they have it, and that they use it where they can.
>
> The language also makes a very clear and unambiguous enumeration of the
> minimum information IT should provide to AT. We have never had that before.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>
>> OK I'm extremely concerned about this proposal. Concern is greater
>> because,
>> at the same time, it is proposed to reduce the Functional Performance
>> Criteria to something lokie philosophy rather than requirement applicable
>> to
>> all.
>> So, taken together with the proposal for interoperability, it really does
>> appear to me that products which could theoretically have AT support but
>> don't, would be equally compliant with those that have AT support. Where
>> is
>> the incentive there? More important, where is any accessibility? I really
>> fail to see how the end user gains from this.
>> I could live with the concept of the API being adequate if the final test
>> would be the FPC. But that appears to be going away or significantly
>> weakened based on discussions at General.
>> So, my concern remains that products which are not accessible to consumers
>> with disabilities will pass with equal status as those which are. And
>> agencies, woh may lack the expertise to discern all the nuances will
>> purchase those that do not as readily as those that do.
>> This is a pretty fundamental change in the construct of Section 508 with
>> huge implications.
>> ----- Original Message -----
>> From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
>> To: "TEITAC Web/Software Subcommittee"
>> < = EMAIL ADDRESS REMOVED = >
>> Sent: Tuesday, August 14, 2007 10:20 AM
>> Subject: Re: [teitac-websoftware] AT Interoperability
>>
>>
>> Hi Gregg,
>>
>> We have more or less come to the consensus that we don't want to write
>> specific provisions for assistive technologies (e.g. requiring that AT
>> purchased by the government must implement support for platform
>> accessibility services, let alone any API that any application chooses
>> to invent and use). Unless that changes, we cannot insist that AT and IT
>> must work together. Further, we cannot tell IT that it has the sole,
>> unshared burden of working with AT.
>>
>> I feel this provision is nearly the best that is possible within those
>> constraints. Pushing IT to use platform accessibility services where
>> they exist (and by implication encouraging platforms to define and
>> promulgate such services) will go a long way to improving AT-IT
>> interoperability.
>>
>> But at AT and IT typically come from different companies, there is no
>> way one can control the other. And since government-wide regulations
>> like 508 must be technology neutral, 508 itself cannot say "your IT must
>> work with the Gregorian Screen Reader". Individual agencies can (and
>> do!) do that, but that is part of how they define their business need.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>
>>
>>> I can't tell from the current language.
>>>
>>> 1) Does this provision require that software actually work with
>>> assistive technology?
>>>
>>> 2) Or does it only require that information be provided that AT could
>>> work with?
>>>
>>> 3) Could someone sell something to the government that met this
>>> provision – but where there was no assistive technology available for
>>> one or all disability groups?
>>>
>>> Thanks
>>>
>>>
>>> Gregg
>>>
>>> ------------------------
>>>
>>> Gregg C Vanderheiden Ph.D.
>>> Professor - Depts of Ind. Engr. & BioMed Engr.
>>> Director - Trace R & D Center
>>> University of Wisconsin-Madison
>>> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>>>
>>> DSS Player at http://tinyurl.com/dho6b
>>>
>>> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>>>
>>> <http://trace.wisc.edu:8080/mailman/listinfo/>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>

From: Debbie Cook
Date: Tue, Aug 14 2007 2:40 PM
Subject: Re: AT Interoperability

Yes, I would certainly consider a continuem that looks like what Alan
proposes below. Assists agencies to determine "best meets" and addresses my
concern that all efforts do not yield equal re3sults for the end user.
----- Original Message -----
From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, August 14, 2007 12:16 PM
Subject: Re: [teitac-websoftware] AT Interoperability


I have to disagree with this.

I believe Section 508 does need to more clearly define what cooperation
and interoperability between IT and AT means, when possible. Debbie
Cook's point about this potentially being problematic if functional
performance criteria are weakened significantly is valid also. I
support creating more clear AT/IT interoperability requirements that are
incremental, E.G. vendors can meet portions and those who meet more get
more points at evaluation time, and then applying that principle to IT
vendors for all IT products including platforms, software applications,
and AT. This implies that, for example, platform vendors should be
evaluated upon the availability of accessibility services, applications
evaluated upon inclusion of accessibility services for At and from the
platforms they support, and AT evaluated against usage of, or equivalent
alternate provisioning of such services as an interoperability equation.
Agencies need to consider their particular business needs for specific
interoperability with specific AT as they must, but unclear requirements
to "work together" are not measurable in my opinion, and won't get used
at evaluation and selection time well.

So, what gaps would fill this in for the web/software to provide a real
continuum?

1. We need a standard to indicate the platforms must provide
"accessibility services", that allow them to meet our interoperability
requirements.

2. We should consider adding a software AT standard that requires use
of such platform accessibility services when available, or equivalent
facilitation of such information.

Finally, when we say programmatically determinable, that may be AT, but
does not have to be.

Let me provide an example as illustration.

Agency needs to procure an item which is a combination of platform and
application:

Vendor 1 meets platform standards, and application meets application
requirements, but there is no At that meets requirements for this
platform. The seller of the "solution" would then respond to all three
sets of requirements. In this simplistic case would get 2 of 3. The
product fails several functional performance criteria because the AT
doesn't get them there.

Vendor two fails platform standards, fails application requirements, but
passes At requirements because some very specialized At exists to
provide this level of access for one group via equivalent facilitation.
They would get 1 of 3, but the FPC might be higher and evens out.

Vendor three meets all standards and gets 3 of 3 and meets the FPC, so
wins.

This situation is exactly why the "best meets" language is in the
standard in subpart A, do allow agencies to have some leeway to select
the items that do in reality do what is needed, which is work for people
with disabilities. I don't believe there is a simple way to
specifically require that IT work with AT without some generally agreed
upon foundation of roles and responsibilities in the chain.







Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

From: Gregg Vanderheiden
Date: Tue, Aug 14 2007 3:10 PM
Subject: Re: AT Interoperability

In WCAG we use terms in the provisions ("programmatically determined") that
are tied to conformance requirement terminology "accessibility supported"
such that Web technologies (or features of them) can only be used to conform
to WCAG if the technologies/features are in fact supported by AT and access
features of user agents.

One can argue that this means that a vendor could have trouble selling the
government E&IT if they didn't have AT supporting them.

That is good. At least it is what 508 is supposed to do. It is supposed
to cause the government to purchase products that their employees with
disabilities can use. If there is no AT they cannot use them, even if
there is an API.

If the choice is between two products and there is no built in access and no
AT for either - then the government should purchase the one with the API
since there is better hope that someday it would be accessible. But neither
should pass 508 since neither is useable by the government employees.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Tuesday, August 14, 2007 1:57 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] AT Interoperability
>
> Hi Debbie,
>
> What specifically do you propose?
>
> You wrote "it really does appear to me that products which
> could theoretically have AT support but don't, would be
> equally compliant with those that have AT support." What
> does "have AT support" mean? That a single assistive
> technology vendor has taken the time to reverse engineer the
> product to make their AT work with it? 3 AT vendors? One in
> each AT area? And in all of these cases, what has the IT
> product done - other than be popular enough to get the
> attention of AT vendors - in order to make itself work with AT?
>
> Here are the constraints as I see them:
> 1. We must have criteria that are testable; we don't know
> how to test "usability" (in any field, let alone
> accessibility) 2. We cannot require party A (e.g. industry)
> to guarantee the functionality from a product from party B
> (e.g. AT) that it doesn't control 3. We want to improve
> AT-IT interoperability, and move the AT/IT industry away from
> their history (by necessity) of reverse engineering for
> access and to supported techniques for access
>
> Do you disagree with these constraints?
>
> As has been discussed in the General SC and in other places,
> the FPC as written aren't testable. It was also noted
> several times (including on the General SC call earlier this
> week) that agencies don't try to test against the FPC - the
> direction is to use the technical provision, and only go to
> the FPC when a product isn't covered by the technical
> provisions. As such, I don't see a change in implementation
> in what we are doing (clarify that the FPC aren't testable);
> rather it is a formal recognition of the reality of
> application. As such, we can deal with the situation more
> explicitly, and move to test what can be tested.
>
> To your question about "where is the incentive?" I see this
> language as providing three incentives:
> 1. Incentive for IT to use platform accessibility services,
> or some other means "...to cooperate with AT..."
> 2. Incentive for a platform to define such services 3.
> Incentive for AT to use this information - because it has
> been called out
>
> Perhaps These incentives could be made stronger. But please
> note that AT as long said that they want this kind of
> information, that it makes their lives easier if they have
> it, and that they use it where they can.
>
> The language also makes a very clear and unambiguous
> enumeration of the minimum information IT should provide to
> AT. We have never had that before.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> > OK I'm extremely concerned about this proposal. Concern is
> greater because,
> > at the same time, it is proposed to reduce the Functional
> Performance
> > Criteria to something lokie philosophy rather than
> requirement applicable to
> > all.
> > So, taken together with the proposal for interoperability,
> it really does
> > appear to me that products which could theoretically have
> AT support but
> > don't, would be equally compliant with those that have AT
> support. Where is
> > the incentive there? More important, where is any
> accessibility? I really
> > fail to see how the end user gains from this.
> > I could live with the concept of the API being adequate if
> the final test
> > would be the FPC. But that appears to be going away or
> significantly
> > weakened based on discussions at General.
> > So, my concern remains that products which are not
> accessible to consumers
> > with disabilities will pass with equal status as those
> which are. And
> > agencies, woh may lack the expertise to discern all the
> nuances will
> > purchase those that do not as readily as those that do.
> > This is a pretty fundamental change in the construct of
> Section 508 with
> > huge implications.
> > ----- Original Message -----
> > From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
> > To: "TEITAC Web/Software Subcommittee"
> < = EMAIL ADDRESS REMOVED = >
> > Sent: Tuesday, August 14, 2007 10:20 AM
> > Subject: Re: [teitac-websoftware] AT Interoperability
> >
> >
> > Hi Gregg,
> >
> > We have more or less come to the consensus that we don't
> want to write
> > specific provisions for assistive technologies (e.g.
> requiring that AT
> > purchased by the government must implement support for platform
> > accessibility services, let alone any API that any
> application chooses
> > to invent and use). Unless that changes, we cannot insist
> that AT and IT
> > must work together. Further, we cannot tell IT that it has the sole,
> > unshared burden of working with AT.
> >
> > I feel this provision is nearly the best that is possible
> within those
> > constraints. Pushing IT to use platform accessibility services where
> > they exist (and by implication encouraging platforms to define and
> > promulgate such services) will go a long way to improving AT-IT
> > interoperability.
> >
> > But at AT and IT typically come from different companies,
> there is no
> > way one can control the other. And since government-wide regulations
> > like 508 must be technology neutral, 508 itself cannot say
> "your IT must
> > work with the Gregorian Screen Reader". Individual agencies can (and
> > do!) do that, but that is part of how they define their
> business need.
> >
> >
> > Regards,
> >
> > Peter Korn
> > Accessibility Architect,
> > Sun Microsystems, Inc.
> >
> >
> >> I can't tell from the current language.
> >>
> >> 1) Does this provision require that software actually work with
> >> assistive technology?
> >>
> >> 2) Or does it only require that information be provided
> that AT could
> >> work with?
> >>
> >> 3) Could someone sell something to the government that met this
> >> provision - but where there was no assistive technology
> available for
> >> one or all disability groups?
> >>
> >> Thanks
> >>
> >>
> >> Gregg
> >>
> >> ------------------------
> >>
> >> Gregg C Vanderheiden Ph.D.
> >> Professor - Depts of Ind. Engr. & BioMed Engr.
> >> Director - Trace R & D Center
> >> University of Wisconsin-Madison
> >> _<http://trace.wisc.edu/>_ FAX 608/262-8848
> >>
> >> DSS Player at http://tinyurl.com/dho6b
> >>
> >> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
> >>
> >> <http://trace.wisc.edu:8080/mailman/listinfo/>
> >>
> >>
> --------------------------------------------------------------
> ----------
> >>
> >>

From: Andi Snow-Weaver
Date: Tue, Aug 14 2007 4:20 PM
Subject: Re: AT interoperability

This discussion has taken a hard left turn away from the specific AT
interoperability provision to the bigger issue of functional performance.

I will remind everyone that the proposed AT interoperability was developed
between AT and IT vendors who are the ones that ultimately have to solve
this problem and has been agreed to since sometime in April I think. And it
is much stronger than the vague requirement for object information to be
programmatically exposed that is in the current (2001) 508 standard. So
with just this one provision, we can improve things over the current
situation even if we keep the 2001 wording for the functional performance
criteria.

This issue is being debated at length in the general subcommittee and they
have scheduled another call tomorrow to continue looking for a solution.
This discussion needs to be happening on the general subcommittee mailing
list to ensure that everyone's point of view is considered.

Andi

From: Andi Snow-Weaver
Date: Tue, Aug 14 2007 4:35 PM
Subject: Re: AT Interoperability

>Just let me know what specific wording or section you're proposing to
change, and let's see if we can't come up with mutually agreeable language.

Randy,

We are not proposing a significant change at all from what we (AT & IT)
collaboratively developed [1].

[1]
http://teitac.org/wiki/Web_and_Software:_Reorganized_Web_and_Software_provisions_2#At_interoperability

Andi

From: Randy Marsden
Date: Tue, Aug 14 2007 4:40 PM
Subject: Re: AT Interoperability

Peter:

Well, we agree on your last point of trying to come to a close on
draft language. I actually haven't seen a specific provision cited
anywhere in this thread. What specific section(s) are we talking
about? I was reacting generally to your suggestion (which I thought
was generally stated) about removing the burden of IT to interoperate
with AT. I expect that covers a number of sections in both the FPC
and the Technical Criteria.

I definitely don't want to hold up the process. Just let me know
what specific wording or section you're proposing to change, and
let's see if we can't come up with mutually agreeable language.

-Rand


On Aug 14, 2007, at 1:52 PM, Peter Korn wrote:

> Randy,
>
> I'm sorry, but I don't understand what *specifically* you are
> recommending.
>
> Right now the draft FPC is not testable, and agencies have told us
> they
> don't even try to test it. If we go back to the original FPC which
> says
> "support for AT", then we have something we can test, and with the "AT
> Interoperability" provision, we have a specific testable set of
> behaviors for IT to do.
>
> Would that satisfy you?
>
> Or, when you say "leave it the way it current is", you mean have no AT
> Interoperability provision at all (no enumeration of what IT must
> provide at a technical level to AT)?
>
> Or, do you mean we have the current draft FPC, but make it clear
> that it
> is not intended to be a testable provision.
>
>
> We are trying very hard to come to a close on draft language to
> send to
> the Access Board. In order to move the discussion forward, we need to
> be discussing *specific* language suggestions. Otherwise we get
> nowhere.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>> That was not the point I was making (but nice try) :-)
>>
>> My point is that a technical interoperability standard doesn't exist
>> today. And yet we are trying to come up with something that is
>> "testable" for interoperability in Section 508. In my opinion, you
>> can't have one without the other. That's why we are all having such
>> difficulty with this issue.
>>
>> My suggestion for something better is that until a generally accepted
>> technical standard exists, leave it the way it currently is: simply
>> state that IT should work with AT. Is that vague? Yes. Will it
>> require interpretation at the agency level? Yes. Is that anything
>> new? No.
>>
>>
>> -Randy
>>
>>
>> On Aug 14, 2007, at 1:04 PM, Peter Korn wrote:
>>
>>> Hi Randy,
>>>
>>>
>>> The "consensus" I was referring to was that we weren't going to
>>> require
>>>
>>> AT to support an API, or make any other explicit requirements on
>>> AT in
>>>
>>> Section 508. This was something I understood was particularly
>>> important
>>>
>>> to ATIA. What I see you saying now, below, is that you hope to
>>> be able
>>>
>>> to change the wording of Section 508 to place a requirement on AT
>>> (you
>>>
>>> wrote: 'Someday, I hope we will be able to change the wording of
>>> Section
>>>
>>> 508 to say something like "AT and IT products must conform to the
>>>
>>> ABC123XXX interoperability standard".'). Doing that would
>>> essentially
>>>
>>> mean that AT that didn't conform to your theoretical ABC123XXX
>>>
>>> interoperability standard could NOT be acquired by agencies under
>>> 508.
>>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>>

From: Debbie Cook
Date: Tue, Aug 14 2007 4:45 PM
Subject: Re: AT Interoperability

I think what is sparking the discussion for a second look at this provision
is precisely the discussion of the FPC in the General group. Suffice to say
that any change in the FPC that reduces the regulatory intent(despite any TA
statements) of the FPC would cause some of us to request a relook at
provisions like interoperability and undoubtedly others. So in that
contextalone, the discussionof how the FPC impacts this provision should be
appropriate to this list.
----- Original Message -----
From: "Andi Snow-Weaver" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, August 14, 2007 3:32 PM
Subject: Re: [teitac-websoftware] AT Interoperability


>Just let me know what specific wording or section you're proposing to
change, and let's see if we can't come up with mutually agreeable language.

Randy,

We are not proposing a significant change at all from what we (AT & IT)
collaboratively developed [1].

[1]
http://teitac.org/wiki/Web_and_Software:_Reorganized_Web_and_Software_provisions_2#At_interoperability

Andi

From: Peter Korn
Date: Tue, Aug 14 2007 6:15 PM
Subject: Re: AT Interoperability

Hi Debbie, Allen,

[adding General SC to the distribution]

I understand the sketch in your sketch/illustration. But we have a more
complex world, with multiple AT products filling the same niche
(multiple screen readers, multiple screen magnifiers). Any FPC language
that we use for this must take that into account. Also, especially with
FPC language around cognitive impairment, is the notion then that no IT
can be fully compliant until some cognitive AT exists on some platform
(at which time only IT on that platform even has the potential to be
fully compliant)?

Another concern I have is that this introduces a notion of "points" in
an evaluation. We discussed that issue quite some TEITAC meetings ago
in the context of offering guidance to agencies on what provisions were
important to which disabilities (allowing them to "score" a product
based on which disabilities they most cared about). I don't know if
this variant of "best meets scoring" differs significantly from that one
- in your sketch we would be stating that there is equal weight to
support by shipping AT products vs. accessibility services support by
the IT vs. accessibility services definition by the platform. I don't
see how to work that out in practice. Doesn't that, too, need to be the
purview of either the FAR or individual agencies?


As Andi suggests in another note in this thread, this should probably be
moved to the General SC. I've cc-ed that mailing list. We should fully
move this there, I think. Would folks replying please drop the Web &
Software e-mail alias from the To: field?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Yes, I would certainly consider a continuem that looks like what Alan
> proposes below. Assists agencies to determine "best meets" and addresses my
> concern that all efforts do not yield equal re3sults for the end user.
> ----- Original Message -----
> From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
> To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, August 14, 2007 12:16 PM
> Subject: Re: [teitac-websoftware] AT Interoperability
>
>
> I have to disagree with this.
>
> I believe Section 508 does need to more clearly define what cooperation
> and interoperability between IT and AT means, when possible. Debbie
> Cook's point about this potentially being problematic if functional
> performance criteria are weakened significantly is valid also. I
> support creating more clear AT/IT interoperability requirements that are
> incremental, E.G. vendors can meet portions and those who meet more get
> more points at evaluation time, and then applying that principle to IT
> vendors for all IT products including platforms, software applications,
> and AT. This implies that, for example, platform vendors should be
> evaluated upon the availability of accessibility services, applications
> evaluated upon inclusion of accessibility services for At and from the
> platforms they support, and AT evaluated against usage of, or equivalent
> alternate provisioning of such services as an interoperability equation.
> Agencies need to consider their particular business needs for specific
> interoperability with specific AT as they must, but unclear requirements
> to "work together" are not measurable in my opinion, and won't get used
> at evaluation and selection time well.
>
> So, what gaps would fill this in for the web/software to provide a real
> continuum?
>
> 1. We need a standard to indicate the platforms must provide
> "accessibility services", that allow them to meet our interoperability
> requirements.
>
> 2. We should consider adding a software AT standard that requires use
> of such platform accessibility services when available, or equivalent
> facilitation of such information.
>
> Finally, when we say programmatically determinable, that may be AT, but
> does not have to be.
>
> Let me provide an example as illustration.
>
> Agency needs to procure an item which is a combination of platform and
> application:
>
> Vendor 1 meets platform standards, and application meets application
> requirements, but there is no At that meets requirements for this
> platform. The seller of the "solution" would then respond to all three
> sets of requirements. In this simplistic case would get 2 of 3. The
> product fails several functional performance criteria because the AT
> doesn't get them there.
>
> Vendor two fails platform standards, fails application requirements, but
> passes At requirements because some very specialized At exists to
> provide this level of access for one group via equivalent facilitation.
> They would get 1 of 3, but the FPC might be higher and evens out.
>
> Vendor three meets all standards and gets 3 of 3 and meets the FPC, so
> wins.
>
> This situation is exactly why the "best meets" language is in the
> standard in subpart A, do allow agencies to have some leeway to select
> the items that do in reality do what is needed, which is work for people
> with disabilities. I don't believe there is a simple way to
> specifically require that IT work with AT without some generally agreed
> upon foundation of roles and responsibilities in the chain.
>
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>
>
>

From: Peter Korn
Date: Tue, Aug 14 2007 6:20 PM
Subject: Re: AT Interoperability

Hi Randy,

[adding General SC to the distribution]

> Well, we agree on your last point of trying to come to a close on
> draft language. I actually haven't seen a specific provision cited
> anywhere in this thread. What specific section(s) are we talking
> about? I was reacting generally to your suggestion (which I thought
> was generally stated) about removing the burden of IT to interoperate
> with AT. I expect that covers a number of sections in both the FPC
> and the Technical Criteria.

I don't believe that was my suggestion; certainly not in this thread.
In the General SC we are discussing the language of the FPC and the role
of the FPC. I and others have argued that the current draft FPC are not
testable. It has also been noted multiple times that the FPC we've been
using since 2001 aren't being tested to, for similar reasons (in fact,
in general the Access Board asked TEITAC to improve the language of the
technical provisions in order to make them testable).

The circa 2001 FPC says "... or support for assistive technology...
shall be provided" for most of the provisions. I know there is a lot of
history and different interpretations of this language. But clearly,
the language doesn't say "IT is solely responsible for making AT work
with IT"; nor does it say "IT must create AT"

Looking at the other software provisions that talk about AT, we have
1194.21(c): "...focus shall be programmatically exposed so that
assistive technology can track focus and focus changes"; and 1194.21(d):
"...information about a user interface element... shall be available to
assistive technology"; and 1194.21(l): "When electronic forms are used,
the form shall allow people using assistive technology to access the
information."

Nothing in this text that we've had from before says that IT bears the
sole burden of interoperating with AT. What we have are specific
technical means IT must use to provide information that AT needs. Our
updated provides have only expanded that (something I have consistently
and forcefully pushed for).

As Andi noted (and also Debbie), this review of the AT Interoperability
provision was triggered by discussions in the General SC around the
FPC. Specifically about whether the FPC should require:
"Full use without Vision - in at least one mode (direct or via AT)"
(April 16 General SC draft)
"At least one mode shall be provided ... directly or with users' AT."
(May 30th draft)
"At least one mode must be provided ... directly or via AT." (July 6th
draft)
"Products must provide at least one mode... provided directly or
through assistive technology." (August 13 draft)

Defining "full use" was a huge problem. Demanding that this be "with
users' AT" isn't workable when we talk about all of the different
agencies and their different AT, let alone the general public, and also
means that innovation ends with this requirement since as long as one
user is clinging to an old version that doesn't support something,
nobody can use IT that needs that support. For the "via AT" and
"through assistive technology" language runs into the problem of
testability. We can't test this without defining what this means. For
either of these, is it sufficient to demonstrate that a single AT
product in any given category works (what if the agency doesn't use that
AT)? What about cross-platform products (a cross platform app that
works well with the built-in AT on the Macintosh, but not with similar
AT on Windows)? And what about version issues (my favorite hobby horse:
a Java app that worked with one version of JAWS, but not a later version
of JAWS)?

How can we possibly demand - and test - this scenario?


This is why, again, I believe what we can achieve in a testable
provision is a very detailed enumeration of the information IT must
provide AT. Ideally, what must be provided in the platform specified
(and AT supported) accessibility services.


But let me turn this around Randy. Why shouldn't there be a burden on
AT to work with IT?

>
> I definitely don't want to hold up the process. Just let me know what
> specific wording or section you're proposing to change, and let's see
> if we can't come up with mutually agreeable language.


As Andi suggests in another note in this thread, this should probably be
moved to the General SC. I've cc-ed that mailing list. We should fully
move this there, I think. Would folks replying please drop the Web &
Software e-mail alias from the To: field?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

>
>
> On Aug 14, 2007, at 1:52 PM, Peter Korn wrote:
>
>> Randy,
>>
>> I'm sorry, but I don't understand what *specifically* you are
>> recommending.
>>
>> Right now the draft FPC is not testable, and agencies have told us they
>> don't even try to test it. If we go back to the original FPC which says
>> "support for AT", then we have something we can test, and with the "AT
>> Interoperability" provision, we have a specific testable set of
>> behaviors for IT to do.
>>
>> Would that satisfy you?
>>
>> Or, when you say "leave it the way it current is", you mean have no AT
>> Interoperability provision at all (no enumeration of what IT must
>> provide at a technical level to AT)?
>>
>> Or, do you mean we have the current draft FPC, but make it clear that it
>> is not intended to be a testable provision.
>>
>>
>> We are trying very hard to come to a close on draft language to send to
>> the Access Board. In order to move the discussion forward, we need to
>> be discussing *specific* language suggestions. Otherwise we get nowhere.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>> That was not the point I was making (but nice try) :-)
>>>
>>> My point is that a technical interoperability standard doesn't exist
>>> today. And yet we are trying to come up with something that is
>>> "testable" for interoperability in Section 508. In my opinion, you
>>> can't have one without the other. That's why we are all having such
>>> difficulty with this issue.
>>>
>>> My suggestion for something better is that until a generally accepted
>>> technical standard exists, leave it the way it currently is: simply
>>> state that IT should work with AT. Is that vague? Yes. Will it
>>> require interpretation at the agency level? Yes. Is that anything
>>> new? No.
>>>
>>>
>>> -Randy
>>>
>>>
>>> On Aug 14, 2007, at 1:04 PM, Peter Korn wrote:
>>>
>>>> Hi Randy,
>>>>
>>>>
>>>> The "consensus" I was referring to was that we weren't going to
>>>> require
>>>>
>>>> AT to support an API, or make any other explicit requirements on AT in
>>>>
>>>> Section 508. This was something I understood was particularly
>>>> important
>>>>
>>>> to ATIA. What I see you saying now, below, is that you hope to be
>>>> able
>>>>
>>>> to change the wording of Section 508 to place a requirement on AT (you
>>>>
>>>> wrote: 'Someday, I hope we will be able to change the wording of
>>>> Section
>>>>
>>>> 508 to say something like "AT and IT products must conform to the
>>>>
>>>> ABC123XXX interoperability standard".'). Doing that would essentially
>>>>
>>>> mean that AT that didn't conform to your theoretical ABC123XXX
>>>>
>>>> interoperability standard could NOT be acquired by agencies under 508.
>>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>

From: Peter Korn
Date: Tue, Aug 14 2007 6:25 PM
Subject: Re: AT Interoperability

Hi Randy,

[adding General SC to the distribution]

> Well, we agree on your last point of trying to come to a close on
> draft language. I actually haven't seen a specific provision cited
> anywhere in this thread. What specific section(s) are we talking
> about? I was reacting generally to your suggestion (which I thought
> was generally stated) about removing the burden of IT to interoperate
> with AT. I expect that covers a number of sections in both the FPC
> and the Technical Criteria.

I don't believe that was my suggestion; certainly not in this thread.
In the General SC we are discussing the language of the FPC and the role
of the FPC. I and others have argued that the current draft FPC are not
testable. It has also been noted multiple times that the FPC we've been
using since 2001 aren't being tested to, for similar reasons (in fact,
in general the Access Board asked TEITAC to improve the language of the
technical provisions in order to make them testable).

The circa 2001 FPC says "... or support for assistive technology...
shall be provided" for most of the provisions. I know there is a lot of
history and different interpretations of this language. But clearly,
the language doesn't say "IT is solely responsible for making AT work
with IT"; nor does it say "IT must create AT"

Looking at the other software provisions that talk about AT, we have
1194.21(c): "...focus shall be programmatically exposed so that
assistive technology can track focus and focus changes"; and 1194.21(d):
"...information about a user interface element... shall be available to
assistive technology"; and 1194.21(l): "When electronic forms are used,
the form shall allow people using assistive technology to access the
information."

Nothing in this text that we've had from before says that IT bears the
sole burden of interoperating with AT. What we have are specific
technical means IT must use to provide information that AT needs. Our
updated provides have only expanded that (something I have consistently
and forcefully pushed for).

As Andi noted (and also Debbie), this review of the AT Interoperability
provision was triggered by discussions in the General SC around the
FPC. Specifically about whether the FPC should require:
"Full use without Vision - in at least one mode (direct or via AT)"
(April 16 General SC draft)
"At least one mode shall be provided ... directly or with users' AT."
(May 30th draft)
"At least one mode must be provided ... directly or via AT." (July 6th
draft)
"Products must provide at least one mode... provided directly or
through assistive technology." (August 13 draft)

Defining "full use" was a huge problem. Demanding that this be "with
users' AT" isn't workable when we talk about all of the different
agencies and their different AT, let alone the general public, and also
means that innovation ends with this requirement since as long as one
user is clinging to an old version that doesn't support something,
nobody can use IT that needs that support. For the "via AT" and
"through assistive technology" language runs into the problem of
testability. We can't test this without defining what this means. For
either of these, is it sufficient to demonstrate that a single AT
product in any given category works (what if the agency doesn't use that
AT)? What about cross-platform products (a cross platform app that
works well with the built-in AT on the Macintosh, but not with similar
AT on Windows)? And what about version issues (my favorite hobby horse:
a Java app that worked with one version of JAWS, but not a later version
of JAWS)?

How can we possibly demand - and test - this scenario?


This is why, again, I believe what we can achieve in a testable
provision is a very detailed enumeration of the information IT must
provide AT. Ideally, what must be provided in the platform specified
(and AT supported) accessibility services.


But let me turn this around Randy. Why shouldn't there be a burden on
AT to work with IT?

>
> I definitely don't want to hold up the process. Just let me know what
> specific wording or section you're proposing to change, and let's see
> if we can't come up with mutually agreeable language.


As Andi suggests in another note in this thread, this should probably be
moved to the General SC. I've cc-ed that mailing list. We should fully
move this there, I think. Would folks replying please drop the Web &
Software e-mail alias from the To: field?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

>
>
> On Aug 14, 2007, at 1:52 PM, Peter Korn wrote:
>
>> Randy,
>>
>> I'm sorry, but I don't understand what *specifically* you are
>> recommending.
>>
>> Right now the draft FPC is not testable, and agencies have told us they
>> don't even try to test it. If we go back to the original FPC which says
>> "support for AT", then we have something we can test, and with the "AT
>> Interoperability" provision, we have a specific testable set of
>> behaviors for IT to do.
>>
>> Would that satisfy you?
>>
>> Or, when you say "leave it the way it current is", you mean have no AT
>> Interoperability provision at all (no enumeration of what IT must
>> provide at a technical level to AT)?
>>
>> Or, do you mean we have the current draft FPC, but make it clear that it
>> is not intended to be a testable provision.
>>
>>
>> We are trying very hard to come to a close on draft language to send to
>> the Access Board. In order to move the discussion forward, we need to
>> be discussing *specific* language suggestions. Otherwise we get nowhere.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>> That was not the point I was making (but nice try) :-)
>>>
>>> My point is that a technical interoperability standard doesn't exist
>>> today. And yet we are trying to come up with something that is
>>> "testable" for interoperability in Section 508. In my opinion, you
>>> can't have one without the other. That's why we are all having such
>>> difficulty with this issue.
>>>
>>> My suggestion for something better is that until a generally accepted
>>> technical standard exists, leave it the way it currently is: simply
>>> state that IT should work with AT. Is that vague? Yes. Will it
>>> require interpretation at the agency level? Yes. Is that anything
>>> new? No.
>>>
>>>
>>> -Randy
>>>
>>>
>>> On Aug 14, 2007, at 1:04 PM, Peter Korn wrote:
>>>
>>>> Hi Randy,
>>>>
>>>>
>>>> The "consensus" I was referring to was that we weren't going to
>>>> require
>>>>
>>>> AT to support an API, or make any other explicit requirements on AT in
>>>>
>>>> Section 508. This was something I understood was particularly
>>>> important
>>>>
>>>> to ATIA. What I see you saying now, below, is that you hope to be
>>>> able
>>>>
>>>> to change the wording of Section 508 to place a requirement on AT (you
>>>>
>>>> wrote: 'Someday, I hope we will be able to change the wording of
>>>> Section
>>>>
>>>> 508 to say something like "AT and IT products must conform to the
>>>>
>>>> ABC123XXX interoperability standard".'). Doing that would essentially
>>>>
>>>> mean that AT that didn't conform to your theoretical ABC123XXX
>>>>
>>>> interoperability standard could NOT be acquired by agencies under 508.
>>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>

From: Peter Korn
Date: Tue, Aug 14 2007 6:30 PM
Subject: Re: AT Interoperability

Hi Debbie, Allen,

[adding General SC to the distribution]

I understand the sketch in your sketch/illustration. But we have a more
complex world, with multiple AT products filling the same niche
(multiple screen readers, multiple screen magnifiers). Any FPC language
that we use for this must take that into account. Also, especially with
FPC language around cognitive impairment, is the notion then that no IT
can be fully compliant until some cognitive AT exists on some platform
(at which time only IT on that platform even has the potential to be
fully compliant)?

Another concern I have is that this introduces a notion of "points" in
an evaluation. We discussed that issue quite some TEITAC meetings ago
in the context of offering guidance to agencies on what provisions were
important to which disabilities (allowing them to "score" a product
based on which disabilities they most cared about). I don't know if
this variant of "best meets scoring" differs significantly from that one
- in your sketch we would be stating that there is equal weight to
support by shipping AT products vs. accessibility services support by
the IT vs. accessibility services definition by the platform. I don't
see how to work that out in practice. Doesn't that, too, need to be the
purview of either the FAR or individual agencies?


As Andi suggests in another note in this thread, this should probably be
moved to the General SC. I've cc-ed that mailing list. We should fully
move this there, I think. Would folks replying please drop the Web &
Software e-mail alias from the To: field?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Yes, I would certainly consider a continuem that looks like what Alan
> proposes below. Assists agencies to determine "best meets" and addresses my
> concern that all efforts do not yield equal re3sults for the end user.
> ----- Original Message -----
> From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
> To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, August 14, 2007 12:16 PM
> Subject: Re: [teitac-websoftware] AT Interoperability
>
>
> I have to disagree with this.
>
> I believe Section 508 does need to more clearly define what cooperation
> and interoperability between IT and AT means, when possible. Debbie
> Cook's point about this potentially being problematic if functional
> performance criteria are weakened significantly is valid also. I
> support creating more clear AT/IT interoperability requirements that are
> incremental, E.G. vendors can meet portions and those who meet more get
> more points at evaluation time, and then applying that principle to IT
> vendors for all IT products including platforms, software applications,
> and AT. This implies that, for example, platform vendors should be
> evaluated upon the availability of accessibility services, applications
> evaluated upon inclusion of accessibility services for At and from the
> platforms they support, and AT evaluated against usage of, or equivalent
> alternate provisioning of such services as an interoperability equation.
> Agencies need to consider their particular business needs for specific
> interoperability with specific AT as they must, but unclear requirements
> to "work together" are not measurable in my opinion, and won't get used
> at evaluation and selection time well.
>
> So, what gaps would fill this in for the web/software to provide a real
> continuum?
>
> 1. We need a standard to indicate the platforms must provide
> "accessibility services", that allow them to meet our interoperability
> requirements.
>
> 2. We should consider adding a software AT standard that requires use
> of such platform accessibility services when available, or equivalent
> facilitation of such information.
>
> Finally, when we say programmatically determinable, that may be AT, but
> does not have to be.
>
> Let me provide an example as illustration.
>
> Agency needs to procure an item which is a combination of platform and
> application:
>
> Vendor 1 meets platform standards, and application meets application
> requirements, but there is no At that meets requirements for this
> platform. The seller of the "solution" would then respond to all three
> sets of requirements. In this simplistic case would get 2 of 3. The
> product fails several functional performance criteria because the AT
> doesn't get them there.
>
> Vendor two fails platform standards, fails application requirements, but
> passes At requirements because some very specialized At exists to
> provide this level of access for one group via equivalent facilitation.
> They would get 1 of 3, but the FPC might be higher and evens out.
>
> Vendor three meets all standards and gets 3 of 3 and meets the FPC, so
> wins.
>
> This situation is exactly why the "best meets" language is in the
> standard in subpart A, do allow agencies to have some leeway to select
> the items that do in reality do what is needed, which is work for people
> with disabilities. I don't believe there is a simple way to
> specifically require that IT work with AT without some generally agreed
> upon foundation of roles and responsibilities in the chain.
>
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>
>
>

From: Randy Marsden
Date: Tue, Aug 14 2007 8:05 PM
Subject: Re: AT interoperability

Thank you Andi. That is what I recall as well. I remember going
over these issues in a special break-out group and working out
language that both IT and AT agreed with (included in your link). I
agree now, as I did then, with that language. At this moment, I
don't see why what is being discussed in the General SC regarding the
FPC should cause that language to be changed.

-Randy
ATIA


On Aug 14, 2007, at 4:17 PM, Andi Snow-Weaver wrote:

>
> This discussion has taken a hard left turn away from the specific AT
> interoperability provision to the bigger issue of functional
> performance.
>
> I will remind everyone that the proposed AT interoperability was
> developed
> between AT and IT vendors who are the ones that ultimately have to
> solve
> this problem and has been agreed to since sometime in April I
> think. And it
> is much stronger than the vague requirement for object information
> to be
> programmatically exposed that is in the current (2001) 508
> standard. So
> with just this one provision, we can improve things over the current
> situation even if we keep the 2001 wording for the functional
> performance
> criteria.
>
> This issue is being debated at length in the general subcommittee
> and they
> have scheduled another call tomorrow to continue looking for a
> solution.
> This discussion needs to be happening on the general subcommittee
> mailing
> list to ensure that everyone's point of view is considered.
>
> Andi
>
>

From: Gregg Vanderheiden
Date: Tue, Aug 14 2007 11:05 PM
Subject: Re: AT Interoperability

The FPC discussion should be in general.

But the discussion here is about the AT Interoperability technical
provisions and I don't think those should be moved to general.

If both are being discussed on this thread - then lets take the FPC to
general and the AT Interop in SoftWeb.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Tuesday, August 14, 2007 7:10 PM
> To: TEITAC Web/Software Subcommittee; TEITAC General
> Interface Accessibility Subcommittee
> Subject: Re: [teitac-websoftware] AT Interoperability
>
> Hi Debbie, Allen,
>
> [adding General SC to the distribution]
>
> I understand the sketch in your sketch/illustration. But we
> have a more complex world, with multiple AT products filling
> the same niche (multiple screen readers, multiple screen
> magnifiers). Any FPC language that we use for this must take
> that into account. Also, especially with FPC language around
> cognitive impairment, is the notion then that no IT can be
> fully compliant until some cognitive AT exists on some
> platform (at which time only IT on that platform even has the
> potential to be fully compliant)?
>
> Another concern I have is that this introduces a notion of
> "points" in an evaluation. We discussed that issue quite
> some TEITAC meetings ago in the context of offering guidance
> to agencies on what provisions were important to which
> disabilities (allowing them to "score" a product based on
> which disabilities they most cared about). I don't know if
> this variant of "best meets scoring" differs significantly
> from that one
> - in your sketch we would be stating that there is equal
> weight to support by shipping AT products vs. accessibility
> services support by the IT vs. accessibility services
> definition by the platform. I don't see how to work that out
> in practice. Doesn't that, too, need to be the purview of
> either the FAR or individual agencies?
>
>
> As Andi suggests in another note in this thread, this should
> probably be moved to the General SC. I've cc-ed that mailing
> list. We should fully move this there, I think. Would folks
> replying please drop the Web & Software e-mail alias from the
> To: field?
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> > Yes, I would certainly consider a continuem that looks like
> what Alan
> > proposes below. Assists agencies to determine "best meets" and
> > addresses my concern that all efforts do not yield equal
> re3sults for the end user.
> > ----- Original Message -----
> > From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
> > To: "TEITAC Web/Software Subcommittee"
> > < = EMAIL ADDRESS REMOVED = >
> > Sent: Tuesday, August 14, 2007 12:16 PM
> > Subject: Re: [teitac-websoftware] AT Interoperability
> >
> >
> > I have to disagree with this.
> >
> > I believe Section 508 does need to more clearly define what
> > cooperation and interoperability between IT and AT means, when
> > possible. Debbie Cook's point about this potentially being
> > problematic if functional performance criteria are weakened
> > significantly is valid also. I support creating more clear AT/IT
> > interoperability requirements that are incremental, E.G.
> vendors can
> > meet portions and those who meet more get more points at evaluation
> > time, and then applying that principle to IT vendors for all IT
> > products including platforms, software applications, and AT. This
> > implies that, for example, platform vendors should be
> evaluated upon
> > the availability of accessibility services, applications evaluated
> > upon inclusion of accessibility services for At and from
> the platforms
> > they support, and AT evaluated against usage of, or
> equivalent alternate provisioning of such services as an
> interoperability equation.
> > Agencies need to consider their particular business needs
> for specific
> > interoperability with specific AT as they must, but unclear
> > requirements to "work together" are not measurable in my
> opinion, and
> > won't get used at evaluation and selection time well.
> >
> > So, what gaps would fill this in for the web/software to provide a
> > real continuum?
> >
> > 1. We need a standard to indicate the platforms must provide
> > "accessibility services", that allow them to meet our
> interoperability
> > requirements.
> >
> > 2. We should consider adding a software AT standard that
> requires use
> > of such platform accessibility services when available, or
> equivalent
> > facilitation of such information.
> >
> > Finally, when we say programmatically determinable, that may be AT,
> > but does not have to be.
> >
> > Let me provide an example as illustration.
> >
> > Agency needs to procure an item which is a combination of
> platform and
> > application:
> >
> > Vendor 1 meets platform standards, and application meets
> application
> > requirements, but there is no At that meets requirements for this
> > platform. The seller of the "solution" would then respond to all
> > three sets of requirements. In this simplistic case would
> get 2 of 3.
> > The product fails several functional performance criteria
> because the
> > AT doesn't get them there.
> >
> > Vendor two fails platform standards, fails application
> requirements,
> > but passes At requirements because some very specialized At
> exists to
> > provide this level of access for one group via equivalent
> facilitation.
> > They would get 1 of 3, but the FPC might be higher and evens out.
> >
> > Vendor three meets all standards and gets 3 of 3 and meets
> the FPC, so
> > wins.
> >
> > This situation is exactly why the "best meets" language is in the
> > standard in subpart A, do allow agencies to have some
> leeway to select
> > the items that do in reality do what is needed, which is work for
> > people with disabilities. I don't believe there is a simple way to
> > specifically require that IT work with AT without some generally
> > agreed upon foundation of roles and responsibilities in the chain.
> >
> >
> >
> >
> >
> >
> >
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> >
> >
> >

From: Gregg Vanderheiden
Date: Tue, Aug 14 2007 11:10 PM
Subject: Re: AT Interoperability

The FPC discussion should be in general.

But the discussion here is about the AT Interoperability technical
provisions and I don't think those should be moved to general.

If both are being discussed on this thread - then lets take the FPC to
general and the AT Interop in SoftWeb.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Tuesday, August 14, 2007 7:10 PM
> To: TEITAC Web/Software Subcommittee; TEITAC General
> Interface Accessibility Subcommittee
> Subject: Re: [teitac-websoftware] AT Interoperability
>
> Hi Debbie, Allen,
>
> [adding General SC to the distribution]
>
> I understand the sketch in your sketch/illustration. But we
> have a more complex world, with multiple AT products filling
> the same niche (multiple screen readers, multiple screen
> magnifiers). Any FPC language that we use for this must take
> that into account. Also, especially with FPC language around
> cognitive impairment, is the notion then that no IT can be
> fully compliant until some cognitive AT exists on some
> platform (at which time only IT on that platform even has the
> potential to be fully compliant)?
>
> Another concern I have is that this introduces a notion of
> "points" in an evaluation. We discussed that issue quite
> some TEITAC meetings ago in the context of offering guidance
> to agencies on what provisions were important to which
> disabilities (allowing them to "score" a product based on
> which disabilities they most cared about). I don't know if
> this variant of "best meets scoring" differs significantly
> from that one
> - in your sketch we would be stating that there is equal
> weight to support by shipping AT products vs. accessibility
> services support by the IT vs. accessibility services
> definition by the platform. I don't see how to work that out
> in practice. Doesn't that, too, need to be the purview of
> either the FAR or individual agencies?
>
>
> As Andi suggests in another note in this thread, this should
> probably be moved to the General SC. I've cc-ed that mailing
> list. We should fully move this there, I think. Would folks
> replying please drop the Web & Software e-mail alias from the
> To: field?
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> > Yes, I would certainly consider a continuem that looks like
> what Alan
> > proposes below. Assists agencies to determine "best meets" and
> > addresses my concern that all efforts do not yield equal
> re3sults for the end user.
> > ----- Original Message -----
> > From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
> > To: "TEITAC Web/Software Subcommittee"
> > < = EMAIL ADDRESS REMOVED = >
> > Sent: Tuesday, August 14, 2007 12:16 PM
> > Subject: Re: [teitac-websoftware] AT Interoperability
> >
> >
> > I have to disagree with this.
> >
> > I believe Section 508 does need to more clearly define what
> > cooperation and interoperability between IT and AT means, when
> > possible. Debbie Cook's point about this potentially being
> > problematic if functional performance criteria are weakened
> > significantly is valid also. I support creating more clear AT/IT
> > interoperability requirements that are incremental, E.G.
> vendors can
> > meet portions and those who meet more get more points at evaluation
> > time, and then applying that principle to IT vendors for all IT
> > products including platforms, software applications, and AT. This
> > implies that, for example, platform vendors should be
> evaluated upon
> > the availability of accessibility services, applications evaluated
> > upon inclusion of accessibility services for At and from
> the platforms
> > they support, and AT evaluated against usage of, or
> equivalent alternate provisioning of such services as an
> interoperability equation.
> > Agencies need to consider their particular business needs
> for specific
> > interoperability with specific AT as they must, but unclear
> > requirements to "work together" are not measurable in my
> opinion, and
> > won't get used at evaluation and selection time well.
> >
> > So, what gaps would fill this in for the web/software to provide a
> > real continuum?
> >
> > 1. We need a standard to indicate the platforms must provide
> > "accessibility services", that allow them to meet our
> interoperability
> > requirements.
> >
> > 2. We should consider adding a software AT standard that
> requires use
> > of such platform accessibility services when available, or
> equivalent
> > facilitation of such information.
> >
> > Finally, when we say programmatically determinable, that may be AT,
> > but does not have to be.
> >
> > Let me provide an example as illustration.
> >
> > Agency needs to procure an item which is a combination of
> platform and
> > application:
> >
> > Vendor 1 meets platform standards, and application meets
> application
> > requirements, but there is no At that meets requirements for this
> > platform. The seller of the "solution" would then respond to all
> > three sets of requirements. In this simplistic case would
> get 2 of 3.
> > The product fails several functional performance criteria
> because the
> > AT doesn't get them there.
> >
> > Vendor two fails platform standards, fails application
> requirements,
> > but passes At requirements because some very specialized At
> exists to
> > provide this level of access for one group via equivalent
> facilitation.
> > They would get 1 of 3, but the FPC might be higher and evens out.
> >
> > Vendor three meets all standards and gets 3 of 3 and meets
> the FPC, so
> > wins.
> >
> > This situation is exactly why the "best meets" language is in the
> > standard in subpart A, do allow agencies to have some
> leeway to select
> > the items that do in reality do what is needed, which is work for
> > people with disabilities. I don't believe there is a simple way to
> > specifically require that IT work with AT without some generally
> > agreed upon foundation of roles and responsibilities in the chain.
> >
> >
> >
> >
> >
> >
> >
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> >
> >
> >

From: Gregg Vanderheiden
Date: Tue, Aug 14 2007 11:20 PM
Subject: Re: AT Interoperability

The provision under discussion is the one listed in the Subject line.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.


>
>
> >Just let me know what specific wording or section you're proposing to
> change, and let's see if we can't come up with mutually
> agreeable language.
>

From: Jessica M. Brodey
Date: Wed, Aug 15 2007 7:35 AM
Subject: Re: AT interoperability

Andi:

I couldn't agree more. We worked at length with IT to develop that
proposal, and we believe it will greatly improve interoperability in the
future.

>From our perspective, the functional performance criteria should set the bar
for the end results (e.g., one mode that provides access without vision
either on its own or through the use of AT). We are not set on one phrase
to convey that concept - we are still open to conveying that message either
through the old phrasing or new language. The technical provisions should
help ensure that these end results are achieved. With that being said, the
technical standards do not set forth every step necessary for AT and IT to
work together. It is possible to follow every provision and for AT & IT not
to work together. The FPC therefore focus on the result, the technical
standards set forth the components that MUST be done to reach the end
result, and the rest is for IT and AT to work out together on a case-by-case
basis. Is this ideal? No - we would love to be able to point to a
standard(s) and say "if you do this, interoperability will happen." We
don't have that yet - perhaps someday soon we will. Our goal is to ensure
that we do not take a step backward from existing regulation, and continue
to require actual compatibility for the products the federal government
purchases at least to the same degree required today.

Jessica
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Tuesday, August 14, 2007 6:18 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] AT interoperability


This discussion has taken a hard left turn away from the specific AT
interoperability provision to the bigger issue of functional performance.

I will remind everyone that the proposed AT interoperability was developed
between AT and IT vendors who are the ones that ultimately have to solve
this problem and has been agreed to since sometime in April I think. And it
is much stronger than the vague requirement for object information to be
programmatically exposed that is in the current (2001) 508 standard. So
with just this one provision, we can improve things over the current
situation even if we keep the 2001 wording for the functional performance
criteria.

This issue is being debated at length in the general subcommittee and they
have scheduled another call tomorrow to continue looking for a solution.
This discussion needs to be happening on the general subcommittee mailing
list to ensure that everyone's point of view is considered.

Andi

From: Peter Korn
Date: Wed, Aug 15 2007 8:05 AM
Subject: Re: AT Interoperability

Hi Randy,

[adding General SC to the distribution]

> Well, we agree on your last point of trying to come to a close on
> draft language. I actually haven't seen a specific provision cited
> anywhere in this thread. What specific section(s) are we talking
> about? I was reacting generally to your suggestion (which I thought
> was generally stated) about removing the burden of IT to interoperate
> with AT. I expect that covers a number of sections in both the FPC
> and the Technical Criteria.

I don't believe that was my suggestion; certainly not in this thread.
In the General SC we are discussing the language of the FPC and the role
of the FPC. I and others have argued that the current draft FPC are not
testable. It has also been noted multiple times that the FPC we've been
using since 2001 aren't being tested to, for similar reasons (in fact,
in general the Access Board asked TEITAC to improve the language of the
technical provisions in order to make them testable).

The circa 2001 FPC says "... or support for assistive technology...
shall be provided" for most of the provisions. I know there is a lot of
history and different interpretations of this language. But clearly,
the language doesn't say "IT is solely responsible for making AT work
with IT"; nor does it say "IT must create AT"

Looking at the other software provisions that talk about AT, we have
1194.21(c): "...focus shall be programmatically exposed so that
assistive technology can track focus and focus changes"; and 1194.21(d):
"...information about a user interface element... shall be available to
assistive technology"; and 1194.21(l): "When electronic forms are used,
the form shall allow people using assistive technology to access the
information."

Nothing in this text that we've had from before says that IT bears the
sole burden of interoperating with AT. What we have are specific
technical means IT must use to provide information that AT needs. Our
updated provides have only expanded that (something I have consistently
and forcefully pushed for).

As Andi noted (and also Debbie), this review of the AT Interoperability
provision was triggered by discussions in the General SC around the
FPC. Specifically about whether the FPC should require:
"Full use without Vision - in at least one mode (direct or via AT)"
(April 16 General SC draft)
"At least one mode shall be provided ... directly or with users' AT."
(May 30th draft)
"At least one mode must be provided ... directly or via AT." (July 6th
draft)
"Products must provide at least one mode... provided directly or
through assistive technology." (August 13 draft)

Defining "full use" was a huge problem. Demanding that this be "with
users' AT" isn't workable when we talk about all of the different
agencies and their different AT, let alone the general public, and also
means that innovation ends with this requirement since as long as one
user is clinging to an old version that doesn't support something,
nobody can use IT that needs that support. For the "via AT" and
"through assistive technology" language runs into the problem of
testability. We can't test this without defining what this means. For
either of these, is it sufficient to demonstrate that a single AT
product in any given category works (what if the agency doesn't use that
AT)? What about cross-platform products (a cross platform app that
works well with the built-in AT on the Macintosh, but not with similar
AT on Windows)? And what about version issues (my favorite hobby horse:
a Java app that worked with one version of JAWS, but not a later version
of JAWS)?

How can we possibly demand - and test - this scenario?


This is why, again, I believe what we can achieve in a testable
provision is a very detailed enumeration of the information IT must
provide AT. Ideally, what must be provided in the platform specified
(and AT supported) accessibility services.


But let me turn this around Randy. Why shouldn't there be a burden on
AT to work with IT?

>
> I definitely don't want to hold up the process. Just let me know what
> specific wording or section you're proposing to change, and let's see
> if we can't come up with mutually agreeable language.


As Andi suggests in another note in this thread, this should probably be
moved to the General SC. I've cc-ed that mailing list. We should fully
move this there, I think. Would folks replying please drop the Web &
Software e-mail alias from the To: field?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

>
>
> On Aug 14, 2007, at 1:52 PM, Peter Korn wrote:
>
>> Randy,
>>
>> I'm sorry, but I don't understand what *specifically* you are
>> recommending.
>>
>> Right now the draft FPC is not testable, and agencies have told us they
>> don't even try to test it. If we go back to the original FPC which says
>> "support for AT", then we have something we can test, and with the "AT
>> Interoperability" provision, we have a specific testable set of
>> behaviors for IT to do.
>>
>> Would that satisfy you?
>>
>> Or, when you say "leave it the way it current is", you mean have no AT
>> Interoperability provision at all (no enumeration of what IT must
>> provide at a technical level to AT)?
>>
>> Or, do you mean we have the current draft FPC, but make it clear that it
>> is not intended to be a testable provision.
>>
>>
>> We are trying very hard to come to a close on draft language to send to
>> the Access Board. In order to move the discussion forward, we need to
>> be discussing *specific* language suggestions. Otherwise we get nowhere.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>> That was not the point I was making (but nice try) :-)
>>>
>>> My point is that a technical interoperability standard doesn't exist
>>> today. And yet we are trying to come up with something that is
>>> "testable" for interoperability in Section 508. In my opinion, you
>>> can't have one without the other. That's why we are all having such
>>> difficulty with this issue.
>>>
>>> My suggestion for something better is that until a generally accepted
>>> technical standard exists, leave it the way it currently is: simply
>>> state that IT should work with AT. Is that vague? Yes. Will it
>>> require interpretation at the agency level? Yes. Is that anything
>>> new? No.
>>>
>>>
>>> -Randy
>>>
>>>
>>> On Aug 14, 2007, at 1:04 PM, Peter Korn wrote:
>>>
>>>> Hi Randy,
>>>>
>>>>
>>>> The "consensus" I was referring to was that we weren't going to
>>>> require
>>>>
>>>> AT to support an API, or make any other explicit requirements on AT in
>>>>
>>>> Section 508. This was something I understood was particularly
>>>> important
>>>>
>>>> to ATIA. What I see you saying now, below, is that you hope to be
>>>> able
>>>>
>>>> to change the wording of Section 508 to place a requirement on AT (you
>>>>
>>>> wrote: 'Someday, I hope we will be able to change the wording of
>>>> Section
>>>>
>>>> 508 to say something like "AT and IT products must conform to the
>>>>
>>>> ABC123XXX interoperability standard".'). Doing that would essentially
>>>>
>>>> mean that AT that didn't conform to your theoretical ABC123XXX
>>>>
>>>> interoperability standard could NOT be acquired by agencies under 508.
>>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>

From: Peter Korn
Date: Wed, Aug 15 2007 8:10 AM
Subject: Re: AT Interoperability

Hi Debbie, Allen,

[adding General SC to the distribution]

I understand the sketch in your sketch/illustration. But we have a more
complex world, with multiple AT products filling the same niche
(multiple screen readers, multiple screen magnifiers). Any FPC language
that we use for this must take that into account. Also, especially with
FPC language around cognitive impairment, is the notion then that no IT
can be fully compliant until some cognitive AT exists on some platform
(at which time only IT on that platform even has the potential to be
fully compliant)?

Another concern I have is that this introduces a notion of "points" in
an evaluation. We discussed that issue quite some TEITAC meetings ago
in the context of offering guidance to agencies on what provisions were
important to which disabilities (allowing them to "score" a product
based on which disabilities they most cared about). I don't know if
this variant of "best meets scoring" differs significantly from that one
- in your sketch we would be stating that there is equal weight to
support by shipping AT products vs. accessibility services support by
the IT vs. accessibility services definition by the platform. I don't
see how to work that out in practice. Doesn't that, too, need to be the
purview of either the FAR or individual agencies?


As Andi suggests in another note in this thread, this should probably be
moved to the General SC. I've cc-ed that mailing list. We should fully
move this there, I think. Would folks replying please drop the Web &
Software e-mail alias from the To: field?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Yes, I would certainly consider a continuem that looks like what Alan
> proposes below. Assists agencies to determine "best meets" and addresses my
> concern that all efforts do not yield equal re3sults for the end user.
> ----- Original Message -----
> From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
> To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, August 14, 2007 12:16 PM
> Subject: Re: [teitac-websoftware] AT Interoperability
>
>
> I have to disagree with this.
>
> I believe Section 508 does need to more clearly define what cooperation
> and interoperability between IT and AT means, when possible. Debbie
> Cook's point about this potentially being problematic if functional
> performance criteria are weakened significantly is valid also. I
> support creating more clear AT/IT interoperability requirements that are
> incremental, E.G. vendors can meet portions and those who meet more get
> more points at evaluation time, and then applying that principle to IT
> vendors for all IT products including platforms, software applications,
> and AT. This implies that, for example, platform vendors should be
> evaluated upon the availability of accessibility services, applications
> evaluated upon inclusion of accessibility services for At and from the
> platforms they support, and AT evaluated against usage of, or equivalent
> alternate provisioning of such services as an interoperability equation.
> Agencies need to consider their particular business needs for specific
> interoperability with specific AT as they must, but unclear requirements
> to "work together" are not measurable in my opinion, and won't get used
> at evaluation and selection time well.
>
> So, what gaps would fill this in for the web/software to provide a real
> continuum?
>
> 1. We need a standard to indicate the platforms must provide
> "accessibility services", that allow them to meet our interoperability
> requirements.
>
> 2. We should consider adding a software AT standard that requires use
> of such platform accessibility services when available, or equivalent
> facilitation of such information.
>
> Finally, when we say programmatically determinable, that may be AT, but
> does not have to be.
>
> Let me provide an example as illustration.
>
> Agency needs to procure an item which is a combination of platform and
> application:
>
> Vendor 1 meets platform standards, and application meets application
> requirements, but there is no At that meets requirements for this
> platform. The seller of the "solution" would then respond to all three
> sets of requirements. In this simplistic case would get 2 of 3. The
> product fails several functional performance criteria because the AT
> doesn't get them there.
>
> Vendor two fails platform standards, fails application requirements, but
> passes At requirements because some very specialized At exists to
> provide this level of access for one group via equivalent facilitation.
> They would get 1 of 3, but the FPC might be higher and evens out.
>
> Vendor three meets all standards and gets 3 of 3 and meets the FPC, so
> wins.
>
> This situation is exactly why the "best meets" language is in the
> standard in subpart A, do allow agencies to have some leeway to select
> the items that do in reality do what is needed, which is work for people
> with disabilities. I don't believe there is a simple way to
> specifically require that IT work with AT without some generally agreed
> upon foundation of roles and responsibilities in the chain.
>
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>
>
>

From: Gregg Vanderheiden
Date: Wed, Aug 15 2007 9:05 AM
Subject: Re: AT interoperability

Hi Jessica, et al.

You should be aware that in the functional area - there is a proposal to
say that conformance to the technical provisions would mean automatic
fulfillment of the FPC. There is a statement in a government FAQ and in
preamble that supports this point of view at least for software aspect.

Thus - if "support for AT" but not "compatibility with actual AT" is all
that is required in the technical requirements - then working with actual AT
would not be required anywhere.

The questions therefore are:
- when the AT industry agreed on the technical provisions did they
understand them to say that "support for AT" (e.g. an API) was sufficient to
meet the technical provision or did they understand the wording to mean that
the software had to work with actual AT. That is, do they require companies
to work with AT industry to make sure their products work - or could
industry just build to an API and say the rest of the problem belongs to the
AT companies.
- this is not to say that the companies here don't work with AT companies
today. The question is simply - do the new 508 regs REQUIRE that companies'
products work with AT? Or do the regs only require that products have an AT
interface - and it is up to AT to work with what is there?


There was also a statement on the list that this was just a problem between
AT and IT and it was only their concern. I believe that there is a
substantial issue for people who have disabilities too.
- With the "products need to work with AT" approach - products purchased
would have AT and could be used by employees with disabilities.
- With the "support for AT" approach - products could pass 508 if they had
an AT interface even if there was not AT that worked with them. That would
mean that there is no requirement that products that passed 508 would in
fact be usable by employees with disabilities.
So I think people with disabilities also have a concern or interest
in this distinction. So I don't think it is purely an AT-IT industry
concern.

Since we have the final Software Call today at 1 EST before the lock down
this is important.

This is not a new or last minute issue. It has been brought up repeatedly
but the language is now solidifying -- and there appears to be a problem
with different people interpreting the same language in different ways.
The current wording can be read either of the two ways discussed above.

We need to at least add a note that clearly states which interpretation is
intended by the language - so that we can determine if consensus exists for
the language or not. And if so - does it mean "provides and interface that
AT can use?" or does it mean "Works with AT that exists".


PS

Suggestion

1) that we say that conformance with 508 means that it works with AT.
2) that if there are no products that work with AT then the agency should
purchase the product that has an API for AT as a fallback to leave best
opportunity for access in the future.

But to purchase a product with an API but no AT instead of a product that
works with real AT should not be "ok" or what the 508 regs allow.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jessica M. Brodey
> Sent: Wednesday, August 15, 2007 8:28 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] AT interoperability
>
> Andi:
>
> I couldn't agree more. We worked at length with IT to
> develop that proposal, and we believe it will greatly improve
> interoperability in the future.
>
> >From our perspective, the functional performance criteria should set
> >the bar
> for the end results (e.g., one mode that provides access
> without vision either on its own or through the use of AT).
> We are not set on one phrase to convey that concept - we are
> still open to conveying that message either through the old
> phrasing or new language. The technical provisions should
> help ensure that these end results are achieved. With that
> being said, the technical standards do not set forth every
> step necessary for AT and IT to work together. It is
> possible to follow every provision and for AT & IT not to
> work together. The FPC therefore focus on the result, the
> technical standards set forth the components that MUST be
> done to reach the end result, and the rest is for IT and AT
> to work out together on a case-by-case basis. Is this ideal?
> No - we would love to be able to point to a
> standard(s) and say "if you do this, interoperability will
> happen." We don't have that yet - perhaps someday soon we
> will. Our goal is to ensure that we do not take a step
> backward from existing regulation, and continue to require
> actual compatibility for the products the federal government
> purchases at least to the same degree required today.
>
> Jessica
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andi Snow-Weaver
> Sent: Tuesday, August 14, 2007 6:18 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-websoftware] AT interoperability
>
>
> This discussion has taken a hard left turn away from the
> specific AT interoperability provision to the bigger issue of
> functional performance.
>
> I will remind everyone that the proposed AT interoperability
> was developed between AT and IT vendors who are the ones that
> ultimately have to solve this problem and has been agreed to
> since sometime in April I think. And it is much stronger than
> the vague requirement for object information to be
> programmatically exposed that is in the current (2001) 508
> standard. So with just this one provision, we can improve
> things over the current situation even if we keep the 2001
> wording for the functional performance criteria.
>
> This issue is being debated at length in the general
> subcommittee and they have scheduled another call tomorrow to
> continue looking for a solution.
> This discussion needs to be happening on the general
> subcommittee mailing list to ensure that everyone's point of
> view is considered.
>
> Andi
>
>

From: Gregg Vanderheiden
Date: Wed, Aug 15 2007 9:15 AM
Subject: Re: AT Interoperability

A couple notes

1) this did NOT come out of a discussion on the General Thread. It came out
of a review of the technical provision here called "AT Interoperability"
which was part of a review of all the Software provisions.

2) this issue is not covered by General. And can't be if the current
language of the FAQ and preamble are used. They specifically say that (at
least for software) conformance to the technical provisions automatically
means conformance to FPC.

So as things are currently being argued, - if working with real AT is not
required in the technical provisions then it won't be required anywhere.

This was not the intent of the last advisory group - nor the understanding
of many who thought that the current language meant that IT would need to be
tested with real AT. Not all AT. But at least some.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Peter Korn
> Sent: Tuesday, August 14, 2007 7:10 PM
> To: TEITAC Web/Software Subcommittee; TEITAC General
> Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] [teitac-websoftware] AT Interoperability
>
> Hi Randy,
>
> [adding General SC to the distribution]
>
> > Well, we agree on your last point of trying to come to a close on
> > draft language. I actually haven't seen a specific provision cited
> > anywhere in this thread. What specific section(s) are we talking
> > about? I was reacting generally to your suggestion (which
> I thought
> > was generally stated) about removing the burden of IT to
> interoperate
> > with AT. I expect that covers a number of sections in both the FPC
> > and the Technical Criteria.
>
> I don't believe that was my suggestion; certainly not in this
> thread.
> In the General SC we are discussing the language of the FPC
> and the role of the FPC. I and others have argued that the
> current draft FPC are not testable. It has also been noted
> multiple times that the FPC we've been using since 2001
> aren't being tested to, for similar reasons (in fact, in
> general the Access Board asked TEITAC to improve the language
> of the technical provisions in order to make them testable).
>
> The circa 2001 FPC says "... or support for assistive technology...
> shall be provided" for most of the provisions. I know there
> is a lot of history and different interpretations of this
> language. But clearly, the language doesn't say "IT is
> solely responsible for making AT work with IT"; nor does it
> say "IT must create AT"
>
> Looking at the other software provisions that talk about AT, we have
> 1194.21(c): "...focus shall be programmatically exposed so
> that assistive technology can track focus and focus changes";
> and 1194.21(d):
> "...information about a user interface element... shall be
> available to assistive technology"; and 1194.21(l): "When
> electronic forms are used, the form shall allow people using
> assistive technology to access the information."
>
> Nothing in this text that we've had from before says that IT
> bears the sole burden of interoperating with AT. What we
> have are specific technical means IT must use to provide
> information that AT needs. Our updated provides have only
> expanded that (something I have consistently and forcefully
> pushed for).
>
> As Andi noted (and also Debbie), this review of the AT
> Interoperability provision was triggered by discussions in
> the General SC around the FPC. Specifically about whether
> the FPC should require:
> "Full use without Vision - in at least one mode (direct or via AT)"
> (April 16 General SC draft)
> "At least one mode shall be provided ... directly or with
> users' AT."
> (May 30th draft)
> "At least one mode must be provided ... directly or via AT."
> (July 6th
> draft)
> "Products must provide at least one mode... provided
> directly or through assistive technology." (August 13 draft)
>
> Defining "full use" was a huge problem. Demanding that this
> be "with users' AT" isn't workable when we talk about all of
> the different agencies and their different AT, let alone the
> general public, and also means that innovation ends with this
> requirement since as long as one user is clinging to an old
> version that doesn't support something, nobody can use IT
> that needs that support. For the "via AT" and "through
> assistive technology" language runs into the problem of
> testability. We can't test this without defining what this
> means. For either of these, is it sufficient to demonstrate
> that a single AT product in any given category works (what if
> the agency doesn't use that AT)? What about cross-platform
> products (a cross platform app that works well with the
> built-in AT on the Macintosh, but not with similar AT on
> Windows)? And what about version issues (my favorite hobby horse:
> a Java app that worked with one version of JAWS, but not a
> later version of JAWS)?
>
> How can we possibly demand - and test - this scenario?
>
>
> This is why, again, I believe what we can achieve in a
> testable provision is a very detailed enumeration of the
> information IT must provide AT. Ideally, what must be
> provided in the platform specified (and AT supported)
> accessibility services.
>
>
> But let me turn this around Randy. Why shouldn't there be a
> burden on AT to work with IT?
>
> >
> > I definitely don't want to hold up the process. Just let
> me know what
> > specific wording or section you're proposing to change, and
> let's see
> > if we can't come up with mutually agreeable language.
>
>
> As Andi suggests in another note in this thread, this should
> probably be moved to the General SC. I've cc-ed that mailing
> list. We should fully move this there, I think. Would folks
> replying please drop the Web & Software e-mail alias from the
> To: field?
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> >
> >
> > On Aug 14, 2007, at 1:52 PM, Peter Korn wrote:
> >
> >> Randy,
> >>
> >> I'm sorry, but I don't understand what *specifically* you are
> >> recommending.
> >>
> >> Right now the draft FPC is not testable, and agencies have told us
> >> they don't even try to test it. If we go back to the original FPC
> >> which says "support for AT", then we have something we can
> test, and
> >> with the "AT Interoperability" provision, we have a
> specific testable
> >> set of behaviors for IT to do.
> >>
> >> Would that satisfy you?
> >>
> >> Or, when you say "leave it the way it current is", you
> mean have no
> >> AT Interoperability provision at all (no enumeration of
> what IT must
> >> provide at a technical level to AT)?
> >>
> >> Or, do you mean we have the current draft FPC, but make it
> clear that
> >> it is not intended to be a testable provision.
> >>
> >>
> >> We are trying very hard to come to a close on draft
> language to send
> >> to the Access Board. In order to move the discussion forward, we
> >> need to be discussing *specific* language suggestions.
> Otherwise we get nowhere.
> >>
> >>
> >> Regards,
> >>
> >> Peter Korn
> >> Accessibility Architect,
> >> Sun Microsystems, Inc.
> >>
> >>> That was not the point I was making (but nice try) :-)
> >>>
> >>> My point is that a technical interoperability standard
> doesn't exist
> >>> today. And yet we are trying to come up with something that is
> >>> "testable" for interoperability in Section 508. In my
> opinion, you
> >>> can't have one without the other. That's why we are all
> having such
> >>> difficulty with this issue.
> >>>
> >>> My suggestion for something better is that until a generally
> >>> accepted technical standard exists, leave it the way it currently
> >>> is: simply state that IT should work with AT. Is that
> vague? Yes.
> >>> Will it require interpretation at the agency level? Yes.
> Is that
> >>> anything new? No.
> >>>
> >>>
> >>> -Randy
> >>>
> >>>
> >>> On Aug 14, 2007, at 1:04 PM, Peter Korn wrote:
> >>>
> >>>> Hi Randy,
> >>>>
> >>>>
> >>>> The "consensus" I was referring to was that we weren't going to
> >>>> require
> >>>>
> >>>> AT to support an API, or make any other explicit
> requirements on AT
> >>>> in
> >>>>
> >>>> Section 508. This was something I understood was particularly
> >>>> important
> >>>>
> >>>> to ATIA. What I see you saying now, below, is that you
> hope to be
> >>>> able
> >>>>
> >>>> to change the wording of Section 508 to place a
> requirement on AT
> >>>> (you
> >>>>
> >>>> wrote: 'Someday, I hope we will be able to change the wording of
> >>>> Section
> >>>>
> >>>> 508 to say something like "AT and IT products must conform to the
> >>>>
> >>>> ABC123XXX interoperability standard".'). Doing that would
> >>>> essentially
> >>>>
> >>>> mean that AT that didn't conform to your theoretical ABC123XXX
> >>>>
> >>>> interoperability standard could NOT be acquired by
> agencies under 508.
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> --------------------------------------------------------------------
> >>> ----
> >>>
> >>>

From: Jim Tobias
Date: Wed, Aug 15 2007 9:40 AM
Subject: Re: AT interoperability

One way of resolving this problem is to require the vendor, at some point in
the procurement
process, to reveal what AT or AT-compatibility testing tool was used, and
what the results were.
This approach has the advantage of finessing the absence, for now, of an
AT-IT compatibility API.
It would improve over current practice, in which vendors may or may not
report any testing
results or even what was tested. It would leave it up to the vendors and
their customers to
determine what is sufficient -- a disadvantage, I think, but a realistic one
-- while motivating
vendors to increase the AT against which they test. Such a solution might
even spur the
development of the API, because this reporting requirement would chafe
against IT vendors, AT
vendors, and federal employees with disabilities whose preferred AT was not
being tested against.

Clearly, there would still be lots to debate over whether all this info
shows up in a VPAT or
only when a specific RFQ/RFI or negotiation is underway. But as I see it,
the only rigorous
alternative would be to create a list of AT, including models and versions,
with which compatibility
is required. If I remeber correctly, we couldn't even agree to create a
list of AT *categories*.

Can TEITAC or even the Access Board make such a requirement stick? Maybe
not -- it seems like a
FAR provision to me. But we can make this recommendation, and it's a far
more realistic and
workable solution than any technical provision could be in the current state
of API underdevelopment.

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


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, August 15, 2007 11:03 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] AT interoperability
>
> Hi Jessica, et al.
>
> You should be aware that in the functional area - there is a
> proposal to say that conformance to the technical provisions
> would mean automatic fulfillment of the FPC. There is a
> statement in a government FAQ and in preamble that supports
> this point of view at least for software aspect.
>
> Thus - if "support for AT" but not "compatibility with actual
> AT" is all that is required in the technical requirements -
> then working with actual AT would not be required anywhere.
>
> The questions therefore are:
> - when the AT industry agreed on the technical provisions did
> they understand them to say that "support for AT" (e.g. an
> API) was sufficient to meet the technical provision or did
> they understand the wording to mean that the software had to
> work with actual AT. That is, do they require companies to
> work with AT industry to make sure their products work - or
> could industry just build to an API and say the rest of the
> problem belongs to the AT companies.
> - this is not to say that the companies here don't work
> with AT companies today. The question is simply - do the new
> 508 regs REQUIRE that companies'
> products work with AT? Or do the regs only require that
> products have an AT interface - and it is up to AT to work
> with what is there?
>
>
> There was also a statement on the list that this was just a
> problem between AT and IT and it was only their concern. I
> believe that there is a substantial issue for people who have
> disabilities too.
> - With the "products need to work with AT" approach -
> products purchased would have AT and could be used by
> employees with disabilities.
> - With the "support for AT" approach - products could pass
> 508 if they had an AT interface even if there was not AT that
> worked with them. That would mean that there is no
> requirement that products that passed 508 would in fact be
> usable by employees with disabilities.
> So I think people with disabilities also have a concern
> or interest in this distinction. So I don't think it is
> purely an AT-IT industry concern.
>
> Since we have the final Software Call today at 1 EST before
> the lock down this is important.
>
> This is not a new or last minute issue. It has been brought
> up repeatedly but the language is now solidifying -- and
> there appears to be a problem with different people
> interpreting the same language in different ways.
> The current wording can be read either of the two ways
> discussed above.
>
> We need to at least add a note that clearly states which
> interpretation is intended by the language - so that we can
> determine if consensus exists for
> the language or not. And if so - does it mean "provides and
> interface that
> AT can use?" or does it mean "Works with AT that exists".
>
>
> PS
>
> Suggestion
>
> 1) that we say that conformance with 508 means that it works with AT.
> 2) that if there are no products that work with AT then the
> agency should purchase the product that has an API for AT as
> a fallback to leave best opportunity for access in the future.
>
> But to purchase a product with an API but no AT instead of a
> product that works with real AT should not be "ok" or what
> the 508 regs allow.
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Jessica M. Brodey
> > Sent: Wednesday, August 15, 2007 8:28 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] AT interoperability
> >
> > Andi:
> >
> > I couldn't agree more. We worked at length with IT to develop that
> > proposal, and we believe it will greatly improve
> interoperability in
> > the future.
> >
> > >From our perspective, the functional performance criteria
> should set
> > >the bar
> > for the end results (e.g., one mode that provides access without
> > vision either on its own or through the use of AT).
> > We are not set on one phrase to convey that concept - we are still
> > open to conveying that message either through the old
> phrasing or new
> > language. The technical provisions should help ensure that
> these end
> > results are achieved. With that being said, the technical
> standards
> > do not set forth every step necessary for AT and IT to work
> together.
> > It is possible to follow every provision and for AT & IT
> not to work
> > together. The FPC therefore focus on the result, the technical
> > standards set forth the components that MUST be done to
> reach the end
> > result, and the rest is for IT and AT to work out together on a
> > case-by-case basis. Is this ideal?
> > No - we would love to be able to point to a
> > standard(s) and say "if you do this, interoperability will
> happen."
> > We don't have that yet - perhaps someday soon we will. Our
> goal is to
> > ensure that we do not take a step backward from existing
> regulation,
> > and continue to require actual compatibility for the products the
> > federal government purchases at least to the same degree required
> > today.
> >
> > Jessica
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Andi
> > Snow-Weaver
> > Sent: Tuesday, August 14, 2007 6:18 PM
> > To: = EMAIL ADDRESS REMOVED =
> > Subject: Re: [teitac-websoftware] AT interoperability
> >
> >
> > This discussion has taken a hard left turn away from the
> specific AT
> > interoperability provision to the bigger issue of functional
> > performance.
> >
> > I will remind everyone that the proposed AT interoperability was
> > developed between AT and IT vendors who are the ones that
> ultimately
> > have to solve this problem and has been agreed to since sometime in
> > April I think. And it is much stronger than the vague
> requirement for
> > object information to be programmatically exposed that is in the
> > current (2001) 508 standard. So with just this one
> provision, we can
> > improve things over the current situation even if we keep the 2001
> > wording for the functional performance criteria.
> >
> > This issue is being debated at length in the general
> subcommittee and
> > they have scheduled another call tomorrow to continue looking for a
> > solution.
> > This discussion needs to be happening on the general subcommittee
> > mailing list to ensure that everyone's point of view is considered.
> >
> > Andi
> >
> >

From: Randy Marsden
Date: Wed, Aug 15 2007 9:45 AM
Subject: Re: AT interoperability

Hi Gregg:

Thanks for summing this up so well. Certainly it has never been our
intent to say simply providing an API was good enough. "Works with
AT that exists" is obviously our choice. A bilateral, mutual
cooperation approach with IT to ensuring that happens is our goal.
And most certainly people with disabilities have a stake in all of
this - after all, that's what it's all about. When we suggest "let
industry work it out", we mean the technical implementation part.
(And most, if not all, AT companies either have people with
disabilities on staff or as advisors / beta testers to ensure what we
are creating is actually useful.)

Your tiered suggestion sounds like reasonable approach (I think Alan
also suggested this yesterday).

-Randy
ATIA

On Aug 15, 2007, at 9:03 AM, Gregg Vanderheiden wrote:

> Hi Jessica, et al.
>
> You should be aware that in the functional area - there is a
> proposal to
> say that conformance to the technical provisions would mean automatic
> fulfillment of the FPC. There is a statement in a government FAQ
> and in
> preamble that supports this point of view at least for software
> aspect.
>
> Thus - if "support for AT" but not "compatibility with actual AT"
> is all
> that is required in the technical requirements - then working with
> actual AT
> would not be required anywhere.
>
> The questions therefore are:
> - when the AT industry agreed on the technical provisions did they
> understand them to say that "support for AT" (e.g. an API) was
> sufficient to
> meet the technical provision or did they understand the wording to
> mean that
> the software had to work with actual AT. That is, do they require
> companies
> to work with AT industry to make sure their products work - or could
> industry just build to an API and say the rest of the problem
> belongs to the
> AT companies.
> - this is not to say that the companies here don't work with AT
> companies
> today. The question is simply - do the new 508 regs REQUIRE that
> companies'
> products work with AT? Or do the regs only require that products
> have an AT
> interface - and it is up to AT to work with what is there?
>
>
> There was also a statement on the list that this was just a problem
> between
> AT and IT and it was only their concern. I believe that there is a
> substantial issue for people who have disabilities too.
> - With the "products need to work with AT" approach - products
> purchased
> would have AT and could be used by employees with disabilities.
> - With the "support for AT" approach - products could pass 508 if
> they had
> an AT interface even if there was not AT that worked with them.
> That would
> mean that there is no requirement that products that passed 508
> would in
> fact be usable by employees with disabilities.
> So I think people with disabilities also have a concern or interest
> in this distinction. So I don't think it is purely an AT-IT industry
> concern.
>
> Since we have the final Software Call today at 1 EST before the
> lock down
> this is important.
>
> This is not a new or last minute issue. It has been brought up
> repeatedly
> but the language is now solidifying -- and there appears to be a
> problem
> with different people interpreting the same language in different
> ways.
> The current wording can be read either of the two ways discussed
> above.
>
> We need to at least add a note that clearly states which
> interpretation is
> intended by the language - so that we can determine if consensus
> exists for
> the language or not. And if so - does it mean "provides and
> interface that
> AT can use?" or does it mean "Works with AT that exists".
>
>
> PS
>
> Suggestion
>
> 1) that we say that conformance with 508 means that it works with AT.
> 2) that if there are no products that work with AT then the agency
> should
> purchase the product that has an API for AT as a fallback to leave
> best
> opportunity for access in the future.
>
> But to purchase a product with an API but no AT instead of a
> product that
> works with real AT should not be "ok" or what the 508 regs allow.
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>

From: Hoffman, Allen
Date: Wed, Aug 15 2007 2:20 PM
Subject: Re: AT Interoperability

Peter Korn wrote:
"I understand the sketch in your sketch/illustration. But we have a
more complex world, with multiple AT products filling the same niche
(multiple screen readers, multiple screen magnifiers). Any FPC language
that we use for this must take that into account. Also, especially with
FPC language around cognitive impairment, is the notion then that no IT
can be fully compliant until some cognitive AT exists on some platform
(at which time only IT on that platform even has the potential to be
fully compliant)?"

By increasing the FPC(s), and updating our technical requirements we
will make the set of items that are fully conforming far smaller in the
beginning, but hopefully that will again grow larger over time. This
will mean that the "most compliant" item is to be selected and this is
often an agency evaluation issue, yes.



Peter Korn continues:
"Another concern I have is that this introduces a notion of "points" in
an evaluation. We discussed that issue quite some TEITAC meetings ago
in the context of offering guidance to agencies on what provisions were
important to which disabilities (allowing them to "score" a product
based on which disabilities they most cared about). I don't know if
this variant of "best meets scoring" differs significantly from that one
- in your sketch we would be stating that there is equal weight to
support by shipping AT products vs. accessibility services support by
the IT vs. accessibility services definition by the platform. I don't
see how to work that out in practice. Doesn't that, too, need to be the
purview of either the FAR or individual agencies?"

yes, i think the actual procedure recommended would be at FAR time. I
think expansion of how "most compliant" is documented and evaluated
could possibly be considered that would be one way to get there.

From: Baker, Robert C.
Date: Wed, Aug 15 2007 2:40 PM
Subject: Re: AT Interoperability

As I mentioned during a 508 Coordinators Meeting in DC today - I believe we are at a critical juncture with respect to 508 implementation. Anything we do to further complicate the standards and make it harder for requiring officials to make procurement decisions may seriously impact any future success we are hoping for with 508. We need an implementation reality check. I am all for aspirational guidance, but strongly against unachievable standards. We need to build more credibility into 508 to regain momentum - not forstall it. We need to gain consensus on the major points, and possibly let go of the "good ideas" that could possibly sink the whole ship.

In my humble opinion,
Robert Baker

------------------------------
Robert Baker
Social Security Administration
Section 508 Coordinator
SSA Accessibility Resource Center

Office: 410.966.7602
Email: = EMAIL ADDRESS REMOVED =

Sent by Blackberry
------------------------------

----- Original Message -----
From: = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >
To: TEITAC Web/Software Subcommittee < = EMAIL ADDRESS REMOVED = >; TEITAC General Interface Accessibility Subcommittee < = EMAIL ADDRESS REMOVED = >
Sent: Wed Aug 15 16:08:19 2007
Subject: Re: [teitac-general] [teitac-websoftware] AT Interoperability

Peter Korn wrote:
"I understand the sketch in your sketch/illustration. But we have a
more complex world, with multiple AT products filling the same niche
(multiple screen readers, multiple screen magnifiers). Any FPC language
that we use for this must take that into account. Also, especially with
FPC language around cognitive impairment, is the notion then that no IT
can be fully compliant until some cognitive AT exists on some platform
(at which time only IT on that platform even has the potential to be
fully compliant)?"

By increasing the FPC(s), and updating our technical requirements we
will make the set of items that are fully conforming far smaller in the
beginning, but hopefully that will again grow larger over time. This
will mean that the "most compliant" item is to be selected and this is
often an agency evaluation issue, yes.



Peter Korn continues:
"Another concern I have is that this introduces a notion of "points" in
an evaluation. We discussed that issue quite some TEITAC meetings ago
in the context of offering guidance to agencies on what provisions were
important to which disabilities (allowing them to "score" a product
based on which disabilities they most cared about). I don't know if
this variant of "best meets scoring" differs significantly from that one
- in your sketch we would be stating that there is equal weight to
support by shipping AT products vs. accessibility services support by
the IT vs. accessibility services definition by the platform. I don't
see how to work that out in practice. Doesn't that, too, need to be the
purview of either the FAR or individual agencies?"

yes, i think the actual procedure recommended would be at FAR time. I
think expansion of how "most compliant" is documented and evaluated
could possibly be considered that would be one way to get there.

From: terry.weaver@gsa.gov
Date: Thu, Aug 16 2007 10:35 AM
Subject: Re: AT interoperability

Jim's approach is one that I've asked my team to investigate. I don't think a solution which attempts to assign a point value would work gov-wide and is really a consideration to be addressed in implementation, e.g. The FAR.


----- Original Message -----
From: "Jim Tobias" [ = EMAIL ADDRESS REMOVED = ]
Sent: 08/15/2007 11:30 AM AST
To: "'TEITAC Web/Software Subcommittee'" < = EMAIL ADDRESS REMOVED = >
Subject: Re: [teitac-websoftware] AT interoperability



One way of resolving this problem is to require the vendor, at some point in
the procurement
process, to reveal what AT or AT-compatibility testing tool was used, and
what the results were.
This approach has the advantage of finessing the absence, for now, of an
AT-IT compatibility API.
It would improve over current practice, in which vendors may or may not
report any testing
results or even what was tested. It would leave it up to the vendors and
their customers to
determine what is sufficient -- a disadvantage, I think, but a realistic one
-- while motivating
vendors to increase the AT against which they test. Such a solution might
even spur the
development of the API, because this reporting requirement would chafe
against IT vendors, AT
vendors, and federal employees with disabilities whose preferred AT was not
being tested against.

Clearly, there would still be lots to debate over whether all this info
shows up in a VPAT or
only when a specific RFQ/RFI or negotiation is underway. But as I see it,
the only rigorous
alternative would be to create a list of AT, including models and versions,
with which compatibility
is required. If I remeber correctly, we couldn't even agree to create a
list of AT *categories*.

Can TEITAC or even the Access Board make such a requirement stick? Maybe
not -- it seems like a
FAR provision to me. But we can make this recommendation, and it's a far
more realistic and
workable solution than any technical provision could be in the current state
of API underdevelopment.

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


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, August 15, 2007 11:03 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] AT interoperability
>
> Hi Jessica, et al.
>
> You should be aware that in the functional area - there is a
> proposal to say that conformance to the technical provisions
> would mean automatic fulfillment of the FPC. There is a
> statement in a government FAQ and in preamble that supports
> this point of view at least for software aspect.
>
> Thus - if "support for AT" but not "compatibility with actual
> AT" is all that is required in the technical requirements -
> then working with actual AT would not be required anywhere.
>
> The questions therefore are:
> - when the AT industry agreed on the technical provisions did
> they understand them to say that "support for AT" (e.g. an
> API) was sufficient to meet the technical provision or did
> they understand the wording to mean that the software had to
> work with actual AT. That is, do they require companies to
> work with AT industry to make sure their products work - or
> could industry just build to an API and say the rest of the
> problem belongs to the AT companies.
> - this is not to say that the companies here don't work
> with AT companies today. The question is simply - do the new
> 508 regs REQUIRE that companies'
> products work with AT? Or do the regs only require that
> products have an AT interface - and it is up to AT to work
> with what is there?
>
>
> There was also a statement on the list that this was just a
> problem between AT and IT and it was only their concern. I
> believe that there is a substantial issue for people who have
> disabilities too.
> - With the "products need to work with AT" approach -
> products purchased would have AT and could be used by
> employees with disabilities.
> - With the "support for AT" approach - products could pass
> 508 if they had an AT interface even if there was not AT that
> worked with them. That would mean that there is no
> requirement that products that passed 508 would in fact be
> usable by employees with disabilities.
> So I think people with disabilities also have a concern
> or interest in this distinction. So I don't think it is
> purely an AT-IT industry concern.
>
> Since we have the final Software Call today at 1 EST before
> the lock down this is important.
>
> This is not a new or last minute issue. It has been brought
> up repeatedly but the language is now solidifying -- and
> there appears to be a problem with different people
> interpreting the same language in different ways.
> The current wording can be read either of the two ways
> discussed above.
>
> We need to at least add a note that clearly states which
> interpretation is intended by the language - so that we can
> determine if consensus exists for
> the language or not. And if so - does it mean "provides and
> interface that
> AT can use?" or does it mean "Works with AT that exists".
>
>
> PS
>
> Suggestion
>
> 1) that we say that conformance with 508 means that it works with AT.
> 2) that if there are no products that work with AT then the
> agency should purchase the product that has an API for AT as
> a fallback to leave best opportunity for access in the future.
>
> But to purchase a product with an API but no AT instead of a
> product that works with real AT should not be "ok" or what
> the 508 regs allow.
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Jessica M. Brodey
> > Sent: Wednesday, August 15, 2007 8:28 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] AT interoperability
> >
> > Andi:
> >
> > I couldn't agree more. We worked at length with IT to develop that
> > proposal, and we believe it will greatly improve
> interoperability in
> > the future.
> >
> > >From our perspective, the functional performance criteria
> should set
> > >the bar
> > for the end results (e.g., one mode that provides access without
> > vision either on its own or through the use of AT).
> > We are not set on one phrase to convey that concept - we are still
> > open to conveying that message either through the old
> phrasing or new
> > language. The technical provisions should help ensure that
> these end
> > results are achieved. With that being said, the technical
> standards
> > do not set forth every step necessary for AT and IT to work
> together.
> > It is possible to follow every provision and for AT & IT
> not to work
> > together. The FPC therefore focus on the result, the technical
> > standards set forth the components that MUST be done to
> reach the end
> > result, and the rest is for IT and AT to work out together on a
> > case-by-case basis. Is this ideal?
> > No - we would love to be able to point to a
> > standard(s) and say "if you do this, interoperability will
> happen."
> > We don't have that yet - perhaps someday soon we will. Our
> goal is to
> > ensure that we do not take a step backward from existing
> regulation,
> > and continue to require actual compatibility for the products the
> > federal government purchases at least to the same degree required
> > today.
> >
> > Jessica
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Andi
> > Snow-Weaver
> > Sent: Tuesday, August 14, 2007 6:18 PM
> > To: = EMAIL ADDRESS REMOVED =
> > Subject: Re: [teitac-websoftware] AT interoperability
> >
> >
> > This discussion has taken a hard left turn away from the
> specific AT
> > interoperability provision to the bigger issue of functional
> > performance.
> >
> > I will remind everyone that the proposed AT interoperability was
> > developed between AT and IT vendors who are the ones that
> ultimately
> > have to solve this problem and has been agreed to since sometime in
> > April I think. And it is much stronger than the vague
> requirement for
> > object information to be programmatically exposed that is in the
> > current (2001) 508 standard. So with just this one
> provision, we can
> > improve things over the current situation even if we keep the 2001
> > wording for the functional performance criteria.
> >
> > This issue is being debated at length in the general
> subcommittee and
> > they have scheduled another call tomorrow to continue looking for a
> > solution.
> > This discussion needs to be happening on the general subcommittee
> > mailing list to ensure that everyone's point of view is considered.
> >
> > Andi
> >
> >

From: Gregg Vanderheiden
Date: Sun, Aug 26 2007 10:45 PM
Subject: Re: AT Interoperability

This has morphed from a Technical provision discussion to include General
FPC.

Peter wrote:
> Also, especially with FPC language around
> cognitive impairment, is the notion then that no IT can be
> fully compliant until some cognitive AT exists on some
> platform (at which time only IT on that platform even has the
> potential to be fully compliant)?

RE FPC - I'm not sure I follow the argument about having to wait for
cognitive AT. The FPC all have AT as an option, not a requirement. As
cognitive AT become available they can be relied upon. Until then you can
work with direct. There is no need to wait for cognitive AT so IT can
conform. Also - note that that cognitive provision is still under
consideration. We actually don't have one yet.


Thanks

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Peter Korn
> Sent: Tuesday, August 14, 2007 7:10 PM
> To: TEITAC Web/Software Subcommittee; TEITAC General
> Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] [teitac-websoftware] AT Interoperability
>
> Hi Debbie, Allen,
>
> [adding General SC to the distribution]
>
> I understand the sketch in your sketch/illustration. But we
> have a more complex world, with multiple AT products filling
> the same niche (multiple screen readers, multiple screen
> magnifiers). Any FPC language that we use for this must take
> that into account. Also, especially with FPC language around
> cognitive impairment, is the notion then that no IT can be
> fully compliant until some cognitive AT exists on some
> platform (at which time only IT on that platform even has the
> potential to be fully compliant)?
>
> Another concern I have is that this introduces a notion of
> "points" in an evaluation. We discussed that issue quite
> some TEITAC meetings ago in the context of offering guidance
> to agencies on what provisions were important to which
> disabilities (allowing them to "score" a product based on
> which disabilities they most cared about). I don't know if
> this variant of "best meets scoring" differs significantly
> from that one
> - in your sketch we would be stating that there is equal
> weight to support by shipping AT products vs. accessibility
> services support by the IT vs. accessibility services
> definition by the platform. I don't see how to work that out
> in practice. Doesn't that, too, need to be the purview of
> either the FAR or individual agencies?
>
>
> As Andi suggests in another note in this thread, this should
> probably be moved to the General SC. I've cc-ed that mailing
> list. We should fully move this there, I think. Would folks
> replying please drop the Web & Software e-mail alias from the
> To: field?
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> > Yes, I would certainly consider a continuem that looks like
> what Alan
> > proposes below. Assists agencies to determine "best meets" and
> > addresses my concern that all efforts do not yield equal
> re3sults for the end user.
> > ----- Original Message -----
> > From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
> > To: "TEITAC Web/Software Subcommittee"
> > < = EMAIL ADDRESS REMOVED = >
> > Sent: Tuesday, August 14, 2007 12:16 PM
> > Subject: Re: [teitac-websoftware] AT Interoperability
> >
> >
> > I have to disagree with this.
> >
> > I believe Section 508 does need to more clearly define what
> > cooperation and interoperability between IT and AT means, when
> > possible. Debbie Cook's point about this potentially being
> > problematic if functional performance criteria are weakened
> > significantly is valid also. I support creating more clear AT/IT
> > interoperability requirements that are incremental, E.G.
> vendors can
> > meet portions and those who meet more get more points at evaluation
> > time, and then applying that principle to IT vendors for all IT
> > products including platforms, software applications, and AT. This
> > implies that, for example, platform vendors should be
> evaluated upon
> > the availability of accessibility services, applications evaluated
> > upon inclusion of accessibility services for At and from
> the platforms
> > they support, and AT evaluated against usage of, or
> equivalent alternate provisioning of such services as an
> interoperability equation.
> > Agencies need to consider their particular business needs
> for specific
> > interoperability with specific AT as they must, but unclear
> > requirements to "work together" are not measurable in my
> opinion, and
> > won't get used at evaluation and selection time well.
> >
> > So, what gaps would fill this in for the web/software to provide a
> > real continuum?
> >
> > 1. We need a standard to indicate the platforms must provide
> > "accessibility services", that allow them to meet our
> interoperability
> > requirements.
> >
> > 2. We should consider adding a software AT standard that
> requires use
> > of such platform accessibility services when available, or
> equivalent
> > facilitation of such information.
> >
> > Finally, when we say programmatically determinable, that may be AT,
> > but does not have to be.
> >
> > Let me provide an example as illustration.
> >
> > Agency needs to procure an item which is a combination of
> platform and
> > application:
> >
> > Vendor 1 meets platform standards, and application meets
> application
> > requirements, but there is no At that meets requirements for this
> > platform. The seller of the "solution" would then respond to all
> > three sets of requirements. In this simplistic case would
> get 2 of 3.
> > The product fails several functional performance criteria
> because the
> > AT doesn't get them there.
> >
> > Vendor two fails platform standards, fails application
> requirements,
> > but passes At requirements because some very specialized At
> exists to
> > provide this level of access for one group via equivalent
> facilitation.
> > They would get 1 of 3, but the FPC might be higher and evens out.
> >
> > Vendor three meets all standards and gets 3 of 3 and meets
> the FPC, so
> > wins.
> >
> > This situation is exactly why the "best meets" language is in the
> > standard in subpart A, do allow agencies to have some
> leeway to select
> > the items that do in reality do what is needed, which is work for
> > people with disabilities. I don't believe there is a simple way to
> > specifically require that IT work with AT without some generally
> > agreed upon foundation of roles and responsibilities in the chain.
> >
> >
> >
> >
> >
> >
> >
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> >
> >
> >