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

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Peter Korn
Date: Tue, Mar 18 2008 11:00 AM

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

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University