Thread Subject: Re: Touch-basedcontrols language

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: Debbie Cook
Date: Fri, Nov 09 2007 6:05 PM

Randy, the difficulty with version 1 is that any product requiring
mechanical controls must already comply with the requirements for mechanical
controls. You cannot have one group of products with mechanical controls
that do not comply with those provisions. So, in #2 this is clarified. It is
those requirements for mechanical controls that make the product more
useable for individuals with motor control issues.
----- Original Message -----
From: "Randy Marsden" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC desktop/portable (hardware) subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 09, 2007 4:44 PM
Subject: [teitac-hardware] teitac-hardware] [teitac-closed]
Touch-basedcontrols language


Hi Everyone:

I know we missed the deadline for getting info into the sandbox, but
I wanted to try to get everyone on the same page regarding Touch
Controls prior to next week's meetings.

The following is proposed text that we brought to the last plenary,
after a fair amount of vetting on the list serve (and recognition
goes to Peter Manyin for drafting this):

Version 1
If a product utilizes touch screens or touch-operated controls then
the product must provide, without requiring user-speech:

A functionally equivalent, alternate means of operation that uses
Mechanical Controls and does not require vision.
A functionally equivalent, alternate means of operation that does not
require fine motor control.
Note: This provision should not discourage the provision of control
via user speech in addition to the above methods.


Then, during the plenary when it was being discussed, a Version 2 was
entered on the Wiki as follows:

Version 2 (proposal from plenary)
If a product uses touch screens or touch-operated controls, it must
provide a functionally equivalent alternative means of operation that
meets the requirements for Mechanical Controls. This alternative must
not require either vision or fine motor control.

Note: A product may also provide control via user speech in addition
to the above methods.

Rationale: This language addresses the issues associated with touch-
based controls (including biophysical, accidental activation and
vision) by requiring a redundant interaction method without assigning
the control type.



As Rob and I reviewed this earlier this week, we realized that we
don't think that Version 2 was exactly what we intended and may have
been incomplete when entered into the Wiki during the last plenary.
Specifically, the first sentence of Version 2 requires Mechanical
Controls, while the second stipulates use not requiring fine motor
control. Those two requirements will likely conflict with one
another (ie. you can't require mechanical controls AND require that
they don't require fine motor control).

I have checked my notes from the last plenary, but unfortunately
didn't document what the objections were to the Version 1 wording.
So, we'd like to take a step back to the original language in Version
1 (which we feel addresses both disability segments - blindness and
motor impairments - who will have trouble with touch controls) and re-
discuss it. If there are valid concerns, we can amend it again and
go from there. Sorry for the confusion - this one fell through the
cracks.

-Randy Marsden (HW co-chair)
ATIA





--------------------------------------------------------------------------------

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