Thread Subject: Re: Section 3 provisions for discussion on the 11/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: Marlaina Lieberg
Date: Mon, Nov 26 2007 4:45 PM

I am unable to make tomorrow's call, as I'll be flying. However, here are
my thoughts which I'd express if I were present. Thanks in advance for
considering them.

Marlaina Lieberg
American Council of the Blind


> 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.
>
> ***
If I'm reading this correctly, it seems we are saying form fields could be
in red text. red is very difficult for people with low vision to read in
general.


> 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".

Agree, thank you.

> ***
>
> 3-F Non-text objects
>
> 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.
>
Agree.

> ***
>
> 3-G Hu***
>
> 3-H La3-S Keyboard Operation
>
> 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."
Agree.



>
>
> ***
> 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