Thread Subject: Proposed language for user controls on video programming products

Return to this mailing list's archives

From: Karen Peltz Strauss
Date: Thu, Oct 11 2007 5:30 AM
Subject: Proposed language for user controls on video programming products

Here is another attempt at proposed language for user controls on video
programming products. I have taken a little bit from Dave's, Sean's and
Gregg's proposals, and here is what I have come up with. By way of
explanation: First, this really should stay in the audio-video section of
the guidelines, not a general section where it is likely to be overlooked.
We are talking about very specific types of controls for accessing
television and television-like products and it would be better if we dealt
with this here. Second, this provision does not belong in 1.2-A because
that section deals with activation by the agency - such as when
accessibility is built into a phone system and the agency does not trigger
the switch to turn on the access features built in (this was discussed at
length in the telecom subcommittee where this provision originated).
Third, I agree with Gregg that the examples may get lost, but if we include
some language about comparable prominence to volume and channel controls, I
think that will help. I know there were some concerns about this, and that
is why I added "where the ability to control these features is otherwise
provided." Finally, I tried to put this whole requirement into plain
English - "make the controls easy to find and easy to use":



In order to comply with this subpart, the user controls needed to configure
and activate general and accessibility features on products that receive or
display analog or digital television must be easy to find and easy to use by
people with disabilities. These must be comparable in prominence to the
controls needed to change volume and channels, where the ability to control
these features is otherwise provided.



For example:
1. For captioning: (a) A caption on/off on a TV remote comparable in
prominence to the volume control on that remote; (b) Caption controls on the
first menu that appear when on-screen menus are displayed

2. Audio equivalents to on-screen information and visual menu selections
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable from
a login screen.



Karen

From: Sean Hayes
Date: Thu, Oct 11 2007 8:15 AM
Subject: Re: Proposed language for user controls on video programming products

I understand your focus on the specifics of AV access, but I do think this is a general concept that needs to be articulated, as its appropriate for all kinds of products. Since 508 deals with products operated by agencies I think it is right to use 1.2A, regardless of its origins in telecom. It should be possible for a person with a disability to do the configuration don't you think?

Perhaps we could keep the new language I suggested for 1.2 A (see reply to Gregg today), but create a reference to it from the AV section and move examples 1 and 2 under that reference. I'm not sure exactly what that cross reference would look like, I'll give it more thought.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Karen Peltz Strauss
Sent: 11 October 2007 12:29
To: TEITAC Audio/Video Subcommittee; 'Dave Singer'; 'Al Sonnenstrahl'; = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
Cc: Rosaline Crawford; = EMAIL ADDRESS REMOVED =
Subject: [teitac-video] Proposed language for user controls on video programming products

Here is another attempt at proposed language for user controls on video
programming products. I have taken a little bit from Dave's, Sean's and
Gregg's proposals, and here is what I have come up with. By way of
explanation: First, this really should stay in the audio-video section of
the guidelines, not a general section where it is likely to be overlooked.
We are talking about very specific types of controls for accessing
television and television-like products and it would be better if we dealt
with this here. Second, this provision does not belong in 1.2-A because
that section deals with activation by the agency - such as when
accessibility is built into a phone system and the agency does not trigger
the switch to turn on the access features built in (this was discussed at
length in the telecom subcommittee where this provision originated).
Third, I agree with Gregg that the examples may get lost, but if we include
some language about comparable prominence to volume and channel controls, I
think that will help. I know there were some concerns about this, and that
is why I added "where the ability to control these features is otherwise
provided." Finally, I tried to put this whole requirement into plain
English - "make the controls easy to find and easy to use":



In order to comply with this subpart, the user controls needed to configure
and activate general and accessibility features on products that receive or
display analog or digital television must be easy to find and easy to use by
people with disabilities. These must be comparable in prominence to the
controls needed to change volume and channels, where the ability to control
these features is otherwise provided.



For example:
1. For captioning: (a) A caption on/off on a TV remote comparable in
prominence to the volume control on that remote; (b) Caption controls on the
first menu that appear when on-screen menus are displayed

2. Audio equivalents to on-screen information and visual menu selections
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable from
a login screen.



Karen

From: Schomburg, Paul
Date: Thu, Oct 11 2007 8:40 AM
Subject: Re: Proposed language for user controls on videoprogramming products

Karen: Although the example you provided applies to remote controls and
on-screen menus, the sentence "These must be comparable in prominence to
the controls needed to change volume and channels, where the ability to
control these features is otherwise provided" might be interpreted to
require buttons for caption control and secondary audio on the main TV
unit itself. I don't think this is a good result as it would exclude a
large number of commercial units which could be made accessible with a
special remote. Was this what you intended?

Thanks, Paul

Paul G. Schomburg, Sr. Manager
Tel: (202) 912-3800 x114; Cell: (202) 550-2230

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Karen Peltz
Strauss
Sent: Thursday, October 11, 2007 7:29 AM
To: TEITAC Audio/Video Subcommittee; 'Dave Singer'; 'Al Sonnenstrahl';
= EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED =
Cc: Rosaline Crawford; = EMAIL ADDRESS REMOVED =
Subject: [teitac-video] Proposed language for user controls on
videoprogramming products

Here is another attempt at proposed language for user controls on video
programming products. I have taken a little bit from Dave's, Sean's and
Gregg's proposals, and here is what I have come up with. By way of
explanation: First, this really should stay in the audio-video section
of the guidelines, not a general section where it is likely to be
overlooked. We are talking about very specific types of controls for
accessing television and television-like products and it would be better
if we dealt with this here. Second, this provision does not belong in
1.2-A because that section deals with activation by the agency - such as
when accessibility is built into a phone system and the agency does not
trigger the switch to turn on the access features built in (this was
discussed at length in the telecom subcommittee where this provision
originated). Third, I agree with Gregg that the examples may get lost,
but if we include some language about comparable prominence to volume
and channel controls, I think that will help. I know there were some
concerns about this, and that is why I added "where the ability to
control these features is otherwise provided." Finally, I tried to put
this whole requirement into plain English - "make the controls easy to
find and easy to use":

In order to comply with this subpart, the user controls needed to
configure and activate general and accessibility features on products
that receive or display analog or digital television must be easy to
find and easy to use by people with disabilities. These must be
comparable in prominence to the controls needed to change volume and
channels, where the ability to control these features is otherwise
provided.

For example:
1. For captioning: (a) A caption on/off on a TV remote comparable in
prominence to the volume control on that remote; (b) Caption controls on
the first menu that appear when on-screen menus are displayed
2. Audio equivalents to on-screen information and visual menu selections
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable
from a login screen.

Karen

From: Dave Singer
Date: Thu, Oct 11 2007 12:40 PM
Subject: Re: Proposed language for user controls on video programming products

Ooops, I missed Karen's later message and I should have started with
that, ahem. Sorry, Karen.

I get the "general and" part here is saying that people with an
accessibility need will need two kinds of control ability (a) the
need to control the accessibility feature and (b) the need to control
everything else that is part of normal access.


How about this:

In order to comply with this subpart, the user controls needed to
configure and activate any accessibility feature, and the general
controls used by those needing that accessibility feature, on
products that receive or display analog or digital television, must
be easy to find and easy to use by people needing that accessibility
feature. These must be comparable in prominence to the controls
needed to change volume and channels, where the ability to control
these features is otherwise provided.



For example:
1. For captioning: (a) A caption on/off on a TV remote comparable in
prominence to the volume control on that remote; (b) Caption controls
on the first menu that appear when on-screen menus are displayed

2. Audio equivalents to on-screen information and visual menu selections
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable from
a login screen.




At 7:29 -0400 11/10/07, Karen Peltz Strauss wrote:
>Here is another attempt at proposed language for user controls on
>video programming products. I have taken a little bit from Dave's,
>Sean's and Gregg's proposals, and here is what I have come up with.
>By way of explanation: First, this really should stay in the
>audio-video section of the guidelines, not a general section where
>it is likely to be overlooked. We are talking about very specific
>types of controls for accessing television and television-like
>products and it would be better if we dealt with this here.
>Second, this provision does not belong in 1.2-A because that section
>deals with activation by the agency - such as when accessibility is
>built into a phone system and the agency does not trigger the switch
>to turn on the access features built in (this was discussed at
>length in the telecom subcommittee where this provision originated).
>Third, I agree with Gregg that the examples may get lost, but if we
>include some language about comparable prominence to volume and
>channel controls, I think that will help. I know there were some
>concerns about this, and that is why I added "where the ability to
>control these features is otherwise provided." Finally, I tried to
>put this whole requirement into plain English - "make the controls
>easy to find and easy to use":
>
>
>
>In order to comply with this subpart, the user controls needed to
>configure and activate general and accessibility features on
>products that receive or display analog or digital television must
>be easy to find and easy to use by people with disabilities. These
>must be comparable in prominence to the controls needed to change
>volume and channels, where the ability to control these features is
>otherwise provided.
>
>
>
>For example:
>1. For captioning: (a) A caption on/off on a TV remote comparable
>in prominence to the volume control on that remote; (b) Caption
>controls on the first menu that appear when on-screen menus are
>displayed
>
>2. Audio equivalents to on-screen information and visual menu selections
>3. A tactile button to turn on audio equivalents;
>4. A user preferences dialog that is accessible and directly reachable from
>a login screen.
>
>
>
>Karen


--
David Singer
Apple/QuickTime

From: Karen Peltz Strauss
Date: Thu, Oct 11 2007 1:10 PM
Subject: Re: Proposed language for user controls on video programming products

In theory I don't have a problem with how you have revised this. I am a
little concerned about its readability though.

I will be leaving to go out of town for a while and not have much access to
e-mail again until Sunday. I will check back then to read this discussion
strand.

Karen

----- Original Message -----
From: "Dave Singer" < = EMAIL ADDRESS REMOVED = >
To: "Karen Peltz Strauss" < = EMAIL ADDRESS REMOVED = >; "TEITAC Audio/Video
Subcommittee" < = EMAIL ADDRESS REMOVED = >; "'Al Sonnenstrahl'"
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "'Toby R. Silver'"
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Cc: "Rosaline Crawford" < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, October 11, 2007 2:37 PM
Subject: Re: Proposed language for user controls on video programming
products


> Ooops, I missed Karen's later message and I should have started with that,
> ahem. Sorry, Karen.
>
> I get the "general and" part here is saying that people with an
> accessibility need will need two kinds of control ability (a) the need to
> control the accessibility feature and (b) the need to control everything
> else that is part of normal access.
>
>
> How about this:
>
> In order to comply with this subpart, the user controls needed to
> configure and activate any accessibility feature, and the general controls
> used by those needing that accessibility feature, on products that receive
> or display analog or digital television, must be easy to find and easy to
> use by people needing that accessibility feature. These must be
> comparable in prominence to the controls needed to change volume and
> channels, where the ability to control these features is otherwise
> provided.
>
>
>
> For example:
> 1. For captioning: (a) A caption on/off on a TV remote comparable in
> prominence to the volume control on that remote; (b) Caption controls on
> the first menu that appear when on-screen menus are displayed
>
> 2. Audio equivalents to on-screen information and visual menu selections
> 3. A tactile button to turn on audio equivalents;
> 4. A user preferences dialog that is accessible and directly reachable
> from
> a login screen.
>
>
>
>
> At 7:29 -0400 11/10/07, Karen Peltz Strauss wrote:
>>Here is another attempt at proposed language for user controls on video
>>programming products. I have taken a little bit from Dave's, Sean's and
>>Gregg's proposals, and here is what I have come up with. By way of
>>explanation: First, this really should stay in the audio-video section of
>>the guidelines, not a general section where it is likely to be overlooked.
>>We are talking about very specific types of controls for accessing
>>television and television-like products and it would be better if we dealt
>>with this here. Second, this provision does not belong in 1.2-A because
>>that section deals with activation by the agency - such as when
>>accessibility is built into a phone system and the agency does not trigger
>>the switch to turn on the access features built in (this was discussed at
>>length in the telecom subcommittee where this provision originated).
>>Third, I agree with Gregg that the examples may get lost, but if we
>>include some language about comparable prominence to volume and channel
>>controls, I think that will help. I know there were some concerns about
>>this, and that is why I added "where the ability to control these features
>>is otherwise provided." Finally, I tried to put this whole requirement
>>into plain English - "make the controls easy to find and easy to use":
>>
>>
>>
>>In order to comply with this subpart, the user controls needed to
>>configure and activate general and accessibility features on products that
>>receive or display analog or digital television must be easy to find and
>>easy to use by people with disabilities. These must be comparable in
>>prominence to the controls needed to change volume and channels, where the
>>ability to control these features is otherwise provided.
>>
>>
>>
>>For example:
>>1. For captioning: (a) A caption on/off on a TV remote comparable in
>>prominence to the volume control on that remote; (b) Caption controls on
>>the first menu that appear when on-screen menus are displayed
>>
>>2. Audio equivalents to on-screen information and visual menu selections
>>3. A tactile button to turn on audio equivalents;
>>4. A user preferences dialog that is accessible and directly reachable
>>from
>>a login screen.
>>
>>
>>
>>Karen
>
>
> --
> David Singer
> Apple/QuickTime

From: Dave Singer
Date: Thu, Oct 11 2007 2:20 PM
Subject: Re: Proposed language for user controls on video programming products

At 15:56 -0400 11/10/07, Alfred Sonnenstrahl wrote:
>My big concern is lack of simplicty of both the language and product.
>
>The language as I see it is very complicated and confusing. Based on my
>experiences, Ive met many well-intended technicans who often misunderstood
>our choice of words which often led to unnecessary confusions, delays and
>expensive reactive modifications and expensive time consuming litigations.
>
>Just keep it KISS and in 3rd grade reading level.
>
>Thanks!
>
>Sonny

I agree, what I wrote is rather contorted and not up to my own
standards. :-(. however, if it expresses what we want, we can fix
that.

>
>-----Original Message-----
>From: Karen Peltz Strauss [mailto: = EMAIL ADDRESS REMOVED = ]
>Sent: Thursday, October 11, 2007 3:07 PM
>To: TEITAC Audio/Video Subcommittee; 'Al Sonnenstrahl';
> = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ;
> = EMAIL ADDRESS REMOVED = ; Dave Singer
>Cc: Rosaline Crawford; = EMAIL ADDRESS REMOVED =
>Subject: Re: Proposed language for user controls on video programming
>products
>
>
>In theory I don't have a problem with how you have revised this. I am a
>little concerned about its readability though.
>
>I will be leaving to go out of town for a while and not have much access to
>e-mail again until Sunday. I will check back then to read this discussion
>strand.
>
>Karen
>
>----- Original Message -----
>From: "Dave Singer" < = EMAIL ADDRESS REMOVED = >
>To: "Karen Peltz Strauss" < = EMAIL ADDRESS REMOVED = >; "TEITAC Audio/Video
>
>Subcommittee" < = EMAIL ADDRESS REMOVED = >; "'Al Sonnenstrahl'"
>< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "'Toby R. Silver'"
>< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
>Cc: "Rosaline Crawford" < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
>Sent: Thursday, October 11, 2007 2:37 PM
>Subject: Re: Proposed language for user controls on video programming
>products
>
>
>> Ooops, I missed Karen's later message and I should have started with
>> that,
>> ahem. Sorry, Karen.
>>
>> I get the "general and" part here is saying that people with an
>> accessibility need will need two kinds of control ability (a) the need to
>> control the accessibility feature and (b) the need to control everything
>> else that is part of normal access.
>>
>>
>> How about this:
>>
>> In order to comply with this subpart, the user controls needed to
>> configure and activate any accessibility feature, and the general controls
>
>> used by those needing that accessibility feature, on products that receive
>
>> or display analog or digital television, must be easy to find and easy to
>> use by people needing that accessibility feature. These must be
>> comparable in prominence to the controls needed to change volume and
>> channels, where the ability to control these features is otherwise
>> provided.
>>
>>
>>
>> For example:
>> 1. For captioning: (a) A caption on/off on a TV remote comparable in
>> prominence to the volume control on that remote; (b) Caption controls on
>> the first menu that appear when on-screen menus are displayed
>>
>> 2. Audio equivalents to on-screen information and visual menu
>> selections 3. A tactile button to turn on audio equivalents; 4. A user
>> preferences dialog that is accessible and directly reachable from
>> a login screen.
>>
>>
>>
>>
>> At 7:29 -0400 11/10/07, Karen Peltz Strauss wrote:
>>>Here is another attempt at proposed language for user controls on
>>>video
>>>programming products. I have taken a little bit from Dave's, Sean's and
>>>Gregg's proposals, and here is what I have come up with. By way of
>>>explanation: First, this really should stay in the audio-video section of
>
>>>the guidelines, not a general section where it is likely to be overlooked.
>
>>>We are talking about very specific types of controls for accessing
>>>television and television-like products and it would be better if we dealt
>
>>>with this here. Second, this provision does not belong in 1.2-A because
>>>that section deals with activation by the agency - such as when
>>>accessibility is built into a phone system and the agency does not trigger
>
>>>the switch to turn on the access features built in (this was discussed at
>>>length in the telecom subcommittee where this provision originated).
>>>Third, I agree with Gregg that the examples may get lost, but if we
>>>include some language about comparable prominence to volume and channel
>>>controls, I think that will help. I know there were some concerns about
>>>this, and that is why I added "where the ability to control these features
>
>>>is otherwise provided." Finally, I tried to put this whole requirement
>>>into plain English - "make the controls easy to find and easy to use":
>>>
>>>
>>>
>>>In order to comply with this subpart, the user controls needed to
>>>configure and activate general and accessibility features on products that
>
>>>receive or display analog or digital television must be easy to find and
>>>easy to use by people with disabilities. These must be comparable in
>>>prominence to the controls needed to change volume and channels, where the
>
>>>ability to control these features is otherwise provided.
>>>
>>>
>>>
>>>For example:
>>>1. For captioning: (a) A caption on/off on a TV remote comparable in
>>>prominence to the volume control on that remote; (b) Caption controls on
>>>the first menu that appear when on-screen menus are displayed
>>>
>>>2. Audio equivalents to on-screen information and visual menu
>>>selections 3. A tactile button to turn on audio equivalents; 4. A user
>>>preferences dialog that is accessible and directly reachable from
>>>a login screen.
>>>
>>>
>>>
>>>Karen
>>
>>
>> --
>> David Singer
>> Apple/QuickTime


--
David Singer
Apple/QuickTime