Thread Subject: Re: FPCs

From: Jim Tobias
Date: Mon, Sep 24 2007 11:40 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Hoffman, Allen: "Re: FPCs"
• Previous message in thread: Phill Jenkins: "Re: FPCs"
• Messages sorted by: Author | Thread | Date

I don't understand this. 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.


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




_____

From: Phill Jenkins [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, September 24, 2007 1:02 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-general] FPCs



Thanks Gregg for taking a pass at my questions. I'm not a lawyer either,
but I must have been staying at a different Holiday Inn <smile> cause I
really do see the answers differently. Maybe it is just semantics between
policy and standards, so please understand I'm trying to make progress here.


Perhaps it is also my past experience working with hundreds of engineers
across IBM and some clients over the last decade (pre WCAG 1.0 and pre 508),
and perhaps it is also from experience working on both sides (wearing both
hats) of the accessible solution - developing the AT (such as Screen Reader
for OS/2, Home Page Reader, Java Self Voicing kit, etc.) and developing the
mainstream technology to be supported by AT, such that when the two both
support each other there is an accessible solution that a person with a
disability can successfully use to maintain their employment. But the way
I've been using 508 policy and standards is subtlety but almost strikingly
different. By going through each of your answers I'll hope to be able to
make that clearer.

Regards,
Phill

> My understanding of the answers to your questions are:
>
>1) RE can AT customization be used for Equiv facilitation
>yes - anything can be used for equivalent facilitation.

Yes, O.K.

> Use of AT is allowed as a means to meet 508.

Not exactly. Sure AT needs to be purchased and supplied by the agency to
meet the 508 "goals"and of course the "use of AT is allowed" and required in
many cases to meet the goals of 508. But the use of AT has little if
anything to do with meeting the 508 "standards". I've always treated 508 as
both a policy - such as "purchase good stuff", and as a standard - the
definition of what "good stuff" is. Use of AT is not part of the product's
means for meeting the technical provisions. For example the TPs require the
product to provide keyboard access, the focus indicator, and the name and
role of the object - but it is the AT that presents that information to the
end user. There are no TPs requiring the AT to do its half.

> So use with AT with customization should also be allowed to meet 508
> (presuming you actually have the customization and aren't just saying 'it
would work if someone would customize it').

Not to meet 508 'standards'. Yes it should be allowed for the agency to
meet its mission of accommodating individuals, and is related to the policy
of 508. But when I add the term "standard", then I do not agree that AT
with customization is meeting the technical provision. For example, if I
customize JAWS to speak the label of an entry field to its right (instead of
left) on a 3270 green screen emulation product, it is equiv facil, but the
product still fails that 508 standard. And because it was the AT that was
customized, not the product, it probably won't work with other ATs such as
screen magnifiers and other screen readers without customizing them as well.


> Remember it is the Agency that complies with 508 Standards.

No, it is the product that complies with the 508 Standards, the agency
complies with the 508 Policy. Sure it is the agency that is procuring the
product, but see the subtle but striking difference? And yes the 508 policy
only applies to agencies, and yes the vendor or manufacture does not have to
comply to the technical standards.

> 2) RE can Equiv Facil be used to meet 508 standards
> Equivalent facilitation is indeed meeting 508 (or rather the 508
standard). That is the meaning of equivalent facilitation clause.

No, I don't see equiv facil as meeting the technical provision of the 508
standards. Equiv facil is a means to still meet the policy of 508 and
social goals, and the role of the FPC is check that the eqiv facil does in
fact allow the product to be used with out vision, etc. But an agency can
quickly go down a rat hole when assuming AT customization is meeting 508
standards; the agency has to soon ask or accept which AT is customized, and
if the vendor provides a WindowEyes custom solution, but the agency wanted a
JAWS customized solution as an example, you soon realize that this is
outside the scope of 508 purchasing policy. The product didn't meet the
TPs, so neither customized solution meets the 508 Standards. Of course the
agency is still free, as does SSA and others do, to specify the AT they want
customized. But that requirement is outside of 508.

> I would have to ask the access board if equiv facil of a provision means
that you fail the provision
> but pass 508 via equiv facilitation, - or whether it means that you pass
the provision via equivalent facilitation.

Yes, getting a reading from the Access Board and perhaps DOJ would be
helpful. I tend to view it as if product fails the technical provision,
then it fails 508 unless AT is not required. So, if AT was included in the
"product bundle" (i.e., self voicing, self magnifying, etc.), then it could
"pass" 508 FPC without requiring additionally purchased AT and avoiding the
need to comply with the TPs that support separate AT.

> RE: technical provisions covering software.
> They don't really. They only cover some aspects of Software and
interface. For example there are no provisions covering free space gestures
- though those are beginning to appear in products.

Hmm, I believe the keyboard input provision would apply to gesture input,
voice input, or any other input.

> They cover a lot - and most of the interface techniques in common use
today. But they are not comprehensive today nor in the future.

Yes, but I think they cover everything we know about today. Even 3D
environments. And free space gesture input. I do understand that the 3D
environments do not comply with the technical provisions, not that we need
more technical provisions. And even if they did comply with the ones we
have, there is no AT that supports them. In other words, I believe the
framework for accessibility is well established in the 508 standards. But
again, it's only half of the equation - you still need AT that supports the
role=avitar or object=island to make it useful as a role=tree view or
object=video that you can interact with today.

>There was a statement that .21 did meet one particular FPC (the first one).


Yes.

> But other text clearly says that FPC are to be used in addition to
Technical as the overall evaluation.

Mostly, in fact it is in the same text I quoted. The text says that the FPC
is "for overall product evaluation and for technologies or components for
which there is no specific requirement under other sections. . .", but it
does not mention "in addition to Technical".

>RE technical provisions covering FPC.
>If the section is read carefully one can see that it only says that .21
covers the FPC for No Vision.

Yes, so we're in agreement for only the first FPC then?

>The sentences before that one say that the FPC should also be used for
overall assessment - beyond the technical.

Also? Yes for BOTH overall assessment AND beyond technical provisions for
technologies or components for which there is no specific requirement.
However, by changing the "product categories" in the current 508 to "product
functions", we may have a framework that will always have requirements that
apply. In other words I'm now not going to have the chance to say that my
web application doesn't have to be keyboard accessible because only the
current Software (not Web) set of provisions included a keyboard
requirement.

> So in general this looks like FPC are intended to be used in addition to
the technical - not just if technical fail.

No. I view that the FPC only need to be used when the product doesn't
support AT. Its not exactly that black & white because some of the latter
FPC are almost identical to some of the TPs, especially those not requiring
AT - direct TPs as we started to call them. I also view the first FPC as
setting the precedent, where perhaps you're viewing the first one as an
exception. If we include the first FPC as an exception to only having to
apply the FPC if some technical provisions fail - then might we be being too
burdensome and vague in our requirements? There are clearly provisions that
don't apply to vision. So if a product meet all the TPs except it fails to
provide captions for audio, would the first FPC still need to be applied? I
would not ask my engineers to apply the first FPC with a vague and
burdensome requirement like that. They need to know when they are done and
what to report back to the procuring agency, and the agency need to know
what to expect in the response.

> RE: AT Support.
> There is much discussion on this.
> First - there is no requirement on vendors to have AT support because 508
standards
> are not industry requirements but rather they are agency requirements.

Yes, but not really. The 508 standards do apply to products being purchased
by agencies. Sure a vendor doesn't have to respond to the bid, and there is
no legislation that requires the product to comply with the 508 standards,
but the TPs clearly have to do with product, not the agency. Again I view
508 policy as a different part from the 508 standard. Just like I view WCAG
as a standard, but not a policy. The EU or any other institution can create
a policy that says one has to only purchase, or to only develop, or to only
host a website that complies with the WCAG technical standard - or it could
be a similar policy that requires compliance with the 508 technical
standards - which many States and other institutions are adopting.

> Agencies are (and should be) required to consider whether there is any or
sufficient support by AT
> (i.e. AT that works with product) for products they are considering
purchasing -
> and that agencies preferentially purchase products (that meet their
purchase requirements)
> that have support from AT vs products that do not have support of AT.

Wow, that is not what I read the 508 policy, standards, or Access Board
guidance to say. Although personally I would like to see this as it would
mean more accessible jobs for people with disabilities. I would like an
Access Board and DOJ opinion on this interpretation.

> This responsibility stems from 508 law itself
> (whose purpose is to see that people with disabilities can actually use
the E&IT in government)

Yes, but "stems from" sounds like the lawyer opinion at the Holiday Inn
talking . . . We would need a legal ruling.

> and should be reflected in the standards.

I do not agree with reflecting policy into technical standards. And if AT
is included in the 508 policy and/or standard, then it needs to be more
explicit and there needs to be TPs that apply to AT, at least to screen
readers, magnifiers, and such that need to support the TPs being complied
with in the procured products.

> Industry can help Agencies by identifying what AT works with their
products
> - but there is certainly no requirement that they do so (since the 508
standards are for agencies - not companies).

Yes, both industry and AT vendors could tell the agency if and how they know
they comply with the TPs. Yes, neither 508 policy nor 508 standards
currently require that - for products to disclose which AT was used in
testing (whether tested by the agency or by the vendor), but I think there
is general agreement in industry to amend the VPAT guidance to include which
AT and inspections tools were used to test compliance. This is currently
IBM practice to include which AT and tools were used in the VPAT itself.
But that doesn't cause any change to the technical standards (TPs) in 508.


>This all comes together quite nicely with your question.
>> "So is it the agency's, vendor's, or AT's responsibility to provide the
AT customization to fully support the product
>> that is fully compliant with the technical provisions?"
> I think the answer is fairly clear that all of the responsibilities are
the Agency's.
> 508 does not place any responsibilities on industry.
> Agencies may ask for information from companies to help them in their
responsibilities.
> But the responsibilities are with the agency.

"All of the responsibilities"? Not really. Sure the 508 policy only
applies to agencies, but clearly the 508 TPs (standards) apply to the
product. I suppose an I/T vendor could say: "hey, its the agencies problem
to provide the AT customization", and I believe that should be the case if
and when the vendor's product has fully met the TPs. By allowing an agency
or vendor to say it complies with the technical provisions (designed to
allow AT to interoperate with the product) by providing customization for a
specific AT as an equi facil, then doesn't that create vendor favoritism,
non-competition, and reduced innovation? You're right that I/T vendors
don't have the responsibility, but vendors are choosing to respond to an
agency bid and many have volunteered to include in their response how the
product complies with each TP standard and which AT or tool was used in
testing. Feedback to me has been that if the product meets the TPs and the
ATs or tools used to test were listed also listed in the VPAT, then its
sufficient for agency market research for purchasing decisions.

> I think a good way to stay centered is to look at the intent of 508.
> The intent of 508 is clearly to ensure that people with disabilities can
actually use E&IT.

Yes that is the goal, but I view 508 as "helping to ensure" because there
are no TPs applying to the AT. There is no guidance or proposed text to
provide guidance to agencies to request how the AT supports the 508
standards. I believe that Industry and AT want to continue to work
together, but the 508 technical provisions (standards) do not apply
currently to AT, only to products.

> And the 508 language is that
>(i) individuals with disabilities who are Federal employees to have access
to and use of
> information and data that is comparable to the access to and use of
> the information and data by Federal employees who are not individuals
> with disabilities; and
> (ii) individuals with disabilities who are members of the public seeking
information
> or services from a Federal department or agency to have access to and use
of
> information and data that is comparable to the access to and use of the
> information and data by such members of the public who are not individuals
with disabilities.
> It does not talk about compatibility with AT. It talks about access.

Yep, not here anyway. These are the goals not the technical standards.

> If the product is not directly accessible, then access through AT would
seem to be OK.

Yes, that is the whole purpose of providing that non-direct technical
provisions - so that access through AT is possible.

> But potential access, or future access is not discussed.
> I think it would need to work with AT that the users have or can be
assumed to be able to get.
> No?
> Gregg

Yes, that is the goal of 508. But until 508 applies to AT, that is not the
role of the FPCs nor the TPs for products that require AT support. So
currently, outside of 508, the agencies and industry could and should
encourage AT vendors to support the enablement in products that comply with
the technical provisions.

Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able

• Next message in Thread: Hoffman, Allen: "Re: FPCs"
• Previous message in Thread: Phill Jenkins: "Re: FPCs"