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: Mon, Mar 19 2007 9:50 AM

One more question -- How does this direct access work for captioned VCO,
where there is both text and voice outgoing? I assume that would be yet
another choice up front in the IVR - to get both text and voice information
and the system could send both. Buth then if/when that call is transferred
out of the IVR system to a live person, who do they send both voice and
text. Are they expected to talk and type at the same time? Just trying to
wrap my brain around how this would work . . .

Diane
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ]On Behalf Of Diane Golden
Sent: Sunday, March 18, 2007 7:33 PM
To: TEITAC Telecommunications Subcommittee
Subject: Re: [teitac-telecom] Comments re: the proposed
revisionsto1194.23(c)



I understand how you build the direct access into an IVR. What I still
don't get is how VCO/HCO users know to call directly rather than through the
relay (which again they do for 100% of their calls) and how an agency deals
with live interactions. Do they deploy telecom end units with keyboards (to
send text to VCO users) and display screens (to receive text from HCO users)
to every employee that might engage in live interaction with a caller as
part of the IVR system?

Diane


----- Original Message ----
From: "Michaelis, Paul R. (Paul)" < = EMAIL ADDRESS REMOVED = >
To: = EMAIL ADDRESS REMOVED = ; TEITAC Telecommunications Subcommittee
< = EMAIL ADDRESS REMOVED = >
Sent: Saturday, March 17, 2007 4:07:36 PM
Subject: RE: [teitac-telecom] Comments re: the proposed revisions
to1194.23(c)


Diane,

VCO means that the user receives via text and then responds by voice. A
voicemail system that supports VCO-style interaction would provide
prompts, menus, and other system-generated information (e.g., someone's
telephone number if a directory look-up function is available) as text,
but nevertheless permit the user to leave a voice message. By the same
token, support for HCO by a voicemail system would mean that, even when
the system is prompting by voice, a caller could still use a TTY device
to leave a message. None of these operations would require support from
a relay service.

In case you are wondering whether this is readily achievable, I first
built this capability for the Intuity AUDIX voicemail system in 1993.
The feature is provided, for free, with every voicemail system we sell.
Specifically, if a voicemail mailbox on the system is TTY-enabled by the
system administrator, users may select via touchtone command whether
they wish to be prompted by voice or in TTY format. Regardless of the
prompting format they select, users may leave a voice or TTY message.
(In other words, voice transmissions in both directions between the user
and the messaging server are permitted by this system, as is TTY in both
directions, along with VCO and HCO.) Note that the ability to switch
between voice and TTY prompting can be enabled on any phone number for
any mailbox, thereby making it unnecessary to designate specific phone
numbers as being an organization's TTY/VCO/HCO mailboxes.

Keeping in mind that we've been providing this capability on our
voicemail systems for close to 14 years, you may be wondering why you've
never come across this feature. The simple answer is that the vast
majority of organizations that have purchased our voicemail systems have
never taken the time to activate the TTY feature -- including the FCC.
Given that the feature is provided for free, and is documented in the
system literature, the fact that it's not being used is awfully hard to
explain.

-- Paul Michaelis




-----Original Message-----
From: Diane Golden [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, March 17, 2007 1:47 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] Comments re: the proposed revisions
to1194.23(c)

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