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: Michaelis, Paul R. (Paul)
Date: Mon, Mar 12 2007 9:25 AM

Jim,

Thank you for your feedback. I definitely feel that we are moving in
the right direction. (I hope others agree!) My comments are embedded
with yours, indicated by [PRM].

-- Paul

_____

From: Jim Tobias [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, March 12, 2007 9:10 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] Comments re: the proposed revisions to
1194.23(c)


Thanks, Paul, for your thoughtful edits. See below for comments and
suggestions, indicated by "[JT]". Some of these are
based on the current draft standards for IVRs, HFES 200.4.

One general issue is the definition of "voice mail, auto attendant, and
interactive voice response". First, this leaves out audiotext
systems (where you get information in audio form, not just a voice mail
message or routing to a specific phone line). Second,
I think the generic term is interactive voice response, or IVR. I'd
recommend that we use that umbrella term and make sure that
the Definitions section of Subpart A includes it and the services under
it.


***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias



_____

From: Michaelis, Paul R. (Paul) [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Sunday, March 04, 2007 2: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.

[JT] This sounds like the systems themselves would be responsible for
translation between voice and TTY. I think we need to make it clear
that those translations will be performed by some flavor of relay, and
that the systems must be fully interoperable and usable with relay.



[PRM] I did not intend this requirement to refer to relay.
(More about that later.) It is presently that case that voicemail, IVR,
and automated attendant systems provide prompts, menus, and other
system-generated information (e.g., your account balance when accessing
a bank's IVR) by voice. My goal with this requirement was to say that
the systems must also be able to provide this information as
Baudot-encoded text prompts directly to TTY users without requiring the
use of relay services. With regard to relay, I think we'd be doing a
disservice to TTY users if we imply that relay-based access to these
systems is an acceptable substitute for direct access via TTY. There
are many reasons why I feel this way, but one of them is that some of my
non-government customers have told me recently that their TTY-using
customers want direct TTY access to services such as IVR because they
are concerned about issues such as identify theft.



[PRM] I deleted reference to "interoperable and usable with
relay" because this, as worded, is an objective rather than being a
testable requirement. What are the metrics by which an engineer or
contract officer can tell whether the requirement has been satisfied?
My opinion is that the explicit, testable requirement that is presently
outlined in 1194.23(d) is the key to being interoperable and usable with
relay. Is anything else required in order to support relay?



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

[JT] How about "recording and playing back"?



[PRM] Agree.



(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.


[JT] I'm reluctant to refer to only one standard, but you are definitely
the expert on this. Is there a toolset to compare other encoders?



[PRM] G.711 encoding, also known as 64 kilobit pulse code modulation,
has been a telephony standard for more than twenty years. The voice
quality is considered to be comparable to that of the high quality
analog PSTN transmissions. Prior to the advent of VoIP telephony, G.711
was (and still is) the standard encoding technique for wired digital
telephones. I'm not aware of any manufacturer that does not support
G.711 on its wired digital or wired VoIP telephones. Perhaps most
importantly, it is the benchmark commonly used by telephony engineers as
the reference against which other coders are evaluated.



[PRM] It is generally accepted that test procedures, such as those that
derive MOS scores from groups of users, are highly reliable indicators
of voice quality. Although I'm not 100% comfortable with some of the
newer automatic test procedures, such as PESQ (http://www.pesq.org/
<http://www.pesq.org/> ), they do have the advantage of being fast and
reasonably reliable. (If you want to list this test in the Section 508
requirements, the appropriate reference is ITU-T recommendation P.862.)
For test procedures that might be a more useful indicator of
intelligibility among people who are hearing impaired, we might want to
check with Linda Kozma-Spytek at Gallaudet.



[PRM] The reason I proposed this requirement is that some voicemail
systems economize on disk space by relying on compression codecs, such
as G.729 and GSM, in order to reduce the number of bits-per-second
required to store the voice recording. Algorithms such as these two do
not provide voice quality as good as what we find on clean PSTN
connections, or as good as what's provided by G.711 encoding.



[PRM] By the way, there are new encoders that are starting to appear in
VoIP products that provide audio that is superior to G.711. This is why
I worded the proposed requirement to permit encoders other than G.711 if
they could be demonstrated to be equal to or better.





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



My proposed rewrite for item #2 covers this.


[JT] #2 is about the system capability; #3 is about how the agency
creates and stores its announcements. I agree that the

"highly intelligible" part is untestable and needs to be replaced, but
the "no background sounds" is okay as it is.



[PRM] I agree that "background sounds" can be a real headache. The
problem here is that they can come from many different sources that are
not controllable by voicemail or IVR systems, such as ambient noise at
the user's location, transcoding within IP networks, and packet loss.
Unless you specify a type of distortion for which the voicemail or IVR
system would be responsible (e.g., background noise in the recordings of
the system's prompts), a requirement like this would be hard to enforce.



(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."


[JT] I've spent some time reviewing this. First, you're right to
distinguish between "global commands" and menu options. I only

meant to refer to the latter. Second, the only existing standard for
this item, ISO 13714, limits menu items to 4. But the consensus

right now seems to be that menus should be driven by the domain. For
example, when you call a movie theatre and want to get

show times, it's okay for them to read out all 12 movies, because you
know you're listening to a list of movies and can easily respond

to the one you want info about. But if the domain is more vague, with
highly dissimilar options, there should be a limit to the number

of menu items because you will not be able to remember them all. Lots
of cognitive issues here. The good news here is that most

new systems are going to use an open vocabulary and speech input. This
means that they will not read a list of items to you,

but will try to understand you when you say what you're trying to do.
(Bad news: this technique has other cognitive issues, plus

barriers for people with impaired speech.)



We could pick a number like 4 or 6 because it would make things easier
for developers to know when they had complied, or we

could keep the language more abstract and issue better guidance
materials. I have no preference.





(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.


[JT] The only solution here is to refer to "simple language" which needs
to be defined in many contexts, and consistent use of

terms like "press", "say", "enter", etc.



[PRM] Agree.





(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.


[JT] I think this is phrased right as it is; it doesn't say absolutely
no changes, but that control consistency is a goal.



(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.


[JT] Not *this* again! <grin>. It's at least *one* of how "agencies
develop, procure, maintain or use" the system. That's the 508 scope,
vendor fisheyes to the contrary notwithstanding.



(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."


[JT] I would like to reword it to conform with HFES 200.4: "The caller
should be able to access a human representative at any point in the

IVR by pressing '0', and that the caller should be notified of this
capability early in the call."



[PRM] Again, I feel that conformance to (8) and (9) are clearly the
responsibility of the purchasing agency. The best I can do as a vendor
is ensure that the ability to implement this feature is present in the
systems I manufacture. I wonder whether we should spell out which of
the requirements are the responsibility of the vendor, and which are the
responsibility of the purchaser.







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.


[JT] I agree, and would add "speak through" and "speak ahead" to refer
to speech input IVRs. [JT] Here's some language: "(10) provide support
for dial-through, dial-ahead, speak-through, and speak-ahead."



[PRM[ Agree.

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