Thread Subject: Tomorrow's conf call

Return to this mailing list's archives

From: Larry Goldberg
Date: Tue, Oct 09 2007 1:35 PM
Subject: Tomorrow's conf call

Wednesday, October 10, 2007, 3:00 - 4:00pm ET (can continue to 4:30pm ET if
needed).

PHONE BRIDGE (supplied by Adobe):

Meeting id#: 107147
1-877-220-5439 (US)

FRCC is:
796924

TOHRU:
AV subcom

We will discuss today's Plenary meeting/conference call, suggested changes
to the enclosed draft, and hopefully come to a conclusion regarding the
"caption button"/"top-level menu" proposal.

- Larry

From: Dave Singer
Date: Tue, Oct 09 2007 4:00 PM
Subject: Re: Tomorrow's conf call

At 15:31 -0400 9/10/07, Larry Goldberg wrote:
>
>We will discuss today's Plenary meeting/conference call, suggested changes
>to the enclosed draft, and hopefully come to a conclusion regarding the
>"caption button"/"top-level menu" proposal.

As worded, I really don't think I can -- or we should -- agree to
these, unless they are restricted to 'classical analog television'.
They are both making into mandates a question of the design of the
system.

The furthest we should go in this direction is a recommendation. We
simply do not know how to design these products, and inserting a
design mandate may well have a counter-productive effect:
manufacturers who were willing to meet the spirit of the regulations,
and provide accessible equipment, may well not wish to meet the
letter of such a design mandate, and consequently (since they would
no longer be able to claim compliance) do nothing.

I am also wondering why the people needing captions need to have this
explicit access method, but those (for example) needing audio
description of video are left without even a guideline as to how it
should be enabled?

Finally, what happens to option (2) when the menus on a system are
enabled some other way than pressing a menu button on a remote?

So, trying again, I'd like to *broaden* the scope of the *mandate*
while leaving product design only recommended:

* * * * *

For all accessibility options, including but not limited to Captions,
and Audio Description of Video [or whatever the term we settled on
is], the enabling and disabling of that accessibility option must
also be readily accessible to those desiring it, meaning that the
control must both be easy to find, and easily used by someone needing
it.

For captions, recommended approaches include:
1. A caption on/off button on the TV remote control;
2. Caption control(s) on the first menu that appears when on-screen
menus are displayed;
--
David Singer
Apple/QuickTime

From: Larry Goldberg
Date: Wed, Oct 10 2007 9:35 AM
Subject: Re: Tomorrow's conf call

Dave's suggestion regarding a more generic, but strong, requirement for the
accessibility and usability of access controls bears serious consideration.
Let's do so at today's conference call.

... Larry ...


Dave Singer wrote:

> At 15:31 -0400 9/10/07, Larry Goldberg wrote:
>>
>> We will discuss today's Plenary meeting/conference call, suggested changes
>> to the enclosed draft, and hopefully come to a conclusion regarding the
>> "caption button"/"top-level menu" proposal.
>
> As worded, I really don't think I can -- or we should -- agree to
> these, unless they are restricted to 'classical analog television'.
> They are both making into mandates a question of the design of the
> system.
>
> The furthest we should go in this direction is a recommendation. We
> simply do not know how to design these products, and inserting a
> design mandate may well have a counter-productive effect:
> manufacturers who were willing to meet the spirit of the regulations,
> and provide accessible equipment, may well not wish to meet the
> letter of such a design mandate, and consequently (since they would
> no longer be able to claim compliance) do nothing.
>
> I am also wondering why the people needing captions need to have this
> explicit access method, but those (for example) needing audio
> description of video are left without even a guideline as to how it
> should be enabled?
>
> Finally, what happens to option (2) when the menus on a system are
> enabled some other way than pressing a menu button on a remote?
>
> So, trying again, I'd like to *broaden* the scope of the *mandate*
> while leaving product design only recommended:
>
> * * * * *
>
> For all accessibility options, including but not limited to Captions,
> and Audio Description of Video [or whatever the term we settled on
> is], the enabling and disabling of that accessibility option must
> also be readily accessible to those desiring it, meaning that the
> control must both be easy to find, and easily used by someone needing
> it.
>
> For captions, recommended approaches include:
> 1. A caption on/off button on the TV remote control;
> 2. Caption control(s) on the first menu that appears when on-screen
> menus are displayed;


- Larry

From: Karen Peltz Strauss
Date: Wed, Oct 10 2007 10:00 AM
Subject: Re: Tomorrow's conf call

That is fine, but one thing I disagree with - that manufacturers simply do
not know how to design a remote control with a captioning button.

As for why this would be required for captions and not video description,
ideally it would be added for both. At present, given that 100% of all new
television programming with few exceptions, are captioned, the need is more
immediate for captions. However, the need for audio output of ALL menu
functions is more pressing for people who cannot see - not only access to
video description but to all menu features.

Karen

----- Original Message -----
From: "Larry Goldberg" < = EMAIL ADDRESS REMOVED = >
To: "Dave Singer" < = EMAIL ADDRESS REMOVED = >; "TEITAC AV list"
< = EMAIL ADDRESS REMOVED = >; "Al Sonnenstrahl" < = EMAIL ADDRESS REMOVED = >;
< = EMAIL ADDRESS REMOVED = >; "Toby R. Silver" < = EMAIL ADDRESS REMOVED = >;
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, October 10, 2007 11:30 AM
Subject: Re: [teitac-video] Tomorrow's conf call


> Dave's suggestion regarding a more generic, but strong, requirement for
> the
> accessibility and usability of access controls bears serious
> consideration.
> Let's do so at today's conference call.
>
> ... Larry ...
>
>
> Dave Singer wrote:
>
>> At 15:31 -0400 9/10/07, Larry Goldberg wrote:
>>>
>>> We will discuss today's Plenary meeting/conference call, suggested
>>> changes
>>> to the enclosed draft, and hopefully come to a conclusion regarding the
>>> "caption button"/"top-level menu" proposal.
>>
>> As worded, I really don't think I can -- or we should -- agree to
>> these, unless they are restricted to 'classical analog television'.
>> They are both making into mandates a question of the design of the
>> system.
>>
>> The furthest we should go in this direction is a recommendation. We
>> simply do not know how to design these products, and inserting a
>> design mandate may well have a counter-productive effect:
>> manufacturers who were willing to meet the spirit of the regulations,
>> and provide accessible equipment, may well not wish to meet the
>> letter of such a design mandate, and consequently (since they would
>> no longer be able to claim compliance) do nothing.
>>
>> I am also wondering why the people needing captions need to have this
>> explicit access method, but those (for example) needing audio
>> description of video are left without even a guideline as to how it
>> should be enabled?
>>
>> Finally, what happens to option (2) when the menus on a system are
>> enabled some other way than pressing a menu button on a remote?
>>
>> So, trying again, I'd like to *broaden* the scope of the *mandate*
>> while leaving product design only recommended:
>>
>> * * * * *
>>
>> For all accessibility options, including but not limited to Captions,
>> and Audio Description of Video [or whatever the term we settled on
>> is], the enabling and disabling of that accessibility option must
>> also be readily accessible to those desiring it, meaning that the
>> control must both be easy to find, and easily used by someone needing
>> it.
>>
>> For captions, recommended approaches include:
>> 1. A caption on/off button on the TV remote control;
>> 2. Caption control(s) on the first menu that appears when on-screen
>> menus are displayed;
>
>
> - Larry
>
>
>
>

From: Sean Hayes
Date: Wed, Oct 10 2007 2:00 PM
Subject: Re: Tomorrow's conf call

Here is the text I was working on, I've attached four examples, if anyone thinks we need more then please suggest them


I suggest a modification of the existing provision 1.2 A to allow for the requirement that the means to set up a feature be accessible to the person that needs it, as follows;

1.2-A - Accessibility Configuration
In complying with this subpart, each agency must activate accessibility features and configure products so that they are accessible to and usable by people with disabilities. The means to activate the accessibility features and configure products must be accessible, discoverable and usable by those desiring the feature.

For example:
1. A caption on/off on a TV remote comparable in prominence to the volume control on that remote;
2. A gain wheel or slider on a telephone receiver handset;
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable from a login screen.


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 Larry Goldberg
Sent: 10 October 2007 16:30
To: Dave Singer; TEITAC AV list; Al Sonnenstrahl; = EMAIL ADDRESS REMOVED = ; Toby R. Silver; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-video] Tomorrow's conf call

Dave's suggestion regarding a more generic, but strong, requirement for the
accessibility and usability of access controls bears serious consideration.
Let's do so at today's conference call.

... Larry ...


Dave Singer wrote:

> At 15:31 -0400 9/10/07, Larry Goldberg wrote:
>>
>> We will discuss today's Plenary meeting/conference call, suggested changes
>> to the enclosed draft, and hopefully come to a conclusion regarding the
>> "caption button"/"top-level menu" proposal.
>
> As worded, I really don't think I can -- or we should -- agree to
> these, unless they are restricted to 'classical analog television'.
> They are both making into mandates a question of the design of the
> system.
>
> The furthest we should go in this direction is a recommendation. We
> simply do not know how to design these products, and inserting a
> design mandate may well have a counter-productive effect:
> manufacturers who were willing to meet the spirit of the regulations,
> and provide accessible equipment, may well not wish to meet the
> letter of such a design mandate, and consequently (since they would
> no longer be able to claim compliance) do nothing.
>
> I am also wondering why the people needing captions need to have this
> explicit access method, but those (for example) needing audio
> description of video are left without even a guideline as to how it
> should be enabled?
>
> Finally, what happens to option (2) when the menus on a system are
> enabled some other way than pressing a menu button on a remote?
>
> So, trying again, I'd like to *broaden* the scope of the *mandate*
> while leaving product design only recommended:
>
> * * * * *
>
> For all accessibility options, including but not limited to Captions,
> and Audio Description of Video [or whatever the term we settled on
> is], the enabling and disabling of that accessibility option must
> also be readily accessible to those desiring it, meaning that the
> control must both be easy to find, and easily used by someone needing
> it.
>
> For captions, recommended approaches include:
> 1. A caption on/off button on the TV remote control;
> 2. Caption control(s) on the first menu that appears when on-screen
> menus are displayed;


- Larry

From: Gregg Vanderheiden
Date: Thu, Oct 11 2007 12:20 AM
Subject: Re: Tomorrow's conf call

This is good but the examples will be dropped and the rest is pretty vague.
I would see the current menu's as being described as 'discoverable'. Even
with the examples - one can argue that current menus are discoverable. How
about just moving the one phrase up to the provision.



1.2-A - Accessibility Configuration
In complying with this subpart, each agency must activate accessibility
features and configure products so that they are accessible to and usable by
people with disabilities such that the means to activate the accessibility
features and configure products is comparable in prominence to the volume or
channel changing controls.

For example:
1. A caption on/off on a TV remote comparable in prominence to the volume
control on that remote;
2. A gain wheel or slider on a telephone receiver handset;
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable from
a login screen.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
> Sent: Wednesday, October 10, 2007 2:50 PM
> To: TEITAC Audio/Video Subcommittee; Dave Singer; Al
> Sonnenstrahl; = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-video] Tomorrow's conf call
>
> Here is the text I was working on, I've attached four
> examples, if anyone thinks we need more then please suggest them
>
>
> I suggest a modification of the existing provision 1.2 A to
> allow for the requirement that the means to set up a feature
> be accessible to the person that needs it, as follows;
>
> 1.2-A - Accessibility Configuration
> In complying with this subpart, each agency must activate
> accessibility features and configure products so that they
> are accessible to and usable by people with disabilities. The
> means to activate the accessibility features and configure
> products must be accessible, discoverable and usable by those
> desiring the feature.
>
> For example:
> 1. A caption on/off on a TV remote comparable in prominence
> to the volume control on that remote; 2. A gain wheel or
> slider on a telephone receiver handset; 3. A tactile button
> to turn on audio equivalents; 4. A user preferences dialog
> that is accessible and directly reachable from a login screen.
>
>
> 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
> Larry Goldberg
> Sent: 10 October 2007 16:30
> To: Dave Singer; TEITAC AV list; Al Sonnenstrahl;
> = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-video] Tomorrow's conf call
>
> Dave's suggestion regarding a more generic, but strong,
> requirement for the accessibility and usability of access
> controls bears serious consideration.
> Let's do so at today's conference call.
>
> ... Larry ...
>
>
> Dave Singer wrote:
>
> > At 15:31 -0400 9/10/07, Larry Goldberg wrote:
> >>
> >> We will discuss today's Plenary meeting/conference call, suggested
> >> changes to the enclosed draft, and hopefully come to a conclusion
> >> regarding the "caption button"/"top-level menu" proposal.
> >
> > As worded, I really don't think I can -- or we should -- agree to
> > these, unless they are restricted to 'classical analog television'.
> > They are both making into mandates a question of the design of the
> > system.
> >
> > The furthest we should go in this direction is a
> recommendation. We
> > simply do not know how to design these products, and inserting a
> > design mandate may well have a counter-productive effect:
> > manufacturers who were willing to meet the spirit of the
> regulations,
> > and provide accessible equipment, may well not wish to meet
> the letter
> > of such a design mandate, and consequently (since they
> would no longer
> > be able to claim compliance) do nothing.
> >
> > I am also wondering why the people needing captions need to
> have this
> > explicit access method, but those (for example) needing audio
> > description of video are left without even a guideline as to how it
> > should be enabled?
> >
> > Finally, what happens to option (2) when the menus on a system are
> > enabled some other way than pressing a menu button on a remote?
> >
> > So, trying again, I'd like to *broaden* the scope of the *mandate*
> > while leaving product design only recommended:
> >
> > * * * * *
> >
> > For all accessibility options, including but not limited to
> Captions,
> > and Audio Description of Video [or whatever the term we settled on
> > is], the enabling and disabling of that accessibility
> option must also
> > be readily accessible to those desiring it, meaning that
> the control
> > must both be easy to find, and easily used by someone needing it.
> >
> > For captions, recommended approaches include:
> > 1. A caption on/off button on the TV remote control; 2. Caption
> > control(s) on the first menu that appears when on-screen menus are
> > displayed;
>
>
> - Larry
>
>
>
>

From: Sean Hayes
Date: Thu, Oct 11 2007 8:05 AM
Subject: Re: Tomorrow's conf call

That wouldn't work in the context of 1.2A, which is a general provision; so referring to volume or channel changing controls wouldn't make sense for all products and it loses the sense of David's idea that the means to activate an accessibility feature must be operable by the person that needs that feature.

The specific case of raising the prominence of a caption control really is outside of the scope of the provision itself, just as we don't have any specifics on the form of volume controls on phones, or contrast controls in software or on a display - so it does need to be an example.

How about:
1.2-A - Accessibility Configuration
In complying with this subpart, each agency must activate accessibility
features and configure products so that they are accessible to and usable by
people with disabilities, and the means to activate the accessibility
features and configure products is accessible to those that need those features and
comparable in prominence to similar configuration mechanisms for general operation.

For example:
1. A caption on/off on a TV remote comparable in prominence to the volume
control on that remote;
2. A gain wheel or slider on a telephone receiver handset;
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable from
a login screen.

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 Gregg Vanderheiden
Sent: 11 October 2007 07:19
To: 'TEITAC Audio/Video Subcommittee'; 'Dave Singer'; 'Al Sonnenstrahl'; = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-video] Tomorrow's conf call

This is good but the examples will be dropped and the rest is pretty vague.
I would see the current menu's as being described as 'discoverable'. Even
with the examples - one can argue that current menus are discoverable. How
about just moving the one phrase up to the provision.



1.2-A - Accessibility Configuration
In complying with this subpart, each agency must activate accessibility
features and configure products so that they are accessible to and usable by
people with disabilities such that the means to activate the accessibility
features and configure products is comparable in prominence to the volume or
channel changing controls.

For example:
1. A caption on/off on a TV remote comparable in prominence to the volume
control on that remote;
2. A gain wheel or slider on a telephone receiver handset;
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable from
a login screen.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
> Sent: Wednesday, October 10, 2007 2:50 PM
> To: TEITAC Audio/Video Subcommittee; Dave Singer; Al
> Sonnenstrahl; = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-video] Tomorrow's conf call
>
> Here is the text I was working on, I've attached four
> examples, if anyone thinks we need more then please suggest them
>
>
> I suggest a modification of the existing provision 1.2 A to
> allow for the requirement that the means to set up a feature
> be accessible to the person that needs it, as follows;
>
> 1.2-A - Accessibility Configuration
> In complying with this subpart, each agency must activate
> accessibility features and configure products so that they
> are accessible to and usable by people with disabilities. The
> means to activate the accessibility features and configure
> products must be accessible, discoverable and usable by those
> desiring the feature.
>
> For example:
> 1. A caption on/off on a TV remote comparable in prominence
> to the volume control on that remote; 2. A gain wheel or
> slider on a telephone receiver handset; 3. A tactile button
> to turn on audio equivalents; 4. A user preferences dialog
> that is accessible and directly reachable from a login screen.
>
>
> 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
> Larry Goldberg
> Sent: 10 October 2007 16:30
> To: Dave Singer; TEITAC AV list; Al Sonnenstrahl;
> = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-video] Tomorrow's conf call
>
> Dave's suggestion regarding a more generic, but strong,
> requirement for the accessibility and usability of access
> controls bears serious consideration.
> Let's do so at today's conference call.
>
> ... Larry ...
>
>
> Dave Singer wrote:
>
> > At 15:31 -0400 9/10/07, Larry Goldberg wrote:
> >>
> >> We will discuss today's Plenary meeting/conference call, suggested
> >> changes to the enclosed draft, and hopefully come to a conclusion
> >> regarding the "caption button"/"top-level menu" proposal.
> >
> > As worded, I really don't think I can -- or we should -- agree to
> > these, unless they are restricted to 'classical analog television'.
> > They are both making into mandates a question of the design of the
> > system.
> >
> > The furthest we should go in this direction is a
> recommendation. We
> > simply do not know how to design these products, and inserting a
> > design mandate may well have a counter-productive effect:
> > manufacturers who were willing to meet the spirit of the
> regulations,
> > and provide accessible equipment, may well not wish to meet
> the letter
> > of such a design mandate, and consequently (since they
> would no longer
> > be able to claim compliance) do nothing.
> >
> > I am also wondering why the people needing captions need to
> have this
> > explicit access method, but those (for example) needing audio
> > description of video are left without even a guideline as to how it
> > should be enabled?
> >
> > Finally, what happens to option (2) when the menus on a system are
> > enabled some other way than pressing a menu button on a remote?
> >
> > So, trying again, I'd like to *broaden* the scope of the *mandate*
> > while leaving product design only recommended:
> >
> > * * * * *
> >
> > For all accessibility options, including but not limited to
> Captions,
> > and Audio Description of Video [or whatever the term we settled on
> > is], the enabling and disabling of that accessibility
> option must also
> > be readily accessible to those desiring it, meaning that
> the control
> > must both be easy to find, and easily used by someone needing it.
> >
> > For captions, recommended approaches include:
> > 1. A caption on/off button on the TV remote control; 2. Caption
> > control(s) on the first menu that appears when on-screen menus are
> > displayed;
>
>
> - Larry
>
>
>
>

From: Greg Fields
Date: Thu, Oct 11 2007 9:05 AM
Subject: Re: Tomorrow's conf call

This looks good.
GregF


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
Sent: Thursday, October 11, 2007 10:01 AM
To: TEITAC Audio/Video Subcommittee; 'Dave Singer'; 'Al Sonnenstrahl';
= EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-video] Tomorrow's conf call

That wouldn't work in the context of 1.2A, which is a general provision;
so referring to volume or channel changing controls wouldn't make sense
for all products and it loses the sense of David's idea that the means
to activate an accessibility feature must be operable by the person that
needs that feature.

The specific case of raising the prominence of a caption control really
is outside of the scope of the provision itself, just as we don't have
any specifics on the form of volume controls on phones, or contrast
controls in software or on a display - so it does need to be an example.

How about:
1.2-A - Accessibility Configuration
In complying with this subpart, each agency must activate accessibility
features and configure products so that they are accessible to and
usable by
people with disabilities, and the means to activate the accessibility
features and configure products is accessible to those that need those
features and
comparable in prominence to similar configuration mechanisms for general
operation.

For example:
1. A caption on/off on a TV remote comparable in prominence to the
volume
control on that remote;
2. A gain wheel or slider on a telephone receiver handset;
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable
from
a login screen.

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 Gregg
Vanderheiden
Sent: 11 October 2007 07:19
To: 'TEITAC Audio/Video Subcommittee'; 'Dave Singer'; 'Al Sonnenstrahl';
= EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-video] Tomorrow's conf call

This is good but the examples will be dropped and the rest is pretty
vague.
I would see the current menu's as being described as 'discoverable'.
Even
with the examples - one can argue that current menus are discoverable.
How
about just moving the one phrase up to the provision.



1.2-A - Accessibility Configuration
In complying with this subpart, each agency must activate accessibility
features and configure products so that they are accessible to and
usable by
people with disabilities such that the means to activate the
accessibility
features and configure products is comparable in prominence to the
volume or
channel changing controls.

For example:
1. A caption on/off on a TV remote comparable in prominence to the
volume
control on that remote;
2. A gain wheel or slider on a telephone receiver handset;
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable
from
a login screen.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
> Sent: Wednesday, October 10, 2007 2:50 PM
> To: TEITAC Audio/Video Subcommittee; Dave Singer; Al
> Sonnenstrahl; = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-video] Tomorrow's conf call
>
> Here is the text I was working on, I've attached four
> examples, if anyone thinks we need more then please suggest them
>
>
> I suggest a modification of the existing provision 1.2 A to
> allow for the requirement that the means to set up a feature
> be accessible to the person that needs it, as follows;
>
> 1.2-A - Accessibility Configuration
> In complying with this subpart, each agency must activate
> accessibility features and configure products so that they
> are accessible to and usable by people with disabilities. The
> means to activate the accessibility features and configure
> products must be accessible, discoverable and usable by those
> desiring the feature.
>
> For example:
> 1. A caption on/off on a TV remote comparable in prominence
> to the volume control on that remote; 2. A gain wheel or
> slider on a telephone receiver handset; 3. A tactile button
> to turn on audio equivalents; 4. A user preferences dialog
> that is accessible and directly reachable from a login screen.
>
>
> 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
> Larry Goldberg
> Sent: 10 October 2007 16:30
> To: Dave Singer; TEITAC AV list; Al Sonnenstrahl;
> = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-video] Tomorrow's conf call
>
> Dave's suggestion regarding a more generic, but strong,
> requirement for the accessibility and usability of access
> controls bears serious consideration.
> Let's do so at today's conference call.
>
> ... Larry ...
>
>
> Dave Singer wrote:
>
> > At 15:31 -0400 9/10/07, Larry Goldberg wrote:
> >>
> >> We will discuss today's Plenary meeting/conference call, suggested
> >> changes to the enclosed draft, and hopefully come to a conclusion
> >> regarding the "caption button"/"top-level menu" proposal.
> >
> > As worded, I really don't think I can -- or we should -- agree to
> > these, unless they are restricted to 'classical analog television'.
> > They are both making into mandates a question of the design of the
> > system.
> >
> > The furthest we should go in this direction is a
> recommendation. We
> > simply do not know how to design these products, and inserting a
> > design mandate may well have a counter-productive effect:
> > manufacturers who were willing to meet the spirit of the
> regulations,
> > and provide accessible equipment, may well not wish to meet
> the letter
> > of such a design mandate, and consequently (since they
> would no longer
> > be able to claim compliance) do nothing.
> >
> > I am also wondering why the people needing captions need to
> have this
> > explicit access method, but those (for example) needing audio
> > description of video are left without even a guideline as to how it
> > should be enabled?
> >
> > Finally, what happens to option (2) when the menus on a system are
> > enabled some other way than pressing a menu button on a remote?
> >
> > So, trying again, I'd like to *broaden* the scope of the *mandate*
> > while leaving product design only recommended:
> >
> > * * * * *
> >
> > For all accessibility options, including but not limited to
> Captions,
> > and Audio Description of Video [or whatever the term we settled on
> > is], the enabling and disabling of that accessibility
> option must also
> > be readily accessible to those desiring it, meaning that
> the control
> > must both be easy to find, and easily used by someone needing it.
> >
> > For captions, recommended approaches include:
> > 1. A caption on/off button on the TV remote control; 2. Caption
> > control(s) on the first menu that appears when on-screen menus are
> > displayed;
>
>
> - Larry
>
>
>
>

From: Karen Peltz Strauss
Date: Thu, Oct 11 2007 9:40 AM
Subject: Re: Tomorrow's conf call

Sean

In answer to this and your prior message, I do not have a problem with
offering a general, more generic provision for the guidelines as a whole,
but do think we need the section that I am proposing in the audio video
section, even if it is redundant in part. Otherwise it will get lost.
Also, I am afraid that the re-write below is a bit confusing because it
mixes two very different concepts - configuration/activation by the agency
and activation by individuals - in the same sentence.

The proposed TEITAC re-write does contain a full section on user interfaces
(currently section 3), so that would probably be the best place to add
something about user activation of controls, if it is needed to supplement
what that section already has.

Karen

----- Original Message -----
From: "Sean Hayes" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Audio/Video Subcommittee" < = EMAIL ADDRESS REMOVED = >; "'Dave
Singer'" < = EMAIL ADDRESS REMOVED = >; "'Al Sonnenstrahl'" < = EMAIL ADDRESS REMOVED = >;
< = EMAIL ADDRESS REMOVED = >; "'Toby R. Silver'" < = EMAIL ADDRESS REMOVED = >;
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, October 11, 2007 10:01 AM
Subject: Re: [teitac-video] Tomorrow's conf call


> That wouldn't work in the context of 1.2A, which is a general provision;
> so referring to volume or channel changing controls wouldn't make sense
> for all products and it loses the sense of David's idea that the means to
> activate an accessibility feature must be operable by the person that
> needs that feature.
>
> The specific case of raising the prominence of a caption control really
> is outside of the scope of the provision itself, just as we don't have any
> specifics on the form of volume controls on phones, or contrast controls
> in software or on a display - so it does need to be an example.
>
> How about:
> 1.2-A - Accessibility Configuration
> In complying with this subpart, each agency must activate accessibility
> features and configure products so that they are accessible to and usable
> by
> people with disabilities, and the means to activate the accessibility
> features and configure products is accessible to those that need those
> features and
> comparable in prominence to similar configuration mechanisms for general
> operation.
>
> For example:
> 1. A caption on/off on a TV remote comparable in prominence to the volume
> control on that remote;
> 2. A gain wheel or slider on a telephone receiver handset;
> 3. A tactile button to turn on audio equivalents;
> 4. A user preferences dialog that is accessible and directly reachable
> from
> a login screen.
>
> 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 Gregg
> Vanderheiden
> Sent: 11 October 2007 07:19
> To: 'TEITAC Audio/Video Subcommittee'; 'Dave Singer'; 'Al Sonnenstrahl';
> = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ;
> = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-video] Tomorrow's conf call
>
> This is good but the examples will be dropped and the rest is pretty
> vague.
> I would see the current menu's as being described as 'discoverable'.
> Even
> with the examples - one can argue that current menus are discoverable.
> How
> about just moving the one phrase up to the provision.
>
>
>
> 1.2-A - Accessibility Configuration
> In complying with this subpart, each agency must activate accessibility
> features and configure products so that they are accessible to and usable
> by
> people with disabilities such that the means to activate the accessibility
> features and configure products is comparable in prominence to the volume
> or
> channel changing controls.
>
> For example:
> 1. A caption on/off on a TV remote comparable in prominence to the volume
> control on that remote;
> 2. A gain wheel or slider on a telephone receiver handset;
> 3. A tactile button to turn on audio equivalents;
> 4. A user preferences dialog that is accessible and directly reachable
> from
> a login screen.
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
>> Sent: Wednesday, October 10, 2007 2:50 PM
>> To: TEITAC Audio/Video Subcommittee; Dave Singer; Al
>> Sonnenstrahl; = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>> Subject: Re: [teitac-video] Tomorrow's conf call
>>
>> Here is the text I was working on, I've attached four
>> examples, if anyone thinks we need more then please suggest them
>>
>>
>> I suggest a modification of the existing provision 1.2 A to
>> allow for the requirement that the means to set up a feature
>> be accessible to the person that needs it, as follows;
>>
>> 1.2-A - Accessibility Configuration
>> In complying with this subpart, each agency must activate
>> accessibility features and configure products so that they
>> are accessible to and usable by people with disabilities. The
>> means to activate the accessibility features and configure
>> products must be accessible, discoverable and usable by those
>> desiring the feature.
>>
>> For example:
>> 1. A caption on/off on a TV remote comparable in prominence
>> to the volume control on that remote; 2. A gain wheel or
>> slider on a telephone receiver handset; 3. A tactile button
>> to turn on audio equivalents; 4. A user preferences dialog
>> that is accessible and directly reachable from a login screen.
>>
>>
>> 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
>> Larry Goldberg
>> Sent: 10 October 2007 16:30
>> To: Dave Singer; TEITAC AV list; Al Sonnenstrahl;
>> = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>> Subject: Re: [teitac-video] Tomorrow's conf call
>>
>> Dave's suggestion regarding a more generic, but strong,
>> requirement for the accessibility and usability of access
>> controls bears serious consideration.
>> Let's do so at today's conference call.
>>
>> ... Larry ...
>>
>>
>> Dave Singer wrote:
>>
>> > At 15:31 -0400 9/10/07, Larry Goldberg wrote:
>> >>
>> >> We will discuss today's Plenary meeting/conference call, suggested
>> >> changes to the enclosed draft, and hopefully come to a conclusion
>> >> regarding the "caption button"/"top-level menu" proposal.
>> >
>> > As worded, I really don't think I can -- or we should -- agree to
>> > these, unless they are restricted to 'classical analog television'.
>> > They are both making into mandates a question of the design of the
>> > system.
>> >
>> > The furthest we should go in this direction is a
>> recommendation. We
>> > simply do not know how to design these products, and inserting a
>> > design mandate may well have a counter-productive effect:
>> > manufacturers who were willing to meet the spirit of the
>> regulations,
>> > and provide accessible equipment, may well not wish to meet
>> the letter
>> > of such a design mandate, and consequently (since they
>> would no longer
>> > be able to claim compliance) do nothing.
>> >
>> > I am also wondering why the people needing captions need to
>> have this
>> > explicit access method, but those (for example) needing audio
>> > description of video are left without even a guideline as to how it
>> > should be enabled?
>> >
>> > Finally, what happens to option (2) when the menus on a system are
>> > enabled some other way than pressing a menu button on a remote?
>> >
>> > So, trying again, I'd like to *broaden* the scope of the *mandate*
>> > while leaving product design only recommended:
>> >
>> > * * * * *
>> >
>> > For all accessibility options, including but not limited to
>> Captions,
>> > and Audio Description of Video [or whatever the term we settled on
>> > is], the enabling and disabling of that accessibility
>> option must also
>> > be readily accessible to those desiring it, meaning that
>> the control
>> > must both be easy to find, and easily used by someone needing it.
>> >
>> > For captions, recommended approaches include:
>> > 1. A caption on/off button on the TV remote control; 2. Caption
>> > control(s) on the first menu that appears when on-screen menus are
>> > displayed;
>>
>>
>> - Larry
>>
>>
>>
>>

From: Greg Fields
Date: Thu, Oct 11 2007 10:50 AM
Subject: Re: Tomorrow's conf call

User activation of controls is already defined and covered as follows:

Operable Controls
Any physical control that affects the operation of the product. Operable
controls include, but are not limited to, mechanically operated
controls, input and output trays, card slots, keyboards, keypads, keys,
or buttons, including touch-screens.

Provisions
2.1-C Mechanical Controls
2.1-D Touch Operated Controls
2.1-F Installed or Free-Standing Products
3.P User Interface Components
3.S Keyboard Operation
7.1-C.3 User Interface Descriptions

The definition and abovementioned provisions do encompass user
activation, expected reach range and documentation requirements for
physical/virtual controls that "affect the operation of the product".

Karen - can you clarify how you see "user controls on video programming
products" as different than "any control that affects the operation of
the product"?

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Karen Peltz
Strauss
Sent: Thursday, October 11, 2007 11:37 AM
To: TEITAC Audio/Video Subcommittee; 'Dave Singer'; 'Al Sonnenstrahl';
= EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-video] Tomorrow's conf call

Sean

In answer to this and your prior message, I do not have a problem with
offering a general, more generic provision for the guidelines as a
whole,
but do think we need the section that I am proposing in the audio video
section, even if it is redundant in part. Otherwise it will get lost.
Also, I am afraid that the re-write below is a bit confusing because it
mixes two very different concepts - configuration/activation by the
agency
and activation by individuals - in the same sentence.

The proposed TEITAC re-write does contain a full section on user
interfaces
(currently section 3), so that would probably be the best place to add
something about user activation of controls, if it is needed to
supplement
what that section already has.

Karen

----- Original Message -----
From: "Sean Hayes" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Audio/Video Subcommittee" < = EMAIL ADDRESS REMOVED = >;
"'Dave
Singer'" < = EMAIL ADDRESS REMOVED = >; "'Al Sonnenstrahl'" < = EMAIL ADDRESS REMOVED = >;
< = EMAIL ADDRESS REMOVED = >; "'Toby R. Silver'" < = EMAIL ADDRESS REMOVED = >;
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, October 11, 2007 10:01 AM
Subject: Re: [teitac-video] Tomorrow's conf call


> That wouldn't work in the context of 1.2A, which is a general
provision;
> so referring to volume or channel changing controls wouldn't make
sense
> for all products and it loses the sense of David's idea that the means
to
> activate an accessibility feature must be operable by the person that
> needs that feature.
>
> The specific case of raising the prominence of a caption control
really
> is outside of the scope of the provision itself, just as we don't have
any
> specifics on the form of volume controls on phones, or contrast
controls
> in software or on a display - so it does need to be an example.
>
> How about:
> 1.2-A - Accessibility Configuration
> In complying with this subpart, each agency must activate
accessibility
> features and configure products so that they are accessible to and
usable
> by
> people with disabilities, and the means to activate the accessibility
> features and configure products is accessible to those that need those

> features and
> comparable in prominence to similar configuration mechanisms for
general
> operation.
>
> For example:
> 1. A caption on/off on a TV remote comparable in prominence to the
volume
> control on that remote;
> 2. A gain wheel or slider on a telephone receiver handset;
> 3. A tactile button to turn on audio equivalents;
> 4. A user preferences dialog that is accessible and directly reachable

> from
> a login screen.
>
> 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 Gregg
> Vanderheiden
> Sent: 11 October 2007 07:19
> To: 'TEITAC Audio/Video Subcommittee'; 'Dave Singer'; 'Al
Sonnenstrahl';
> = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ;
> = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-video] Tomorrow's conf call
>
> This is good but the examples will be dropped and the rest is pretty
> vague.
> I would see the current menu's as being described as 'discoverable'.
> Even
> with the examples - one can argue that current menus are discoverable.

> How
> about just moving the one phrase up to the provision.
>
>
>
> 1.2-A - Accessibility Configuration
> In complying with this subpart, each agency must activate
accessibility
> features and configure products so that they are accessible to and
usable
> by
> people with disabilities such that the means to activate the
accessibility
> features and configure products is comparable in prominence to the
volume
> or
> channel changing controls.
>
> For example:
> 1. A caption on/off on a TV remote comparable in prominence to the
volume
> control on that remote;
> 2. A gain wheel or slider on a telephone receiver handset;
> 3. A tactile button to turn on audio equivalents;
> 4. A user preferences dialog that is accessible and directly reachable

> from
> a login screen.
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
>> Sent: Wednesday, October 10, 2007 2:50 PM
>> To: TEITAC Audio/Video Subcommittee; Dave Singer; Al
>> Sonnenstrahl; = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>> Subject: Re: [teitac-video] Tomorrow's conf call
>>
>> Here is the text I was working on, I've attached four
>> examples, if anyone thinks we need more then please suggest them
>>
>>
>> I suggest a modification of the existing provision 1.2 A to
>> allow for the requirement that the means to set up a feature
>> be accessible to the person that needs it, as follows;
>>
>> 1.2-A - Accessibility Configuration
>> In complying with this subpart, each agency must activate
>> accessibility features and configure products so that they
>> are accessible to and usable by people with disabilities. The
>> means to activate the accessibility features and configure
>> products must be accessible, discoverable and usable by those
>> desiring the feature.
>>
>> For example:
>> 1. A caption on/off on a TV remote comparable in prominence
>> to the volume control on that remote; 2. A gain wheel or
>> slider on a telephone receiver handset; 3. A tactile button
>> to turn on audio equivalents; 4. A user preferences dialog
>> that is accessible and directly reachable from a login screen.
>>
>>
>> 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
>> Larry Goldberg
>> Sent: 10 October 2007 16:30
>> To: Dave Singer; TEITAC AV list; Al Sonnenstrahl;
>> = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>> Subject: Re: [teitac-video] Tomorrow's conf call
>>
>> Dave's suggestion regarding a more generic, but strong,
>> requirement for the accessibility and usability of access
>> controls bears serious consideration.
>> Let's do so at today's conference call.
>>
>> ... Larry ...
>>
>>
>> Dave Singer wrote:
>>
>> > At 15:31 -0400 9/10/07, Larry Goldberg wrote:
>> >>
>> >> We will discuss today's Plenary meeting/conference call, suggested
>> >> changes to the enclosed draft, and hopefully come to a conclusion
>> >> regarding the "caption button"/"top-level menu" proposal.
>> >
>> > As worded, I really don't think I can -- or we should -- agree to
>> > these, unless they are restricted to 'classical analog television'.
>> > They are both making into mandates a question of the design of the
>> > system.
>> >
>> > The furthest we should go in this direction is a
>> recommendation. We
>> > simply do not know how to design these products, and inserting a
>> > design mandate may well have a counter-productive effect:
>> > manufacturers who were willing to meet the spirit of the
>> regulations,
>> > and provide accessible equipment, may well not wish to meet
>> the letter
>> > of such a design mandate, and consequently (since they
>> would no longer
>> > be able to claim compliance) do nothing.
>> >
>> > I am also wondering why the people needing captions need to
>> have this
>> > explicit access method, but those (for example) needing audio
>> > description of video are left without even a guideline as to how it
>> > should be enabled?
>> >
>> > Finally, what happens to option (2) when the menus on a system are
>> > enabled some other way than pressing a menu button on a remote?
>> >
>> > So, trying again, I'd like to *broaden* the scope of the *mandate*
>> > while leaving product design only recommended:
>> >
>> > * * * * *
>> >
>> > For all accessibility options, including but not limited to
>> Captions,
>> > and Audio Description of Video [or whatever the term we settled on
>> > is], the enabling and disabling of that accessibility
>> option must also
>> > be readily accessible to those desiring it, meaning that
>> the control
>> > must both be easy to find, and easily used by someone needing it.
>> >
>> > For captions, recommended approaches include:
>> > 1. A caption on/off button on the TV remote control; 2. Caption
>> > control(s) on the first menu that appears when on-screen menus are
>> > displayed;
>>
>>
>> - Larry
>>
>>
>>
>>

From: Dave Singer
Date: Thu, Oct 11 2007 12:20 PM
Subject: Re: Tomorrow's conf call

There is a small snag here: you ask for the controls to be
accessible to people with (unspecified) disabilities, which is too
broad, I believe (and untestable). I also have been told that I
should shy away from describing people who need accessibility as
having disabilities. That's why my original text said that the means
to enable an accessibility option must be accessible to those needing
that option; that's a more focused, testable, requirement. (e.g.
you fail if you provide visual menus for those needing visual
accessibility, or voice-activated menus for those with audio
accessibility needs).

The issue that the 'activate' is used with two senses is also
addressed here (using 'enable' the feature by the agency).

How about:

1.2-A - Accessibility Configuration
In complying with this subpart, each agency must enable and configure
the accessibility features of products, so that the products and the
media they present are accessible to and usable by people needing
accessible access, and the means to activate any accessibility
feature must be accessible to those that need each feature, and
comparable in prominence to similar configuration mechanisms for
general operation.

For example:
1. A caption on/off on a TV remote comparable in prominence to the volume
control on that remote;
2. A gain wheel or slider on a telephone receiver handset;
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 15:01 +0100 11/10/07, Sean Hayes wrote:
>That wouldn't work in the context of 1.2A, which is a general
>provision; so referring to volume or channel changing controls
>wouldn't make sense for all products and it loses the sense of
>David's idea that the means to activate an accessibility feature
>must be operable by the person that needs that feature.
>
>The specific case of raising the prominence of a caption control
>really is outside of the scope of the provision itself, just as we
>don't have any specifics on the form of volume controls on phones,
>or contrast controls in software or on a display - so it does need
>to be an example.
>
>How about:
>1.2-A - Accessibility Configuration
>In complying with this subpart, each agency must activate accessibility
>features and configure products so that they are accessible to and usable by
>people with disabilities, and the means to activate the accessibility
>features and configure products is accessible to those that need
>those features and
>comparable in prominence to similar configuration mechanisms for
>general operation.
>
>For example:
>1. A caption on/off on a TV remote comparable in prominence to the volume
>control on that remote;
>2. A gain wheel or slider on a telephone receiver handset;
>3. A tactile button to turn on audio equivalents;
>4. A user preferences dialog that is accessible and directly reachable from
>a login screen.
>
>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 Gregg
>Vanderheiden
>Sent: 11 October 2007 07:19
>To: 'TEITAC Audio/Video Subcommittee'; 'Dave Singer'; 'Al
>Sonnenstrahl'; = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver';
> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>Subject: Re: [teitac-video] Tomorrow's conf call
>
>This is good but the examples will be dropped and the rest is pretty vague.
>I would see the current menu's as being described as 'discoverable'. Even
>with the examples - one can argue that current menus are discoverable. How
>about just moving the one phrase up to the provision.
>
>
>
>1.2-A - Accessibility Configuration
>In complying with this subpart, each agency must activate accessibility
>features and configure products so that they are accessible to and usable by
>people with disabilities such that the means to activate the accessibility
>features and configure products is comparable in prominence to the volume or
>channel changing controls.
>
>For example:
>1. A caption on/off on a TV remote comparable in prominence to the volume
>control on that remote;
>2. A gain wheel or slider on a telephone receiver handset;
>3. A tactile button to turn on audio equivalents;
>4. A user preferences dialog that is accessible and directly reachable from
>a login screen.
>
>
>
>Gregg
> -- ------------------------------
>Gregg C Vanderheiden Ph.D.
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
>> Sent: Wednesday, October 10, 2007 2:50 PM
>> To: TEITAC Audio/Video Subcommittee; Dave Singer; Al
>> Sonnenstrahl; = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>> Subject: Re: [teitac-video] Tomorrow's conf call
>>
>> Here is the text I was working on, I've attached four
>> examples, if anyone thinks we need more then please suggest them
>>
>>
>> I suggest a modification of the existing provision 1.2 A to
>> allow for the requirement that the means to set up a feature
> > be accessible to the person that needs it, as follows;
>>
>> 1.2-A - Accessibility Configuration
>> In complying with this subpart, each agency must activate
>> accessibility features and configure products so that they
>> are accessible to and usable by people with disabilities. The
>> means to activate the accessibility features and configure
>> products must be accessible, discoverable and usable by those
>> desiring the feature.
>>
>> For example:
>> 1. A caption on/off on a TV remote comparable in prominence
>> to the volume control on that remote; 2. A gain wheel or
>> slider on a telephone receiver handset; 3. A tactile button
>> to turn on audio equivalents; 4. A user preferences dialog
>> that is accessible and directly reachable from a login screen.
>>
>>
>> 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
>> Larry Goldberg
>> Sent: 10 October 2007 16:30
>> To: Dave Singer; TEITAC AV list; Al Sonnenstrahl;
>> = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>> Subject: Re: [teitac-video] Tomorrow's conf call
>>
>> Dave's suggestion regarding a more generic, but strong,
>> requirement for the accessibility and usability of access
>> controls bears serious consideration.
>> Let's do so at today's conference call.
>>
>> ... Larry ...
>>
>>
>> Dave Singer wrote:
>>
>> > At 15:31 -0400 9/10/07, Larry Goldberg wrote:
>> >>
>> >> We will discuss today's Plenary meeting/conference call, suggested
>> >> changes to the enclosed draft, and hopefully come to a conclusion
>> >> regarding the "caption button"/"top-level menu" proposal.
>> >
>> > As worded, I really don't think I can -- or we should -- agree to
>> > these, unless they are restricted to 'classical analog television'.
>> > They are both making into mandates a question of the design of the
>> > system.
>> >
>> > The furthest we should go in this direction is a
>> recommendation. We
>> > simply do not know how to design these products, and inserting a
>> > design mandate may well have a counter-productive effect:
>> > manufacturers who were willing to meet the spirit of the
>> regulations,
>> > and provide accessible equipment, may well not wish to meet
>> the letter
>> > of such a design mandate, and consequently (since they
>> would no longer
>> > be able to claim compliance) do nothing.
>> >
>> > I am also wondering why the people needing captions need to
>> have this
>> > explicit access method, but those (for example) needing audio
>> > description of video are left without even a guideline as to how it
> > > should be enabled?
>> >
>> > Finally, what happens to option (2) when the menus on a system are
>> > enabled some other way than pressing a menu button on a remote?
>> >
>> > So, trying again, I'd like to *broaden* the scope of the *mandate*
>> > while leaving product design only recommended:
>> >
>> > * * * * *
>> >
>> > For all accessibility options, including but not limited to
>> Captions,
>> > and Audio Description of Video [or whatever the term we settled on
>> > is], the enabling and disabling of that accessibility
>> option must also
>> > be readily accessible to those desiring it, meaning that
>> the control
>> > must both be easy to find, and easily used by someone needing it.
>> >
>> > For captions, recommended approaches include:
>> > 1. A caption on/off button on the TV remote control; 2. Caption
>> > control(s) on the first menu that appears when on-screen menus are
>> > displayed;
>>
>>
>> - Larry
>>
>>
>>
>>

From: Sean Hayes
Date: Thu, Oct 11 2007 12:35 PM
Subject: Re: Tomorrow's conf call

While I agree with you, the people with disabilities language is pre-extant in 2.1A. The new language I was proposing is from ", and the means to...".

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 Dave Singer
Sent: 11 October 2007 19:14
To: Sean Hayes; TEITAC Audio/Video Subcommittee; 'Al Sonnenstrahl'; = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-video] Tomorrow's conf call

There is a small snag here: you ask for the controls to be
accessible to people with (unspecified) disabilities, which is too
broad, I believe (and untestable). I also have been told that I
should shy away from describing people who need accessibility as
having disabilities. That's why my original text said that the means
to enable an accessibility option must be accessible to those needing
that option; that's a more focused, testable, requirement. (e.g.
you fail if you provide visual menus for those needing visual
accessibility, or voice-activated menus for those with audio
accessibility needs).

The issue that the 'activate' is used with two senses is also
addressed here (using 'enable' the feature by the agency).

How about:

1.2-A - Accessibility Configuration
In complying with this subpart, each agency must enable and configure
the accessibility features of products, so that the products and the
media they present are accessible to and usable by people needing
accessible access, and the means to activate any accessibility
feature must be accessible to those that need each feature, and
comparable in prominence to similar configuration mechanisms for
general operation.

For example:
1. A caption on/off on a TV remote comparable in prominence to the volume
control on that remote;
2. A gain wheel or slider on a telephone receiver handset;
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 15:01 +0100 11/10/07, Sean Hayes wrote:
>That wouldn't work in the context of 1.2A, which is a general
>provision; so referring to volume or channel changing controls
>wouldn't make sense for all products and it loses the sense of
>David's idea that the means to activate an accessibility feature
>must be operable by the person that needs that feature.
>
>The specific case of raising the prominence of a caption control
>really is outside of the scope of the provision itself, just as we
>don't have any specifics on the form of volume controls on phones,
>or contrast controls in software or on a display - so it does need
>to be an example.
>
>How about:
>1.2-A - Accessibility Configuration
>In complying with this subpart, each agency must activate accessibility
>features and configure products so that they are accessible to and usable by
>people with disabilities, and the means to activate the accessibility
>features and configure products is accessible to those that need
>those features and
>comparable in prominence to similar configuration mechanisms for
>general operation.
>
>For example:
>1. A caption on/off on a TV remote comparable in prominence to the volume
>control on that remote;
>2. A gain wheel or slider on a telephone receiver handset;
>3. A tactile button to turn on audio equivalents;
>4. A user preferences dialog that is accessible and directly reachable from
>a login screen.
>
>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 Gregg
>Vanderheiden
>Sent: 11 October 2007 07:19
>To: 'TEITAC Audio/Video Subcommittee'; 'Dave Singer'; 'Al
>Sonnenstrahl'; = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver';
> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>Subject: Re: [teitac-video] Tomorrow's conf call
>
>This is good but the examples will be dropped and the rest is pretty vague.
>I would see the current menu's as being described as 'discoverable'. Even
>with the examples - one can argue that current menus are discoverable. How
>about just moving the one phrase up to the provision.
>
>
>
>1.2-A - Accessibility Configuration
>In complying with this subpart, each agency must activate accessibility
>features and configure products so that they are accessible to and usable by
>people with disabilities such that the means to activate the accessibility
>features and configure products is comparable in prominence to the volume or
>channel changing controls.
>
>For example:
>1. A caption on/off on a TV remote comparable in prominence to the volume
>control on that remote;
>2. A gain wheel or slider on a telephone receiver handset;
>3. A tactile button to turn on audio equivalents;
>4. A user preferences dialog that is accessible and directly reachable from
>a login screen.
>
>
>
>Gregg
> -- ------------------------------
>Gregg C Vanderheiden Ph.D.
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
>> Sent: Wednesday, October 10, 2007 2:50 PM
>> To: TEITAC Audio/Video Subcommittee; Dave Singer; Al
>> Sonnenstrahl; = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>> Subject: Re: [teitac-video] Tomorrow's conf call
>>
>> Here is the text I was working on, I've attached four
>> examples, if anyone thinks we need more then please suggest them
>>
>>
>> I suggest a modification of the existing provision 1.2 A to
>> allow for the requirement that the means to set up a feature
> > be accessible to the person that needs it, as follows;
>>
>> 1.2-A - Accessibility Configuration
>> In complying with this subpart, each agency must activate
>> accessibility features and configure products so that they
>> are accessible to and usable by people with disabilities. The
>> means to activate the accessibility features and configure
>> products must be accessible, discoverable and usable by those
>> desiring the feature.
>>
>> For example:
>> 1. A caption on/off on a TV remote comparable in prominence
>> to the volume control on that remote; 2. A gain wheel or
>> slider on a telephone receiver handset; 3. A tactile button
>> to turn on audio equivalents; 4. A user preferences dialog
>> that is accessible and directly reachable from a login screen.
>>
>>
>> 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
>> Larry Goldberg
>> Sent: 10 October 2007 16:30
>> To: Dave Singer; TEITAC AV list; Al Sonnenstrahl;
>> = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>> Subject: Re: [teitac-video] Tomorrow's conf call
>>
>> Dave's suggestion regarding a more generic, but strong,
>> requirement for the accessibility and usability of access
>> controls bears serious consideration.
>> Let's do so at today's conference call.
>>
>> ... Larry ...
>>
>>
>> Dave Singer wrote:
>>
>> > At 15:31 -0400 9/10/07, Larry Goldberg wrote:
>> >>
>> >> We will discuss today's Plenary meeting/conference call, suggested
>> >> changes to the enclosed draft, and hopefully come to a conclusion
>> >> regarding the "caption button"/"top-level menu" proposal.
>> >
>> > As worded, I really don't think I can -- or we should -- agree to
>> > these, unless they are restricted to 'classical analog television'.
>> > They are both making into mandates a question of the design of the
>> > system.
>> >
>> > The furthest we should go in this direction is a
>> recommendation. We
>> > simply do not know how to design these products, and inserting a
>> > design mandate may well have a counter-productive effect:
>> > manufacturers who were willing to meet the spirit of the
>> regulations,
>> > and provide accessible equipment, may well not wish to meet
>> the letter
>> > of such a design mandate, and consequently (since they
>> would no longer
>> > be able to claim compliance) do nothing.
>> >
>> > I am also wondering why the people needing captions need to
>> have this
>> > explicit access method, but those (for example) needing audio
>> > description of video are left without even a guideline as to how it
> > > should be enabled?
>> >
>> > Finally, what happens to option (2) when the menus on a system are
>> > enabled some other way than pressing a menu button on a remote?
>> >
>> > So, trying again, I'd like to *broaden* the scope of the *mandate*
>> > while leaving product design only recommended:
>> >
>> > * * * * *
>> >
>> > For all accessibility options, including but not limited to
>> Captions,
>> > and Audio Description of Video [or whatever the term we settled on
>> > is], the enabling and disabling of that accessibility
>> option must also
>> > be readily accessible to those desiring it, meaning that
>> the control
>> > must both be easy to find, and easily used by someone needing it.
>> >
>> > For captions, recommended approaches include:
>> > 1. A caption on/off button on the TV remote control; 2. Caption
>> > control(s) on the first menu that appears when on-screen menus are
>> > displayed;
>>
>>
>> - Larry
>>
>>
>>
>>

From: Larry Goldberg
Date: Thu, Oct 11 2007 12:45 PM
Subject: Re: Tomorrow's conf call

The problem with such a requirement of "each agency must enable and
configure" is that without the capacity built into the hardware, the
agencies have no ability to follow this requirement. Does the purchasing
agent have to reconfigure the menus on a DTV they buy?

It really has to be built in somehow so that any government employee or
taxpaying recipient of government information can access the controls
independently - and certainly without having to ask for direct help from the
procuring agency.

... Larry ...


Dave Singer wrote:

> There is a small snag here: you ask for the controls to be
> accessible to people with (unspecified) disabilities, which is too
> broad, I believe (and untestable). I also have been told that I
> should shy away from describing people who need accessibility as
> having disabilities. That's why my original text said that the means
> to enable an accessibility option must be accessible to those needing
> that option; that's a more focused, testable, requirement. (e.g.
> you fail if you provide visual menus for those needing visual
> accessibility, or voice-activated menus for those with audio
> accessibility needs).
>
> The issue that the 'activate' is used with two senses is also
> addressed here (using 'enable' the feature by the agency).
>
> How about:
>
> 1.2-A - Accessibility Configuration
> In complying with this subpart, each agency must enable and configure
> the accessibility features of products, so that the products and the
> media they present are accessible to and usable by people needing
> accessible access, and the means to activate any accessibility
> feature must be accessible to those that need each feature, and
> comparable in prominence to similar configuration mechanisms for
> general operation.
>
> For example:
> 1. A caption on/off on a TV remote comparable in prominence to the volume
> control on that remote;
> 2. A gain wheel or slider on a telephone receiver handset;
> 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 15:01 +0100 11/10/07, Sean Hayes wrote:
>> That wouldn't work in the context of 1.2A, which is a general
>> provision; so referring to volume or channel changing controls
>> wouldn't make sense for all products and it loses the sense of
>> David's idea that the means to activate an accessibility feature
>> must be operable by the person that needs that feature.
>>
>> The specific case of raising the prominence of a caption control
>> really is outside of the scope of the provision itself, just as we
>> don't have any specifics on the form of volume controls on phones,
>> or contrast controls in software or on a display - so it does need
>> to be an example.
>>
>> How about:
>> 1.2-A - Accessibility Configuration
>> In complying with this subpart, each agency must activate accessibility
>> features and configure products so that they are accessible to and usable by
>> people with disabilities, and the means to activate the accessibility
>> features and configure products is accessible to those that need
>> those features and
>> comparable in prominence to similar configuration mechanisms for
>> general operation.
>>
>> For example:
>> 1. A caption on/off on a TV remote comparable in prominence to the volume
>> control on that remote;
>> 2. A gain wheel or slider on a telephone receiver handset;
>> 3. A tactile button to turn on audio equivalents;
>> 4. A user preferences dialog that is accessible and directly reachable from
>> a login screen.
>>
>> 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 Gregg
>> Vanderheiden
>> Sent: 11 October 2007 07:19
>> To: 'TEITAC Audio/Video Subcommittee'; 'Dave Singer'; 'Al
>> Sonnenstrahl'; = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver';
>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>> Subject: Re: [teitac-video] Tomorrow's conf call
>>
>> This is good but the examples will be dropped and the rest is pretty vague.
>> I would see the current menu's as being described as 'discoverable'. Even
>> with the examples - one can argue that current menus are discoverable. How
>> about just moving the one phrase up to the provision.
>>
>>
>>
>> 1.2-A - Accessibility Configuration
>> In complying with this subpart, each agency must activate accessibility
>> features and configure products so that they are accessible to and usable by
>> people with disabilities such that the means to activate the accessibility
>> features and configure products is comparable in prominence to the volume or
>> channel changing controls.
>>
>> For example:
>> 1. A caption on/off on a TV remote comparable in prominence to the volume
>> control on that remote;
>> 2. A gain wheel or slider on a telephone receiver handset;
>> 3. A tactile button to turn on audio equivalents;
>> 4. A user preferences dialog that is accessible and directly reachable from
>> a login screen.
>>
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
>>> Sent: Wednesday, October 10, 2007 2:50 PM
>>> To: TEITAC Audio/Video Subcommittee; Dave Singer; Al
>>> Sonnenstrahl; = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>>> Subject: Re: [teitac-video] Tomorrow's conf call
>>>
>>> Here is the text I was working on, I've attached four
>>> examples, if anyone thinks we need more then please suggest them
>>>
>>>
>>> I suggest a modification of the existing provision 1.2 A to
>>> allow for the requirement that the means to set up a feature
>>> be accessible to the person that needs it, as follows;
>>>
>>> 1.2-A - Accessibility Configuration
>>> In complying with this subpart, each agency must activate
>>> accessibility features and configure products so that they
>>> are accessible to and usable by people with disabilities. The
>>> means to activate the accessibility features and configure
>>> products must be accessible, discoverable and usable by those
>>> desiring the feature.
>>>
>>> For example:
>>> 1. A caption on/off on a TV remote comparable in prominence
>>> to the volume control on that remote; 2. A gain wheel or
>>> slider on a telephone receiver handset; 3. A tactile button
>>> to turn on audio equivalents; 4. A user preferences dialog
>>> that is accessible and directly reachable from a login screen.
>>>
>>>
>>> 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
>>> Larry Goldberg
>>> Sent: 10 October 2007 16:30
>>> To: Dave Singer; TEITAC AV list; Al Sonnenstrahl;
>>> = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>>> Subject: Re: [teitac-video] Tomorrow's conf call
>>>
>>> Dave's suggestion regarding a more generic, but strong,
>>> requirement for the accessibility and usability of access
>>> controls bears serious consideration.
>>> Let's do so at today's conference call.
>>>
>>> ... Larry ...
>>>
>>>
>>> Dave Singer wrote:
>>>
>>>> At 15:31 -0400 9/10/07, Larry Goldberg wrote:
>>>>>
>>>>> We will discuss today's Plenary meeting/conference call, suggested
>>>>> changes to the enclosed draft, and hopefully come to a conclusion
>>>>> regarding the "caption button"/"top-level menu" proposal.
>>>>
>>>> As worded, I really don't think I can -- or we should -- agree to
>>>> these, unless they are restricted to 'classical analog television'.
>>>> They are both making into mandates a question of the design of the
>>>> system.
>>>>
>>>> The furthest we should go in this direction is a
>>> recommendation. We
>>>> simply do not know how to design these products, and inserting a
>>>> design mandate may well have a counter-productive effect:
>>>> manufacturers who were willing to meet the spirit of the
>>> regulations,
>>>> and provide accessible equipment, may well not wish to meet
>>> the letter
>>>> of such a design mandate, and consequently (since they
>>> would no longer
>>>> be able to claim compliance) do nothing.
>>>>
>>>> I am also wondering why the people needing captions need to
>>> have this
>>>> explicit access method, but those (for example) needing audio
>>>> description of video are left without even a guideline as to how it
>>>> should be enabled?
>>>>
>>>> Finally, what happens to option (2) when the menus on a system are
>>>> enabled some other way than pressing a menu button on a remote?
>>>>
>>>> So, trying again, I'd like to *broaden* the scope of the *mandate*
>>>> while leaving product design only recommended:
>>>>
>>>> * * * * *
>>>>
>>>> For all accessibility options, including but not limited to
>>> Captions,
>>>> and Audio Description of Video [or whatever the term we settled on
>>>> is], the enabling and disabling of that accessibility
>>> option must also
>>>> be readily accessible to those desiring it, meaning that
>>> the control
>>>> must both be easy to find, and easily used by someone needing it.
>>>>
>>>> For captions, recommended approaches include:
>>>> 1. A caption on/off button on the TV remote control; 2. Caption
>>>> control(s) on the first menu that appears when on-screen menus are
>>>> displayed;
>>>
>>>
>>> - Larry
>>>
>>>
>>>
>>>

From: Karen Peltz Strauss
Date: Thu, Oct 11 2007 1:00 PM
Subject: Re: Tomorrow's conf call

Greg

I just saw this and think that I answered it in another e-mail - I actually
agree that a more general statement in these sections is ok, but again, feel
very strongly that we need something in the video programming section as
well.

Karen
----- Original Message -----
From: "Greg Fields" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Audio/Video Subcommittee" < = EMAIL ADDRESS REMOVED = >; "Dave
Singer" < = EMAIL ADDRESS REMOVED = >; "Al Sonnenstrahl" < = EMAIL ADDRESS REMOVED = >;
< = EMAIL ADDRESS REMOVED = >; "Toby R. Silver" < = EMAIL ADDRESS REMOVED = >;
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, October 11, 2007 12:45 PM
Subject: Re: [teitac-video] Tomorrow's conf call


> User activation of controls is already defined and covered as follows:
>
> Operable Controls
> Any physical control that affects the operation of the product. Operable
> controls include, but are not limited to, mechanically operated
> controls, input and output trays, card slots, keyboards, keypads, keys,
> or buttons, including touch-screens.
>
> Provisions
> 2.1-C Mechanical Controls
> 2.1-D Touch Operated Controls
> 2.1-F Installed or Free-Standing Products
> 3.P User Interface Components
> 3.S Keyboard Operation
> 7.1-C.3 User Interface Descriptions
>
> The definition and abovementioned provisions do encompass user
> activation, expected reach range and documentation requirements for
> physical/virtual controls that "affect the operation of the product".
>
> Karen - can you clarify how you see "user controls on video programming
> products" as different than "any control that affects the operation of
> the product"?
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Karen Peltz
> Strauss
> Sent: Thursday, October 11, 2007 11:37 AM
> To: TEITAC Audio/Video Subcommittee; 'Dave Singer'; 'Al Sonnenstrahl';
> = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ;
> = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-video] Tomorrow's conf call
>
> Sean
>
> In answer to this and your prior message, I do not have a problem with
> offering a general, more generic provision for the guidelines as a
> whole,
> but do think we need the section that I am proposing in the audio video
> section, even if it is redundant in part. Otherwise it will get lost.
> Also, I am afraid that the re-write below is a bit confusing because it
> mixes two very different concepts - configuration/activation by the
> agency
> and activation by individuals - in the same sentence.
>
> The proposed TEITAC re-write does contain a full section on user
> interfaces
> (currently section 3), so that would probably be the best place to add
> something about user activation of controls, if it is needed to
> supplement
> what that section already has.
>
> Karen
>
> ----- Original Message -----
> From: "Sean Hayes" < = EMAIL ADDRESS REMOVED = >
> To: "TEITAC Audio/Video Subcommittee" < = EMAIL ADDRESS REMOVED = >;
> "'Dave
> Singer'" < = EMAIL ADDRESS REMOVED = >; "'Al Sonnenstrahl'" < = EMAIL ADDRESS REMOVED = >;
> < = EMAIL ADDRESS REMOVED = >; "'Toby R. Silver'" < = EMAIL ADDRESS REMOVED = >;
> < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday, October 11, 2007 10:01 AM
> Subject: Re: [teitac-video] Tomorrow's conf call
>
>
>> That wouldn't work in the context of 1.2A, which is a general
> provision;
>> so referring to volume or channel changing controls wouldn't make
> sense
>> for all products and it loses the sense of David's idea that the means
> to
>> activate an accessibility feature must be operable by the person that
>> needs that feature.
>>
>> The specific case of raising the prominence of a caption control
> really
>> is outside of the scope of the provision itself, just as we don't have
> any
>> specifics on the form of volume controls on phones, or contrast
> controls
>> in software or on a display - so it does need to be an example.
>>
>> How about:
>> 1.2-A - Accessibility Configuration
>> In complying with this subpart, each agency must activate
> accessibility
>> features and configure products so that they are accessible to and
> usable
>> by
>> people with disabilities, and the means to activate the accessibility
>> features and configure products is accessible to those that need those
>
>> features and
>> comparable in prominence to similar configuration mechanisms for
> general
>> operation.
>>
>> For example:
>> 1. A caption on/off on a TV remote comparable in prominence to the
> volume
>> control on that remote;
>> 2. A gain wheel or slider on a telephone receiver handset;
>> 3. A tactile button to turn on audio equivalents;
>> 4. A user preferences dialog that is accessible and directly reachable
>
>> from
>> a login screen.
>>
>> 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 Gregg
>> Vanderheiden
>> Sent: 11 October 2007 07:19
>> To: 'TEITAC Audio/Video Subcommittee'; 'Dave Singer'; 'Al
> Sonnenstrahl';
>> = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver'; = EMAIL ADDRESS REMOVED = ;
>> = EMAIL ADDRESS REMOVED =
>> Subject: Re: [teitac-video] Tomorrow's conf call
>>
>> This is good but the examples will be dropped and the rest is pretty
>> vague.
>> I would see the current menu's as being described as 'discoverable'.
>> Even
>> with the examples - one can argue that current menus are discoverable.
>
>> How
>> about just moving the one phrase up to the provision.
>>
>>
>>
>> 1.2-A - Accessibility Configuration
>> In complying with this subpart, each agency must activate
> accessibility
>> features and configure products so that they are accessible to and
> usable
>> by
>> people with disabilities such that the means to activate the
> accessibility
>> features and configure products is comparable in prominence to the
> volume
>> or
>> channel changing controls.
>>
>> For example:
>> 1. A caption on/off on a TV remote comparable in prominence to the
> volume
>> control on that remote;
>> 2. A gain wheel or slider on a telephone receiver handset;
>> 3. A tactile button to turn on audio equivalents;
>> 4. A user preferences dialog that is accessible and directly reachable
>
>> from
>> a login screen.
>>
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
>>> Sent: Wednesday, October 10, 2007 2:50 PM
>>> To: TEITAC Audio/Video Subcommittee; Dave Singer; Al
>>> Sonnenstrahl; = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>>> Subject: Re: [teitac-video] Tomorrow's conf call
>>>
>>> Here is the text I was working on, I've attached four
>>> examples, if anyone thinks we need more then please suggest them
>>>
>>>
>>> I suggest a modification of the existing provision 1.2 A to
>>> allow for the requirement that the means to set up a feature
>>> be accessible to the person that needs it, as follows;
>>>
>>> 1.2-A - Accessibility Configuration
>>> In complying with this subpart, each agency must activate
>>> accessibility features and configure products so that they
>>> are accessible to and usable by people with disabilities. The
>>> means to activate the accessibility features and configure
>>> products must be accessible, discoverable and usable by those
>>> desiring the feature.
>>>
>>> For example:
>>> 1. A caption on/off on a TV remote comparable in prominence
>>> to the volume control on that remote; 2. A gain wheel or
>>> slider on a telephone receiver handset; 3. A tactile button
>>> to turn on audio equivalents; 4. A user preferences dialog
>>> that is accessible and directly reachable from a login screen.
>>>
>>>
>>> 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
>>> Larry Goldberg
>>> Sent: 10 October 2007 16:30
>>> To: Dave Singer; TEITAC AV list; Al Sonnenstrahl;
>>> = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
>>> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
>>> Subject: Re: [teitac-video] Tomorrow's conf call
>>>
>>> Dave's suggestion regarding a more generic, but strong,
>>> requirement for the accessibility and usability of access
>>> controls bears serious consideration.
>>> Let's do so at today's conference call.
>>>
>>> ... Larry ...
>>>
>>>
>>> Dave Singer wrote:
>>>
>>> > At 15:31 -0400 9/10/07, Larry Goldberg wrote:
>>> >>
>>> >> We will discuss today's Plenary meeting/conference call, suggested
>>> >> changes to the enclosed draft, and hopefully come to a conclusion
>>> >> regarding the "caption button"/"top-level menu" proposal.
>>> >
>>> > As worded, I really don't think I can -- or we should -- agree to
>>> > these, unless they are restricted to 'classical analog television'.
>>> > They are both making into mandates a question of the design of the
>>> > system.
>>> >
>>> > The furthest we should go in this direction is a
>>> recommendation. We
>>> > simply do not know how to design these products, and inserting a
>>> > design mandate may well have a counter-productive effect:
>>> > manufacturers who were willing to meet the spirit of the
>>> regulations,
>>> > and provide accessible equipment, may well not wish to meet
>>> the letter
>>> > of such a design mandate, and consequently (since they
>>> would no longer
>>> > be able to claim compliance) do nothing.
>>> >
>>> > I am also wondering why the people needing captions need to
>>> have this
>>> > explicit access method, but those (for example) needing audio
>>> > description of video are left without even a guideline as to how it
>>> > should be enabled?
>>> >
>>> > Finally, what happens to option (2) when the menus on a system are
>>> > enabled some other way than pressing a menu button on a remote?
>>> >
>>> > So, trying again, I'd like to *broaden* the scope of the *mandate*
>>> > while leaving product design only recommended:
>>> >
>>> > * * * * *
>>> >
>>> > For all accessibility options, including but not limited to
>>> Captions,
>>> > and Audio Description of Video [or whatever the term we settled on
>>> > is], the enabling and disabling of that accessibility
>>> option must also
>>> > be readily accessible to those desiring it, meaning that
>>> the control
>>> > must both be easy to find, and easily used by someone needing it.
>>> >
>>> > For captions, recommended approaches include:
>>> > 1. A caption on/off button on the TV remote control; 2. Caption
>>> > control(s) on the first menu that appears when on-screen menus are
>>> > displayed;
>>>
>>>
>>> - Larry
>>>
>>>
>>>
>>>

From: Gregg Vanderheiden
Date: Thu, Oct 11 2007 2:15 PM
Subject: Re: Tomorrow's conf call

Good point

There needs to be a provision that requires the product to do it.

The "agency must enable and configure" part is covered already in the
general provision on settings I believe.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Larry Goldberg
> Sent: Thursday, October 11, 2007 1:40 PM
> To: TEITAC AV list; Sean Hayes; Al Sonnenstrahl;
> = EMAIL ADDRESS REMOVED = ; Toby R. Silver;
> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-video] Tomorrow's conf call
>
> The problem with such a requirement of "each agency must
> enable and configure" is that without the capacity built into
> the hardware, the agencies have no ability to follow this
> requirement. Does the purchasing agent have to reconfigure
> the menus on a DTV they buy?
>
> It really has to be built in somehow so that any government
> employee or taxpaying recipient of government information can
> access the controls independently - and certainly without
> having to ask for direct help from the procuring agency.
>
> ... Larry ...
>
>
> Dave Singer wrote:
>
> > There is a small snag here: you ask for the controls to be
> accessible
> > to people with (unspecified) disabilities, which is too broad, I
> > believe (and untestable). I also have been told that I should shy
> > away from describing people who need accessibility as having
> > disabilities. That's why my original text said that the means to
> > enable an accessibility option must be accessible to those needing
> > that option; that's a more focused, testable, requirement. (e.g.
> > you fail if you provide visual menus for those needing visual
> > accessibility, or voice-activated menus for those with audio
> > accessibility needs).
> >
> > The issue that the 'activate' is used with two senses is also
> > addressed here (using 'enable' the feature by the agency).
> >
> > How about:
> >
> > 1.2-A - Accessibility Configuration
> > In complying with this subpart, each agency must enable and
> configure
> > the accessibility features of products, so that the
> products and the
> > media they present are accessible to and usable by people needing
> > accessible access, and the means to activate any
> accessibility feature
> > must be accessible to those that need each feature, and
> comparable in
> > prominence to similar configuration mechanisms for general
> operation.
> >
> > For example:
> > 1. A caption on/off on a TV remote comparable in prominence to the
> > volume control on that remote; 2. A gain wheel or slider on a
> > telephone receiver handset; 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 15:01 +0100 11/10/07, Sean Hayes wrote:
> >> That wouldn't work in the context of 1.2A, which is a general
> >> provision; so referring to volume or channel changing controls
> >> wouldn't make sense for all products and it loses the sense of
> >> David's idea that the means to activate an accessibility
> feature must
> >> be operable by the person that needs that feature.
> >>
> >> The specific case of raising the prominence of a caption control
> >> really is outside of the scope of the provision itself, just as we
> >> don't have any specifics on the form of volume controls on
> phones, or
> >> contrast controls in software or on a display - so it does
> need to be
> >> an example.
> >>
> >> How about:
> >> 1.2-A - Accessibility Configuration
> >> In complying with this subpart, each agency must activate
> >> accessibility features and configure products so that they are
> >> accessible to and usable by people with disabilities, and
> the means
> >> to activate the accessibility features and configure products is
> >> accessible to those that need those features and comparable in
> >> prominence to similar configuration mechanisms for general
> operation.
> >>
> >> For example:
> >> 1. A caption on/off on a TV remote comparable in prominence to the
> >> volume control on that remote; 2. A gain wheel or slider on a
> >> telephone receiver handset; 3. A tactile button to turn on audio
> >> equivalents; 4. A user preferences dialog that is accessible and
> >> directly reachable from a login screen.
> >>
> >> 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 Gregg
> >> Vanderheiden
> >> Sent: 11 October 2007 07:19
> >> To: 'TEITAC Audio/Video Subcommittee'; 'Dave Singer'; 'Al
> >> Sonnenstrahl'; = EMAIL ADDRESS REMOVED = ; 'Toby R. Silver';
> >> = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
> >> Subject: Re: [teitac-video] Tomorrow's conf call
> >>
> >> This is good but the examples will be dropped and the rest
> is pretty vague.
> >> I would see the current menu's as being described as
> 'discoverable'. Even
> >> with the examples - one can argue that current menus are
> discoverable. How
> >> about just moving the one phrase up to the provision.
> >>
> >>
> >>
> >> 1.2-A - Accessibility Configuration
> >> In complying with this subpart, each agency must activate
> >> accessibility features and configure products so that they are
> >> accessible to and usable by people with disabilities such that the
> >> means to activate the accessibility features and configure
> products
> >> is comparable in prominence to the volume or channel
> changing controls.
> >>
> >> For example:
> >> 1. A caption on/off on a TV remote comparable in prominence to the
> >> volume control on that remote; 2. A gain wheel or slider on a
> >> telephone receiver handset; 3. A tactile button to turn on audio
> >> equivalents; 4. A user preferences dialog that is accessible and
> >> directly reachable from a login screen.
> >>
> >>
> >>
> >> Gregg
> >> -- ------------------------------
> >> Gregg C Vanderheiden Ph.D.
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: = EMAIL ADDRESS REMOVED =
> >>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean
> >>> Hayes
> >>> Sent: Wednesday, October 10, 2007 2:50 PM
> >>> To: TEITAC Audio/Video Subcommittee; Dave Singer; Al
> Sonnenstrahl;
> >>> = EMAIL ADDRESS REMOVED = ; Toby R. Silver; = EMAIL ADDRESS REMOVED = ;
> >>> = EMAIL ADDRESS REMOVED =
> >>> Subject: Re: [teitac-video] Tomorrow's conf call
> >>>
> >>> Here is the text I was working on, I've attached four
> examples, if
> >>> anyone thinks we need more then please suggest them
> >>>
> >>>
> >>> I suggest a modification of the existing provision 1.2 A
> to allow
> >>> for the requirement that the means to set up a feature be
> accessible
> >>> to the person that needs it, as follows;
> >>>
> >>> 1.2-A - Accessibility Configuration In complying with this
> >>> subpart, each agency must activate accessibility features and
> >>> configure products so that they are accessible to and usable by
> >>> people with disabilities. The means to activate the
> accessibility
> >>> features and configure products must be accessible, discoverable
> >>> and usable by those desiring the feature.
> >>>
> >>> For example:
> >>> 1. A caption on/off on a TV remote comparable in
> prominence to the
> >>> volume control on that remote; 2. A gain wheel or slider on a
> >>> telephone receiver handset; 3. A tactile button to turn on audio
> >>> equivalents; 4. A user preferences dialog that is accessible and
> >>> directly reachable from a login screen.
> >>>
> >>>
> >>> 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 Larry
> >>> Goldberg
> >>> Sent: 10 October 2007 16:30
> >>> To: Dave Singer; TEITAC AV list; Al Sonnenstrahl;
> >>> = EMAIL ADDRESS REMOVED = ; Toby R. Silver; = EMAIL ADDRESS REMOVED = ;
> >>> = EMAIL ADDRESS REMOVED =
> >>> Subject: Re: [teitac-video] Tomorrow's conf call
> >>>
> >>> Dave's suggestion regarding a more generic, but strong,
> >>> requirement for the accessibility and usability of access
> controls
> >>> bears serious consideration.
> >>> Let's do so at today's conference call.
> >>>
> >>> ... Larry ...
> >>>
> >>>
> >>> Dave Singer wrote:
> >>>
> >>>> At 15:31 -0400 9/10/07, Larry Goldberg wrote:
> >>>>>
> >>>>> We will discuss today's Plenary meeting/conference
> call, suggested
> >>>>> changes to the enclosed draft, and hopefully come to a
> conclusion
> >>>>> regarding the "caption button"/"top-level menu" proposal.
> >>>>
> >>>> As worded, I really don't think I can -- or we should --
> agree to
> >>>> these, unless they are restricted to 'classical analog
> television'.
> >>>> They are both making into mandates a question of the
> design of the
> >>>> system.
> >>>>
> >>>> The furthest we should go in this direction is a
> >>> recommendation. We
> >>>> simply do not know how to design these products, and inserting a
> >>>> design mandate may well have a counter-productive effect:
> >>>> manufacturers who were willing to meet the spirit of the
> >>> regulations,
> >>>> and provide accessible equipment, may well not wish to meet
> >>> the letter
> >>>> of such a design mandate, and consequently (since they
> >>> would no longer
> >>>> be able to claim compliance) do nothing.
> >>>>
> >>>> I am also wondering why the people needing captions need to
> >>> have this
> >>>> explicit access method, but those (for example) needing audio
> >>>> description of video are left without even a guideline
> as to how it
> >>>> should be enabled?
> >>>>
> >>>> Finally, what happens to option (2) when the menus on a
> system are
> >>>> enabled some other way than pressing a menu button on a remote?
> >>>>
> >>>> So, trying again, I'd like to *broaden* the scope of the
> *mandate*
> >>>> while leaving product design only recommended:
> >>>>
> >>>> * * * * *
> >>>>
> >>>> For all accessibility options, including but not limited to
> >>> Captions,
> >>>> and Audio Description of Video [or whatever the term we
> settled on
> >>>> is], the enabling and disabling of that accessibility
> >>> option must also
> >>>> be readily accessible to those desiring it, meaning that
> >>> the control
> >>>> must both be easy to find, and easily used by someone needing it.
> >>>>
> >>>> For captions, recommended approaches include:
> >>>> 1. A caption on/off button on the TV remote control; 2. Caption
> >>>> control(s) on the first menu that appears when on-screen
> menus are
> >>>> displayed;
> >>>
> >>>
> >>> - Larry
> >>>
> >>>
> >>>
> >>>