Thread Subject: Re: Section 3 provisions for discussion on the 11/27 Plenary call

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: Creagan Tim
Date: Mon, Nov 26 2007 9:30 AM

There are TWO conference calls this week: the TEITAC conference calls
are on Tuesdays, starting 11/27 and continuing every Tuesday, 11/27,
12/4, 12/11 and 12/18.

The Task Force conference calls (which are ONLY open to Task Force
members. See Mike, Tim or Jim about this.) will be held starting on
Wednesday, 11/28, and continuing until Dec. 19th, as needed.

Note: TEITAC calls are open to the general public and all TEITAC
members. During the TEITAC calls, ALL substantive remaining work of the
TEITAC will be discussed and completed.

The Task Force calls are ONLY a small caucus of TEITAC members who
volunteered to work on putting together a document which distinguishes
between those provisions covered under Section 255 and those under
Section 508. The document will be disseminated by the Task Force and
discussed by the full TEITAC at the Dec. 4th call. This was discussed
at the last face to face meeting, November 16th.

I hope this clarifies the situation.

Tim

Timothy P. Creagan
Senior Accessibility Specialist
U.S. Access Board
1331 F Street, N.W.
Suite 1000
Washington, DC 20004-1111

202-272-0016 (V); 1-(800) 872-2253 (V)
202-272-0082 (TTY);1-800-993-2822 (TTY)
202-272-0081 (Fax)
= EMAIL ADDRESS REMOVED =

"Thank you for your questions concerning section 508 of the
Rehabilitation Act Amendments of 1998. Section 508 authorizes the
Access Board to provide technical assistance to individuals and Federal
departments and agencies concerning the requirements of this section.
This technical assistance is intended solely as informal guidance; it is
not a determination of the legal rights or responsibilities of entities
subject to section 508."

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of James
Elekes
Sent: Monday, November 26, 2007 11:16 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Section 3 provisions for discussion on
the 11/27 Plenary call

Jim,

Bit confused. Acccording to earlier E-Mail from Tim, the schedule
calls for us to meet Wednesday, November 28th. Is it Tuesday or
Wednesday.

Thanks,

-Jim

James J. Elekes, M.Ed, MPA, CPM
(O) 888.564.8430
(E) = EMAIL ADDRESS REMOVED =


At 11:03 AM 11/26/2007, you wrote:
>Hi All,
>
>Below are the provisions we will be discussing on tomorrow's call; we
are
>sending them out like this so you can have them all in one place with
full
>text. Each item shows its 10/26 draft, any comments and an editorial
reply,
>and the new draft.
>
>These provisions have been selected because they have recently been
edited
>to reflect all current comments. We hope that this means they can be
>approved by the Committee with little discussion and no further
editing.
>Thanks in advance for your forbearance.
>
>***
>
>3-A Color
>
>10/26 draft:
>Color must not be used as the only visual means of conveying
information,
>indicating an action, prompting a response, or distinguishing a visual
>element. For example, mandatory form fields are identified with red
text and
>labeled as "mandatory".
>
>Comments:
>Gregg was concerned about harmonizing with WCAG; this language is now
>identical.
>ITAA wanted an example; one was added to this draft.
>
>Proposed draft:
>No change.
>
>***
>
>3-C Size, shape, location
>
>10/26 draft:
>Instructions provided for understanding information and operating user
>interfaces must not rely on shape, size, visual location, or
orientation of
>components.
>. Note: Object information provided per the "Information and
>Relationships", "User Interface Components", or "AT interoperability"
>provision that describes the necessary visual cues or relationships can
be
>used to meet this provision.
>. Note: This applies to onscreen information only.
>
>Comments:
>Allen H: Shouldn't this include the phrase "as the only means of
conveying
>information"? Agreed; adding "solely" in new draft
>ITAA: Remove second note; Agreed.
>ITAA: Add example; Agreed.
>ITAA and Hajime: Add "onscreen" to clarify application; agreed.
>
>Proposed draft:
>Instructions provided for understanding information and operating
on-screen
>user interfaces must not rely solely on shape, size, visual location,
or
>orientation of components.
>
>Example: A user of a screen reader cannot discern which on-screen
button he
>or she needs to trigger if the desired button is only identified by a
visual
>characteristic such as shape, size or location such as "When done press
the
>button on the right" or "round button" or "large button" or "arrow
pointing
>to the right".
>
>***
>
>3-F Non-text objects
>
>10/26 draft:
>All non-text objects that are presented to the user must have a text
>alternative that presents equivalent information, except for the
situations
>listed below.
>. Controls-Input: If a non-text objects is a control or accepts
user
>input, then it must have a name that describes its purpose. (See also
User
>Interface Components provisions)
>. Media: If a non-text object is synchronized media, live
audio-only
>or live video-only content, then text alternatives must identify at
least
>the non-text object with a descriptive text label. (For synchronized
media,
>see also Audio and/or Video provisions)
>. Test: If a non-text object is a test or exercise that must be
>presented in non-text format, then text alternatives must identify at
least
>the non-text object with a descriptive text label. (For synchronized
media,
>see also Audio and/or Video provisions)
>. Sensory: If a non-text object is primarily intended to create a
>specific sensory experience, then text alternatives must identify at
least
>the non-text object with a descriptive text label. (For synchronized
media,
>see also Audio and/or Video provisions)
>. CAPTCHA: If the purpose of a non-text object is to confirm that
>content is being accessed by a person rather than a computer then text
>alternatives that identify and describe the purpose of the non-text
object
>must be provided and alternative forms in different modalities must be
>provided to accommodate different disabilities.
>. Decoration, Formatting, Invisible Objects: If a non-text object
is
>pure decoration, or used only for visual formatting, or if it is not
>presented to users, then it is implemented such that it can be ignored
by
>assistive technology.
>. Note: In order to achieve this provision, non text objects in
data
>operated on by the software would need to be associated with textual
>equivalents that the software can obtain as readily as it can obtain
the
>non-text object itself. Where a non-text object is a scanned image of
text,
>textual equivalents would need to allow for the inclusion of the text
of the
>scanned image of text. Where a non-text object is a dynamic
presentation,
>graphs, or other derived information from a data source, textual
equivalents
>would need to allow for the inclusion of the data used.
>
>Comments:
>ITAA: number exceptions instead of bullet; Agreed.
>ITAA: define CAPTCHA; Agreed.
>Other comments were on typos that are now fixed.
>
>Proposed draft:
>All non-text objects that are presented to the user must have a text
>alternative that presents equivalent information, except for the
situations
>listed below.
>1. Controls-Input: If a non-text objects is a control or accepts user
input,
>then it must have a name that describes its purpose. (See also User
>Interface Components provisions)
>2. Media: If a non-text object is synchronized media, live audio-only
or
>live video-only content, then text alternatives must identify at least
the
>non-text object with a descriptive text label. (For synchronized media,
see
>also Audio and/or Video provisions)
>3. Test: If a non-text object is a test or exercise that must be
presented
>in non-text format, then text alternatives must identify at least the
>non-text object with a descriptive text label. (For synchronized media,
see
>also Audio and/or Video provisions)
>4. Sensory: If a non-text object is primarily intended to create a
specific
>sensory experience, then text alternatives must identify at least the
>non-text object with a descriptive text label. (For synchronized media,
see
>also Audio and/or Video provisions)
>5. CAPTCHA: If the purpose of a non-text object is to confirm that
content
>is being accessed by a person rather than a computer then text
alternatives
>that identify and describe the purpose of the non-text object must be
>provided and alternative forms in different modalities must be provided
to
>accommodate different disabilities.
>6. Decoration, Formatting, Invisible Objects: If a non-text object is
pure
>decoration, or used only for visual formatting, or if it is not
presented to
>users, then it is implemented such that it can be ignored by assistive
>technology.
>Note: In order to achieve this provision, non text objects in data
operated
>on by the software would need to be associated with textual equivalents
that
>the software can obtain as readily as it can obtain the non-text object
>itself. Where a non-text object is a scanned image of text, textual
>equivalents would need to allow for the inclusion of the text of the
scanned
>image of text. Where a non-text object is a dynamic presentation,
graphs, or
>other derived information from a data source, textual equivalents would
need
>to allow for the inclusion of the data used.
>Adding the following definition of CAPTCHA (from WCAG 2.0) to 1194.4:
>
>CAPTCHA: Initialism for "Completely Automated Public Turing test to
tell
>Computers and Humans Apart"
>Note 1: CAPTCHA tests often involve asking the user to type in text
that is
>displayed in an obscured image or audio file.
>Note 2: A Turing test is any system of tests designed to differentiate
a
>human from a computer. It is named after famed computer scientist Alan
>Turing. The term was coined by researchers at Carnegie Mellon
University.
>
>***
>
>3-G Human Language
>
>10/26 draft:
>When presentation of electronic documents supports it, the default
human
>language of electronic documents can be programmatically determined.
>
>Comments:
>Hajime: not clear what "it" refers to; agreed.
>Andi and others: does not use regulatory "must"; agreed.
>
>Proposed draft:
>When supported in the presentation of electronic documents, the default
>human language of electronic documents must be programmatically
>determinable.
>
>***
>
>3-H Language of parts
>
>10/26 draft:
>When presentation of electronic documents supports it, the human
language of
>each passage or phrase in electronic documents can be programmatically
>determined.
>
>Comments:
>Hajime: not clear what "it" refers to; agreed.
>Andi and others: does not use regulatory "must".
>
>Proposed draft:
>When supported in the presentation of electronic documents supports,
the
>human language of each passage or phrase in electronic documents must
be
>programmatically determinable.
>
>***
>
>3-J Flashing
>
>10/26 draft:
>Content and applications must not contain anything that flashes more
than 3
>times in any one second period or the flashing is below the general
flash
>and red flash thresholds."
>
>Comments:
>One addressed the flashing provision in General section; no longer
relevant.
>Andi and others: should not refer to "applications"; wording unclear;
>Agreed.
>
>Proposed draft:
>Content and user interfaces must not contain anything that flashes more
than
>3 times in any one second period or the flashing is below the general
flash
>and red flash thresholds.
>
>***
>
>3-S Keyboard Operation
>
>10/26 draft:
>Where products have a keyboard or a keyboard interface, all
functionality of
>the product operable through the user interface must be operable
through the
>keyboard, or a keyboard interface. Specific timing for individual
keystrokes
>must not be required. This provision does not apply where the
underlying
>function requires input that depends on the full path of the user's
>movement, not just the endpoints.
>
>Comments:
>Closed Subcommittee, ITI, and ITAA: add phrase to front: "For products
that
>have a keyboard or keyboard interface, or content that can be viewed on
>devices that have a keyboard."; Agreed.
>ITAA: Define Keyboard; agreed.
>
>Proposed draft:
>Where products have a keyboard or a keyboard interface, or content that
can
>be viewed on devices that have a keyboard, all functionality of the
product
>operable through the user interface must be operable through the
keyboard,
>or a keyboard interface. Specific timing for individual keystrokes must
not
>be required. This provision does not apply where the underlying
function
>requires input that depends on the full path of the user's movement,
not
>just the endpoints.
>
>And adding a definition of keyboard to 1194.4: "A set of systematically
>arranged keys by which a machine or device is operated such as a
computer
>keyboard, a cellphone keypad, or a television remote control."
>
>
>
>***
>Jim Tobias
>Inclusive Technologies
>+1.732.441.0831 v/tty
>+1.908.907.2387 mobile
>skype jimtobias
>
>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University