Thread Subject: Re: Text and the importance of programmatically determinable

From: Gregg Vanderheiden
Date: Tue, Mar 18 2008 4:50 PM

• 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: Peter Korn: "Re: Text and the importance of programmatically determinable"
• Messages sorted by: Author | Thread | Date

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







_____

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