Thread Subject: Text and the importance of programmatically determinable

Return to this mailing list's archives

From: Gregg Vanderheiden
Date: Tue, Mar 18 2008 10:40 AM
Subject: Text and the importance of programmatically determinable

Hi



I also had run a complete analysis - but was hesitant to post it.

But since it came up with a different conclusion here it is.



I agree that clearing up text would cause us to need to change some
provisions or definitions (just 3)



But if we do not make it clear in the definition that text must be PD it
would cause us to have to change 25.



Several that Sean posted are already fixed in today's drafts - or are not a
problem (see below). They don't require text to be programmatically
determined, but the wording of the provisions accounts for that definition.
For example they already say "text or images of text"





For all 25 of these provisions it is essential that text be electronically
accessible by AT or the provisions do not work.


1. Note: Simple text editors that can only create or modify content in
conforming formats by directly editing the code are not considered authoring
tools under this definition.
2. Note 1: CAPTCHA tests often involve asking the user to type in text
that is presented in an obscured image or audio file.
3. Content (Consensed) Information and sensory experience to be
communicated to the user by means of software, including but not limited to:
text, images, sounds, videos, controls and animations, as well as the
encoding that defines the structure, presentation, and interactions
associated with those elements. For example: word processing files,
presentation files, spreadsheet files, text files, portable document files,
web based content, etc.
4. Label (Consensed) Text or other component with a text alternative
that is presented to a user to identify a component within content.
5. Non-text Object (Consensed) Any object that is not a sequence of
characters that is programmatically determinable or where the sequence is
not expressing something in human language. Note: This includes, but is not
limited to, ASCII Art (which is a pattern of characters), emoticons,
leetspeak (which is character substitution), and images representing text.
6. Real-time Text: Communications that employ the transmission of text
wherein the characters are transmitted by a terminal within a maximum of 1
second of character input. This would typically be for conversational
purposes but also may be used in voicemail, IVR and other similar
applications. {TTYs are AT and need to access this - and IP real-time
text AT needs to be able to receive the IPtext (and translate into different
forms - for example braille for those who are deafblind.}
7. Text: Sequence of characters that is programmatically determinable,
where the sequence is expressing something in human language.
8. TTY (Consensed) An abbreviation for teletypewriter. Machinery or
equipment that enables interactive text based communications through the
transmission of frequency-shift-keying audio tones across the PSTN according
to TIA-825-A (A Frequency Shift Keyed Modem For Use On The Public Switched
Telephone Network). As used in this part, the term TTY includes devices for
text-to-text communications along with voice and text intermixed
communications such as voice carry over and hearing carry over. TTYs may
include computers with special modems. TTYs are a subset of devices called
text telephones.
9. 1-C - Pass Through (Consensed): Products that transmit or conduct
information or communication must preserve accessibility information that is
transmitted in non-proprietary, industry-standard codes, translation
protocols, or formats. Technologies which use encoding, signal
compression, format transformation, or similar techniques must not remove
information needed for access, or must restore it upon delivery.
Firewalls, routers,gateways and other products that pass real-time voice
communication must also pass real-time text communication signals (including
mixed voice and real-time text) that are standard in the United States for
that technology platform without distortion or error beyond 1%. {See
real-time-text definition above. Must be accessible by AT}
10. 1-E - Visual Information (Partial recommendation, No quorum) Version
2 All information that is needed for operation and use that is provided in
visual form must also be available in at least one mode in audio form or in
simple tactile form, either directly or {ending to be determined in AT
discussion}. Visual content that includes text and that is closed due to
Digital Rights Management (DRM) such that it cannot be rendered in audio
form by AT and other players must include an audio form that can be. Note
1: Section 255 and Section 508 treat AT solutions differently, so review
section XX of this document before implementing a solution. Note 2: Braille
is not a simple tactile form. It is encouraged but cannot be used to satisfy
this provision. {This clearly says that the text - which would otherwise
be accessible to AT is rendered in such a way that it is not}.
11. 3-A - Color (Consensed): Color must not be used as the only visual
means of conveying information, indicating an action, prompting a response,
or distinguishing a visual element. Example: A conforming example is
mandatory form fields are identified with colored text and labeled as
"Required". { This is an example and if field is identified by text -
then the text needs to be accessible by AT (by non-text provision) in order
to be the means for identifying. Otherwise this example would be written
"visually identified" Also, if identification was not accessible to AT then
the example would show that the person could tell it was required but
provide no means for identifying what to put into the field.}.
12. 3-F - Non-text Objects (Consensed)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 object 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 at least provide a
descriptive label that identifies the non-text object. (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 must be implemented such that it can be ignored by assistive
technology.

Note: In order to satisfy 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

13. 3-G - Human Language (Consensed): When supported in the technologies
of electronic documents, the default human language of electronic document
must be programmatically determinable. Note: In order to achieve this
provision, text encoded in data operated on by the software would need to be
associated with sufficient information to identify both the primary language
of the text, and the language of any sections or the text that are in
another language from the primary language, that the software can obtain as
readily as it can obtain the text itself.

14. 3-N - Link Purpose (Consensed): On Web pages, it must be possible to
determine the purpose of each link from the link text or the link text
together with its programmatically determinable link context. Note: In
order to achieve this provision, links encoded in data operated on by the
software would need to be associated with link text that the software can
obtain as readily as it can obtain the link itself.

15. 3-O - Information and Relationships (Consensed): Information and
relationships conveyed through presentation of electronic documents must be
either programmatically determinable or available in text, and notification
of changes to these is available to user agents, including assistive
technologies.

16. 3-P - User Interface Components: ... Example: Frames must be
titled with text that facilitates frame identification and navigation.

17. 3-S - Keyboard Operation: (Consensed): .. Note 2: The exception
relates to the underlying function, not the input technique. For example, if
using handwriting to enter text, the input technique (handwriting) requires
path dependent input but the underlying function (text input) does not.

18. 3-NEW - Visual Indication of Keyboard Shortcuts : All keyboard
commands associated directly with user interface controls must be visible
within the visual user interface in at least one mode, and available
programmatically to AT on products that support AT interoperability. Note 1:
This includes commands such as those used to active a menu item or button
(e.g. the "S" of a "Save File" menu item), but does not include commands
that are system-wide or common conventions for using an item (e.g. a command
to switch windows such as ALT-TAB, or a command to advance the caret in text
such as Ctrl-Arrow). Note 2: User-configurable keyboard commands may be
considered not directly tied to interface elements. However, when possible
such user-configurable keyboard bindings should be visually presented as
configured.

19. 3-U - AT Interoperability (Discussed March 4, partial consensus): On
platforms that support AT-E&IT interoperability, software that provides user
interface components must either use the accessibility services provided by
platform software or other services to cooperate with assistive technologies
when such services allow the software to meet the accessibility provisions
of this standard.

Using such services, software must:

1. expose object information including but not limited to:

a. role, state(s), boundary, name, and description

b. the row and column a component is in, and the headers for the row and
column for that component if it is in a table that has row or column
headers,

c. current value and any minimum or maximum values, if the component
represents one of a range of values

d. relationship this component has as a label for another component, or
being labeled by another component

e. name of parent or containing element, and any children components

f. text contents, text attributes, and the boundary of text rendered to the
screen

g. keyboard shortcuts and implicit designators.

In order to meet this provision, interactive elements encoded in data
operated on by the software must be associated with sufficient information
to programmatically determine a role, state(s), name, and description for
the interactive element, that the software can obtain as readily as it can
obtain the interactive element itself.

2. expose a list of actions that can be executed on an object and allow
assistive technology to programmatically execute any of those actions;

Proposed revision to #2 from Sean, March 5: Note 2: expose a list of actions
that can be executed on an object and allow programmatic execution of any of
those actions;

3. expose information necessary to track and modify: focus, text insertion
point, and selection attributes of user interface components;

4. expose notification of events relevant to user interactions, including
but not limited to changes in the component's state(s), value, name,
description, or boundary

Note 1: This provision also applies to forms in the software.

Note 2: Software that provides remote access to graphical user interfaces
(GUIs) would need to ensure that AT has access to the information required
by this provision. There are two known ways to accomplish this: run the AT
remotely as well or run the AT locally and provide a mechanism for it to
communicate accessibility information with the remote GUI.

Note 3: The term 'assistive technology' in this provision and provision
3-V-Accessibility Services refers to assistive technology that exists and
that is available to government employees (or members of the public for
public facing E&IT). If no AT exists for a given platform or application at
the time of procurement then the technical provisions should still be met in
absence of AT and the FPC should, as in all cases, be used as a guide toward
measurement of overall accessibility.

20. 3-AA - Error Identification (Consensed): If an input error is
automatically detected in content or electronic documents, the item that is
in error must be identified and described to the user in text.

21. 5-B - Video Description (Consensed): Materials containing video
and/or audio, regardless of format, that contain visual information
necessary for the comprehension of the content, must comply with the
following:

1. Materials containing prerecorded video and no original audio or other
additional time-based content must provide either a separate text
description of the video or provide an additional audio track to convey the
informational content of the video.

2. When the visual informational content is not conveyed through other
means, materials containing prerecorded video with concurrent audio must
provide synchronized video descriptions, or when space is not available in
the main program audio for synchronized video descriptions, a separate text
description of the video content must be provided.

3. Materials containing live video must provide synchronized video
descriptions in real time to convey any informational content of the video
that is not conveyed through other means.

22. 6-A - Real-Time Text Reliability and Interoperability (Consensed): If
hardware or software provides real-time voice conversation functionality it
must provide at least one means of real-time text communication where the
following reliability requirements are met:

1. Products must use a real-time text (RTT) system that meets the following
requirements:

* a. RTT format must be a standard real-time text format for the voice
platform that is supported by all terminal, router, gateway and other
products on that platform;

* b. RTT format must transmit characters with less than 1 second delay
from entry;

* c. RTT system must transmit text with less than 1% Total Character
Error Rate at the peak network traffic specified for intelligible speech
transmission (text must work on the network as long as speech does);

* d. The RTT system, together with the audio system, must support speech
and text in both directions in the same call session (and support speech and
text simultaneously in both directions in the same call session if IP based)

* e. RTT system must not utilize audio tones for transmission of
real-time text over IP. Note: this is subject to a waiver of the TTY support
requirement from the FCC for systems that implement IP based RTT. Also
subject to consumer acceptance of prefixes or phone numbers to direct TTY
traffic to gateways capable of handling TTY translation.

2. Where products or systems interoperate outside of their closed systems,
they must:

* a. If product interfaces with PSTN, it must use TIA 825A Baudot where
it interfaces to the PSTN.

* b. If product interfaces with other VoIP products or systems (outside
of a self-contained product-system) using SIP it must support transmission
of text as per XXX where it interfaces with other VoIP products or systems.
Note: this is subject to a waiver of the TTY support requirement from the
FCC for systems that implement IP based RTT. Also subject to consumer
acceptance of prefixes or phone numbers to direct TTY traffic to gateways
capable of handling TTY translation.

* c. If product connects to other products or systems using a protocol
other than SIP it must use the standard real-time text protocol that meets
provision 1 above that has been established for that protocol.

Note 1: RFC-4103, TIA 1001, and MSRP (RFC4975) are being explored to fill
the role of XXX. The intention is that XXX will be replaced by one
interconnection format in all places it was used.

Note 2: All products may support and use other protocols in addition to
these as long as they meet the 5 requirements of 5-B(1) above.

Note 3: A self-contained SIP system that uses the same real-time text
protocol can be treated as a single product and can use any protocol
internally as long as it supports XXX where the system-product connects to
other systems or products.

23. 6-B - Voice Terminal Hardware and Software (Consensed, still have
items to resolve) Terminal hardware or software that is capable of
providing voice communications in real-time must comply with the following:

1. Receive only: If hardware or software terminal provides voice
conversation over IP in any form, and has a user interface with a multi-line
display or a user interface that runs on devices that have a multi-line
display, then that terminal must display any real-time text that is received
if it is received in the format for the voice and real-time text system
being used on the network on which it is installed.

2. Send and Receive: If terminal hardware or software provides voice
conversation over IP in any form, and has text generation capability, then
the terminal must allow users to send real-time text in the format for the
voice and real-time text system being used on the network on which it is
installed.

3. If IP terminal hardware or software does not provide real-time text send
and receive capability then the terminal must support the addition of
terminals and terminal peripheral equipment that do support real-time text
functionality in conjunction with the voice call functionality, in the same
location and with the same permissions for use as their voice terminal. If
the terminal is in a public or shared area and not in an individual's
private work area then the connection must be possible [without requiring
system-administrator intervention]. Note: the "without system-administrator
intervention" is a serious concern due to security issues, but removal would
prevent people from connecting devices outside of their home system.
Additional work is needed to address this issue.]

4. If terminal is analog or TDM-digital wired terminal then it must support
the connection of a TTY via an RJ-11 jack in the same location and with the
same permissions for use as the telephone and it must be capable of allowing
simultaneous speech and text conversation without interference or its
microphone must be capable of being turned on and off to allow the user to
intermix speech with text use.

Note 1: Provision of the RJ-11 jack may be accomplished through one of the
following techniques:

a. provision of the RJ-11 jack on the telephone,

b. the use of a Y-adapter that allows both the analog telephone and the TTY
to be plugged into the same line outlet,

c. having built in capability to support an RJ11 module that can provide a
connection point for TTYs.

Note 2: The standard format for PSTN is TIA-825A. For SIP is it XXX. For
other voice transport protocols the format is to be determined by the entity
responsible for the voice transport protocol.

24. 6-C - IVR, Auto-Attendant and Messaging (Consensed): Voice mail,
messaging, auto-attendant, and interactive voice response telecommunications
systems must provide access in the following manner: 1) All functions that
are accessible to voice users must also be directly accessible to users of
real-time text. <SNIP>

25. 2. Text descriptions: Documentation and training materials should
include text descriptions of the interface. These descriptions should stand
on their own and be understandable without relying on graphic images in the
materials.


4 Places where PD is not required but current language accounts for PD
definition of text. (in fact- assumes it)


1. * Large Scale Text (Consensed) At least 18 point or 14 point bold
{In provision we actually say large scale text or images of large scale
text}

2. * 3-T - Focus Indicator (Consensed): Any keyboard operable user
interface must support a mode of operation where the indication of keyboard
focus has a high degree of visibility. Note 1: The presence of a highly
visible text insertion point is sufficient for a text area. Note 2: A focus
cursor that is visually locatable at 3.5 times the typical viewing distance
without moving the cursor by people who have unimpaired vision and are
familiar with what the focus cursor looks like is sufficient. For example,
when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x
768 pixels resolution, a focus cursor that is visually locatable at 2.5
meters without moving the cursor by people who are familiar with what the
cursor looks like and have unimpaired vision is sufficient.

3. * 3-B - Contrast (Consensed) Presentation of text, and images of
text, in electronic documents must have a contrast ratio of at least 5:1,
except for the following: * Large Print: Large-scale text and images of
large-scale text must have a contrast ratio of at least 3:1; *
Incidental: Text or images of text that are part of an inactive user
interface component, that are pure decoration, that are incidental text in
an image, or that are not visible to anyone, have no minimum contrast
requirement.

4. * 3-D - User Preferences (Consensed) Applications must provide a
mode that utilizes platform settings for color, contrast, font type, font
size, and focus cursor. In the absence of platform settings for color and
contrast, all text (and images of text) must have a contrast ratio of at
least 5:1 except for the following: * Large Print: Large-scale text
and images of large-scale text must have a contrast ratio of at least 3:1;
* Incidental: Text or images of text that are part of an inactive user
interface component, that are pure decoration, that are incidental text in
an image, or that are not visible to anyone, have no minimum contrast
requirement.

5. Captions (new wording )

6.




Places where text being PD would require a change




The following items would need small changes like adding "and images of
text". This would be needed in order to make their wording consistent with
other provisions anyway.




Contrast Ratio (Consensed) (just changing some informative notes)


Note 3: Text AND IMAGES OF TEXT can be evaluated with anti-aliasing turned
off.

Note 4: Background color is the specified color of content over which the
text OR IMAGE OF TEXT is to be rendered in normal usage. If no background
color is specified, then white is assumed.

Note 5: For text OR IMAGES OF TEXT displayed over gradients and background
images, authors should ensure that sufficient contrast exists for each part
of each character in the content.






Video Description


The insertion of verbal or auditory description(s) of on-screen visuals
intended to describe important visual details that are not contained in, or
that cannot be understood from, the main audio output alone. Video
descriptions supplement the regular audio track of the program and are
usually inserted between dialogue narration to provide information about
actions, characters, and on-screen text OR IMAGES OF TEXT that appear
without verbalization. Video descriptions are a way to let people who are
blind or have low vision know what is happening on screen.






1-G - Text size (Discussed Feb 7, 12, 19)


There must be at least one mode where all information that is required for
product use and is provided in text OR IMAGES OF TEXT is readable by people
with 20/20 vision at 3.5 times their typical viewing distance. This mode
must be the default mode unless the activation method for that mode can be
done at 3.5 times the typical viewing distance or the product automatically
sets itself to that mode for users who require it. This provision does not
apply to safety labels, regulatory labels, and marks that are not required
for product use. This requirement does not apply to the caption decoding
functions of products that are governed by U.S. Federal Communications
Commission (FCC) regulations 47 CFR 15.119 or to devices which provide
equivalent functionality as stipulated by 4-A - Caption Processing
















Gregg

------------------------

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at <http://tinyurl.com/dho6b> http://tinyurl.com/dho6b

If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

<http://trace.wisc.edu:8080/mailman/listinfo/>

From: Peter Korn
Date: Tue, Mar 18 2008 11:00 AM
Subject: Re: Text and the importance of programmatically determinable

Hi all,

I think what makes the most sense is to define "text" as a variant of
what Andi put forth, and to define "accessible text" using PD language
(that we when call out to the Access Board on the topic of whether or
not PD is defined in terms of what existing & commercially available AT
are already using). We can do this in the same definition block of
text, with a second paragraph detailing "accessible text". Then it is a
simple editorial change to make "text" be "accessible text" in most
places in the document.

This preserves the meaning of "text" that most engineers will
understand, and makes clear everywhere in the document where we mean it
to be so that we are talking about a particular variant of "text" that
has the additional property of being accessible.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Hi
>
>
>
> I also had run a complete analysis -- but was hesitant to post it.
>
> But since it came up with a different conclusion here it is.
>
>
>
> I agree that clearing up text would cause us to need to change some
> provisions or definitions (just 3)
>
>
>
> But if we do not make it clear in the definition that text must be PD
> it would cause us to have to change 25.
>
>
>
> Several that Sean posted are already fixed in today's drafts -- or are
> not a problem (see below). They don't require text to be
> programmatically determined, but the wording of the provisions
> accounts for that definition. For example they already say "text or
> images of text"
>
>
> * *
>
>
> * For all 25 of these provisions it is essential that text be
> electronically accessible by AT or the provisions do not work. *
>
> 1. Note: Simple text editors that can only create or modify content
> in conforming formats by directly editing the code are not
> considered authoring tools under this definition.
> 2. Note 1: CAPTCHA tests often involve asking the user to type in
> text that is presented in an obscured image or audio file.
> 3. *Content *(Consensed) Information and sensory experience to be
> communicated to the user by means of software, including but not
> limited to: text, images, sounds, videos, controls and
> animations, as well as the encoding that defines the structure,
> presentation, and interactions associated with those elements.
> For example: word processing files, presentation files,
> spreadsheet files, text files, portable document files, web
> based content, etc.
> 4. *Label* (Consensed) Text or other component with a text
> alternative that is presented to a user to identify a component
> within content.
> 5. *Non-text Object *(Consensed) Any object that is not a
> sequence of characters that is programmatically determinable or
> where the sequence is not expressing something in human
> language. *Note*: This includes, but is not limited to, ASCII
> Art (which is a pattern of characters), emoticons, leetspeak
> (which is character substitution), and images representing text.
> 6. *Real-time Text: *Communications that employ the transmission
> of text wherein the characters are transmitted by a terminal
> within a maximum of 1 second of character input. This would
> typically be for conversational purposes but also may be used in
> voicemail, IVR and other similar applications. {TTYs are AT
> and need to access this -- and IP real-time text AT needs to be
> able to receive the IPtext (and translate into different forms
> -- for example braille for those who are deafblind.}
> 7. *Text:* Sequence of characters that is programmatically
> determinable, where the sequence is expressing something in
> human language.
> 8. *TTY *(Consensed) An abbreviation for teletypewriter.
> Machinery or equipment that enables interactive text based
> communications through the transmission of
> frequency-shift-keying audio tones across the PSTN according to
> TIA-825-A (A Frequency Shift Keyed Modem For Use On The Public
> Switched Telephone Network). As used in this part, the term TTY
> includes devices for text-to-text communications along with
> voice and text intermixed communications such as voice carry
> over and hearing carry over. TTYs may include computers with
> special modems. TTYs are a subset of devices called text telephones.
> 9. *1-C - Pass Through* (Consensed): Products that transmit or
> conduct information or communication must preserve accessibility
> information that is transmitted in non-proprietary,
> industry-standard codes, translation protocols, or formats.
> Technologies which use encoding, signal compression, format
> transformation, or similar techniques must not remove
> information needed for access, or must restore it upon
> delivery. Firewalls, routers,gateways and other products that
> pass real-time voice communication must also pass real-time text
> communication signals (including mixed voice and real-time text)
> that are standard in the United States for that technology
> platform without distortion or error beyond 1%. {See
> real-time-text definition above. Must be accessible by AT}
> 10. *1-E - Visual Information* (Partial recommendation, No quorum)
> Version 2 All information that is needed for operation and use
> that is provided in visual form must also be available in at
> least one mode in audio form or in simple tactile form, either
> directly or {ending to be determined in AT discussion}. Visual
> content that includes text and that is closed due to Digital
> Rights Management (DRM) such that it cannot be rendered in audio
> form by AT and other players must include an audio form that can
> be. *Note* 1: Section 255 and Section 508 treat AT solutions
> differently, so review section XX of this document before
> implementing a solution. *Note* 2: Braille is not a simple
> tactile form. It is encouraged but cannot be used to satisfy
> this provision. {This clearly says that the text -- which
> would otherwise be accessible to AT is rendered in such a way
> that it is not}.
> 11. *3-A - Color *(Consensed): Color must not be used as the only
> visual means of conveying information, indicating an action,
> prompting a response, or distinguishing a visual element.
> Example: A conforming example is mandatory form fields are
> identified with colored text and labeled as "Required". {
> This is an example and if field is identified by text -- then
> the text needs to be accessible by AT (by non-text provision) in
> order to be the means for identifying. Otherwise this example
> would be written "visually identified" Also, if identification
> was not accessible to AT then the example would show that the
> person could tell it was required but provide no means for
> identifying what to put into the field.}.
> 12. *3-F - Non-text Objects* (Consensed)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 object 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 at least
> provide a descriptive label that identifies the non-text object. (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 must be implemented such that it can be
> ignored by assistive technology.
>
> Note: In order to satisfy 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
>
> 13. *3-G - Human Language *(Consensed): When supported in the
> technologies of electronic documents, the default human language of
> electronic document must be programmatically determinable. *Note*: In
> order to achieve this provision, text encoded in data operated on by
> the software would need to be associated with sufficient information
> to identify both the primary language of the text, and the language of
> any sections or the text that are in another language from the primary
> language, that the software can obtain as readily as it can obtain the
> text itself.
>
> 14. *3-N - Link Purpose *(Consensed): On Web pages, it must be
> possible to determine the purpose of each link from the link text or
> the link text together with its programmatically determinable link
> context. *Note:* In order to achieve this provision, links encoded in
> data operated on by the software would need to be associated with link
> text that the software can obtain as readily as it can obtain the link
> itself.
>
> 15. *3-O - Information and Relationships* (Consensed): Information
> and relationships conveyed through presentation of electronic
> documents must be either programmatically determinable or available in
> text, and notification of changes to these is available to user
> agents, including assistive technologies.
>
> 16. *3-P - User Interface Components: * ..... Example: Frames
> must be titled with text that facilitates frame identification and
> navigation.
>
> 17. *3-S - Keyboard Operation: *(Consensed): ...... Note 2:
> The exception relates to the underlying function, not the input
> technique. For example, if using handwriting to enter text, the input
> technique (handwriting) requires path dependent input but the
> underlying function (text input) does not.
>
> 18. *3-NEW - Visual Indication of Keyboard Shortcuts *: All
> keyboard commands associated directly with user interface controls
> must be visible within the visual user interface in at least one mode,
> and available programmatically to AT on products that support AT
> interoperability. Note 1: This includes commands such as those used to
> active a menu item or button (e.g. the "S" of a "Save File" menu
> item), but does not include commands that are system-wide or common
> conventions for using an item (e.g. a command to switch windows such
> as ALT-TAB, or a command to advance the caret in text such as
> Ctrl-Arrow). Note 2: User-configurable keyboard commands may be
> considered not directly tied to interface elements. However, when
> possible such user-configurable keyboard bindings should be visually
> presented as configured.
>
> 19. *3-U - AT Interoperability* (Discussed March 4, partial
> consensus): On platforms that support AT-E&IT interoperability,
> software that provides user interface components must either use the
> accessibility services provided by platform software or other services
> to cooperate with assistive technologies when such services allow the
> software to meet the accessibility provisions of this standard.
>
> Using such services, software must:
>
> 1. expose object information including but not limited to:
>
> a. role, state(s), boundary, name, and description
>
> b. the row and column a component is in, and the headers for the row
> and column for that component if it is in a table that has row or
> column headers,
>
> c. current value and any minimum or maximum values, if the component
> represents one of a range of values
>
> d. relationship this component has as a label for another component,
> or being labeled by another component
>
> e. name of parent or containing element, and any children components
>
> f. text contents, text attributes, and the boundary of text rendered
> to the screen
>
> g. keyboard shortcuts and implicit designators.
>
> In order to meet this provision, interactive elements encoded in data
> operated on by the software must be associated with sufficient
> information to programmatically determine a role, state(s), name, and
> description for the interactive element, that the software can obtain
> as readily as it can obtain the interactive element itself.
>
> 2. expose a list of actions that can be executed on an object and
> allow assistive technology to programmatically execute any of those
> actions;
>
> Proposed revision to #2 from Sean, March 5: Note 2: expose a list of
> actions that can be executed on an object and allow programmatic
> execution of any of those actions;
>
> 3. expose information necessary to track and modify: focus, text
> insertion point, and selection attributes of user interface components;
>
> 4. expose notification of events relevant to user interactions,
> including but not limited to changes in the component's state(s),
> value, name, description, or boundary
>
> Note 1: This provision also applies to forms in the software.
>
> Note 2: Software that provides remote access to graphical user
> interfaces (GUIs) would need to ensure that AT has access to the
> information required by this provision. There are two known ways to
> accomplish this: run the AT remotely as well or run the AT locally and
> provide a mechanism for it to communicate accessibility information
> with the remote GUI.
>
> Note 3: The term 'assistive technology' in this provision and
> provision 3-V-Accessibility Services refers to assistive technology
> that exists and that is available to government employees (or members
> of the public for public facing E&IT). If no AT exists for a given
> platform or application at the time of procurement then the technical
> provisions should still be met in absence of AT and the FPC should, as
> in all cases, be used as a guide toward measurement of overall
> accessibility.
>
> 20. *3-AA - Error Identification* (Consensed): If an input error is
> automatically detected in content or electronic documents, the item
> that is in error must be identified and described to the user in text.
>
> 21. *5-B - Video Description* (Consensed): Materials containing
> video and/or audio, regardless of format, that contain visual
> information necessary for the comprehension of the content, must
> comply with the following:
>
> 1. Materials containing prerecorded video and no original audio or
> other additional time-based content must provide either a separate
> text description of the video or provide an additional audio track to
> convey the informational content of the video.
>
> 2. When the visual informational content is not conveyed through other
> means, materials containing prerecorded video with concurrent audio
> must provide synchronized video descriptions, or when space is not
> available in the main program audio for synchronized video
> descriptions, a separate text description of the video content must be
> provided.
>
> 3. Materials containing live video must provide synchronized video
> descriptions in real time to convey any informational content of the
> video that is not conveyed through other means.
>
> 22. *6-A - Real-Time Text Reliability and Interoperability
> *(Consensed): If hardware or software provides real-time voice
> conversation functionality it must provide at least one means of
> real-time text communication where the following reliability
> requirements are met:
>
> 1. Products must use a real-time text (RTT) system that meets the
> following requirements:
>
> * a. RTT format must be a standard real-time text format for the
> voice platform that is supported by all terminal, router, gateway and
> other products on that platform;
>
> * b. RTT format must transmit characters with less than 1 second
> delay from entry;
>
> * c. RTT system must transmit text with less than 1% Total
> Character Error Rate at the peak network traffic specified for
> intelligible speech transmission (text must work on the network as
> long as speech does);
>
> * d. The RTT system, together with the audio system, must support
> speech and text in both directions in the same call session (and
> support speech and text simultaneously in both directions in the same
> call session if IP based)
>
> * e. RTT system must not utilize audio tones for transmission of
> real-time text over IP. Note: this is subject to a waiver of the TTY
> support requirement from the FCC for systems that implement IP based
> RTT. Also subject to consumer acceptance of prefixes or phone numbers
> to direct TTY traffic to gateways capable of handling TTY translation.
>
> 2. Where products or systems interoperate outside of their closed
> systems, they must:
>
> * a. If product interfaces with PSTN, it must use TIA 825A Baudot
> where it interfaces to the PSTN.
>
> * b. If product interfaces with other VoIP products or systems
> (outside of a self-contained product-system) using SIP it must support
> transmission of text as per XXX where it interfaces with other VoIP
> products or systems. Note: this is subject to a waiver of the TTY
> support requirement from the FCC for systems that implement IP based
> RTT. Also subject to consumer acceptance of prefixes or phone numbers
> to direct TTY traffic to gateways capable of handling TTY translation.
>
> * c. If product connects to other products or systems using a
> protocol other than SIP it must use the standard real-time text
> protocol that meets provision 1 above that has been established for
> that protocol.
>
> Note 1: RFC-4103, TIA 1001, and MSRP (RFC4975) are being explored to
> fill the role of XXX. The intention is that XXX will be replaced by
> one interconnection format in all places it was used.
>
> Note 2: All products may support and use other protocols in addition
> to these as long as they meet the 5 requirements of 5-B(1) above.
>
> Note 3: A self-contained SIP system that uses the same real-time text
> protocol can be treated as a single product and can use any protocol
> internally as long as it supports XXX where the system-product
> connects to other systems or products.
>
> 23. *6-B - Voice Terminal Hardware and Software* (Consensed, still
> have items to resolve) Terminal hardware or software that is capable
> of providing voice communications in real-time must comply with the
> following:
>
> 1. Receive only: If hardware or software terminal provides voice
> conversation over IP in any form, and has a user interface with a
> multi-line display or a user interface that runs on devices that have
> a multi-line display, then that terminal must display any real-time
> text that is received if it is received in the format for the voice
> and real-time text system being used on the network on which it is
> installed.
>
> 2. Send and Receive: If terminal hardware or software provides voice
> conversation over IP in any form, and has text generation capability,
> then the terminal must allow users to send real-time text in the
> format for the voice and real-time text system being used on the
> network on which it is installed.
>
> 3. If IP terminal hardware or software does not provide real-time text
> send and receive capability then the terminal must support the
> addition of terminals and terminal peripheral equipment that do
> support real-time text functionality in conjunction with the voice
> call functionality, in the same location and with the same permissions
> for use as their voice terminal. If the terminal is in a public or
> shared area and not in an individual's private work area then the
> connection must be possible [without requiring system-administrator
> intervention]. Note: the "without system-administrator intervention"
> is a serious concern due to security issues, but removal would prevent
> people from connecting devices outside of their home system.
> Additional work is needed to address this issue.]
>
> 4. If terminal is analog or TDM-digital wired terminal then it must
> support the connection of a TTY via an RJ-11 jack in the same location
> and with the same permissions for use as the telephone and it must be
> capable of allowing simultaneous speech and text conversation without
> interference or its microphone must be capable of being turned on and
> off to allow the user to intermix speech with text use.
>
> Note 1: Provision of the RJ-11 jack may be accomplished through one of
> the following techniques:
>
> a. provision of the RJ-11 jack on the telephone,
>
> b. the use of a Y-adapter that allows both the analog telephone and
> the TTY to be plugged into the same line outlet,
>
> c. having built in capability to support an RJ11 module that can
> provide a connection point for TTYs.
>
> Note 2: The standard format for PSTN is TIA-825A. For SIP is it XXX.
> For other voice transport protocols the format is to be determined by
> the entity responsible for the voice transport protocol.
>
> 24. *6-C - IVR, Auto-Attendant and Messaging *(Consensed): Voice
> mail, messaging, auto-attendant, and interactive voice response
> telecommunications systems must provide access in the following
> manner: 1) All functions that are accessible to voice users must
> also be directly accessible to users of real-time text. <SNIP>
>
> 25. * 2. Text descriptions: *Documentation and training materials
> should include text descriptions of the interface. These descriptions
> should stand on their own and be understandable without relying on
> graphic images in the materials.
>
>
> */4 Places where PD is not required but current language accounts
> for PD definition of text. (in fact- assumes it) /*
>
> 1. ** Large Scale Text *(Consensed) At least 18 point or 14 point
> bold {In provision we actually say large scale text or
> images of large scale text}
>
> 2. ** 3-T - Focus Indicator* (Consensed): Any keyboard operable
> user interface must support a mode of operation where the indication
> of keyboard focus has a high degree of visibility. Note 1: The
> presence of a highly visible text insertion point is sufficient for a
> text area. Note 2: A focus cursor that is visually locatable at 3.5
> times the typical viewing distance without moving the cursor by people
> who have unimpaired vision and are familiar with what the focus cursor
> looks like is sufficient. For example, when software is displayed on a
> 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, a
> focus cursor that is visually locatable at 2.5 meters without moving
> the cursor by people who are familiar with what the cursor looks like
> and have unimpaired vision is sufficient.
>
> 3. ** 3-B - Contrast *(Consensed) Presentation of text, and images
> of text, in electronic documents must have a contrast ratio of
> at least 5:1, except for the following: * Large Print:
> Large-scale text and images of large-scale text must have a
> contrast ratio of at least 3:1; * Incidental: Text or images
> of text that are part of an inactive user interface component,
> that are pure decoration, that are incidental text in an image,
> or that are not visible to anyone, have no minimum contrast
> requirement.
>
> 4. ** 3-D - User Preferences *(Consensed) Applications must
> provide a mode that utilizes platform settings for color, contrast,
> font type, font size, and focus cursor. In the absence of platform
> settings for color and contrast, all text (and images of text) must
> have a contrast ratio of at least 5:1 except for the following:
> * Large Print: Large-scale text and images of large-scale text must
> have a contrast ratio of at least 3:1; * Incidental: Text or
> images of text that are part of an inactive user interface component,
> that are pure decoration, that are incidental text in an image, or
> that are not visible to anyone, have no minimum contrast requirement.
>
> 5. *Captions (new wording )*
>
> 6.
>
>
>
>
> */Places where text being PD would require a change /*
>
>
>
> The following items would need small changes like adding "and images
> of text". This would be needed in order to make their wording
> consistent with other provisions anyway.
>
>
>
>
> *Contrast Ratio (Consensed) (just changing some informative
> notes)*
>
> *Note 3:* Text *AND IMAGES OF TEXT* can be evaluated with
> anti-aliasing turned off.
>
> *Note 4:* Background color is the specified color of content over
> which the text* OR IMAGE OF TEXT* is to be rendered in normal usage.
> If no background color is specified, then white is assumed.
>
> *Note 5:* For* *text *OR IMAGES OF TEXT *displayed over gradients and
> background images, authors should ensure that sufficient contrast
> exists for each part of each character in the content.
>
>
>
>
>
>
> *Video Description *
>
> The insertion of verbal or auditory description(s) of on-screen
> visuals intended to describe important visual details that are not
> contained in, or that cannot be understood from, the main audio output
> alone. Video descriptions supplement the regular audio track of the
> program and are usually inserted between dialogue narration to provide
> information about actions, characters, and on-screen text* OR IMAGES
> OF TEXT* that appear without verbalization. Video descriptions are a
> way to let people who are blind or have low vision know what is
> happening on screen.
>
>
>
>
>
>
> *1-G - Text size (Discussed Feb 7, 12, 19)*
>
> There must be at least one mode where all information that is required
> for product use and is provided in text *OR IMAGES OF TEXT* is
> readable by people with 20/20 vision at 3.5 times their typical
> viewing distance. This mode must be the default mode unless the
> activation method for that mode can be done at 3.5 times the typical
> viewing distance or the product automatically sets itself to that mode
> for users who require it. This provision does not apply to safety
> labels, regulatory labels, and marks that are not required for product
> use. /This requirement does not apply to the caption decoding
> functions of products that are governed by U.S. Federal Communications
> Commission (FCC) regulations 47 CFR 15.119 or to devices which provide
> equivalent functionality as stipulated by 4-A - Caption Processing/
>
>
> * *
>
>
>
>
>
>
>
>
>
>
>
>
> Gregg
>
> ------------------------
>
> Gregg C Vanderheiden Ph.D.
> Professor - Depts of Ind.__ Engr. & BioMed Engr.
> Director - Trace R & D Center
> University of Wisconsin-Madison
> _<_http://trace.wisc.edu/_>_ FAX 608/262-8848
>
> DSS Player at http://tinyurl.com/dho6b
>
> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>
> <http://trace.wisc.edu:8080/mailman/listinfo/>__
>
>
>
>
>
> ------------------------------------------------------------------------
>
>

From: Gregg Vanderheiden
Date: Tue, Mar 18 2008 4:50 PM
Subject: Re: Text and the importance of programmatically determinable

Interesting thought. I worry about the word "accessible" though.



People who are colorblind would not consider "programmatically determinable
text" accessible nor would people with cognitive, language or learning.



It would also add length to a lot of provisions.



BUT on the positive side it lets 'text' have its broader common meaning.



I thought of using e-text years ago (in WCAG) to do this but people
thought this was too 'tech-y' or hard to read.







Can anyone think of something that would allow us to have two types of Text
generic text which we wouild call text and programmatically determinable
text that we would call.. what? e-text is awkward. 'accessible-text'
isn't accurate (or is one-disability accessible) pd-text?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

If Attachment is a mail.dat try http://www.kopf.com.br/winmail/






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Tuesday, March 18, 2008 11:48 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Text and the importance of programmatically
determinable

Hi all,

I think what makes the most sense is to define "text" as a variant of what
Andi put forth, and to define "accessible text" using PD language (that we
when call out to the Access Board on the topic of whether or not PD is
defined in terms of what existing & commercially available AT are already
using). We can do this in the same definition block of text, with a second
paragraph detailing "accessible text". Then it is a simple editorial change
to make "text" be "accessible text" in most places in the document.

This preserves the meaning of "text" that most engineers will understand,
and makes clear everywhere in the document where we mean it to be so that we
are talking about a particular variant of "text" that has the additional
property of being accessible.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.





Hi

I also had run a complete analysis - but was hesitant to post it.

But since it came up with a different conclusion here it is.

I agree that clearing up text would cause us to need to change some
provisions or definitions (just 3)

But if we do not make it clear in the definition that text must be PD it
would cause us to have to change 25.

Several that Sean posted are already fixed in today's drafts - or are not a
problem (see below). They don't require text to be programmatically
determined, but the wording of the provisions accounts for that definition.
For example they already say "text or images of text"


For all 25 of these provisions it is essential that text be electronically
accessible by AT or the provisions do not work.


1. Note: Simple text editors that can only create or modify content in
conforming formats by directly editing the code are not considered authoring
tools under this definition.
2. Note 1: CAPTCHA tests often involve asking the user to type in text
that is presented in an obscured image or audio file.
3. Content (Consensed) Information and sensory experience to be
communicated to the user by means of software, including but not limited to:
text, images, sounds, videos, controls and animations, as well as the
encoding that defines the structure, presentation, and interactions
associated with those elements. For example: word processing files,
presentation files, spreadsheet files, text files, portable document files,
web based content, etc.
4. Label (Consensed) Text or other component with a text alternative
that is presented to a user to identify a component within content.
5. Non-text Object (Consensed) Any object that is not a sequence of
characters that is programmatically determinable or where the sequence is
not expressing something in human language. Note: This includes, but is not
limited to, ASCII Art (which is a pattern of characters), emoticons,
leetspeak (which is character substitution), and images representing text.
6. Real-time Text: Communications that employ the transmission of text
wherein the characters are transmitted by a terminal within a maximum of 1
second of character input. This would typically be for conversational
purposes but also may be used in voicemail, IVR and other similar
applications. {TTYs are AT and need to access this - and IP real-time
text AT needs to be able to receive the IPtext (and translate into different
forms - for example braille for those who are deafblind.}
7. Text: Sequence of characters that is programmatically determinable,
where the sequence is expressing something in human language.
8. TTY (Consensed) An abbreviation for teletypewriter. Machinery or
equipment that enables interactive text based communications through the
transmission of frequency-shift-keying audio tones across the PSTN according
to TIA-825-A (A Frequency Shift Keyed Modem For Use On The Public Switched
Telephone Network). As used in this part, the term TTY includes devices for
text-to-text communications along with voice and text intermixed
communications such as voice carry over and hearing carry over. TTYs may
include computers with special modems. TTYs are a subset of devices called
text telephones.
9. 1-C - Pass Through (Consensed): Products that transmit or conduct
information or communication must preserve accessibility information that is
transmitted in non-proprietary, industry-standard codes, translation
protocols, or formats. Technologies which use encoding, signal
compression, format transformation, or similar techniques must not remove
information needed for access, or must restore it upon delivery.
Firewalls, routers,gateways and other products that pass real-time voice
communication must also pass real-time text communication signals (including
mixed voice and real-time text) that are standard in the United States for
that technology platform without distortion or error beyond 1%. {See
real-time-text definition above. Must be accessible by AT}
10. 1-E - Visual Information (Partial recommendation, No quorum) Version
2 All information that is needed for operation and use that is provided in
visual form must also be available in at least one mode in audio form or in
simple tactile form, either directly or {ending to be determined in AT
discussion}. Visual content that includes text and that is closed due to
Digital Rights Management (DRM) such that it cannot be rendered in audio
form by AT and other players must include an audio form that can be. Note
1: Section 255 and Section 508 treat AT solutions differently, so review
section XX of this document before implementing a solution. Note 2: Braille
is not a simple tactile form. It is encouraged but cannot be used to satisfy
this provision. {This clearly says that the text - which would otherwise
be accessible to AT is rendered in such a way that it is not}.
11. 3-A - Color (Consensed): Color must not be used as the only visual
means of conveying information, indicating an action, prompting a response,
or distinguishing a visual element. Example: A conforming example is
mandatory form fields are identified with colored text and labeled as
"Required". { This is an example and if field is identified by text -
then the text needs to be accessible by AT (by non-text provision) in order
to be the means for identifying. Otherwise this example would be written
"visually identified" Also, if identification was not accessible to AT then
the example would show that the person could tell it was required but
provide no means for identifying what to put into the field.}.
12. 3-F - Non-text Objects (Consensed)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 object 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 at least provide a
descriptive label that identifies the non-text object. (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 must be implemented such that it can be ignored by assistive
technology.

Note: In order to satisfy 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

<!--[if !supportLists]-->13. <!--[endif]-->3-G - Human Language
(Consensed): When supported in the technologies of electronic documents,
the default human language of electronic document must be programmatically
determinable. Note: In order to achieve this provision, text encoded in
data operated on by the software would need to be associated with sufficient
information to identify both the primary language of the text, and the
language of any sections or the text that are in another language from the
primary language, that the software can obtain as readily as it can obtain
the text itself.

<!--[if !supportLists]-->14. <!--[endif]-->3-N - Link Purpose (Consensed):
On Web pages, it must be possible to determine the purpose of each link from
the link text or the link text together with its programmatically
determinable link context. Note: In order to achieve this provision, links
encoded in data operated on by the software would need to be associated with
link text that the software can obtain as readily as it can obtain the link
itself.

<!--[if !supportLists]-->15. <!--[endif]-->3-O - Information and
Relationships (Consensed): Information and relationships conveyed through
presentation of electronic documents must be either programmatically
determinable or available in text, and notification of changes to these is
available to user agents, including assistive technologies.

<!--[if !supportLists]-->16. <!--[endif]-->3-P - User Interface
Components: ... Example: Frames must be titled with text that
facilitates frame identification and navigation.

<!--[if !supportLists]-->17. <!--[endif]-->3-S - Keyboard Operation:
(Consensed): .. Note 2: The exception relates to the underlying
function, not the input technique. For example, if using handwriting to
enter text, the input technique (handwriting) requires path dependent input
but the underlying function (text input) does not.

<!--[if !supportLists]-->18. <!--[endif]-->3-NEW - Visual Indication of
Keyboard Shortcuts : All keyboard commands associated directly with user
interface controls must be visible within the visual user interface in at
least one mode, and available programmatically to AT on products that
support AT interoperability. Note 1: This includes commands such as those
used to active a menu item or button (e.g. the "S" of a "Save File" menu
item), but does not include commands that are system-wide or common
conventions for using an item (e.g. a command to switch windows such as
ALT-TAB, or a command to advance the caret in text such as Ctrl-Arrow).
Note 2: User-configurable keyboard commands may be considered not directly
tied to interface elements. However, when possible such user-configurable
keyboard bindings should be visually presented as configured.

<!--[if !supportLists]-->19. <!--[endif]-->3-U - AT Interoperability
(Discussed March 4, partial consensus): On platforms that support AT-E&IT
interoperability, software that provides user interface components must
either use the accessibility services provided by platform software or other
services to cooperate with assistive technologies when such services allow
the software to meet the accessibility provisions of this standard.

Using such services, software must:

1. expose object information including but not limited to:

a. role, state(s), boundary, name, and description

b. the row and column a component is in, and the headers for the row and
column for that component if it is in a table that has row or column
headers,

c. current value and any minimum or maximum values, if the component
represents one of a range of values

d. relationship this component has as a label for another component, or
being labeled by another component

e. name of parent or containing element, and any children components

f. text contents, text attributes, and the boundary of text rendered to the
screen

g. keyboard shortcuts and implicit designators.

In order to meet this provision, interactive elements encoded in data
operated on by the software must be associated with sufficient information
to programmatically determine a role, state(s), name, and description for
the interactive element, that the software can obtain as readily as it can
obtain the interactive element itself.

2. expose a list of actions that can be executed on an object and allow
assistive technology to programmatically execute any of those actions;

Proposed revision to #2 from Sean, March 5: Note 2: expose a list of actions
that can be executed on an object and allow programmatic execution of any of
those actions;

3. expose information necessary to track and modify: focus, text insertion
point, and selection attributes of user interface components;

4. expose notification of events relevant to user interactions, including
but not limited to changes in the component's state(s), value, name,
description, or boundary

Note 1: This provision also applies to forms in the software.

Note 2: Software that provides remote access to graphical user interfaces
(GUIs) would need to ensure that AT has access to the information required
by this provision. There are two known ways to accomplish this: run the AT
remotely as well or run the AT locally and provide a mechanism for it to
communicate accessibility information with the remote GUI.

Note 3: The term 'assistive technology' in this provision and provision
3-V-Accessibility Services refers to assistive technology that exists and
that is available to government employees (or members of the public for
public facing E&IT). If no AT exists for a given platform or application at
the time of procurement then the technical provisions should still be met in
absence of AT and the FPC should, as in all cases, be used as a guide toward
measurement of overall accessibility.

<!--[if !supportLists]-->20. <!--[endif]-->3-AA - Error Identification
(Consensed): If an input error is automatically detected in content or
electronic documents, the item that is in error must be identified and
described to the user in text.

<!--[if !supportLists]-->21. <!--[endif]-->5-B - Video Description
(Consensed): Materials containing video and/or audio, regardless of
format, that contain visual information necessary for the comprehension of
the content, must comply with the following:

1. Materials containing prerecorded video and no original audio or other
additional time-based content must provide either a separate text
description of the video or provide an additional audio track to convey the
informational content of the video.

2. When the visual informational content is not conveyed through other
means, materials containing prerecorded video with concurrent audio must
provide synchronized video descriptions, or when space is not available in
the main program audio for synchronized video descriptions, a separate text
description of the video content must be provided.

3. Materials containing live video must provide synchronized video
descriptions in real time to convey any informational content of the video
that is not conveyed through other means.

<!--[if !supportLists]-->22. <!--[endif]-->6-A - Real-Time Text
Reliability and Interoperability (Consensed): If hardware or software
provides real-time voice conversation functionality it must provide at least
one means of real-time text communication where the following reliability
requirements are met:

1. Products must use a real-time text (RTT) system that meets the following
requirements:

* a. RTT format must be a standard real-time text format for the voice
platform that is supported by all terminal, router, gateway and other
products on that platform;

* b. RTT format must transmit characters with less than 1 second delay
from entry;

* c. RTT system must transmit text with less than 1% Total Character
Error Rate at the peak network traffic specified for intelligible speech
transmission (text must work on the network as long as speech does);

* d. The RTT system, together with the audio system, must support speech
and text in both directions in the same call session (and support speech and
text simultaneously in both directions in the same call session if IP based)

* e. RTT system must not utilize audio tones for transmission of
real-time text over IP. Note: this is subject to a waiver of the TTY support
requirement from the FCC for systems that implement IP based RTT. Also
subject to consumer acceptance of prefixes or phone numbers to direct TTY
traffic to gateways capable of handling TTY translation.

2. Where products or systems interoperate outside of their closed systems,
they must:

* a. If product interfaces with PSTN, it must use TIA 825A Baudot where
it interfaces to the PSTN.

* b. If product interfaces with other VoIP products or systems (outside
of a self-contained product-system) using SIP it must support transmission
of text as per XXX where it interfaces with other VoIP products or systems.
Note: this is subject to a waiver of the TTY support requirement from the
FCC for systems that implement IP based RTT. Also subject to consumer
acceptance of prefixes or phone numbers to direct TTY traffic to gateways
capable of handling TTY translation.

* c. If product connects to other products or systems using a protocol
other than SIP it must use the standard real-time text protocol that meets
provision 1 above that has been established for that protocol.

Note 1: RFC-4103, TIA 1001, and MSRP (RFC4975) are being explored to fill
the role of XXX. The intention is that XXX will be replaced by one
interconnection format in all places it was used.

Note 2: All products may support and use other protocols in addition to
these as long as they meet the 5 requirements of 5-B(1) above.

Note 3: A self-contained SIP system that uses the same real-time text
protocol can be treated as a single product and can use any protocol
internally as long as it supports XXX where the system-product connects to
other systems or products.

<!--[if !supportLists]-->23. <!--[endif]-->6-B - Voice Terminal Hardware
and Software (Consensed, still have items to resolve) Terminal hardware or
software that is capable of providing voice communications in real-time must
comply with the following:

1. Receive only: If hardware or software terminal provides voice
conversation over IP in any form, and has a user interface with a multi-line
display or a user interface that runs on devices that have a multi-line
display, then that terminal must display any real-time text that is received
if it is received in the format for the voice and real-time text system
being used on the network on which it is installed.

2. Send and Receive: If terminal hardware or software provides voice
conversation over IP in any form, and has text generation capability, then
the terminal must allow users to send real-time text in the format for the
voice and real-time text system being used on the network on which it is
installed.

3. If IP terminal hardware or software does not provide real-time text send
and receive capability then the terminal must support the addition of
terminals and terminal peripheral equipment that do support real-time text
functionality in conjunction with the voice call functionality, in the same
location and with the same permissions for use as their voice terminal. If
the terminal is in a public or shared area and not in an individual's
private work area then the connection must be possible [without requiring
system-administrator intervention]. Note: the "without system-administrator
intervention" is a serious concern due to security issues, but removal would
prevent people from connecting devices outside of their home system.
Additional work is needed to address this issue.]

4. If terminal is analog or TDM-digital wired terminal then it must support
the connection of a TTY via an RJ-11 jack in the same location and with the
same permissions for use as the telephone and it must be capable of allowing
simultaneous speech and text conversation without interference or its
microphone must be capable of being turned on and off to allow the user to
intermix speech with text use.

Note 1: Provision of the RJ-11 jack may be accomplished through one of the
following techniques:

a. provision of the RJ-11 jack on the telephone,

b. the use of a Y-adapter that allows both the analog telephone and the TTY
to be plugged into the same line outlet,

c. having built in capability to support an RJ11 module that can provide a
connection point for TTYs.

Note 2: The standard format for PSTN is TIA-825A. For SIP is it XXX. For
other voice transport protocols the format is to be determined by the entity
responsible for the voice transport protocol.

<!--[if !supportLists]-->24. <!--[endif]-->6-C - IVR, Auto-Attendant and
Messaging (Consensed): Voice mail, messaging, auto-attendant, and
interactive voice response telecommunications systems must provide access in
the following manner: 1) All functions that are accessible to voice users
must also be directly accessible to users of real-time text. <SNIP>

<!--[if !supportLists]-->25. <!--[endif]--> 2. Text descriptions:
Documentation and training materials should include text descriptions of the
interface. These descriptions should stand on their own and be
understandable without relying on graphic images in the materials.


4 Places where PD is not required but current language accounts for PD
definition of text. (in fact- assumes it)


1. * Large Scale Text (Consensed) At least 18 point or 14 point bold
{In provision we actually say large scale text or images of large scale
text}

<!--[if !supportLists]-->2. <!--[endif]-->* 3-T - Focus Indicator
(Consensed): Any keyboard operable user interface must support a mode of
operation where the indication of keyboard focus has a high degree of
visibility. Note 1: The presence of a highly visible text insertion point is
sufficient for a text area. Note 2: A focus cursor that is visually
locatable at 3.5 times the typical viewing distance without moving the
cursor by people who have unimpaired vision and are familiar with what the
focus cursor looks like is sufficient. For example, when software is
displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels
resolution, a focus cursor that is visually locatable at 2.5 meters without
moving the cursor by people who are familiar with what the cursor looks like
and have unimpaired vision is sufficient.

3. * 3-B - Contrast (Consensed) Presentation of text, and images of
text, in electronic documents must have a contrast ratio of at least 5:1,
except for the following: * Large Print: Large-scale text and images of
large-scale text must have a contrast ratio of at least 3:1; *
Incidental: Text or images of text that are part of an inactive user
interface component, that are pure decoration, that are incidental text in
an image, or that are not visible to anyone, have no minimum contrast
requirement.

<!--[if !supportLists]-->4. <!--[endif]-->* 3-D - User Preferences
(Consensed) Applications must provide a mode that utilizes platform
settings for color, contrast, font type, font size, and focus cursor. In the
absence of platform settings for color and contrast, all text (and images of
text) must have a contrast ratio of at least 5:1 except for the following:
* Large Print: Large-scale text and images of large-scale text must have a
contrast ratio of at least 3:1; * Incidental: Text or images of text
that are part of an inactive user interface component, that are pure
decoration, that are incidental text in an image, or that are not visible to
anyone, have no minimum contrast requirement.

<!--[if !supportLists]-->5. <!--[endif]-->Captions (new wording )

<!--[if !supportLists]-->6. <!--[endif]-->


Places where text being PD would require a change


The following items would need small changes like adding "and images of
text". This would be needed in order to make their wording consistent with
other provisions anyway.


Contrast Ratio (Consensed) (just changing some informative notes)


Note 3: Text AND IMAGES OF TEXT can be evaluated with anti-aliasing turned
off.

Note 4: Background color is the specified color of content over which the
text OR IMAGE OF TEXT is to be rendered in normal usage. If no background
color is specified, then white is assumed.

Note 5: For text OR IMAGES OF TEXT displayed over gradients and background
images, authors should ensure that sufficient contrast exists for each part
of each character in the content.


Video Description


The insertion of verbal or auditory description(s) of on-screen visuals
intended to describe important visual details that are not contained in, or
that cannot be understood from, the main audio output alone. Video
descriptions supplement the regular audio track of the program and are
usually inserted between dialogue narration to provide information about
actions, characters, and on-screen text OR IMAGES OF TEXT that appear
without verbalization. Video descriptions are a way to let people who are
blind or have low vision know what is happening on screen.


1-G - Text size (Discussed Feb 7, 12, 19)


There must be at least one mode where all information that is required for
product use and is provided in text OR IMAGES OF TEXT is readable by people
with 20/20 vision at 3.5 times their typical viewing distance. This mode
must be the default mode unless the activation method for that mode can be
done at 3.5 times the typical viewing distance or the product automatically
sets itself to that mode for users who require it. This provision does not
apply to safety labels, regulatory labels, and marks that are not required
for product use. This requirement does not apply to the caption decoding
functions of products that are governed by U.S. Federal Communications
Commission (FCC) regulations 47 CFR 15.119 or to devices which provide
equivalent functionality as stipulated by 4-A - Caption Processing


Gregg

------------------------

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at <http://tinyurl.com/dho6b> http://tinyurl.com/dho6b

If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

<http://trace.wisc.edu:8080/mailman/listinfo/>







_____

From: Peter Korn
Date: Tue, Mar 18 2008 5:05 PM
Subject: Re: Text and the importance of programmatically determinable

Hi Gregg,

Now you sound a bit like me and me like you. You argued that words mean
what we define them to mean, so if we defined "accessible text" as PD
(and expressly not addressing colorblind), then we'd be OK.

For myself, I'm not tied to the term "accessible text". "e-text" or
something else would likely be fine (pending the word/phrase suggested).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Interesting thought. I worry about the word "accessible" though.
>
>
>
> People who are colorblind would not consider "programmatically
> determinable text" accessible nor would people with cognitive,
> language or learning.
>
>
>
> It would also add length to a lot of provisions.
>
>
>
> BUT on the positive side it lets 'text' have its broader common
> meaning.
>
>
>
> I thought of using e-text years ago (in WCAG) to do this but people
> thought this was too 'tech-y' or hard to read.
>
>
>
>
>
>
>
> Can anyone think of something that would allow us to have two types of
> Text generic text which we wouild call text and programmatically
> determinable text that we would call...... what? e-text is
> awkward. 'accessible-text' isn't accurate (or is one-disability
> accessible) pd-text?
>
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
> If Attachment is a mail.dat try http://www.kopf.com.br/winmail/
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
> *Peter Korn
> *Sent:* Tuesday, March 18, 2008 11:48 AM
> *To:* TEITAC Committee
> *Subject:* Re: [teitac-committee] Text and the importance of
> programmatically determinable
>
> Hi all,
>
> I think what makes the most sense is to define "text" as a variant
> of what Andi put forth, and to define "accessible text" using PD
> language (that we when call out to the Access Board on the topic
> of whether or not PD is defined in terms of what existing &
> commercially available AT are already using). We can do this in
> the same definition block of text, with a second paragraph
> detailing "accessible text". Then it is a simple editorial change
> to make "text" be "accessible text" in most places in the document.
>
> This preserves the meaning of "text" that most engineers will
> understand, and makes clear everywhere in the document where we
> mean it to be so that we are talking about a particular variant of
> "text" that has the additional property of being accessible.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>
> Hi
>
> I also had run a complete analysis -- but was hesitant to post it.
>
> But since it came up with a different conclusion here it is.
>
> I agree that clearing up text would cause us to need to change
> some provisions or definitions (just 3)
>
> But if we do not make it clear in the definition that text must be
> PD it would cause us to have to change 25.
>
> Several that Sean posted are already fixed in today's drafts -- or
> are not a problem (see below). They don't require text to be
> programmatically determined, but the wording of the provisions
> accounts for that definition. For example they already say
> "text or images of text"
>
>
> * For all 25 of these provisions it is essential that text
> be electronically accessible by AT or the provisions do not
> work. *
>
> 1. Note: Simple text editors that can only create or modify
> content in conforming formats by directly editing the code
> are not considered authoring tools under this definition.
> 2. Note 1: CAPTCHA tests often involve asking the user to type
> in text that is presented in an obscured image or audio file.
> 3. *Content *(Consensed) Information and sensory experience to
> be communicated to the user by means of software, including
> but not limited to: text, images, sounds, videos, controls
> and animations, as well as the encoding that defines the
> structure, presentation, and interactions associated with
> those elements. For example: word processing files,
> presentation files, spreadsheet files, text files, portable
> document files, web based content, etc.
> 4. *Label* (Consensed) Text or other component with a text
> alternative that is presented to a user to identify a
> component within content.
> 5. *Non-text Object *(Consensed) Any object that is not a
> sequence of characters that is programmatically determinable
> or where the sequence is not expressing something in human
> language. *Note*: This includes, but is not limited to,
> ASCII Art (which is a pattern of characters), emoticons,
> leetspeak (which is character substitution), and images
> representing text.
> 6. *Real-time Text: *Communications that employ the
> transmission of text wherein the characters are transmitted
> by a terminal within a maximum of 1 second of character
> input. This would typically be for conversational purposes
> but also may be used in voicemail, IVR and other similar
> applications. {TTYs are AT and need to access this -- and
> IP real-time text AT needs to be able to receive the IPtext
> (and translate into different forms -- for example braille
> for those who are deafblind.}
> 7. *Text:* Sequence of characters that is programmatically
> determinable, where the sequence is expressing something in
> human language.
> 8. *TTY *(Consensed) An abbreviation for teletypewriter.
> Machinery or equipment that enables interactive text based
> communications through the transmission of
> frequency-shift-keying audio tones across the PSTN according
> to TIA-825-A (A Frequency Shift Keyed Modem For Use On The
> Public Switched Telephone Network). As used in this part,
> the term TTY includes devices for text-to-text
> communications along with voice and text intermixed
> communications such as voice carry over and hearing carry
> over. TTYs may include computers with special modems. TTYs
> are a subset of devices called text telephones.
> 9. *1-C - Pass Through* (Consensed): Products that transmit
> or conduct information or communication must preserve
> accessibility information that is transmitted in
> non-proprietary, industry-standard codes, translation
> protocols, or formats. Technologies which use encoding,
> signal compression, format transformation, or similar
> techniques must not remove information needed for access, or
> must restore it upon delivery. Firewalls, routers,gateways
> and other products that pass real-time voice communication
> must also pass real-time text communication signals
> (including mixed voice and real-time text) that are standard
> in the United States for that technology platform without
> distortion or error beyond 1%. {See real-time-text
> definition above. Must be accessible by AT}
> 10. *1-E - Visual Information* (Partial recommendation, No
> quorum) Version 2 All information that is needed for
> operation and use that is provided in visual form must also
> be available in at least one mode in audio form or in simple
> tactile form, either directly or {ending to be determined in
> AT discussion}. Visual content that includes text and that
> is closed due to Digital Rights Management (DRM) such that
> it cannot be rendered in audio form by AT and other players
> must include an audio form that can be. *Note* 1: Section
> 255 and Section 508 treat AT solutions differently, so
> review section XX of this document before implementing a
> solution. *Note* 2: Braille is not a simple tactile form.
> It is encouraged but cannot be used to satisfy this
> provision. {This clearly says that the text -- which would
> otherwise be accessible to AT is rendered in such a way that
> it is not}.
> 11. *3-A - Color *(Consensed): Color must not be used as the
> only visual means of conveying information, indicating an
> action, prompting a response, or distinguishing a visual
> element. Example: A conforming example is mandatory form
> fields are identified with colored text and labeled as
> "Required". { This is an example and if field is
> identified by text -- then the text needs to be accessible
> by AT (by non-text provision) in order to be the means for
> identifying. Otherwise this example would be written
> "visually identified" Also, if identification was not
> accessible to AT then the example would show that the person
> could tell it was required but provide no means for
> identifying what to put into the field.}.
> 12. *3-F - Non-text Objects* (Consensed)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 object 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
> at least provide a descriptive label that identifies the non-text
> object. (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 must be implemented such that
> it can be ignored by assistive technology.
>
> Note: In order to satisfy 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
>
> <!--[if !supportLists]-->13. <!--[endif]-->*3-G - Human Language
> *(Consensed): When supported in the technologies of electronic
> documents, the default human language of electronic document must
> be programmatically determinable. *Note*: In order to achieve
> this provision, text encoded in data operated on by the software
> would need to be associated with sufficient information to
> identify both the primary language of the text, and the language
> of any sections or the text that are in another language from the
> primary language, that the software can obtain as readily as it
> can obtain the text itself.
>
> <!--[if !supportLists]-->14. <!--[endif]-->*3-N - Link Purpose
> *(Consensed): On Web pages, it must be possible to determine the
> purpose of each link from the link text or the link text together
> with its programmatically determinable link context. *Note:* In
> order to achieve this provision, links encoded in data operated on
> by the software would need to be associated with link text that
> the software can obtain as readily as it can obtain the link itself.
>
> <!--[if !supportLists]-->15. <!--[endif]-->*3-O - Information
> and Relationships* (Consensed): Information and relationships
> conveyed through presentation of electronic documents must be
> either programmatically determinable or available in text, and
> notification of changes to these is available to user agents,
> including assistive technologies.
>
> <!--[if !supportLists]-->16. <!--[endif]-->*3-P - User Interface
> Components: * ..... Example: Frames must be titled with
> text that facilitates frame identification and navigation.
>
> <!--[if !supportLists]-->17. <!--[endif]-->*3-S - Keyboard
> Operation: *(Consensed): ...... Note 2: The exception
> relates to the underlying function, not the input technique. For
> example, if using handwriting to enter text, the input technique
> (handwriting) requires path dependent input but the underlying
> function (text input) does not.
>
> <!--[if !supportLists]-->18. <!--[endif]-->*3-NEW - Visual
> Indication of Keyboard Shortcuts *: All keyboard commands
> associated directly with user interface controls must be visible
> within the visual user interface in at least one mode, and
> available programmatically to AT on products that support AT
> interoperability. Note 1: This includes commands such as those
> used to active a menu item or button (e.g. the "S" of a "Save
> File" menu item), but does not include commands that are
> system-wide or common conventions for using an item (e.g. a
> command to switch windows such as ALT-TAB, or a command to advance
> the caret in text such as Ctrl-Arrow). Note 2: User-configurable
> keyboard commands may be considered not directly tied to interface
> elements. However, when possible such user-configurable keyboard
> bindings should be visually presented as configured.
>
> <!--[if !supportLists]-->19. <!--[endif]-->*3-U - AT
> Interoperability* (Discussed March 4, partial consensus): On
> platforms that support AT-E&IT interoperability, software that
> provides user interface components must either use the
> accessibility services provided by platform software or other
> services to cooperate with assistive technologies when such
> services allow the software to meet the accessibility provisions
> of this standard.
>
> Using such services, software must:
>
> 1. expose object information including but not limited to:
>
> a. role, state(s), boundary, name, and description
>
> b. the row and column a component is in, and the headers for the
> row and column for that component if it is in a table that has row
> or column headers,
>
> c. current value and any minimum or maximum values, if the
> component represents one of a range of values
>
> d. relationship this component has as a label for another
> component, or being labeled by another component
>
> e. name of parent or containing element, and any children components
>
> f. text contents, text attributes, and the boundary of text
> rendered to the screen
>
> g. keyboard shortcuts and implicit designators.
>
> In order to meet this provision, interactive elements encoded in
> data operated on by the software must be associated with
> sufficient information to programmatically determine a role,
> state(s), name, and description for the interactive element, that
> the software can obtain as readily as it can obtain the
> interactive element itself.
>
> 2. expose a list of actions that can be executed on an object and
> allow assistive technology to programmatically execute any of
> those actions;
>
> Proposed revision to #2 from Sean, March 5: Note 2: expose a list
> of actions that can be executed on an object and allow
> programmatic execution of any of those actions;
>
> 3. expose information necessary to track and modify: focus, text
> insertion point, and selection attributes of user interface
> components;
>
> 4. expose notification of events relevant to user interactions,
> including but not limited to changes in the component's state(s),
> value, name, description, or boundary
>
> Note 1: This provision also applies to forms in the software.
>
> Note 2: Software that provides remote access to graphical user
> interfaces (GUIs) would need to ensure that AT has access to the
> information required by this provision. There are two known ways
> to accomplish this: run the AT remotely as well or run the AT
> locally and provide a mechanism for it to communicate
> accessibility information with the remote GUI.
>
> Note 3: The term 'assistive technology' in this provision and
> provision 3-V-Accessibility Services refers to assistive
> technology that exists and that is available to government
> employees (or members of the public for public facing E&IT). If no
> AT exists for a given platform or application at the time of
> procurement then the technical provisions should still be met in
> absence of AT and the FPC should, as in all cases, be used as a
> guide toward measurement of overall accessibility.
>
> <!--[if !supportLists]-->20. <!--[endif]-->*3-AA - Error
> Identification* (Consensed): If an input error is automatically
> detected in content or electronic documents, the item that is in
> error must be identified and described to the user in text.
>
> <!--[if !supportLists]-->21. <!--[endif]-->*5-B - Video
> Description* (Consensed): Materials containing video and/or
> audio, regardless of format, that contain visual information
> necessary for the comprehension of the content, must comply with
> the following:
>
> 1. Materials containing prerecorded video and no original audio or
> other additional time-based content must provide either a separate
> text description of the video or provide an additional audio track
> to convey the informational content of the video.
>
> 2. When the visual informational content is not conveyed through
> other means, materials containing prerecorded video with
> concurrent audio must provide synchronized video descriptions, or
> when space is not available in the main program audio for
> synchronized video descriptions, a separate text description of
> the video content must be provided.
>
> 3. Materials containing live video must provide synchronized video
> descriptions in real time to convey any informational content of
> the video that is not conveyed through other means.
>
> <!--[if !supportLists]-->22. <!--[endif]-->*6-A - Real-Time Text
> Reliability and Interoperability *(Consensed): If hardware or
> software provides real-time voice conversation functionality it
> must provide at least one means of real-time text communication
> where the following reliability requirements are met:
>
> 1. Products must use a real-time text (RTT) system that meets the
> following requirements:
>
> * a. RTT format must be a standard real-time text format for
> the voice platform that is supported by all terminal, router,
> gateway and other products on that platform;
>
> * b. RTT format must transmit characters with less than 1
> second delay from entry;
>
> * c. RTT system must transmit text with less than 1% Total
> Character Error Rate at the peak network traffic specified for
> intelligible speech transmission (text must work on the network as
> long as speech does);
>
> * d. The RTT system, together with the audio system, must
> support speech and text in both directions in the same call
> session (and support speech and text simultaneously in both
> directions in the same call session if IP based)
>
> * e. RTT system must not utilize audio tones for transmission
> of real-time text over IP. Note: this is subject to a waiver of
> the TTY support requirement from the FCC for systems that
> implement IP based RTT. Also subject to consumer acceptance of
> prefixes or phone numbers to direct TTY traffic to gateways
> capable of handling TTY translation.
>
> 2. Where products or systems interoperate outside of their closed
> systems, they must:
>
> * a. If product interfaces with PSTN, it must use TIA 825A
> Baudot where it interfaces to the PSTN.
>
> * b. If product interfaces with other VoIP products or systems
> (outside of a self-contained product-system) using SIP it must
> support transmission of text as per XXX where it interfaces with
> other VoIP products or systems. Note: this is subject to a waiver
> of the TTY support requirement from the FCC for systems that
> implement IP based RTT. Also subject to consumer acceptance of
> prefixes or phone numbers to direct TTY traffic to gateways
> capable of handling TTY translation.
>
> * c. If product connects to other products or systems using a
> protocol other than SIP it must use the standard real-time text
> protocol that meets provision 1 above that has been established
> for that protocol.
>
> Note 1: RFC-4103, TIA 1001, and MSRP (RFC4975) are being explored
> to fill the role of XXX. The intention is that XXX will be
> replaced by one interconnection format in all places it was used.
>
> Note 2: All products may support and use other protocols in
> addition to these as long as they meet the 5 requirements of
> 5-B(1) above.
>
> Note 3: A self-contained SIP system that uses the same real-time
> text protocol can be treated as a single product and can use any
> protocol internally as long as it supports XXX where the
> system-product connects to other systems or products.
>
> <!--[if !supportLists]-->23. <!--[endif]-->*6-B - Voice Terminal
> Hardware and Software* (Consensed, still have items to resolve)
> Terminal hardware or software that is capable of providing voice
> communications in real-time must comply with the following:
>
> 1. Receive only: If hardware or software terminal provides voice
> conversation over IP in any form, and has a user interface with a
> multi-line display or a user interface that runs on devices that
> have a multi-line display, then that terminal must display any
> real-time text that is received if it is received in the format
> for the voice and real-time text system being used on the network
> on which it is installed.
>
> 2. Send and Receive: If terminal hardware or software provides
> voice conversation over IP in any form, and has text generation
> capability, then the terminal must allow users to send real-time
> text in the format for the voice and real-time text system being
> used on the network on which it is installed.
>
> 3. If IP terminal hardware or software does not provide real-time
> text send and receive capability then the terminal must support
> the addition of terminals and terminal peripheral equipment that
> do support real-time text functionality in conjunction with the
> voice call functionality, in the same location and with the same
> permissions for use as their voice terminal. If the terminal is in
> a public or shared area and not in an individual's private work
> area then the connection must be possible [without requiring
> system-administrator intervention]. Note: the "without
> system-administrator intervention" is a serious concern due to
> security issues, but removal would prevent people from connecting
> devices outside of their home system. Additional work is needed to
> address this issue.]
>
> 4. If terminal is analog or TDM-digital wired terminal then it
> must support the connection of a TTY via an RJ-11 jack in the same
> location and with the same permissions for use as the telephone
> and it must be capable of allowing simultaneous speech and text
> conversation without interference or its microphone must be
> capable of being turned on and off to allow the user to intermix
> speech with text use.
>
> Note 1: Provision of the RJ-11 jack may be accomplished through
> one of the following techniques:
>
> a. provision of the RJ-11 jack on the telephone,
>
> b. the use of a Y-adapter that allows both the analog telephone
> and the TTY to be plugged into the same line outlet,
>
> c. having built in capability to support an RJ11 module that can
> provide a connection point for TTYs.
>
> Note 2: The standard format for PSTN is TIA-825A. For SIP is it
> XXX. For other voice transport protocols the format is to be
> determined by the entity responsible for the voice transport protocol.
>
> <!--[if !supportLists]-->24. <!--[endif]-->*6-C - IVR,
> Auto-Attendant and Messaging *(Consensed): Voice mail, messaging,
> auto-attendant, and interactive voice response telecommunications
> systems must provide access in the following manner: 1) All
> functions that are accessible to voice users must also be directly
> accessible to users of real-time text. <SNIP>
>
> <!--[if !supportLists]-->25. <!--[endif]-->* 2. Text
> descriptions: *Documentation and training materials should
> include text descriptions of the interface. These descriptions
> should stand on their own and be understandable without relying on
> graphic images in the materials.
>
>
> */4 Places where PD is not required but current language
> accounts for PD definition of text. (in fact- assumes it) /*
>
> 1. ** Large Scale Text *(Consensed) At least 18 point or 14
> point bold {In provision we actually say large scale
> text or images of large scale text}
>
> <!--[if !supportLists]-->2. <!--[endif]-->** 3-T - Focus
> Indicator* (Consensed): Any keyboard operable user interface must
> support a mode of operation where the indication of keyboard focus
> has a high degree of visibility. Note 1: The presence of a highly
> visible text insertion point is sufficient for a text area. Note
> 2: A focus cursor that is visually locatable at 3.5 times the
> typical viewing distance without moving the cursor by people who
> have unimpaired vision and are familiar with what the focus cursor
> looks like is sufficient. For example, when software is displayed
> on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels
> resolution, a focus cursor that is visually locatable at 2.5
> meters without moving the cursor by people who are familiar with
> what the cursor looks like and have unimpaired vision is sufficient.
>
> 3. ** 3-B - Contrast *(Consensed) Presentation of text, and
> images of text, in electronic documents must have a contrast
> ratio of at least 5:1, except for the following: * Large
> Print: Large-scale text and images of large-scale text must
> have a contrast ratio of at least 3:1; * Incidental:
> Text or images of text that are part of an inactive user
> interface component, that are pure decoration, that are
> incidental text in an image, or that are not visible to
> anyone, have no minimum contrast requirement.
>
> <!--[if !supportLists]-->4. <!--[endif]-->** 3-D - User
> Preferences *(Consensed) Applications must provide a mode that
> utilizes platform settings for color, contrast, font type, font
> size, and focus cursor. In the absence of platform settings for
> color and contrast, all text (and images of text) must have a
> contrast ratio of at least 5:1 except for the following: *
> Large Print: Large-scale text and images of large-scale text must
> have a contrast ratio of at least 3:1; * Incidental: Text or
> images of text that are part of an inactive user interface
> component, that are pure decoration, that are incidental text in
> an image, or that are not visible to anyone, have no minimum
> contrast requirement.
>
> <!--[if !supportLists]-->5. <!--[endif]-->*Captions (new
> wording )*
>
> <!--[if !supportLists]-->6. <!--[endif]-->
>
>
> */Places where text being PD would require a change /*
>
> The following items would need small changes like adding "and
> images of text". This would be needed in order to make their
> wording consistent with other provisions anyway.
>
>
> *Contrast Ratio (Consensed) (just changing some
> informative notes)*
>
> *Note 3:* Text *AND IMAGES OF TEXT* can be evaluated with
> anti-aliasing turned off.
>
> *Note 4:* Background color is the specified color of content over
> which the text* OR IMAGE OF TEXT* is to be rendered in normal
> usage. If no background color is specified, then white is assumed.
>
> *Note 5:* For* *text *OR IMAGES OF TEXT *displayed over gradients
> and background images, authors should ensure that sufficient
> contrast exists for each part of each character in the content.
>
>
> *Video Description *
>
> The insertion of verbal or auditory description(s) of on-screen
> visuals intended to describe important visual details that are not
> contained in, or that cannot be understood from, the main audio
> output alone. Video descriptions supplement the regular audio
> track of the program and are usually inserted between dialogue
> narration to provide information about actions, characters, and
> on-screen text* OR IMAGES OF TEXT* that appear without
> verbalization. Video descriptions are a way to let people who are
> blind or have low vision know what is happening on screen.
>
>
> *1-G - Text size (Discussed Feb 7, 12, 19)*
>
> There must be at least one mode where all information that is
> required for product use and is provided in text *OR IMAGES OF
> TEXT* is readable by people with 20/20 vision at 3.5 times their
> typical viewing distance. This mode must be the default mode
> unless the activation method for that mode can be done at 3.5
> times the typical viewing distance or the product automatically
> sets itself to that mode for users who require it. This provision
> does not apply to safety labels, regulatory labels, and marks that
> are not required for product use. /This requirement does not apply
> to the caption decoding functions of products that are governed by
> U.S. Federal Communications Commission (FCC) regulations 47 CFR
> 15.119 or to devices which provide equivalent functionality as
> stipulated by 4-A - Caption Processing/
>
>
> Gregg
>
> ------------------------
>
> Gregg C Vanderheiden Ph.D.
> Professor - Depts of Ind. Engr. & BioMed Engr.
> Director - Trace R & D Center
> University of Wisconsin-Madison
> _<_http://trace.wisc.edu/_>_ FAX 608/262-8848
>
> DSS Player at http://tinyurl.com/dho6b
>
> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
>

From: Gregg Vanderheiden
Date: Tue, Mar 18 2008 10:50 PM
Subject: Re: Text and the importance of programmatically determinable

Grin - Yes, Peter - I see what you mean.



And yes - you can do that in a standard and it is legal.



However, the access board cannot do that politically and survive. ( They
cannot declare or define something as accessible that is only really
accessible to one disability. Uffda. )



So I would avoid "accessible-text".





But your idea is one I think we should keep shopping. Anyone got any
other ideas?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

If Attachment is a mail.dat try http://www.kopf.com.br/winmail/






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Tuesday, March 18, 2008 5:55 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Text and the importance of programmatically
determinable

Hi Gregg,

Now you sound a bit like me and me like you. You argued that words mean
what we define them to mean, so if we defined "accessible text" as PD (and
expressly not addressing colorblind), then we'd be OK.

For myself, I'm not tied to the term "accessible text". "e-text" or
something else would likely be fine (pending the word/phrase suggested).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.




Interesting thought. I worry about the word "accessible" though.

People who are colorblind would not consider "programmatically determinable
text" accessible nor would people with cognitive, language or learning.

It would also add length to a lot of provisions.

BUT on the positive side it lets 'text' have its broader common meaning.

I thought of using e-text years ago (in WCAG) to do this but people
thought this was too 'tech-y' or hard to read.

Can anyone think of something that would allow us to have two types of Text
generic text which we wouild call text and programmatically determinable
text that we would call.. what? e-text is awkward. 'accessible-text'
isn't accurate (or is one-disability accessible) pd-text?


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

If Attachment is a mail.dat try http://www.kopf.com.br/winmail/




_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Tuesday, March 18, 2008 11:48 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Text and the importance of programmatically
determinable

Hi all,

I think what makes the most sense is to define "text" as a variant of what
Andi put forth, and to define "accessible text" using PD language (that we
when call out to the Access Board on the topic of whether or not PD is
defined in terms of what existing & commercially available AT are already
using). We can do this in the same definition block of text, with a second
paragraph detailing "accessible text". Then it is a simple editorial change
to make "text" be "accessible text" in most places in the document.

This preserves the meaning of "text" that most engineers will understand,
and makes clear everywhere in the document where we mean it to be so that we
are talking about a particular variant of "text" that has the additional
property of being accessible.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.






Hi

I also had run a complete analysis - but was hesitant to post it.

But since it came up with a different conclusion here it is.

I agree that clearing up text would cause us to need to change some
provisions or definitions (just 3)

But if we do not make it clear in the definition that text must be PD it
would cause us to have to change 25.

Several that Sean posted are already fixed in today's drafts - or are not a
problem (see below). They don't require text to be programmatically
determined, but the wording of the provisions accounts for that definition.
For example they already say "text or images of text"


For all 25 of these provisions it is essential that text be electronically
accessible by AT or the provisions do not work.


1. Note: Simple text editors that can only create or modify content in
conforming formats by directly editing the code are not considered authoring
tools under this definition.
2. Note 1: CAPTCHA tests often involve asking the user to type in text
that is presented in an obscured image or audio file.
3. Content (Consensed) Information and sensory experience to be
communicated to the user by means of software, including but not limited to:
text, images, sounds, videos, controls and animations, as well as the
encoding that defines the structure, presentation, and interactions
associated with those elements. For example: word processing files,
presentation files, spreadsheet files, text files, portable document files,
web based content, etc.
4. Label (Consensed) Text or other component with a text alternative
that is presented to a user to identify a component within content.
5. Non-text Object (Consensed) Any object that is not a sequence of
characters that is programmatically determinable or where the sequence is
not expressing something in human language. Note: This includes, but is not
limited to, ASCII Art (which is a pattern of characters), emoticons,
leetspeak (which is character substitution), and images representing text.
6. Real-time Text: Communications that employ the transmission of text
wherein the characters are transmitted by a terminal within a maximum of 1
second of character input. This would typically be for conversational
purposes but also may be used in voicemail, IVR and other similar
applications. {TTYs are AT and need to access this - and IP real-time
text AT needs to be able to receive the IPtext (and translate into different
forms - for example braille for those who are deafblind.}
7. Text: Sequence of characters that is programmatically determinable,
where the sequence is expressing something in human language.
8. TTY (Consensed) An abbreviation for teletypewriter. Machinery or
equipment that enables interactive text based communications through the
transmission of frequency-shift-keying audio tones across the PSTN according
to TIA-825-A (A Frequency Shift Keyed Modem For Use On The Public Switched
Telephone Network). As used in this part, the term TTY includes devices for
text-to-text communications along with voice and text intermixed
communications such as voice carry over and hearing carry over. TTYs may
include computers with special modems. TTYs are a subset of devices called
text telephones.
9. 1-C - Pass Through (Consensed): Products that transmit or conduct
information or communication must preserve accessibility information that is
transmitted in non-proprietary, industry-standard codes, translation
protocols, or formats. Technologies which use encoding, signal
compression, format transformation, or similar techniques must not remove
information needed for access, or must restore it upon delivery.
Firewalls, routers,gateways and other products that pass real-time voice
communication must also pass real-time text communication signals (including
mixed voice and real-time text) that are standard in the United States for
that technology platform without distortion or error beyond 1%. {See
real-time-text definition above. Must be accessible by AT}
10. 1-E - Visual Information (Partial recommendation, No quorum) Version
2 All information that is needed for operation and use that is provided in
visual form must also be available in at least one mode in audio form or in
simple tactile form, either directly or {ending to be determined in AT
discussion}. Visual content that includes text and that is closed due to
Digital Rights Management (DRM) such that it cannot be rendered in audio
form by AT and other players must include an audio form that can be. Note
1: Section 255 and Section 508 treat AT solutions differently, so review
section XX of this document before implementing a solution. Note 2: Braille
is not a simple tactile form. It is encouraged but cannot be used to satisfy
this provision. {This clearly says that the text - which would otherwise
be accessible to AT is rendered in such a way that it is not}.
11. 3-A - Color (Consensed): Color must not be used as the only visual
means of conveying information, indicating an action, prompting a response,
or distinguishing a visual element. Example: A conforming example is
mandatory form fields are identified with colored text and labeled as
"Required". { This is an example and if field is identified by text -
then the text needs to be accessible by AT (by non-text provision) in order
to be the means for identifying. Otherwise this example would be written
"visually identified" Also, if identification was not accessible to AT then
the example would show that the person could tell it was required but
provide no means for identifying what to put into the field.}.
12. 3-F - Non-text Objects (Consensed)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 object 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 at least provide a
descriptive label that identifies the non-text object. (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 must be implemented such that it can be ignored by assistive
technology.

Note: In order to satisfy 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

<!--[if !supportLists]-->13. <!--[endif]-->3-G - Human Language
(Consensed): When supported in the technologies of electronic documents,
the default human language of electronic document must be programmatically
determinable. Note: In order to achieve this provision, text encoded in
data operated on by the software would need to be associated with sufficient
information to identify both the primary language of the text, and the
language of any sections or the text that are in another language from the
primary language, that the software can obtain as readily as it can obtain
the text itself.

<!--[if !supportLists]-->14. <!--[endif]-->3-N - Link Purpose (Consensed):
On Web pages, it must be possible to determine the purpose of each link from
the link text or the link text together with its programmatically
determinable link context. Note: In order to achieve this provision, links
encoded in data operated on by the software would need to be associated with
link text that the software can obtain as readily as it can obtain the link
itself.

<!--[if !supportLists]-->15. <!--[endif]-->3-O - Information and
Relationships (Consensed): Information and relationships conveyed through
presentation of electronic documents must be either programmatically
determinable or available in text, and notification of changes to these is
available to user agents, including assistive technologies.

<!--[if !supportLists]-->16. <!--[endif]-->3-P - User Interface
Components: ... Example: Frames must be titled with text that
facilitates frame identification and navigation.

<!--[if !supportLists]-->17. <!--[endif]-->3-S - Keyboard Operation:
(Consensed): .. Note 2: The exception relates to the underlying
function, not the input technique. For example, if using handwriting to
enter text, the input technique (handwriting) requires path dependent input
but the underlying function (text input) does not.

<!--[if !supportLists]-->18. <!--[endif]-->3-NEW - Visual Indication of
Keyboard Shortcuts : All keyboard commands associated directly with user
interface controls must be visible within the visual user interface in at
least one mode, and available programmatically to AT on products that
support AT interoperability. Note 1: This includes commands such as those
used to active a menu item or button (e.g. the "S" of a "Save File" menu
item), but does not include commands that are system-wide or common
conventions for using an item (e.g. a command to switch windows such as
ALT-TAB, or a command to advance the caret in text such as Ctrl-Arrow).
Note 2: User-configurable keyboard commands may be considered not directly
tied to interface elements. However, when possible such user-configurable
keyboard bindings should be visually presented as configured.

<!--[if !supportLists]-->19. <!--[endif]-->3-U - AT Interoperability
(Discussed March 4, partial consensus): On platforms that support AT-E&IT
interoperability, software that provides user interface components must
either use the accessibility services provided by platform software or other
services to cooperate with assistive technologies when such services allow
the software to meet the accessibility provisions of this standard.

Using such services, software must:

1. expose object information including but not limited to:

a. role, state(s), boundary, name, and description

b. the row and column a component is in, and the headers for the row and
column for that component if it is in a table that has row or column
headers,

c. current value and any minimum or maximum values, if the component
represents one of a range of values

d. relationship this component has as a label for another component, or
being labeled by another component

e. name of parent or containing element, and any children components

f. text contents, text attributes, and the boundary of text rendered to the
screen

g. keyboard shortcuts and implicit designators.

In order to meet this provision, interactive elements encoded in data
operated on by the software must be associated with sufficient information
to programmatically determine a role, state(s), name, and description for
the interactive element, that the software can obtain as readily as it can
obtain the interactive element itself.

2. expose a list of actions that can be executed on an object and allow
assistive technology to programmatically execute any of those actions;

Proposed revision to #2 from Sean, March 5: Note 2: expose a list of actions
that can be executed on an object and allow programmatic execution of any of
those actions;

3. expose information necessary to track and modify: focus, text insertion
point, and selection attributes of user interface components;

4. expose notification of events relevant to user interactions, including
but not limited to changes in the component's state(s), value, name,
description, or boundary

Note 1: This provision also applies to forms in the software.

Note 2: Software that provides remote access to graphical user interfaces
(GUIs) would need to ensure that AT has access to the information required
by this provision. There are two known ways to accomplish this: run the AT
remotely as well or run the AT locally and provide a mechanism for it to
communicate accessibility information with the remote GUI.

Note 3: The term 'assistive technology' in this provision and provision
3-V-Accessibility Services refers to assistive technology that exists and
that is available to government employees (or members of the public for
public facing E&IT). If no AT exists for a given platform or application at
the time of procurement then the technical provisions should still be met in
absence of AT and the FPC should, as in all cases, be used as a guide toward
measurement of overall accessibility.

<!--[if !supportLists]-->20. <!--[endif]-->3-AA - Error Identification
(Consensed): If an input error is automatically detected in content or
electronic documents, the item that is in error must be identified and
described to the user in text.

<!--[if !supportLists]-->21. <!--[endif]-->5-B - Video Description
(Consensed): Materials containing video and/or audio, regardless of
format, that contain visual information necessary for the comprehension of
the content, must comply with the following:

1. Materials containing prerecorded video and no original audio or other
additional time-based content must provide either a separate text
description of the video or provide an additional audio track to convey the
informational content of the video.

2. When the visual informational content is not conveyed through other
means, materials containing prerecorded video with concurrent audio must
provide synchronized video descriptions, or when space is not available in
the main program audio for synchronized video descriptions, a separate text
description of the video content must be provided.

3. Materials containing live video must provide synchronized video
descriptions in real time to convey any informational content of the video
that is not conveyed through other means.

<!--[if !supportLists]-->22. <!--[endif]-->6-A - Real-Time Text
Reliability and Interoperability (Consensed): If hardware or software
provides real-time voice conversation functionality it must provide at least
one means of real-time text communication where the following reliability
requirements are met:

1. Products must use a real-time text (RTT) system that meets the following
requirements:

* a. RTT format must be a standard real-time text format for the voice
platform that is supported by all terminal, router, gateway and other
products on that platform;

* b. RTT format must transmit characters with less than 1 second delay
from entry;

* c. RTT system must transmit text with less than 1% Total Character
Error Rate at the peak network traffic specified for intelligible speech
transmission (text must work on the network as long as speech does);

* d. The RTT system, together with the audio system, must support speech
and text in both directions in the same call session (and support speech and
text simultaneously in both directions in the same call session if IP based)

* e. RTT system must not utilize audio tones for transmission of
real-time text over IP. Note: this is subject to a waiver of the TTY support
requirement from the FCC for systems that implement IP based RTT. Also
subject to consumer acceptance of prefixes or phone numbers to direct TTY
traffic to gateways capable of handling TTY translation.

2. Where products or systems interoperate outside of their closed systems,
they must:

* a. If product interfaces with PSTN, it must use TIA 825A Baudot where
it interfaces to the PSTN.

* b. If product interfaces with other VoIP products or systems (outside
of a self-contained product-system) using SIP it must support transmission
of text as per XXX where it interfaces with other VoIP products or systems.
Note: this is subject to a waiver of the TTY support requirement from the
FCC for systems that implement IP based RTT. Also subject to consumer
acceptance of prefixes or phone numbers to direct TTY traffic to gateways
capable of handling TTY translation.

* c. If product connects to other products or systems using a protocol
other than SIP it must use the standard real-time text protocol that meets
provision 1 above that has been established for that protocol.

Note 1: RFC-4103, TIA 1001, and MSRP (RFC4975) are being explored to fill
the role of XXX. The intention is that XXX will be replaced by one
interconnection format in all places it was used.

Note 2: All products may support and use other protocols in addition to
these as long as they meet the 5 requirements of 5-B(1) above.

Note 3: A self-contained SIP system that uses the same real-time text
protocol can be treated as a single product and can use any protocol
internally as long as it supports XXX where the system-product connects to
other systems or products.

<!--[if !supportLists]-->23. <!--[endif]-->6-B - Voice Terminal Hardware
and Software (Consensed, still have items to resolve) Terminal hardware or
software that is capable of providing voice communications in real-time must
comply with the following:

1. Receive only: If hardware or software terminal provides voice
conversation over IP in any form, and has a user interface with a multi-line
display or a user interface that runs on devices that have a multi-line
display, then that terminal must display any real-time text that is received
if it is received in the format for the voice and real-time text system
being used on the network on which it is installed.

2. Send and Receive: If terminal hardware or software provides voice
conversation over IP in any form, and has text generation capability, then
the terminal must allow users to send real-time text in the format for the
voice and real-time text system being used on the network on which it is
installed.

3. If IP terminal hardware or software does not provide real-time text send
and receive capability then the terminal must support the addition of
terminals and terminal peripheral equipment that do support real-time text
functionality in conjunction with the voice call functionality, in the same
location and with the same permissions for use as their voice terminal. If
the terminal is in a public or shared area and not in an individual's
private work area then the connection must be possible [without requiring
system-administrator intervention]. Note: the "without system-administrator
intervention" is a serious concern due to security issues, but removal would
prevent people from connecting devices outside of their home system.
Additional work is needed to address this issue.]

4. If terminal is analog or TDM-digital wired terminal then it must support
the connection of a TTY via an RJ-11 jack in the same location and with the
same permissions for use as the telephone and it must be capable of allowing
simultaneous speech and text conversation without interference or its
microphone must be capable of being turned on and off to allow the user to
intermix speech with text use.

Note 1: Provision of the RJ-11 jack may be accomplished through one of the
following techniques:

a. provision of the RJ-11 jack on the telephone,

b. the use of a Y-adapter that allows both the analog telephone and the TTY
to be plugged into the same line outlet,

c. having built in capability to support an RJ11 module that can provide a
connection point for TTYs.

Note 2: The standard format for PSTN is TIA-825A. For SIP is it XXX. For
other voice transport protocols the format is to be determined by the entity
responsible for the voice transport protocol.

<!--[if !supportLists]-->24. <!--[endif]-->6-C - IVR, Auto-Attendant and
Messaging (Consensed): Voice mail, messaging, auto-attendant, and
interactive voice response telecommunications systems must provide access in
the following manner: 1) All functions that are accessible to voice users
must also be directly accessible to users of real-time text. <SNIP>

<!--[if !supportLists]-->25. <!--[endif]--> 2. Text descriptions:
Documentation and training materials should include text descriptions of the
interface. These descriptions should stand on their own and be
understandable without relying on graphic images in the materials.


4 Places where PD is not required but current language accounts for PD
definition of text. (in fact- assumes it)


1. * Large Scale Text (Consensed) At least 18 point or 14 point bold
{In provision we actually say large scale text or images of large scale
text}

<!--[if !supportLists]-->2. <!--[endif]-->* 3-T - Focus Indicator
(Consensed): Any keyboard operable user interface must support a mode of
operation where the indication of keyboard focus has a high degree of
visibility. Note 1: The presence of a highly visible text insertion point is
sufficient for a text area. Note 2: A focus cursor that is visually
locatable at 3.5 times the typical viewing distance without moving the
cursor by people who have unimpaired vision and are familiar with what the
focus cursor looks like is sufficient. For example, when software is
displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels
resolution, a focus cursor that is visually locatable at 2.5 meters without
moving the cursor by people who are familiar with what the cursor looks like
and have unimpaired vision is sufficient.

3. * 3-B - Contrast (Consensed) Presentation of text, and images of
text, in electronic documents must have a contrast ratio of at least 5:1,
except for the following: * Large Print: Large-scale text and images of
large-scale text must have a contrast ratio of at least 3:1; *
Incidental: Text or images of text that are part of an inactive user
interface component, that are pure decoration, that are incidental text in
an image, or that are not visible to anyone, have no minimum contrast
requirement.

<!--[if !supportLists]-->4. <!--[endif]-->* 3-D - User Preferences
(Consensed) Applications must provide a mode that utilizes platform
settings for color, contrast, font type, font size, and focus cursor. In the
absence of platform settings for color and contrast, all text (and images of
text) must have a contrast ratio of at least 5:1 except for the following:
* Large Print: Large-scale text and images of large-scale text must have a
contrast ratio of at least 3:1; * Incidental: Text or images of text
that are part of an inactive user interface component, that are pure
decoration, that are incidental text in an image, or that are not visible to
anyone, have no minimum contrast requirement.

<!--[if !supportLists]-->5. <!--[endif]-->Captions (new wording )

<!--[if !supportLists]-->6. <!--[endif]-->


Places where text being PD would require a change


The following items would need small changes like adding "and images of
text". This would be needed in order to make their wording consistent with
other provisions anyway.


Contrast Ratio (Consensed) (just changing some informative notes)


Note 3: Text AND IMAGES OF TEXT can be evaluated with anti-aliasing turned
off.

Note 4: Background color is the specified color of content over which the
text OR IMAGE OF TEXT is to be rendered in normal usage. If no background
color is specified, then white is assumed.

Note 5: For text OR IMAGES OF TEXT displayed over gradients and background
images, authors should ensure that sufficient contrast exists for each part
of each character in the content.


Video Description


The insertion of verbal or auditory description(s) of on-screen visuals
intended to describe important visual details that are not contained in, or
that cannot be understood from, the main audio output alone. Video
descriptions supplement the regular audio track of the program and are
usually inserted between dialogue narration to provide information about
actions, characters, and on-screen text OR IMAGES OF TEXT that appear
without verbalization. Video descriptions are a way to let people who are
blind or have low vision know what is happening on screen.


1-G - Text size (Discussed Feb 7, 12, 19)


There must be at least one mode where all information that is required for
product use and is provided in text OR IMAGES OF TEXT is readable by people
with 20/20 vision at 3.5 times their typical viewing distance. This mode
must be the default mode unless the activation method for that mode can be
done at 3.5 times the typical viewing distance or the product automatically
sets itself to that mode for users who require it. This provision does not
apply to safety labels, regulatory labels, and marks that are not required
for product use. This requirement does not apply to the caption decoding
functions of products that are governed by U.S. Federal Communications
Commission (FCC) regulations 47 CFR 15.119 or to devices which provide
equivalent functionality as stipulated by 4-A - Caption Processing


Gregg

------------------------

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at <http://tinyurl.com/dho6b> http://tinyurl.com/dho6b

If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/








_____

From: Sean Hayes
Date: Wed, Mar 19 2008 10:35 AM
Subject: Re: Text and the importance of programmatically determinable

I think we need two qualified versions of "text"

Written text - that which is a graphical form that can be read, and what the general public would think of as 'text'. And this is probably the term that most TEITAC members had in mind when consensus was reached on the clauses involving 'text'.

Encoded text - that which is the raw data of the coded form, and what an engineer would think of as 'text', and what WCAG assumes (and why it has the unweildy and inaccurate phrase 'text and images of text')

(we may also need the concept of spoken text too)

In some cases there will be a link which software knows about from some 'written text' to its 'encoded text', and sometimes (e.g. open captions) there may not be. 'Written text' may or may not be electronic content (print for example is written text, but not electronic content), but in all cases where there is a linked encoded form that software knows about, it would be.

A text alternative, is where software has a link from something usually other than 'written text', such as an image, to 'encoded text' that conveys information about it.

The concept of providing access to 'encoded text', whether or not the text is presented in a written (or spoken) form is what I understand as 'programmatically determinable'. This latter term is not a form or property of text at all, but is a mode of access provided by software TO 'text' under certain conditions.

The reason Gregg and I differ in our analysis, is that it is my belief that, unlike WCAG, TEITAC will have 3-U, which states:

Using such services, software must:

1. expose object information including but not limited to:
...
f. text contents, text attributes, and the boundary of text rendered to the screen
...

I equate text content (from 3-U) to 'encoded text' (above). Text rendered to the screen (from 3-U) is a form of 'written text' (above).

So for the 25 cases Gregg cites below, no adjustment of the wording is necessary, since the TEITAC draft takes care of the fact through 3-U that "text" must be "PD", since any object which contains a text encoding, and is thus electronic content, must make it available to AT. Except under conditions (such as might exist in a router), where there are no AT services, nor indeed any need to add AT.

Now this is based on the idea that 3-U means the same thing as PD (subject to the caveats of 3-U, which would also need to be true of PD). If in fact the PD in the WCAG definition of text is intended to mean something different from what is in 3-U, I'd like to know what that is, as I do not believe we are going to get to consensus on it.

Sean Hayes
Media Acessibility Strategist
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385

From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: 18 March 2008 22:55
To: TEITAC Committee
Subject: Re: [teitac-committee] Text and the importance of programmatically determinable

Hi Gregg,

Now you sound a bit like me and me like you. You argued that words mean what we define them to mean, so if we defined "accessible text" as PD (and expressly not addressing colorblind), then we'd be OK.

For myself, I'm not tied to the term "accessible text". "e-text" or something else would likely be fine (pending the word/phrase suggested).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


Interesting thought. I worry about the word "accessible" though.

People who are colorblind would not consider "programmatically determinable text" accessible nor would people with cognitive, language or learning.

It would also add length to a lot of provisions.

BUT on the positive side it lets 'text' have its broader common meaning.

I thought of using e-text years ago (in WCAG) to do this but people thought this was too 'tech-y' or hard to read.



Can anyone think of something that would allow us to have two types of Text generic text which we wouild call text and programmatically determinable text that we would call...... what? e-text is awkward. 'accessible-text' isn't accurate (or is one-disability accessible) pd-text?


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
If Attachment is a mail.dat try http://www.kopf.com.br/winmail/