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: Salaets, Ken
Date: Mon, Nov 26 2007 2:05 PM

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