Note

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

Telecom Report 2007-05-12

DRAFT AS OF 5.12.07 from T/Comm Working Group. In Progress

Current provision Keep current language? Change in jurisdiction? Modification Rationale:  Why is this change suggested? Economic Assessment
1194.23(a) no no (a) Telecommunications terminals and other terminals capable of providing real-time voice communications which do not themselves provide TTY or other real-time text conversation functionality shall comply with the following:
  1. Shall provide a standard non-acoustic connection point for TTYs or an equivalent method for text and/or video conversation All analog and TDM-digital wired terminals shall support the connection of a TTY in the same location and with the permissions for use as the telephone.  This shall be accomplished by providing an RJ-11 jack on the telephone, or, in the case of an analog telephone, by the use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet, or have built in capability to support an RJ11 module that can provide a connection point for TTYs;
  2. Other types of terminals covered by this section shall support the connection of real-time text capable devices in conjunction with the voice call capability in the same location and the same permissions for use as the terminal.
    Definition:  Any device that terminates one end (sender or receiver) of a communicated signal and with which an end user interacts is a terminal device.
    Or:
    Terminal device or devices with which the end user directly interacts and that provide the user interface.
  3. Shall be capable of allowing simultaneous speech and text conversation without interference or its microphone shall be capable of being turned on and off to allow the user to intermix speech with text [TTY] use.
CAPtel issue uses modem protocol not recognized by IP gateways.  Proprietary transport protocol.  Use of CAPtel in govt. is the problem.  Agrmt does not need to be addressed.
  • softTTY cheap to productize but significant security issues.  Sec’ty fix very costly.
Proposed Definition
Two-way communcations that employ transmission of, conversational, remote interactions wherein the characters are transmitted w/in 1 sec. of time created.
  • does CPE include Info Srvc?

Incoming text on screen can be supported, but to support another text stream wld be challenge.

Need a definition for terminal device.  These are suggestions.

For cellphone, New s/w needed to rd text as you go.  Add’l to current phone s/w Yes.  Trade off w/ tty to head phone prblm, connector on side.  Allows IP phones to be vco/hco enabled.

Cheaper, easier to do than hardware to t/c products.
xxxxx [new] n/a (x) The user interface of IP terminals that provide real-time voice communication shall meet the following provisions:
  1. IP terminal user interfaces that have a multiline display shall display any real-time text that is received in the standard format for that platform;
  2. IP terminal user interfaces that have the ability to generate text shall allow sending real-time text in the standard real-time text format for that platform;
  3. Such real time text send and receive capabilities shall be synchronized with voice as part of the same communication session.
   
1194.23(b) no no Products that provide real-time conversation text functionality shall do so in the standard format that is supported for that transport medium.
  1. Products that connect directly to the PSTN shall support TIA 825 Baudot where they interface to the PSTN;
  2. Products that connect directly to the Internet via SIP shall support RFC 4103 where they interface to the Internet via SIP;
  3. All other Products (including PBX, cellular, and peer to peer Internet phones) that do not connect to PSTN or use SIP over the Internet shall support the standard real-time text format for that system.  These systems only need to support TIA 825 Baudot at the juncture to the PSTN (if any) and only need to support RFC 4103 at the point where they connect to public SIP systems (if any).
Push to talk that does not connect to PSTN is not covered.

These reqmts apply to the Gateways to insure interoperablity.  This function is not supported by majority of gateways owned by govt. today.  Anyone with a closed system falls under (c).  This is about insuring interoperability between mine and yours.

s/w is available over the air; reqmt is for gateway vendor to support this.

There is a concern among some in industry that reference to specific standards that are proprietary and in early implementation development is premature.  There are also many variations of SIP.
xxxx [new] n/a (x) Systems that support real-time voice communication shall support at least one standard (for the system) means for real time text communication that is supported by all terminal, router, gateway and other products on that system, and that meets the following requirements:
  1. Provides transmission of character with less than 1 second delay from entry;
  2. Provides transmission with less than 1% character error under normal but heavy network traffic;
  3. Support intermixing of speech and text in both directions (simultaneously if and only if IP based).
  4. IP systems cannot rely upon audio channels for transmission of real-time text.
Assume high level of understanding by procurement offcr.
  • what is “systems?”
  • system perf. Reqmts are net roll up;  How does this play w/ component vendor?
  • req robust protocols rather than a metric.

“system as delivered must be reliable” shld be:  System as purchased should use a reliable text transport format.

 
1194.23(c) no no (c) Voice mail, messaging, auto-attendant, and interactive voice response telecommunications systems shall:
  1. be usable by TTY users with their TTYs and by individuals using relay services including voice carry over, hearing carry over, video relay, and speech-to-speech relay services;
  2. use the ITU-T G.711 standard for encoding and storing audio information.  If an audio encoder other than G711 is employed, the vendor must provide evidence that the intelligibility is equal to or better than that provided by G.711.
  3. have prompts without any background sounds that would reduce intelligibility;
  4. provide full player controls that allow users to pause, rewind, slow down and repeat all messages and prompts, and adjust volume;
  5. include menus that contain preferably 4 items but no more than 6 items at a time in the menu structure;
  6. provide easy to understand and act upon menu items and other navigational messages;
  7. provide controls that are consistent throughout the application;
  8. allow the user to correct any errors or confirm any input that would lead to permanent changes in their account or profile;
  9. Have an “easy out” to reach a live customer service representative.
wrt (C) 1 — Diane and Paul will work on reconciling concerns. This is about use of system, implementation, not the equipment.  This is a provision for set-up.

Provisions for product.  Provisions for set up.

  • define menu somewhere.

Based on committee members’ opinion; not backed by research.

1194.23(d) yes no (d) Voice mail, messaging, auto-attendant, and interactive voice response telecommunications systems that require a response from a user within a time interval, shall give an alert when the time interval is about to run out, and shall provide sufficient time for the user to indicate more time is required. n/a 0
1194.23(e) no no (e) Where provided, visual interfaces for telecommunications status information such as caller identification and similar telecommunications functions as part of interactive voice response systems or equivalents shall also be available for users of TTYs or other text conversation systems, and for users who cannot see displays and shall meet all accessibility provisions for software and content. Issue:  Does mute have to be its own button, not a function softkey?  
1194.23(f) no no (f) For receive transmitted voice signals,
  1. line powered telecommunications products shall comply with FCC regulation §68.317 for volume control,
OR
  1. * telecommunications products shall provide a built in gain adjustable up to a minimum of 20 dB.  For incremental volume control, at least one intermediate step of 12 dB of gain shall be provided.
  2. all other telecommunications products or systems that provide a function allowing voice communication shall provide a gain adjustable up to a minimum of 20? dB with [.For] incremental volume control of at least one intermediate step of 12 dB of gain [shall be] provided as measured and documented in accordance with the provisions of the FCC regulation &sect68.317 for volume control.
We need to decide how to address the difference between the gain level in HAC and 508.  Do we want to differentiate between line-powered products and externally powered?  We need to decide on a gain level.

1* There is a problem is measurement of gain from variable floor.  Recommend standard for the floor from which the adjustable gain is measured by developed by TIA.

 
1194.23(g) no no (g) If the telecommunications product allows a user to adjust the receive volume, a function shall be provided to automatically reset the volume to a safe level after every use if the volume is capable of greater than 18 dB of gain along with an option for user override of that automatic default. Is there a need to have a max output specified to prevent the gain from exceeding that level?

What is floor?  JOHN COOMBS, CISCO….  IMPT. TO SET FLOOR, MSMT OF FLOOR.  ALSO WILL HAVE TO SET MSMT FOR DISTORTION. Conform w/ FCC, drop reset if 18 dB and est. common floor measurement.  Est’g common floor so can have a real 18 dB.  Distortion – Matt Bakke.

 
1194.23(h) no no (h) Where a telecommunications product delivers output by an audio transducer which is normally held up to the ear, a means for effective magnetic wireless coupling to hearing technologies shall be provided that allows the user of such technologies to effectively utilize the telecommunication product.  This guideline shall apply to wireless, wireline, cordless and Bluetooth ?? applications.    
1194.23(i) yes no (i) Interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) shall be reduced to the lowest possible level that allows a user of hearing technologies to utilize the telecommunications product. Should metrics be added like the TIA cordless standards?  Or a reference to ANSI/IEEE?  Or other standards?

Do we want to reference FCC regs for wireless technologies?

 
1194.23(j) yes no (j) Products that transmit or conduct information or communication shall pass through cross-manufacturer, non-proprietary, industry-standard codes, translation protocols, formats or other information necessary to provide the information or communication in a usable format.  Technologies which use encoding, signal compression, format transformation, or similar techniques shall not remove information needed for access or shall restore it upon delivery.  Firewalls, routers, gateways and other products that pass real-time voice communication shall also pass real-time text communication signals (including mixed voice & real-time text) that are standard for that technology platform without distortion or error beyond 1%.
  1. for PSTN this would be TIA/EIA 825 Baudot.

NOTE:  Only phones that are passing text signals onto another device, e.g. TTY, would be subject to this provision.

Proposed.  Better than old but needs work.

Don’t want to do Bell 103 and 202. Concern:  What if passing voice but need to translate text?  Want to take 4103 and put it own format for closed network.

 
1194.24(k) [new]   (k) Telecommunications products or systems which have the capacity to transmit video, text and voice communications shall support internet protocol text and voice communications in X format and have sufficient transmission bandwidth capacity to support video communication such as video relay and point to point video communications. What did we decide to do about firewall problems?  
1194.24(k)   yes (k) Products which have mechanically operated controls or keys, shall comply with the following:
  1. Controls and keys shall be tactilely discernible without activating the controls or keys.
  2. Controls and keys shall be operable with one hand and shall not require tight grasping, pinching, or twisting of the wrist. The force required to activate controls and keys shall be 5 lbs. (22.2 N) maximum.
  3. If key repeat is supported, the delay before repeat shall be adjustable to at least 2 seconds.  Key repeat rate shall be adjustable to 2 seconds per character.
  4. The status of all locking or toggle controls or keys shall be visually discernible, and discernible either through touch or sound.

Move to Closed Products  


New Provisions

New Provision Rationale — What issue does this provision address? Estimated Economic Impact
The van der Heiden PROPOSAL: – 4.13.07   [(1) through (4)]]    
(1)Wherever voice is passed through real-time text is passed through

Firewalls, gateways and other products that pass real-time voice conversation signals shall also pass real-time text conversation signals (including mixed voice & real-time text) that are standard for that medium without distortion or error beyond 1%.

Address devices that pass voice not with phones or other terminal devices. Industry Comment:  Econ. Implications for elements not clear or understood, e.g. network, terminal device, client software, etc.  What are standards, what development needs to be done, is unknown.  Time line interdependencies unknown.
(2) Real-time text support is in standard form (for that technology)

Products that provide real-time conversation text functionality shall do so in the standard format that is supported for that transport medium.

  1. products that connect directly to the PSTN shall support TIA 825 Baudot where they interface to the PSTN;
  2. Products that connect directly to the Internet via SIP shall support RFC 4103 where they interface to the Internet via SIP.
  3. All other Products (including PBX, cellular, and peer to peer Internet phones) that do not connect to PSTN or use SIP over the Internet shall support the standard real-time text format for that system.  These systems only need to support TIA 825 Baudot at the juncture to the PSTN (if any) and only need to support RFC 4103 at the point where they connect to public SIP systems (if any).
Allows Skype, PBXs, and other closed systems to use whatever for internal text transport and for transport between and within their own systems.  When and if connect to the PSTN or Public SIP, then these products need to convert to the public formats at that point only.  They are still free to use other formats but they must support public formats to guarantee that they can interface with other equipment at the far end of the public network call.

TIA Comment:  Premature to specify a protocol standard for text.  RFC 4103 separates voice and data ports; has unique characteristics.

Interop testing necessary at end points.  Significant costs.
(3) Voice communication systems support a standard (for the system) real-time text that meets the following:
Systems that support voice conversation shall provide at least one standard (for the system) means for real time text conversation that is supported by all terminal, router, gateway and other products on that system, and that meets the following requirements:
  1. Provides transmission of character with less than 1 second delay from entry;
  2. Provides transmission with less than 1% character error under normal but heavy network traffic;
  3. Support intermixing of speech and text in both directions (simultaneously if packet based).
Provides specifications for text transport.  Although closed systems can use any technology to transport text, the systems must meet these reliability specifications.  TTY and RFC 4103 can already meet these specifications.  
(4) If voice devices are capable of supporting text display or creation they allow their use for Real-time Text.
IP terminals that provide real-time voice function shall meet the following provision:
  1. Terminals that have a display of more than 12 characters shall display any real-time text that is received in standard format;
  2. Terminals that have the ability to generate text shall allow sending real-time text in the standard format in connection with voice phone calls;
  3. Terminals that do not have both send and receive capability for real time text shall support the connection of real-time text devices in parallel with the voice call capability in the same location and the same permissions for use as the product.
    NOTE: Terminals can be hardware or software based.
Last item in (4) — equivalent to TTY today — but would open it up for other technologies and systems.

This says if the device can display text, then it should display real-time text that is sent to it.  If it can generate text, it should allow users to send real-time text.  If it can’t do both, then there should be a method for connecting a device that can and that device should be allowed to work (permission).

 
(5) If voice devices are capable of supporting video then support sign language.
Telecommunication systems with the bandwidth and video capability to support sign language video shall not block video telecommunication for the Deaf and Hard of Hearing Federal employee or member of the public.
If the system technically can be used for sign language, users should be able to use it for such.

Offered by T. Brett to address network mngmt reluctance to open further ports in the agency’s firewall.  Not required for every employee.

 
Tobias Contribution:
  1. The caller must always be able to dial 0 or to say “operator” to queue for a human.
  2. An accurate estimated wait-time, based on call traffice at time of call, should always be given when caller arrives in the queue
  3. Callers should never be asked to repeat info provided to a human or an automated system during a call.
  4. When human not available, callers should be offered option to be called back or to leave a message.
  5. Speech applications should provide touch-tone (DTMF) fall-back.
  6. Long prompts should be avoided.
  7. Callers should be able to interrupt t prompts via DTMS tones or barge-in software.
  8. System must not disconnect for user erros, but instead queue for human operator.
  9. Primary language should be assumed with option for caller to change language.
These are from GetHuman.com and address IVRs.  Very service centric, not hardware.  


Other Material

  • Recommendations on organization of the provisions
  • Issues this subcommittee is not addressing, but which should be addressed.
  • Recommendations relating to Themes or other content
  • Recommendations regarding process: the work of the subcommittees, the whole Committee, liaison with the Access Board, etc.

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