Thread Subject: Re: FPCs

From: Gregg Vanderheiden
Date: Thu, Oct 11 2007 2:10 PM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: None
• Previous message in thread: Peter Korn: "Re: FPCs"
• Messages sorted by: Author | Thread | Date

Hi Peter,

I think the phrase ... or support for assistive technology... is being
misinterpreted there.

All of the agencies I talked to have said that "... or support for assistive
technology..." meant that there was support such that the product would work
with assistive technologies. None of them said that a product that had an
API for which there was no actual assistive technology would meet the
current 508.

We can ask the Access Board if you like - but I believe the intent of that
phrase was that the product work directly with people who had disabilities
or that the product provided the support necessary to work with actual
existing assistive technologies. Otherwise what good would it do employees
(or the public) who had disabilities? If there was no actual AT they would
not be able to use the E&IT to keep (or get) a job that required use of the
E&IT.

The goal of 508 was not to create work for companies (or agencies) but to
increase the ability of people with disabilities to work there. What good
is a provision that requires companies (or agencies) to do something if it
didn't result in the ability of consumers with disabilities to actually use
the product?




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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Peter Korn
> Sent: Thursday, October 11, 2007 11:57 AM
> To: TEITAC General Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] FPCs
>
> Gregg,
>
> I'm sorry, but I must disagree with your characterization of
> what "is true today", and whether what is being discussed is
> a weakening or not.
>
> In the Functional Performance criteria of the published
> Section 508 that we have been living under for some years now
> - at
> http://www.access-board.gov/sec508/standards.htm#Subpart_c -
> the language for (a) - (d) are all: "... or support for
> assistive technology..."
>
> The current language is not "... or must work with assistive
> technology...".
>
> And I believe that the lack of clarity on what "support" is
> for AT in the existing, published document means that by our
> defining that clearly in our draft AT-IT interoperability
> provision means that we are in fact strengthening section 508
> if we otherwise kept the existing published FPC, making no
> changes to it.
>
>
> I understand that even with a detailed description of what "supports"
> means is not in and of itself sufficient to guarantee that AT
> exists and that AT & IT are in fact working together. I
> understand that is a concern and something we are still
> wrestling with. But I object to the claim that the current
> draft work is a weakening. It is, perhaps, an insufficient
> strengthening.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > That is true today because the test has been that IT must work with
> > AT. If we change the rules (weaken them) so that only an API is
> > required then testing with AT would no longer be
> technically required.
> > And I think you would find there would be less work with AT vendors
> > and then things would change rapidly. This is the primary
> concern of
> > AT vendors and consumers.
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> > *From:* = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] *On
> Behalf Of *Tom
> > Brett
> > *Sent:* Monday, October 08, 2007 4:22 AM
> > *To:* 'TEITAC General Interface Accessibility Subcommittee'
> > *Subject:* Re: [teitac-general] FPCs
> >
> > A philosophy that has been employed by the more
> technically astute
> > 508 coordinators is that if the product was developed in
> > accordance with the technical standards and the AT
> still would not
> > allow the employee or member of the public to access
> the EIT, the
> > most likely problem was with the AT not with the product.
> >
> > Still the Government has a responsibility to provide
> access to the
> > EIT. If the EIT is inaccessible using the employee's
> preferred AT,
> > this then becomes a decision point for the Government
> manager.does
> > she say find an alternative or work with the AT vendor
> and product
> > manufacturer to find a reasonable solution. In my
> experience, most
> > managers will take the easy way and look for an alternative. The
> > alternative can take the form of giving the employee
> different job
> > duties that do not require her to access the EIT or providing
> > different AT. That AT will require additional training and there
> > could be a learning curve but the Government would be
> responsible
> > for paying for that training.
> >
> > If the product has the capability to work with AT because the
> > manufacturer has developed the product in accordance with the
> > technical standards and can demonstrate that the
> product meets the
> > technical standards then the manufacturer can say they have met
> > the 508 standards.
> >
> > The FPC really fall on the Government.not the manufacturer.
> >
> > Tom Brett
> >
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> > *From:* = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
> > *Gregg Vanderheiden
> > *Sent:* Sunday, October 07, 2007 11:41 PM
> > *To:* 'TEITAC General Interface Accessibility Subcommittee'
> > *Subject:* Re: [teitac-general] FPCs
> >
> > As was pointed out by several people, the new 508 technical
> > provisions are much better than the old ones but are
> still a long
> > way from being an API. A better characterization is that they
> > describe the requirements on an API. Thus it is very possible to
> > meet the current Technical Provision and not provide
> access to the
> > functionality of the product.
> >
> > There is currently a question on the table as to
> whether a product
> > that has no AT that works with it - can claim to meet 508 via AT
> > compatibility.
> >
> > Some feel it should since it isn't the manufactures problem that
> > AT doesn't work with their product (if there is no known bug in
> > their end)
> >
> > Others feel that the purpose of 508 is to allow employees of the
> > government (and the public for public E&IT) to have access to
> > E&IT. that means that the E&IT is either directly accessible or
> > works with real AT that the people can get. Otherwise
> there is no
> > way for them to use the E&IT to do their jobs.
> >
> > See discussion page.
> >
> > I am hoping that we can find a common ground that says that AT
> > must exist. That lets agencies specify what needs to exist. And
> > that can address the "it worked a minute ago until they updated
> > the AT" and related problems.
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> > *From:* = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] *On
> Behalf Of
> > *Phill Jenkins
> > *Sent:* Tuesday, September 25, 2007 9:02 AM
> > *To:* = EMAIL ADDRESS REMOVED =
> > *Subject:* Re: [teitac-general] FPCs
> >
> >
> > > I don't understand this.
> >
> > What part?
> >
> > > When I say '508' I mean the entire process,
> everything that
> > applies, not just the narrow Technical Provisions.
> > > If we mean 'Technical Provisions', we should say that. I'm
> > trying to reinforce the reality that the FPCs are
> *part* of 508.
> >
> > What do you mean by 'narrow Technical Provisions'? >From a
> > software or web application developer view, they are very
> > comprehensive and inclusive. I too am trying to
> reinforce the
> > reality of the FPCs as *part* of 508. And I believe I do
> > mention and will continue to try to say Technical Provisions
> > (TPs) when I specifically mean that part of 508.
> >
> > Do you agree with me that
> > A product that has only one or more ATs customized for it by
> > the agency or vendor
> > _ instead_ of meeting the TPs
> > is _not_ more 508 compliant than a product that meets all of
> > the TPs?
> >
> > Or are you saying that meeting the FPCs satisfies 508 and
> > trumps not meeting all the TPs?
> >
> > When a product requires AT (not self voicing, not self
> > magnifying, etc.), that is when meeting the TPs should be
> > sufficient, at least from an industry view when completing a
> > VPAT. Because meeting the TPs is what TEITAC has defined as
> > supporting AT. So industry is done then and its the agency
> > that has to provide the AT customization if necessary for
> > meeting the FPCs? Or are you saying industry is not done and
> > in addition to meeting the TPs they also have to have the AT
> > customized to meet the FPCs as well?
> >
> > Products meeting the TPs and then failing to be as usable as
> > desired with a particular AT (failing to meet the FPCs)
> > happens all the time. Its probably more often that
> the product
> > fails to first to even meet the TPs, so industry is still
> > focused on that half. AT does have a role in completing the
> > solution. But everyone keeps telling me that 508 doesn't
> > address AT. If it does - where?
> >
> > When the product does *not* need AT, that is when the FPCs
> > should be used because FPCs address the whole solution
> > (including self voicing, self magnifying, etc.). If you
> > require the FPCs to be used in addition to meeting the TPs,
> > and there is AT involved, then therein lies the problem.
> >
> > Regards,
> > Phill Jenkins
> > IBM Research - Human Ability & Accessibility Center
> > http://www.ibm.com/able
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> >

• Next message in Thread: None
• Previous message in Thread: Peter Korn: "Re: FPCs"