Thread Subject: Re: Section 3 provisions for discussion on the11/27Plenary 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 2:15 PM

yes; we just do what andi tells us.

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


> -----Original Message-----
> From: Salaets, Ken [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, November 26, 2007 4:04 PM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] Section 3 provisions for
> discussion on the11/27Plenary call
>
> Thanks, Jim. This is a useful format. I noticed that other
> Section 3 provisions that have not yet achieved consensus are
> not on the list. I assume that you and Mike are endeavoring
> to bring closure on the "low hanging fruit" first, correct?
>
> Thanks,
>
> Ken
> I T I
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: Monday, November 26, 2007 11:03 AM
> To: 'TEITAC Committee'
> Subject: [teitac-committee] Section 3 provisions for
> discussion on the 11/27Plenary call
>
> 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