Thread Subject: Re: Comments re: the proposed revisions to1194.23(c)

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: Gregg Vanderheiden
Date: Sun, Mar 04 2007 8:35 PM

Hi Paul



I think we should remember that these guidelines are not for companies but
for the government. They may be used for procurement but also for setup.



These requirements could be used in procurement to ensure the basic
capability was there. Then they could be used by the government agency to
determine what the final installed system should look like when it is set
up.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Michaelis, Paul
R. (Paul)
Sent: Sunday, March 04, 2007 1:18 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-telecom] Comments re: the proposed revisions to 1194.23(c)

Below is a copy-and-paste of the proposed 1194.23(c) requirements. My
comments are embedded.



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,



I think it's unlikely that anyone outside our community will know how to
tell whether a system complies with this requirement. I suggest something
like this:



(a) All information presented by voicemail, IVR, or automated attendant
systems via the telephone user interface shall be available by voice and
shall also be available as Baudot TTY signals.



(b) Voicemail systems shall be capable of recording voice messages and
shall also be capable of recording Baudot TTY messages.



(c) Regardless of whether the voicemail telephone user interface is
presenting information by voice or TTY, it shall be possible for users to
record a voice or TTY message.



(2) have audio capability sufficient for high intelligibility,



Another example of a requirement that is not testable. I suggest something
like this:



Voicemail, IVR, or automated attendant systems shall use the ITU-T G.711
standard for encoding and storing audio information. If an audio encoder
other than G.711 is employed, the vendor must provide evidence that the
intelligibility is equal to or better than that provided by G.711.



(3) have highly intelligible recorded messages and prompts without any
background sounds that would reduce intelligibility,



My proposed rewrite for item #2 covers this.



(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 no more than six items,



I support the objective here, but what's being proposed is unrealistic. A
simple example: If the requirements of item #4 were followed, you've already
used up your six menu items.



On the Avaya "Intuity AUDIX" message systems, we have implemented what we
refer to as global commands. For example, regardless of what the user is
doing, star-D is always Delete, star-H is always Help, star-T is always
Transfer, and so on. These commands are available in addition to those that
vary depending on context. When you combine the context-specific menu
items with the global commands, it will often be the case that more than a
dozen options are available at any given time. Even under these conditions,
it is important to note that the initial prompt heard by users at any given
node never exceeds more than four options. In almost all cases, the option
desired by typical users will be among these four. (The full menu is
presented when users ask for help by pressing star-H.) Extensive Human
Factors testing has verified that this is a highly usable design; it has
been in our voicemail systems for over 20 years and is being used by
millions of people all over the world.



I suggest rewording this requirement to say something like, "Unless the user
requests to hear more options, a telephone user interface shall present no
more than four menu options at a time."



(6) provide easy to understand and act upon menu items and other
navigational messages,



Again, I understand and support the objective here, but this requirement is
much too vague. Compliance must be testable.



(7) provide controls that are consistent throughout the application,



I think that we have achieved this to a certain extent with the "global
commands" that I mentioned earlier. Nevertheless, in my opinion, this
requirement is unrealistic in a telephone user interface. Keeping in mind
that dial pads have only twelve buttons, it's unavoidable that the functions
assigned to those buttons will have to change depending on context.



(8) allow the user to correct any errors or confirm any input that would
lead to permanent changes in their account or profile;



In IVR systems, it is the purchaser's responsibility to ensure that this
capability is implemented. This is not a procurement issue.



(9) Have an "easy out" to reach a live customer service representative.



If the system you're calling into doesn't present this option, it ain't my
fault! "Easy out" has been a supported option on all of our voicemail,
IVR, and automated attendant systems ever since the very first models. In
all cases, the availability of the "easy out" option is the decision of, and
implemented by, the purchaser. The best I can do as a manufacturer is
advise the purchaser how to configure our systems in order to provide the
"easy out" option.



Keeping in mind that the availability of this function is not controlled by
the vendor, I'm not sure that having it as a procurement requirement makes
any sense. Perhaps we can modify the wording to say something like, "All
voicemail, IVR, and automated attendant systems shall allow the purchasing
agency to implement an 'easy out' function that would allow callers reach a
live customer service representative."



Finally, I think it's helpful to be aware of what's referred to as
"dial-through" and "dial-ahead." Support for dial-through means that users
may interrupt a prompt and make a menu selection even while the prompt is
playing. Support for dial-ahead means that users, who already know what
they want, can make menu selections even before the associated menu has
begun to play. As an example of how these features can be helpful, support
for dial-through would allow users with cognitive impairments to enter a
command immediately after the desired option is presented; support for
dial-ahead means that a desired sequence of commands can be stored in a
single memory-dialer location on a phone, and thereby be accessible with a
single button push.



I recommend that support for dial-through and dial-ahead be required in
voicemail, IVR, and automated attendant systems.



Regards,



Paul Michaelis

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