Thread Subject: Re: Resolutions from today

From: Gregg Vanderheiden
Date: Fri, Oct 19 2007 6:05 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Gregg Vanderheiden: "Re: Resolutions from today"
• Previous message in thread: Sean Hayes: "Re: Resolutions from today"
• Messages sorted by: Author | Thread | Date

Hi Peter,

Thanks for the comments.

Hmmm Your suggestion below would allow things to pass 508 more easily - but
it would result in the products passing 508 that would not be useable by the
employees in the government. The purpose of 508 is not to make work for
companies. It is to ensure that employees with disabilities can keep their
jobs, get jobs or advance in jobs. All of these require that that the
products work for people with disabilities with AT they have or can get from
their agency.

I understand that some platforms are at a natural disadvantage. But no one
is talking about enshrining any OS. If we were to apply this same logic you
propose to mainstream software- an agency should buy products for an OS
that they don't have simply because the product would work on a different
OS. The agency wouldn't do this because the software wouldn't work with
the computers in their agency. That might mean that products for other OSs
are at a disadvantage but it still wouldn't make sense to buy a product that
the agency's employees (without disabilities) couldn't use. Similarly,
agencies need to buy software that will work with the AT the agency has or
will buy for their employees with disabilities or their employees with
disabilities will not be able to use them. That does put companies who
sell products that won't work with that AT at a disadvantage, but no
differently than the OS example above for employees without disabilities.

I recognize the disadvantage that Sun is at with regard to AT availability.
And I am working to try to address it. But to say that products would pass
508 that don't work with the AT that an agency has or is willing to buy for
their employees - would mean it would pass 508 but not be useable by
employees with disabilities. That is not what the 508 regs should do. And
I don't think the Access Board could write regs that did that.

I think the guidelines themselves should not specify what or how many AT -
and that Sun should be working with the agencies to recognize or use a
broader range of AT. That way Sun products can be purchased that will
indeed be usable by people in the government who need to use AT.

It is a tough problem - but the 508 regs are to implement the 508
legislation which was to create an E&IT environment that employees with
disabilities can actually use. (and the public of course for public
information).


As I mentioned - the working group tried to accommodate industry needs as
much as it possibly could without completely abandoning the need for
products (that were not natively accessible) to work with real AT that the
people could use in their jobs.

This included wording to cover situations where AT has a bug or stops
working etc beyond a company's control. And to point to places where AT is
the problem - so agencies could lean on them.

I wish AT were available evenly for all platforms. I wish that all software
was available on all platforms. But neither is true and both are a
disadvantage to platforms that are not as widely supported. But the
government shouldn't buy software that doesn't run on the platforms of their
employees (or platforms they are willing and able to buy for their
employees). And it shouldn't but software that won't work with the AT
platforms of their employees with disabilities (or AT platform they are
willing and able to buy for their employees).

And as I understand it, that is what 508 was about.



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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Peter Korn
> Sent: Friday, October 19, 2007 1:19 AM
> To: TEITAC General Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] Resolutions from today
>
> Hi Gregg,
>
> Comments in-line, interspersed with yours.
>
> > >
> >
> > > 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 specific text is: "The AT that E&IT must work with is to be
> determined by those implementing the standard (e.g. Federal
> Agencies)."
> So, if agency XYZ is using the Acme screen reader, and agency PDQ is
> using the Yoyodine screen reader (and my product isn't self-voicing),
> then when I sell to XYZ I am given the responsibility of making my
> product work with Acme, and when I sell to PDQ I am given the
> responsibility making my product work with Yoyodine. Or am I
> misreading
> that text?
>
> And if the union of all agencies that go by GSA schedules
> encompasses 4
> different screen readers, then I am potential responsible for
> ensuring
> my product works with all four in order to be listed on the
> GSA schedule.
>
> In addition to not liking this scenario very much at all, I
> am further
> troubled by the emphasis on putting the AT ahead of the IT
> acquisition,
> because it enshrines the existing Windows-dominated world. I
> might have
> a great Macintosh or UNIX product, and it might work exceedingly well
> with Macintosh or UNIX AT; but no matter, since the agency
> first chooses
> its AT (and by extension, its platform), my accessible (with AT)
> Macintosh or UNIX solution need not apply.
>
> > 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.
> >
>
> An alternative is that the E&IT product must either be
> self-accessible,
> or accessible with at least one AT at some point in time
> (some version),
> as recognized by the agency (and since the agency can be expected to
> push this off onto the vendor, as reported by the E&IT vendor).
>
> > > 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.
> >
>
> And most all of the agencies use a single platform; again a policy I
> have no desire to enshrine.
>
> > > 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).
> >
>
> I recognize that intention, but that is not how I read the
> language. It
> must work with some AGENCY SPECIFIED AT, not just "some 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?
> >
>
> This is really difficult - for all of us, with all manner of
> positions.
>
> I frankly don't see a path that satisfies all
> constituencies/desires/positions. The minimal desires/positions, as I
> see them, are:
>
> 1. For each disability need, the E&IT must either self-accessible, or
> must (have in the past) work(ed) with AT, in order for it to "fully
> pass" the updated Section 508.
>
> 2. E&IT vendors shall not be solely responsible for
> interoperability with AT
>
> 3. Section 508 shall place no requirements on AT
>
>
> As I see it, we can have *any* two of these three
> constraints, but not
> all three.
>
> We can insist on #1, and then either E&IT vendors are made
> responsible
> for something that they fundamentally cannot control (we also
> insist on
> #3 and remove #2); or we write new provisions to apply to AT
> such that
> E&IT vendors and AT vendors share a responsibility for
> interoperability
> - most workable by specifying on a per-platform basis some
> interoperability API that both are required to implement. Even then,
> there is no guarantee of interoperability... And we run the
> risk of AT
> vendors simply not offering their products under 508 - the Federal
> government market is too small for many/most of them to be worth the
> burden on top of all of their other burdens.
>
> We can insist on #2 (my position), and then either AT vendors
> must share
> a responsibility to meet #1, or we satisfy ourselves that with all of
> the other technical provisions we have created in this
> update, and with
> something less than a guarantee by E&IT that they do work with AT, we
> will have improved things enough to be in a pretty reasonable place.
>
> For didactic completeness... we can insist on #3 (ATIA's position I
> believe), and then either E&IT is made responsible for something it
> cannot control, or we give up on all of our goals for #1.
>
>
> My suggestion is that we take faith in the following changes in this
> refresh:
> 1. the new 3-U provision on AT-IT interoperability that will give AT
> vendors a tremendous amount of information to make their products
> support E&IT (which they are strongly motivated to do)
> 2. an updated VPAT in which E&IT vendors describe the AT
> interoperability testing they have done and describe at least
> at a high
> level the results (many feel that publishing a set of specific bugs
> reveals competitive information)
>
> This path doesn't require through regulation that E&IT be responsible
> for something it can't control; and it doesn't require through
> regulation that AT vendors do something they assert makes no
> financial
> sense for them to do. That may not be completely satisfying,
> but I think
> it reflects reality.
>
> I am reminded of the story about the French government many years ago
> legislating that the value of the transcendental number pi as
> equal to
> 3.2. It was probably very satisfying to the government, but doing so
> didn't actually change the way the world worked.
>
> Insisting that E&IT be responsible for making AT work with
> our products
> may be satisfying, but that doesn't make it workable.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > >
> >
> > > 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
> >
> > > >
> >
> > > >
> >
> > >
> ----------------------------------------------------------------------
> >
> > > > --
> >
> > > >
> >
> > > >

• Next message in Thread: Gregg Vanderheiden: "Re: Resolutions from today"
• Previous message in Thread: Sean Hayes: "Re: Resolutions from today"