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: Gregg Vanderheiden
Date: Thu, Oct 11 2007 2:15 PM

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

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