Thread Subject: Re: 3-U comment
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: Peter Korn
Date: Thu, Mar 06 2008 8:20 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: None
- Previous message in thread: Sean Hayes: "3-U comment"
- Messages sorted by: Author | Thread | Date
Hi Sean,
Good catch, thanks. I think your proposal for language is sound and has
my ovte.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> My apologies that I was unable to participate fully in the discussion
> on this and only caught the last 40 minutes or so. I have read the
> transcript, and I hope I am up to date with the discussion.
>
>
>
> I think I'm OK with the new consensus language of 3-U but want to
> raise a couple of issues
>
>
>
> 1 The title is not in italic, but I don't believe it is has made
> consensus -- can we clarify please?
>
>
>
> 2 The exercise to remove AT, has missed a bit in clause 2:
>
>
>
> 2. expose a list of actions that can be executed on an object and
> allow assistive technology to programmatically execute any of those
> actions;
>
>
>
> Suggested rewrite:
>
>
>
> 2. expose a list of actions that can be executed on an object and
> allow programmatic execution of any of those actions;
>
>
>
> 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 *Mike
> Paciello
> *Sent:* 04 March 2008 18:07
> *To:* 'TEITAC Committee'
> *Subject:* Re: [teitac-committee] Functional Performance Criteria
>
>
>
> Thanks Gregg. Appreciate the effort.
>
>
>
> - Mike
>
>
>
> Mike Paciello
>
> Cell: +1.603.566.7713
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
> *Gregg Vanderheiden
> *Sent:* Tuesday, March 04, 2008 12:46 PM
> *To:* 'TEITAC Committee'
> *Subject:* [teitac-committee] Functional Performance Criteria
>
> Apologies for the last minute posting on this. Since we didn't
> get to AT (last weeks agenda) I didn't expect that we would be
> doing FPC this week.
>
>
>
>
>
>
>
> Here is an attempt to address the issues around FPC and find a
> common ground
>
>
>
>
>
> 1) It moves the AT text to the header which makes it easier
> to cover the 508/255 issue and to explain that (for 508) AT
> should be an option and why.
>
> 2) It makes the provisions more testable
>
> 3) It shows the relationship between FPC and the Technical
> Provisions
>
> 4) It combines Version 1 and version 2 of the Header
> (Version 1 is first and last sentence (#3) and version two
> contributes bullets #1 and #2)
>
> 5) All FPC are now worded in testable language.
>
>
>
>
>
>
>
>
>
>
>
>
> FPC INTRO (note -- this would have to be directly with the
> provision in the standard -- and not in an introduction or
> preamble -- in order for this to work.
>
>
>
>
>
> The purpose of the Functional Performance Criteria is to help
> Federal departments or agencies determine whether products being
> used, developed, procured or maintained meet the functional needs
> of individuals with disabilities. The functional performance
> criteria have three roles:
>
> 1. If any of the technical provisions are not met, the
> Functional Performance Criteria must be used to see if access is
> provided in another way (i.e. through equivalent facilitation).
>
> 2. If the technical provisions are met, the Functional
> Performance Criteria must be used to see if the technical
> provisions cover all aspects needed to provide access to the
> product. (i.e overall evaluation)
>
> 3. The Functional Performance Criteria can also be used to
> help departments and agencies identify and report product
> functions that may not meet the Functional Performance Criteria
> and evaluate the importance of the lack of access to those
> functions relative to the intended use of the product.
>
> The FPC state what should be possible with the product, but do not
> specify specifically how this would be accomplished. In some
> cases the access to the functionality of the product may be
> direct, without any assistive technologies. In other cases the
> access may be possible if a piece of assistive technology is used
> in conjunction with the product (screen reader, special keyboard,
> etc.). Either means for achieving access would satisfy section
> 508. For section 255, access must be direct if that is readily
> achievable. If not, then access via assistive technology must be
> provided if it is readily achievable.
>
>
>
>
> A - Without Vision
>
> * Products must provide at least one mode that allows access
> to all functionality of the product without using vision.
>
>
> B - With Limited Vision
>
> * Products must provide at least one mode that allows access
> to all functionality of the product visually without
> requiring visual acuity greater than 20/70 and without
> relying on audio output.
>
>
> C - With Color Vision Deficits
>
> * Products must provide at least one mode that allows access
> to all functionality without relying on users' perception of
> color.
>
>
> D - Without Hearing
>
> * Products must provide at least one mode that allows access
> to all functionality of the product without user hearing.
>
>
> E - With Limited Hearing
>
> * Where audio information is important for the use of a
> product, it must provide at least one mode that allows user
> control of volume and/or reduction of background noise.
>
>
> F - With Low Vision and Limited or No Hearing
>
> * (remove -- covered by 1-B)
>
>
> G - Without Speech
>
> * Products must provide at least one mode that allows access
> to all functionality of the product without requiring user
> speech.
>
>
> H - With Limited Reach, Strength, or Manipulation
>
> * Products must provide at least one mode that allows access
> for people within ADAAG reach limits and without requiring
> pinching, twisting of the wrist, tight grasping, or
> simultaneous actions.
>
>
> I - Without Physical Contact
>
> · Products must provide at least one mode that allows
> access to all functionality of the product without requiring any
> physical contact with the product beyond initial connection and
> setup of a special interface device.
>
> Note: While it is preferable that no contact at all be required,
> the use of a standard physical connection such as a USB would meet
> this provision.
>
>
> J - With Cognitive, Language or Learning Limitations
>
> · {This provision subject to wording that would be testable}.
>
>
>
>
>
> ALSO to work with these FPC --
>
>
>
>
> 1-E - Visual Information (Partial recommendation, No quorum)
>
> All information that is needed for operation and use that is
> provided in visual form must also be available in at least one
> mode in audio form or in /simple/ tactile form, either directly or
> {ending to be determined in AT discussion}. Visual content that
> includes text and that is closed due to Digital Rights Management
> (DRM) such that it cannot be rendered in audio form by AT and
> other players must include an audio form that can be.
>
> Note 1: Section 255 and Section 508 treat AT solutions
> differently, so review section XX of this document before
> implementing a solution.
>
> Note 2: Braille is not a simple tactile form. It is encouraged but
> cannot be used to satisfy this provision.
>
>
>
>
> 1-H - Speech Operation
>
> If a product includes operation via user speech, there must be
> an alternative non-speech mode of operation for all functions
> operable by speech.
>
> Or
>
> All functions operable via user speech must also be operable in
> a manner that does not require user speech.
>
>
>
>
>
>
>
>
>
> Gregg
>
> ------------------------
>
> Gregg C Vanderheiden Ph.D.
> Professor - Depts of Ind. Engr. & BioMed Engr.
> Director - Trace R & D Center
> University of Wisconsin-Madison
> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>
> DSS Player at http://tinyurl.com/dho6b
>
> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>
> <http://trace.wisc.edu:8080/mailman/listinfo/>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
- Next message in Thread: None
- Previous message in Thread: Sean Hayes: "3-U comment"