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: Jim Tobias
Date: Mon, Nov 26 2007 9:20 AM

Tuesday is the whole Committee plenary call; Wednesday is the Task Force on
255/508.

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


> -----Original Message-----
> From: James Elekes [mailto: = EMAIL ADDRESS REMOVED = ]
> 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