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: James Elekes
Date: Mon, Nov 26 2007 9:15 AM

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