Thread Subject: Re: Tomorrow's conf call

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Karen Peltz Strauss
Date: Thu, Oct 11 2007 1:00 PM

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
>>>
>>>
>>>
>>>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University