Thread Subject: muting vs. captioning

From: Karen Peltz Strauss
Date: Mon, Sep 24 2007 10:10 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Gregg Vanderheiden: "Re: muting vs. captioning"
• Previous message in thread: None
• Messages sorted by: Author | Thread | Date

Gregg,

I feel a bit uncomfortable equating the mute feature with the captioning
feature (which I realize that you are not trying to do, Gregg, but want to
be sure that others understand this).

When televisions first began building in decoder capability in the early
1990s, some models required users to turn on mute to get captions; others
automatically turned on the captions when mute was turned on. The problem
with this - especially the former - is that many deaf/hh people watch TV
with others who are hearing. Also, many people with residual hearing want
some sound along with their captions. They did not want the television to
be muted to get captions.

You suggested that products should provide a means to turn on captions
wherever they have the ability to mute the volume. While that is true,
even if a product does not have the ability to mute the volume, so long as
there is volume on that product and the product can display video
programming with audio output, really there needs to be an easy way of
turning on the captions.

Also, while you are right that captions must be able to be turned on when
the volume is not muted, captions should also be able to be turned on as
well when the volume IS muted.

Bottom line - while I don't think that it would matter if the captioning
button is near the mute button, the two functions achieve very different
purposes and we should be careful not to mix these up.

Karen

----- Original Message -----
From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC Audio/Video Subcommittee'" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, September 21, 2007 3:58 PM
Subject: Re: [teitac-video] Agenda for today's AV subcom meeting


> In the interest of finding a simple way to do this.
> How about
>
> - Products must provide a means to turn on captions wherever they have the
> ability to mute the volume. If there is no mute then it must be at the
> same level as volume. Captions must be able to be turned on when volume
> is
> not muted.
>
> The mute function is pretty basic and is always fairly easy to find. The
> CC
> on/off can be at the same location. If the control is so simple that
> mute
> is on a menu - it will be easy to find - and captions can be in the same
> location.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Dave Singer
>> Sent: Friday, September 21, 2007 11:13 AM
>> To: TEITAC Audio/Video Subcommittee
>> Subject: Re: [teitac-video] Agenda for today's AV subcom meeting
>>
>> At 9:03 -0400 21/09/07, Larry Goldberg wrote:
>> >Having an access solution that requires external/specialized
>> AT makes
>> >sense in some PC-based products, the notion that a deaf or
>> blind person
>> >would need to bring AT to bear on using the menus on their TV is a
>> >major, untenable burden. The complete opposite of any
>> universal design principle.
>> >
>> >I understand that dictating product design can be anathema to
>> >innovation and the ability of companies to meet marketplace demands,
>> >but because the marketplace hasn't been able to incentivize the
>> >usability of such things as menus that can be accessed by
>> deaf or blind
>> >people, the products have drifted toward implementations
>> that approach
>> >sheer unusability. A hands-off approach has led to such
>> situations as a
>> >cable set-top box that must be powered off to access a
>> secret, hidden
>> >firmware menu which gives access to caption controls. Once adjusted,
>> >the cable box menu must be turned off, the box powered back
>> on, and the
>> >resulting captions then viewed for acceptability. If the
>> captions don't
>> >look right, the user has to start the process all over again.
>> >
>> >Meets the letter of the law? Yes.
>> >Usable? Hardly.
>> >Indicates a need to address a "design" issue? Probably.
>> >
>> >... Larry ...
>>
>> The basic problem is that there is no way to mandate good
>> design. I can do a poorly designed remote, poorly designed
>> top-level menu, and a generally poorly designed product.
>> Indeed, if we mandate a specific design, but not the effect
>> we want, we might be worse off.
>> As you say, the product can claim compliance ('see, this
>> little unlabeled recessed button on the side, it enables
>> captions if you press it for 10 seconds or more!') without
>> being usable at all.
>>
>> Accessibility requires that the delivery chain (authoring,
>> transmission, presentation) have a means to deliver, which
>> means that manufacturers actually build in the function;
>> that content makers actually make useful accessible content;
>> and that users who need it can find it and enable it.
>> Getting the right level and style of mandate so that all this
>> happens is not easy, I fear.
>>
>> I'll give an example of a back-fire from another realm. The
>> installer used on Mac OS X requires that if you choose
>> "custom install", the user is shown the various pieces that
>> might get installed, with a check-box for the optional
>> pieces. Selecting an optional piece shows an explanatory
>> string for what you get if you install that option.
>>
>> I cannot tell you the number of times I have seen something
>> like "Frobotz 2" as an optional install, and wondered if I
>> needed it or not, clicked on it to find out what it was, and
>> been given the explanatory string "This installs the Frobotz
>> 2 option". Which is useless to me. If the design had not
>> mandated a string here, then the author wouldn't have
>> supplied this useless one, and the installer could say "this
>> installs a background process that launches at boot and has
>> root privileges" or "this adds the frobotz extension to
>> Microsoft Office", and so on. The installer can work out
>> what pieces it is putting where. So the mandate ('provide an
>> explanatory string
>> always') was actually counter-productive.
>>
>> And less there is any doubt, people needing accessibility are
>> not the only ones who get frustrated by poorly designed products.
>> --
>> David Singer
>> Apple/QuickTime
>>

• Next message in Thread: Gregg Vanderheiden: "Re: muting vs. captioning"
• Previous message in Thread: None