Thread Subject: Text and the importance of programmatically determinable

From: Gregg Vanderheiden
Date: Tue, Mar 18 2008 10:40 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Peter Korn: "Re: Text and the importance of programmatically determinable"
• Previous message in thread: None
• Messages sorted by: Author | Thread | Date

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

• Next message in Thread: Peter Korn: "Re: Text and the importance of programmatically determinable"
• Previous message in Thread: None