AT/E&IT INTEROPERABILITY
Potential Deliverables from AT/E&IT Interoperability Project
1. Guidelines for Federal Agencies
a. Primer on Interoperability and Accessibility of E&IT
i. Definition of important terms
ii. Examples of how accessibility can be achieved through interoperability
b. Support for Purchasing AT and E&IT
i. When and how to conduct user needs assessments
ii. Questions to ask vendors
iii. How to interpret vendor responses
iv. Tips on obtaining and using evaluation copies
2. Generic Accessibility Requirements Analysis and Recommendations (Being considered)
a. Common characteristics/requirements that describe desirable interactions between E&IT and AT
i. Exploration of other options not part of current state-of-the-practice
Not platform/API specific
1194.21: Software Interoperability Group
This document is intended for Federal Government Agencies as educational information regarding software interoperability.
Guide for Federal Government Agencies
1) A primer on interoperability
2) A list of software interoperability available today
3) A Software Interoperability Needs Assessment Tool
4) A list of questions to ask vendors and how to interpret the responses.
5) Things to look for when using evaluation copies
Section 1 - A primer on interoperability
1.1 Definition of interoperability as it applies to Accessible Software.
Interoperability as it applies to accessible software is defined as a set of rules that are established to allow two software programs (applications) to talk to each other. These rules define how one software program asks another software program for information and defines how the second software program will respond. This set of rules is referred to as an interface. If a software program writes to the interface it should be able to communicate with other applications and the operating system. A software program that writes to an interface is one that has used the standard set of rules to ask for or provide information. These sets of rules are generally referred to as Application Programming Interfaces (API's).
1.2 How current applications and operating systems generally work Operating Systems by their nature are intended to both provide services to applications, and to keep applications from interfering with other applications. If applications need to share data, there is a defined set of API's. Which allow the interaction. In general the transfer of and shared data is through the operating system. This keeps the applications from reading and writing into areas that are reserved for other applications. However as operating systems and applications were developed many made the assumption that the users could see, hear, and use a mouse. This is not true of users with disabilities.
As long as 15 years ago a small group of programmers began the work to make provide software programs to persons with disabilities. With no standard API's provided by the operating systems they created ingenious ways of obtain the information required to provide users with disabilities access to computer. Assistive Technology programs provide unique applications that work to allow disabled user to successfully use standard applications.
1.3 The changing face of accessible software
Current operating systems and operating system environments offer a variety of standard accessible application programming interfaces (API's) to support assistive technology applications. Many software applications were not written to use the standard API's. See Section 2 Many of the assistive technology programs do not use the standard API's as they were written prior to these API's existence. Both software applications and assistive technology applications are changing to use these API's sets. However until both sides are communicating 100% via the Accessible API's there will be interoperability problems.
This does not mean that applications and assistive technology cannot and do not work together. It does mean that when the do work together it is a matter of contrived and accidental compatibility. The entire EIT and AT industry has been awakened by Section 508. It is in the process of moving to provide both software programs and assistive technology programs that will interoperate. However this is likely to take several years. Thus the agency purchasing software and assistive technology software will need to be aware of software interoperability and be able to assess their agencies needs.
Section 2
List of software interoperability available today
2.1 Microsoft Active Accessibility (MSAA)
Microsoft Active Accessibility 2.0 improves the way accessibility aids work with applications running on Microsoft Windows operating systems. It provides dynamic-link libraries that are incorporated into the operating system as well as a COM interface and application programming elements that provide reliable methods for exposing information about user interface elements.
Using this information, Assistive Technology Vendors can represent the UI in alternative formats, such as speech or Braille, and voice command and control applications can remotely manipulate the interface.
By following accessibility design practices and using Microsoft Active Accessibility, technology products can provide for your customers with accessibility needs.
Active Accessibility is based on the Component Object Model (COM), which was developed by Microsoft that defines a common way for applications and Windows operating systems to communicate. Active Accessibility consists of the following components:
2.2 Java Accessibility API's
Sun Java Accessibility Java Accessibility is currently broken into two separate packages: the Java Accessibility API and the Java Accessibility Utilities. The release contained Java Accessibility Utilities and classes designed to help assistive technologies take advantage of the Java Accessibility API. The Java
Accessibility API is a cross platform, toolkit independent API designed to give assistive technologies direct access to the information in user interface objects, and is part of the JavaTM Foundation Classes.
The Java Accessibility API defines a contract between individual user-interface components that make up a Java application and an assistive technology that is providing access to that Java application.
In order to provide access to a Java application, an assistive technology requires more than the Java Accessibility API: it also requires support in locating the objects that implement the API as well as support for being loaded into the Java virtual machine, tracking events, etc. The Java Accessibility utility classes provide this assistance.
Java applications run on a wide variety of host operating systems, many of which already have assistive technologies available for them (e.g. Macintosh, OS/2, Windows). In order for these existing assistive technologies to provide access to programs written in the Java programming language, they need a bridge between themselves in their native environment(s) and the Java Accessibility support that is available from within the Java virtual machine (or Java VM).
2.3 Gnome Accessibility API's Sun GNOME Accessibility
The built-in, extensible GNOME Accessibility Framework provides the foundation for developers to write accessible applications from the ground up, support existing GNOME applications, and adopt enabling technologies to the UNIX platform. Sun's contribution to the GNOME Open Source Project includes an early access version of the GNOME 2.0
Accessibility Framework, which provides:
Accessibility Toolkit (ATK API) and associated implementation library that is integrated with the GTK+ user interface toolkit. This allows developers to use GTK+ widgets to automatically build accessibility applications.
AT SPI helps developers interface technologies such as voice command, text-to speech, and screen readers and screen magnifiers with GNOME accessible applications on a majority of UNIX platforms.
Section 3 - Assessment Tool
3.1 Software Interoperability Tool
Software Interoperability Assessment
Questions
Responses
Remarks and
Explanations
· What are you going to use the software for? And who will use it?
· What operating system(s) are deployed on the computers your end-users use?
· What software programs (applications) do you use in your agency?
· What assistive technology programs (applications) do you use in your agency?
Section 4
Questions to ask vendors and how to interpret the responses.
4.1 Operating system vendors
1. Did the vendor fill out a voluntary procurement accessibility template? An extremely useful tool in answering the questions below. A document is available on the ITI web site that discusses Best Practices for filling out A Voluntary Procurement Accessibility Template. ITI VPAT.
2. Does the operating system have accessibility application programming interfaces (API's)? This should be yes or no.
3. Does the operating system have other accessibility features? Most do so ask for the list of these features.
4. Is there a list of these features? This should be yes and easily provided.
5. Are these features available to product developers? Again the answer should be yes.
4.2 Application vendors
1. Did the vendor fill out a voluntary procurement accessibility template? An extremely useful tool in answering the questions below. A document is available on the ITI web site that discusses Best Practices for filling out A Voluntary Procurement Accessibility Template.
ITI VPAT.
2. Does the application use standard accessibility application programming interfaces (API's)? If the answer is yes it is likely that this program could interoperate with assistive technology. If the answer is no it is most likely it will not interoperate with assistive technology. However some applications have worked with the assistive technology vendors to have support provided for applications without using standard API's.
1. Does the application use custom controls? If so do they provide accessible information to the operating system? Custom controls are not a bad thing if the information has been exposed to the operating system so it can be available to assistive technology.
2. Does the application inherit system settings? If not it is possible that it could override user selections.
4.3 Assistive Technology vendors
1. Did the vendor fill out a voluntary procurement accessibility template? An extremely useful tool in answering the questions below. A document is available on the ITI web site that discusses Best Practices or filling out A Voluntary Procurement Accessibility Template. ITI VPAT.
2. Does the assistive technology use standard accessibility application programming interfaces (API's)? If not it may not work with productivity applications even if the productivity application has used accessible API's. Has the assistive technology application worked with the productivity application vendors to have provide support without using accessibility API's.
3. Does the assistive technology application require changes or scripts to allow applications to work with it? If yes, are they shipped with the assistive technology application?
Section 5 - Evaluation copies
5.1 Evaluation Copies
Another way of obtaining software interoperability information is to do an evaluation of the product(s). For simple productivity applications used by a single individual at a desktop workstation, ask the vendor for an evaluation copy. Then have persons with disabilities participate in the evaluation.
For more complicated applications that require server and client set-ups ask the vendor to help provide a demonstration and include persons with disabilities in the demonstration.
Ground Rules for the document how can we help Federal Government Agencies in regard to Software Interoperability Issues that they may encounter?
Some boilerplate ground rules: These will not be included in the final document.
0) This document is the deliverable from the Interoperability Project in regard to software interoperability.
1) No document section shall be larger than 3 typed pages - No one has time to read and understand any documents that are larger than that.
2) Document sections will be able to stand-alone and not require other sections to understand which might mean combining sections as proposed.
3) The information must be concise and accurate, even if it is not all-inclusive.
4) Known areas that are not covered or are incomplete are noted.
5) The subgroup will first agree on major sections of the document.
6) Once major sections are agreed on content of each section will be agreed too.
7) Finally the actual text will be discussed and agreed too.
Section 1194.23: Specific Provisions for Telecommunications Products
1194.23(a) Telecommunications products or systems which provide a function allowing voice communication and which do not themselves provide a TTY functionality shall provide a standard non-acoustic connection point for TTYs. Microphones shall be capable of being turned on and off to allow the user to intermix speech with TTY use.
Interoperability – Current TTYs use either a RJ-11 connector for direct connection to the analog telephone network, or a 2.5mm audio connector using EIA/TIA TSB-121.
Telecommunications manufacturers could provide any of the following connectors as a standard connection point: RJ-11 or 2.5mm using EIA/TIA TSB-121.
1194.23(b) Telecommunications products which include voice communication functionality shall support all commonly used cross-manufacturer non-proprietary standard TTY signal protocols.
Clarification: The Access Board’s User Guide on Section 508 states:
“TTYs transmit in Baudot code at a rate of 45.5 baud. Products would need to match this protocol to be considered "TTY compatible." A standard was published for TTYs on June 23, 2000, which is available from the Telecommunications Industry Association [TIA/EIA 825]. Under 508, this is the protocol which must be retained as TTY signals pass through phone systems.
Some TTYs also include the optional ability to connect at a rate of 300 baud ASCII, which enables them to communicate with some computers or other TTYs with the same protocol. These two codes (300 baud ASCII and 45.5 baud Baudot) are considered non-proprietary. Equipment that contains a v.18 chip will enable transmission in many protocols including these two. That chip is based on an international standard.”
ITU-T Recommendation V.18 is a reference standard that provides procedures for automatic negotiation of connections with all of the known text telephone protocols in use in the US and Europe.
Interoperability – Minimum: Baudot
Comment: It was noted that there are good features in Baudot that should be preserved in future text telephone protocols. It is much simpler to implement an IVR system that is compatible with Baudot because it does not have a carrier signal and its audio signals are very different from speech and DTMF. Some of the non-Baudot TTY protocols in V.18 cannot be intermixed with voice or with DTMF. Inability to intermix voice adds to the complexity of supporting VCO and HCO. The inability to be intermixed with DTMF also prevents the protocol from being used with many current IVR and voicemail systems without hardware modifications.
Comment: It is important for agencies to recognize that exempting a component of a telecommunications system from 508 due to its location (e.g., spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment), could result in the entire system no longer conforming to this provision.
1194.23(c) Voice mail, auto-attendant, and interactive voice response telecommunications systems shall be usable by TTY users with their TTYs.
Clarification – This is a functional performance requirement.
Interoperability - IVR systems should be usable by TTY users with DTMF-enabled TTY configurations, i.e. telephone with TTY attached, wireless phone with TTY attached or DTMF enabled TTY. Inability to intermix voice adds to the complexity of supporting VCO and HCO. The inability to be intermixed with DTMF also prevents the protocol from being used with many current IVR and voicemail systems without hardware modifications.
Comment: An alternative would be “IVR systems must be usable by TTY users with their TTYs without DTMF.” It is important to understand the implications of the latter. It is possible to get an IVR or voicemail system to recognize TTY tones in the same way that it recognizes DTMF tones, but it would create complex user interface issues, such as:
How does the voicemail system know that the user has finished recording a TTY message and now wishes to enter a TTY command? This is not an unsolvable problem, but it does require the voice user interfaces and TTY user interfaces to behave differently which would add to the cost of programming the IVR, creating documentation and training users.
2.Given the half-duplex nature of the Baudot protocol, provision of capabilities such as “barge-in” and “dial ahead” (the ability to interrupt the system; the ability to make menu selections or enter commands before the menu is presented) would be difficult to support in a TTY-only interface.
For these reasons, we have recommended the interoperability requirement be “Usable by TTY users with DTMF-enabled TTY configurations.”
1194.23(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.
Interoperability – no interoperability requirement
NOTE: Though there is no direct interoperability issue, there is an issue when using VM, AA and IVR through the Telephone Relay Service. When operating through a TRS operator – this ability to ask for additional time is critical – or the IVR system hangs up while operator is getting input from TTY user.
1194.23(e) Where provided, caller identification and similar telecommunications functions shall also be available for users of TTYs, and for users who cannot see displays.
Clarification needed- what are the ‘similar telecommunications functions?’ Some other network-based functions that would present interoperability problems are
(a) call waiting,
(b) call forwarding,
(c) multiple phone numbers on one line with multi-ring patterns, and
(d) requires features in the telephone or TTY which provides a visual equivalent of these signals.
Are there others in addition to these?
These functions use either a change in the dial tone pattern or ring pattern so they are not a problem for visually impaired users but present problems for deaf and hard of hearing users. (c) is easily accommodated using a visual ring adaptation. (a), (b), and (d) require a feature in the telephone or TTY which provides a visual equivalent of these signals.
Interoperability – Caller ID is provided on the analog network and on ISDN. Use of this service requires a Caller ID adapter or a telephone with Caller ID feature built in. Deaf users would be able to use either of these with a TTY. Some existing TTYs have Caller ID features.
Voice versions of the caller ID adapters are available for blind and visually impaired users. Phones with caller ID will need a voice output mode to comply with this provision. This would be a very popular feature for all users since it could be used from a distance rather than requiring the consumer to walk to the phone to see the caller ID display.
1194.23(f) For transmitted voice signals, telecommunications products shall provide a 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.
Interoperability – None, the device must have this feature.
1194.23(g) If the telecommunications product allows a user to adjust the receive volume, a function shall be provided to automatically reset the volume to the default level after every use.
Interoperability – None, device must have this feature.
1194.23(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.
Interoperability – The handset must have effective magnetic coupling with the t-coils in hearing aids and cochlear implants.
Possible standards for this coupling are:
(EIA RS-504) for wireline phones. (can't be used for wireless though)
Relevant portions of ANSI C63.19-2001 for wireless phones.
1194.23(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.
Comment: This section is currently being rewritten.
Interoperability – This area still under exploration.
1194.23(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.
Interoperability – Three areas currently highlighted where this would apply are: Compression and transmission systems should not remove or distort closed caption or audio description tracks from analog or digital video formats or distort or block TTY signals.
Comment: Although there is an exemption for backoffice systems – it is not clear whether that was for the interface (only) for those systems or whether it applies to this provision as well. Exempting a component of a telecommunications system from 508 due to its location (e.g., spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment), could result in the entire system no longer conforming to this provision. Clarification is being sought.
1194.23(k) Products which have mechanically operated controls or keys, shall comply with the following: … (k1) – (k4).
Interoperability – None, devices must have these features.
After satisfying the specific provisions that apply to the device, it must also conform to the functional provisions: ,
1194.31(a) At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided.
1194.31(b) At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 shall be provided in audio and enlarged print output working together or independently, or support for assistive technology used by people who are visually impaired shall be provided.
1194.31(c) At least one mode of operation and information retrieval that does not require user hearing shall be provided, or support for assistive technology used by people who are deaf or hard of hearing shall be provided.
1194.31(d) Where audio information is important for the use of a product, at least one mode of operation and information retrieval shall be provided in an enhanced auditory fashion, or support for assistive hearing devices shall be provided.
1194.31(e) At least one mode of operation and information retrieval that does not require user speech shall be provided, or support for assistive technology used by people with disabilities shall be provided.
1194.31(f) At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength shall be provided.
1194.24: Video and Multimedia Products
(c) All training and informational video and multimedia productions which support the agency's mission, regardless of format, that contain speech or other audio information necessary for the comprehension of the content, shall be open or closed captioned.
(d) All training and informational video and multimedia productions that support the agency's mission, regardless of format, that contain visual information necessary for the comprehension of the content, shall be audio described.
(e) Display or presentation of alternate text presentation or audio descriptions shall be user-selectable unless permanent.
I. Ability to meet 1194.24 standards.
A. Traditional multimedia formats.
a. WGBH has been a pioneer in creating accessible solutions for broadcast and traditional multimedia content for the past 23 years.
1. Closed/Open captioning.
2. Audio description.
B. Web based multimedia formats.
a. AbleTV has been a pioneer in creating accessible solutions for web based video streaming for live and archived content for the past 4 years.
1. Closed/Open captioning.
2. Audio description.
C. Accessible solutions.
a. Traditional multimedia formats.
1. Closed/Open captioning is delivered via scan line 23.
2. Audio description is provided by either scripting through the primary audio channel or via the use of the SAP channel.
b. Web based multimedia formats.
1. Real Networks G2 player
2. Microsoft Windows Media player
3. Apple QuickTime player
II. Current environment and shortcomings.
A. One player supports its player in all win9x, Win N/T, win2000 & XP formats, as well as for the Macintosh and UNEX based OS. In previous versions of this player, the player supported closed/open captioning & audio descriptions. Keyboard equivalents and windows GUI objects are accessible.
1. In the current release of this player, there is no support for audio description.
2. Keyboard equivalents and windows GUI object control is at issue with some screen readers.
b. One player has supported the use of closed/open captioning, however, there has not been any support for audio descriptions. Audio descriptions can be supported through the scripting within the primary audio channel of the player.
1. The current release of the player has not addressed the audio description issue, although it has been brought to the attention of the manufacturer of the player.
c. One player supports the use of closed/open captioning and audio description in a proprietary OS. Player manufacturer has made versions of the player available in windows OS.
1. While versions of the player are accessible in the proprietary OS, the version that is available in the Windows OS is not accessible for the operation of the player.
III. Interoperability and future issues.
A. Interoperability issues concerning multiple OS must be addressed when designing versions of players.
B. Accessibility must become an integral part of the players operation for output and player control.
C. As new technologies surface with the use of agnostic players for video streaming, accessibility must be a part of the initial design of the player before being accepted as meeting Section 508 standards.
D. Interoperability issues must be addressed when moving multimedia formats from traditional analog multimedia to digital multimedia formats.