Thread Subject: Re: Comments re: the proposed revisionsto1194.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: Diane Golden
Date: Sat, Mar 17 2007 12:45 PM

I definately need some help understanding the issue of direct access to IVR
and voice mail systems by individuals using VCO or HCO. The current 508
standard 1194.23 (c) requires only that IVR and voice mail be "usable by TTY
users with their TTYs." Given the definition of TTY that means text-to-text
communication, no voice involved, so it appears there is no current
requirement for direct (non-relay supported) access for VCO or HCO users.



Paul has proposed a revision of that standard which would read "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." As I understand, that is intended to
require direct (non-relay supported) access for people mixing voice and text
(HCO and VCO users.) So the system would need to allow users to use either
voice or text incoming and the system would need to be able to provide
either text or voice outgoing.



What I'm struggling with here is the user side of things . . . TTY lines
are typically "marked" as such. So callers know that text-to-text is
directly available to them via that number. VCO and HCO users make 100% of
their calls via relay because currently there is no direct access for them
to voice callers. In fact phones like the CapTel automatically connect the
relay operator to all outgoing calls when the captioning is active. For
these folks to know they can call a number "directly" (absent using relay)
somehow the phone number would need to be marked. However, I can't figure
out how that would work in a voice mail system for a typical agency where
everyone has their own number. Would all numbers be marked as being able to
support direct VCO access for example? If that is the case, what happens
when voice mail doesn't pick up but the live person does. In order for them
to provide direct VCO access they would need to type to the caller and
listen to them speak. That means every telephone end unit would need to
have a keyboard and given variable keyboarding skills, it would actually
result in much poorer communication access than using relay.



Am I confused about how this direct access for VCO and HCO is supposed to
work? I can sort of see direct VCO and HCO access being implemented in a
"closed" IVR system where live interactions were not an option. But for
routine voice mail and other instances where there is frequent live caller
interaction I'm just not following how it would work.



Diane Golden

NASCIO



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ]On Behalf Of Michaelis, Paul
R. (Paul)
Sent: Monday, March 12, 2007 11:22 AM
To: TEITAC Telecommunications Subcommittee
Subject: Re: [teitac-telecom] Comments re: the proposed revisions
to1194.23(c)



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