Thread Subject: Re: Resolutions from today

Note

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

From: Sean Hayes
Date: Fri, Oct 19 2007 3:40 AM

I think this is not a correct interpretation of 508. E&IT does not 'pass 508'. 508 is used to guide agencies in procuring, maintaining and using E&IT to ensure comparable access to people with disabilities. 508, or the FPC should not be applied to products in isolation, but rather to the procurement process and installations in agencies.

We have clause 1.2A which I believe places the requirement on the agency to configure E&IT in such a way as to provide comparable access, which in my mind includes attaching any necessary AT and ensuring it works.

Thus for example a product can meet all of the provisions in section 3, or the FPC, with or without any AT support in the market. The product if you like "passes" those criteria. However an agency could not purchase it because a procurement could not satisfy 508 as a whole if they could not configure the product in order to provide comparable access.

Thus I believe any language about 'must work with' should not be in the definition of E&IT, the FPC or section 3.

1.2 A might however be reworded:


In complying with this subpart, each agency must activate accessibility features and configure products so that they do provide comparable access for people with disabilities.

Note this includes installing, configuring and testing any necessary Assistive Technology.



Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385

From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg Vanderheiden
Sent: 19 October 2007 04:35
To: 'TEITAC General Interface Accessibility Subcommittee'
Subject: Re: [teitac-general] Resolutions from today


HI Peter,



I'm sorry you weren't there as well. But I think you misunderstand #1



Comments below marked GV:





Gregg

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

Gregg C Vanderheiden Ph.D.







> -----Original Message-----

> From: = EMAIL ADDRESS REMOVED =

> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of

> Peter Korn

> Sent: Thursday, October 18, 2007 9:36 PM

> To: TEITAC General Interface Accessibility Subcommittee

> Subject: Re: [teitac-general] Resolutions from today

>

> Hi Gregg,

>

> I'm sorry I missed the General SC meeting this week.

>

> I'm very troubled by #1 below. Here are the problems I see with it:

>

> 1. The language "[E&IT] Must work with some example(s) for

> each type of AT" and "AT that E&IT must work with" place the

> onus of interoperability solely on E&IT. As we've discussed

> ad nauseum, this is not workable.



GV: This isn't true. It only requires that E&IT (that is not accessible) work with some AT. If particular AT won't work with a company than other AT can be used.



The only alternative to this is that E&IT can pass 508 and not be accessible directly and not work with any AT. And the group did not feel that that would meet 508 whose intent is to ensure that employees with disabilities could use E&IT. Not clear how this is possible if E&IT wasn't directly accessible or work with any AT.



> That issue is recognized in two of the three "positions"

> described below.

>

> 2. Not every agency uses the same AT as every other agency;

> so this language would essentially require E&IT to ensure it

> works with a potentially unbounded set of AT, changing for

> any given bid (and giving E&IT potentially very little time

> to do such evaluations and remediations)



GV: Actually it works mostly the other way. Most all of the agencies use one of a couple AT making it easier for companies to work with.



>

> 3. Since most Federal government sales are "schedule" based -

> that is, a product qualifies for the schedule at which point

> any agency can purchase it if it wants to - this would in

> effect require that E&IT must ensure interoperability with

> *all* AT on a given platform. Again, two of the "positions"

> below recognize that it isn't appropriate to require

> interoperability with all AT.



GV: I don't follow this. The position that the group came down on was only that the product had to work with some AT. And even then it was only if the product didn't have built in accessibility. The provisions below were used to address all of the constraints that we could short of abandoning the ability of people with disabilities to use the product at all. (no direct access or access via AT).



GV: In fact short of that, the group pretty much tried to lean as far away from "it should work with the AT that various users' have" that it could.





GV: Do you have some suggested edits?







>

> Point #3 and point #4 (below) don't fully ameliorate these problems.

>

>

> Regards,

>

> Peter Korn

> Accessibility Architect,

> Sun Microsystems, Inc.

>

> > After success last week in addressing the Role and 'type of access'

> > issues in the FPC we tackled the AT question today.

> >

> > The resolution was to pass the following up for discussion

> by fuller

> > group.

> >

> > *RESOLVED:* To submit the following to the full committee for

> > consideration

> >

> > 1. [E&IT] Must work with some example(s) for each type of AT

> > sufficient to meet the FPC and the technical

> provisions. The AT

> > that E&IT must work with is to be determined by those

> > implementing the standard (e.g. Federal Agencies). The AT that

> > the product must work with is likely to be different within

> > agencies than it is with the general public.

> > 2. "Work with AT" means that all information and functionality of

> > product is accessible but not necessarily all user interface

> > components (e.g. if a function can be achieved through another

> > comparable user interface component that would pass. Tool bar

> > functions might be available via menu for example ).

> > 3. If a product works with AT except for particular aspects, the

> > vendor can report "Works except for the following

> function(s):"

> > 4. If a product worked with AT and then stopped because

> of changes

> > in AT - the vendor could report "Works with Version X

> of YYY on

> > platform ZZZ as of Date". If the vendor knows that some

> > particular thing no longer works after working with AT vendor

> > they *could* report it as a missing feature or stand

> with dated

> > statement.

> >

> > *RESOLVED:* Suggestion to ATIA to publish list of tools

> (and develop

> > them if and as possible) that can be used to test for compatibility

> > with whole classes of AT.

> >

> > It was noted that the suggestion to ATIA would probably not

> work for

> > AT like screen readers - but may be possible for USB based aids and

> > possibly other types of AT.

> >

> > The above text resulted after much discussion and attempts

> to address

> > issues from both sides and find a balance.

> >

> >

> > */Notes from meeting /*

> >

> >

> > */NOTES from discussion /*

> >

> > 1. *Does 508 apply to AT ? *

> > * If AT provides E&IT functions (e.g., AT is a software

> > application such as a special talking word processor )

> > then the 508 technical standards would apply.

> > * If AT is just an adaptation [e.g., a screen reader] then

> > AT isn't E&IT itself and 508 standards do not apply.

> >

> > * Even if we expose with an API it doesn't say 'accessible to whom

> > with what'? It is about evaluating the whole stack from the agency

> > point of view. The question is will it all work for the

> person with a

> > disability when delivered and set up.

> >

> >

> > */QUESTIONS from discussion /*

> >

> > 1. Should 508 standard or its preamble make any statement about

> > which or how many AT?

> > 2. Should a product fail FPC(s) and/or technical standard(s) if

> > some features don't work with some AT?

> > * what if most but not all features work -- bug in AT

> > prevents the rest?

> > * what if it worked fully and then AT changed (bug fix or

> > new version) and no longer works?

> > * what if it works with one AT and not another?

> > 3. Should a product 'pass' 508 FPC(s) and/or technical

> standard(s)

> > if product would work with AT only if AT was customized?

> > * where info is not available at ALL (i.e., fails

> technical

> > standard(s)and/or FPC ) without customization?

> > * where customization is needed to work efficiently?

> >

> >

> > */Table of Issues RE AT /*

> >

> > *Position 1 *

> >

> > Don't need to work with actual AT to pass 508 even if

> access not built

> > in (i.e., not directly accessible).

> >

> > * current 508 doesn't require AT only support.

> > * a company shouldn't be disadvantaged if AT vendors

> don't support

> > the company's product(s).

> > * problems with AT vendors who don't have bandwidth to make AT

> > work with vendors products at all.

> > * technical provisions don't put requirements on AT to work with

> > IT - so how do you guarantee that IT CAN work with (all) AT or

> > AT that doesn't use accessibility services properly.

> > * if the vendor can demonstrate via a tool that they expose

> > information then that should be sufficient even if AT not

> > available that uses the information.

> >

> > *Position 2 *

> >

> > If access not built in - then must work with actual AT -

> but not all

> > (and need to address times when products work with one

> version or one

> > day and not the next).

> >

> > * current 508 does require product to work with AT. 'or support

> > for' does mean 'works with actual AT'.

> > * if it doesn't work with actual AT then actual employees can't

> > use the product.

> > * not realistic to work with all AT.

> > * real problem for vendors when product works but then

> AT changes

> > or has bug and doesn't work completely any longer.

> > * technical provisions don't put requirements on AT to work with

> > IT - so how do you guarantee that IT CAN work with

> (all or any)

> > AT or AT that doesn't use accessibility services provided by

> > product properly?

> >

> > *Position 3 *

> >

> > If access not built in - then must work with all AT that

> users have or

> > can afford

> >

> > * current 508 does require product to work with AT. 'or support

> > for AT' means 'works with actual AT'.

> > * if product doesn't work with employee's (or public's) AT then

> > they can't use the product.

> >

> >

> > */Minutes at /*

> >

> > http://teitac.org/wiki/Monday_10-15-2007_General_telecon

> >

> >

> > Gregg & Michael

> >

> > Co-Chairs

> >

> >

> ----------------------------------------------------------------------

> > --

> >

> >

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