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: Randy Marsden
Date: Tue, Oct 16 2007 9:05 AM

My apologies for missing yesterday's General FPC meeting. It's
Closing the Gap this week, and I am already enroute. Had we known
this was on the agenda, we most certainly would have tried to have
someone on the call. Again - my apologies. This week has to be
dedicated to our day jobs for most of the AT companies involved in
TEITAC.

-Randy



On Oct 15, 2007, at 9:16 PM, Gregg Vanderheiden wrote:

> 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
>
> [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.
> "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 ).
> If a product works with AT except for particular aspects, the
> vendor can report "Works except for the following function(s):"
> 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
>
> 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
>
> Should 508 standard or its preamble make any statement about which
> or how many AT?
> 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?
> 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