EWG:Draft Sept 14 Updates

From TEITAC

Jump to: navigation, search

Contents

Updates to provisions after release of the September 14 Draft

This page will contain the text of any new or updated provision text submitted by subcommittee chairs during the September 17 - October 19 review period.

2.2 If the Product has Speech Output or Throughput

2.2-B - Interference with Hearing Device

Interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) must be reduced to the lowest possible level that allows a user of hearing technologies to utilize the telecommunications product.

Recommended Advisory Note (for US): Include information about existing standards: TIA Standard for Cordless Phones and the ANSI standard for cellular and PCS frequency bands and for hearing aid immunity. Standards do not exist for other frequency bands and for any VoIP at this time.

NOTE: Cellular and PCS handsets that meet a minimum of M3 or M4 and T3 or T4 measurement rating per ANSI C63.19 (2007) will meet this requirement for “lowest possible level.” Devices in other frequency bands (700 MHz, AWS) are not yet included in this standard, but may be so at a later time. Digital wireline cordless devices that meet TIA-1083 will meet the “lowest possible level” standard for those types of devices. 

Discussion or Rationale: 
* SC is working on the wording of this and will report back
* Need exact title/number of existing standards for reference
  • Status: In Progress, Update posted Oct 18, 2007 (Sept 14 version)
  • Text from Hardware and Telecommunications
  • Source: {508}1194.23(i), {255}1193.43(h)
  • Impact:
  • External Reference: (see note above)
  • Testability: Formal test method
  • Metadata
    • Disabilities: Hearing, Hard of Hearing
    • User Activities:
    • Product Characteristics:
    • Product Types:


2.2-E - Volume (Gain)

For incoming voice signals:

  1. Users must be able to adjust the audio output level.
  2. All telecommunications products powered solely from analog telephone lines and having an audio transducer normally held to the ear, and all cordless telephones, must comply with FCC regulation §68.317 for volume control.
  3. All cellular telephones – TBD.
  4. All other products that provide a voice communication function via an audio transducer normally held to the ear must comply with FCC regulation §68.317 for volume control. In addition, they must provide built-in gain of at least 15 dB above the normal unamplified level when measured as specified in FCC regulation §68.317.

NOTE: Headsets and earphones are not subject to this provision as long as they use industry standard connectors that allow specialized headsets, earphones and coupling cables for assistive listening devices to be used in their place. 3.5mm phone, 2.5mm phone, and RJ-10 are all examples of industry standard connectors that meet this requirement.

Rationale: The following notes are to be included either within the provision or advisory notes. Location is to be determined by EWG.

NOTE 1: The provision of volume control gain is not particularly related to whether the voice communication is carried by an analog signal, digital encoding, packet technology (e.g., VoIP), etc. It does, however, depend on the power available to the amplifier providing the gain function. This distinction has been taken into account in specifying the volume control gain requirements. For example the requirements for a battery-powered cordless telephone applies whether the product uses analog, digital or VoIP technology.

NOTE 2: FCC regulation §68.317 requires both analog and digital telephones to provide between 12 and 18 dB of gain at the maximum volume control setting relative to their volume at the normal unamplified level. The gain is allowed to exceed 18 dB if it is automatically reset to the nominal level when the telephone goes back on hook. [The FCC also has a procedure described in Memorandum Opinion and Order DA 01-578 for waiving the automatic reset requirement for telephones specifically designed for use by hard of hearing persons, provided adequate warnings are placed on the telephone.] In addition, the volume at the normal unamplified level has to meet requirements specified in industry standards ANSI/EIA-470-A-1987 (for analog telephones) and ANSI/EIA/TIA-571-1991 (for digital telephones).

NOTE 3: FCC regulation §68.317 makes reference to older industry standards in specifying how to measure the receive acoustic loudness and determine compliance with requirements for both gain and loudness at the normal unamplified level. Clause 15.2 of TIA TSB-31-C, Telecommunications – Telephone Terminal Equipment – Rationale and Measurement Guidelines for U.S. Network Protection, provides guidance on how to apply these requirements to test methods specified in current standards, including measurement procedures for analog, digital, and VoIP telephones.

NOTE 4: Other products or systems that provide a voice communication function, including products and systems that do not have an audio transducer that is normally held to the ear, such as speakerphones, should provide at least 15 dB of volume control range above the normal unamplified listening level. In these cases of speakerphones, it is desirable for the volume control to provide at least 15 dB of gain above the normal unamplified level, but there is no agreed upon specification as to what constitutes the normal unamplified level.

NOTE 5: Volume (gain) on cellular and PCS handsets is currently the focus of review and study in Working Group 11 of the ATIS Incubator program which is expected to be available no later than June 2008. It is recommended that no recommendation be made at this time by the TEITAC, but rather, the recommendations from the study can be given to the Access Board. 

Discussion of Work in Progress:
* Language for cellular phones pending outcome of ATIS Study Group 11 work
* Further research needed for 20 dB requirement
* Review telecoms/communications to be sure requirement is inclusive
* Need to determine if the word "telecommunications" should be removed
  • Status: In Progress, Update posted on October 18, 2007 (Sept 14 version)
  • Text from Telecommunications
  • Source: {508}1194.23(f)
  • Impact:
  • External Reference: FCC §68.317
  • Testability: Formal test method
  • Metadata
    • Disabilities: Hard of hearing
    • User Activities: Real-time voice conversation, IVR
    • Product Characteristics: Audio output
    • Product Types: Telephones, IVRs

3. User Interface and Electronic Content Provisions

3-A - Color

Color must not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. For example, mandatory form fields are identified with red text and labeled as "mandatory". 

Discussion of Work in Progress: 
* Added example, Sept 24, 2007
* Need to add rationale
* (Gregg) WCAG is revising their language on this item in response to TEITAC 
  and Public Comments.  We should look at their new language due out soon
  • Status: Update posted on Sept 24, 2007 (Sept 14 version)
  • Text from Web and Software
  • Source: {508}1194.22(c) and 1194.25(h)
  • Impact:
  • External Reference: Harmonized with WCAG 2.0 and ISO 9241.171
  • Testability: Expert evaluation
  • Metadata
    • Disabilities:
    • User Activities:
    • Product Characteristics:
    • Product Types:

3-D - User Preferences

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 unavailable items or pure decoration. Large scale text (or images of large scale text) must allow a contrast ratio of at least 3:1.

Discussion or Rationale:

  • Status: Done, Corrected text posted Sept 26, 2007 (Sept 14 version)
  • Text from Web and Software
  • Source: {508}1194.21(g) (was 3.2-C in July 18 draft)
  • Impact:
  • External Reference:
  • Testability: If platform settings, inspection; if no platform settings, formal test method
  • Metadata
    • Disabilities:
    • User Activities:
    • Product Characteristics:
    • Product Types:

3-F - Non-text Objects

All non-text objects that are presented to the user must have a text alternative that presents equivalent information, except for the situations listed below.

  • Controls-Input: If a non-text objects is a control or accepts user input, then it must have a name that describes its purpose. (See also User Interface Components provisions)
  • Media: If a non-text object is synchronized media, live audio-only or live video-only content, then text alternatives at least identify the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)
  • Test: If a non-text object is a test or exercise that must be presented in non-text format, then text alternatives at least identify the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)
  • Sensory: If a non-text object is primarily intended to create a specific sensory experience, then text alternatives at least identify the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)
  • CAPTCHA: If the purpose of a non-text object is to confirm that content is being accessed by a person rather than a computer then text alternatives that identify and describe the purpose of the non-text object must be provided and alternative forms in different modalities must be provided to accommodate different disabilities.
  • Decoration, Formatting, Invisible Objects: If a non-text object is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented such that it can be ignored by assistive technology.

Rationale: The word "objects" is used in this provision to make it clear to software developers that their user interface is to be included. If the word "content" was used they may not think this applies to their work.

  • Status: Done, Update posted (fixed typos) Sept 26, 2007 (Sept 14 version)
  • Text from Web and Software
  • Source: {508}1194.22(a) (was 6.1.E in July 18 draft)
  • Impact:
  • External Reference: Harmonized with WCAG 2.0
  • Testability: Expert evaluation
  • Metadata
    • Disabilities:
    • User Activities:
    • Product Characteristics:
    • Product Types:

3-M - Reading Sequence

When the sequence in which information is presented affects its meaning, a correct reading sequence must be programmatically determinable. The sequential navigation of interactive components must be consistent with that reading sequence.

Rationale: 

Discussion of Work in Progress: 
* (Peter K) The phrase "correct reading order" is not clear. In 8.1.C the phrase "logical linear" 
            is used which is clearer. Note: this topic is to be discussed at the plenary not the 
            subcommittee level
* Need rationale
  • Status: Done, Update posted Sept 26, 2007 (Sept 14 version)
  • Text from Web and Software
  • Source: new (was 6.1.N in July 18 draft)
  • Impact:
  • External Reference: Harmonized with WCAG 2.0. Similar to recommendation in ISO 9241.71
  • Testability: Inspection
  • Metadata
    • Disabilities:
    • User Activities:
    • Product Characteristics:
    • Product Types:

3-P - User Interface Components

For all user interface components, including form elements and those generated by scripts, the name and role must be programmatically determined. States, properties, and values that can be set by the user must be programmatically determined and can be programmatically set. Notification of changes to these items must be available to user agents, including assistive technologies. For example: Frames must be titled with text that facilitates frame identification and navigation.

Rationale: To ensure that interactive elements in non-HTML technologies, or those implemented by re-purposing HTML elements with JavaScript, properly expose information for AT interoperability.

Note: The word "components" was used in this provision instead of "objects" since objects is a programming term and can be confuising to vendors. By using the term components it is more generic and will hopefully lead to less confusion.

  • Status: Done, Update posted Sept 26, 2007 (Sept 14 version)
  • Text from Web and Software
  • Source: New (was 6.1.K in July 18 draft)
  • Impact:
  • External Reference: Harmonized with WCAG 2.0
  • Testability: Inspection
  • Metadata
    • Disabilities:
    • User Activities:
    • Product Characteristics:
    • Product Types:

3-S - Keyboard Operation

Where products have a keyboard or a keyboard interface, all functionality of the product operable through the user interface must be operable through the keyboard, or a keyboard interface. Specific timing for individual keystrokes must not be required. This provision does not apply where the underlying function requires input that depends on the full path of the user's movement, not just the endpoints.

  • Note: This does not forbid and should not discourage providing mouse input or other input methods, such as gestures, in addition to keyboard operation.
  • Note: 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.
  • Note: Keyboard interface can be either a hardware keyboard interface, a wireless interface or a software keyboard interface where AT can generate keystrokes that would be seen by software. 
Discussion of Work in Progress: 
* Need to add rationale
  • Status: Done. Update posted on Sept 24, 2007. (Sept 14 version)
  • Text from Web and Software
  • Source: {508}1194.21(a)
  • Impact:
  • External Reference: Harmonized with WCAG 2.0 and ISO 9241.71
  • Testability: Inspection
  • Metadata
    • Disabilities: Blindness, Physical
    • User Activities: All
    • Product Characteristics: Uses Keyboard (Physical - touch typeable)
    • Product Types: Web Content; Telephone only device; IVR (Voicemail, Autoattendant, Audiotext); Software (installed or through browser); Copiers; AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems

3-T - Focus Indicator

Any keyboard operable user interface must have a mode of operation where the indication of keyboard focus has a high degree of visibility. This can be provided by the interface itself or by the interface in combination with focus services provided by the platform.

  • Note: The presence of a highly visible text insertion point can be considered a visual indication of keyboard focus for a text area.
  • Note: A focus cursor that is visually locatable by people (familiar with what the focus cursor would look like) who have 20/20 vision at 3.5 times the typical viewing distance without moving the cursor is sufficient.
  • Note: Since computer software would be displayed on unknown screen sizes: for computer software a focus cursor that is visually locatable by people (familiar with the cursor) who have 20/20 vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor is sufficient.

Rationale: 

Discussion of Work in Progress 
* Need rationale information
  • Status: Done. Update posted on Sept 26, 2007. (Sept 14 version)
  • Text from Web and Software
  • Source: {508}1194.21(c) (was 6.1.J in July 18 draft)
  • Impact:
  • External Reference: Harmonized with ISO 9241.71
  • Testability: Inspection
  • Metadata
    • Disabilities: Blind, Physical
    • User Activities: All
    • Product Characteristics: Involves Web Content or Applications
    • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-U - AT Interoperability

On platforms that support AT interoperability, user interface objects 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:

  • provide assistive technology with object information including but not limited to:
    • role, state(s), boundary, name, and description
    • the row and column an object is in, and the headers for the row and column for that object if it is in a table that has row or column headers.
    • current value and any minimum or maximum values, if the object represents one of a range of values
    • relationship this object has as a label for another object, or being labeled by another object
    • parent or containing element, and any children objects
    • text contents, text attributes, and the boundary of text rendered to the screen
  • provide assistive technology with a list of actions that can be executed on an object and allow assistive technology to programmatically execute any of those actions;
  • allow assistive technology to track and modify focus, text insertion point, and selection attributes of user interface objects;
  • provide assistive technology with notification of events relevant to user interactions, including but not limited to changes in the object's state(s), value, name, description, or boundary
  • Note: This provision applies to forms in the software.

Rationale: The current provisions in Section 508 that address interoperability with AT are 1194.21(c), 1194.21(d) and 1194.21(f). "Sufficient information" in 1194.21(d) is not testable and the three requirements together are insufficient to meet the needs of assistive technology. The proposed provision is much more comprehensive. It details what type of object information must be provided and includes event notification which is critical for assistive technology interoperability. It is also harmonized with ISO 9241.171 and is supported by the major accessibility APIs on desktop operating systems. The phrase beginning "or other services to cooperate with assistive technologies" is provided to allow for other methods of cooperating with assistive technology where platforms and APIs are insufficiently mature to support the necessary functions.

Note: The word "components" was used in this provision instead of "objects" since objects is a programming term and can be confuising to vendors. By using the term components it is more generic and will hopefully lead to less confusion. 

Discussion of Work in Progress
* (from Sept plenary) question raised if this should also list other 
   accessibility issues such as sound.
* Note that there is an outstanding issue as to whether or not this provision 
  is met by software that uses an accessibility API but does not actually work 
  with AT. This issue is related to the issues around the functional 
  performance criteria.
  • Status: Done, Update posted Sept 26, 2007 (Sept 14 version)
  • Text from Web and Software
  • Source: {508}1194.21(d) (was 3.4-A in July 18 draft)
  • Impact:
  • External Reference: Harmonized with ISO 9241.171
  • Testability: Expert evaluation
  • Metadata
    • Disabilities: Blindness
    • User Activities: All
    • Product Characteristics: Has OS that supports installed AT and user can install
    • Product Types: Telephone only device; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems


4. Additional Provisions for Audio-Visual Players or Displays

4-A - Caption Playback

The following text was proposed at the Oct 9, 2007 plenary call.

Analog television, digital television and tuners, computer equipment, and other products must provide support for closed and open captions:

1. Products that are governed by U.S. Federal Communications Commission (FCC) regulations 47 CFR 15.119 (Closed caption decoder requirements for analog television receivers) and 47 CFR 15.122 (Closed caption decoder requirements for digital television receivers and converter boxes) must provide support for TV closed captions and open captions.

Such equipment must either pass TV caption data to the caption decoding circuitry of analog and DTV displays for decoding as displayed text, or decode TV caption data and pass on a decoded ("open-captioned") video signal to the display.

2. Products that do not fall under the regulation of the U.S. Federal Communications Commission (FCC), including personal video display devices and software players, must provide support for a functional equivalent to TV closed captions.

Such products must either pass TV caption data to the caption decoding circuitry of DTV displays for decoding as displayed text or decode a functional equivalent to TV closed captions and pass on a decoded ("open-captioned") video signal to the display.

New definitions referenced to be added to Subpart A:

Television closed captions and television caption data: Captions encoded using CEA 608 format and delivered in analog television signals, or captions encoded using CEA 708 format, carried in digital TV signals, to displays and other products that fall under the U.S. Federal Communications Commission (FCC) caption playback requirements.

Functional equivalent to TV closed captions: User-controllable features equivalent to CEA 708 display of caption text must comply with ß3-B (Contrast), 3-E (Color Adjustment), and 1.2-I (Text size) directly or through assistive technology in order to provide a functional equivalent of the primary FCC user-controllable features. 

Discussion of Work in Progress
* TV caption controls - two options on the table:
1. A caption on/off button must be on TV remote controls 
2. Caption controls must be immediately available on the first menu that appears when the "menu" button is pressed on TV remote controls
  • Status: In Progress, (Sept 14 version)
  • Text from A/V
  • Source: new
  • Impact:
  • External Reference: CEA 608, CEA 708
  • Testability: Inspection
  • Metadata
    • Disabilities:
    • User Activities:
    • Product Characteristics:
    • Product Types:

5. Additional Provisions for Real-time Voice Conversation Functionality

5-F - Video Support

  1. Each agency must ensure the availability of communication access via point to point real-time video communications and video relay services for incoming and outgoing calls for individuals who need such access. This includes the requirement to provide a non-auditory means of alerting users of incoming calls.
  2. Communication products or systems that are used to transmit video communications in real-time between and among individuals must:
    • support interoperability to permit communication between and among users of terminals from different manufacturers and service providers;
    • have a built-in non auditory alerting system or provide compatibility with an external non-auditory alerting system that is capable of alerting users of incoming calls; and
    • at a minimum, support 15 frames per second, QCIF resolution, and a latency of less than 400 milliseconds, in order to provide sufficient quality and fluency that will support real time video communication in which one or more parties are using sign language or is talking in the picture.
  1. Where security concerns are present, this subpart remains in effect, but may be achieved by measures that prevent an individual’s video communications from intermingling with packets of the general government network, for example, through the installation of a separate line to an isolated communications terminal.

NOTES:

  1. The requirement to permit video communications in real-time includes the ability to send and receive video mail, much in the same way that voice telephone users are able to send and receive voice mail.
  2. Twenty frames per second or better is recommended to facilitate lip reading and fingerspelling in the video communications provided under this section.
  3. Explanatory information concerning sign language and lip-reading real-time conversation using low bit rate video communication can be found in ITU-T H-Series Supplement 1. http://www.itu.int/rec/T-REC-H.Sup1/en.
  4. Non-auditory alerting for incoming video communications can be achieved via flashes, vibrations and sound; the preferred method will depend on the needs of the individual using the product.
  • Status: In Progress, (Sept 14 version)
  • Text from Telecommunications
  • Source: new, was 5.H in July 18 draft
  • Impact:
  • External Reference:
  • Testability: Formal test methods and inspection; will depend on how "X format" is defined."
  • Metadata
    • Disabilities:
    • User Activities:
    • Product Characteristics:
    • Product Types:

6. Audio and/or Video Content

6-A - Synchronized Alternatives

This provision will be removed from the next version of the draft.

  • Status: Done
  • Text from Web and Software
  • Source: {508}1194.22(c) (was 3.2.A in July 18 draft)
  • Impact:
  • External Reference:
  • Testability: Inspection
  • Metadata
    • Disabilities:
    • User Activities:
    • Product Characteristics:
    • Product Types:
Retrieved from "http://teitac.org/wiki/EWG:Draft_Sept_14_Updates"
Personal tools
Task Forces