Thread Subject: Re: timed responses

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: Hoffman, Allen
Date: Thu, May 24 2007 8:15 AM

What I'm working through with you all is the concept of moving from an
instance based approach to timed responses to a more systematic and
integrated approach that should allow more flexibility for end-users and
management at the end of the day. So, lets consider that a platform
includes timed response configuration user s settings, just as they do
allow for web preferences, email preferences, display preferences.
These can be hierarchical in nature, role-based, and scoped to
environments by the use of the technology components in a stack.
Requiring that timed response be included in platforms, or (OS(s) for
use of the old term, we can move this problem forward to a more
manageable and useful state. It won't eliminate the application of
timed responses, but could make understanding and management of these
options much simpler for IT folks across the board.

So let me walk through some examples:
If timed response configuration is included in a platform that runs on a
phone. The user may have the option to set pre-notification time,
inactivity time-out accommodation, even call answer auto time. In an OS
the user may set inactivity time modification, pre-notification, and in
the web browser it might set the option to disable time outs for some
websites, or just set it to automatically request more time X amount of
times to help the end-user stop getting interrupted so often.

More thoughts?

Thanks for all the thoughts so far.



Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Deborah
Buck
Sent: Wednesday, May 23, 2007 7:09 PM
To: 'TEITAC General Interface Accessibility Subcommittee'
Subject: Re: [teitac-general] timed responses

I agree with Deb that timed responses for testing and general
applications should be treated differently. Wouldn't the need for a
timed response limitation for use in testing scenario become a part of
the business requirements of the bid. The timed response requirements
would be the baseline for general applications, but because of the
planned use of the application in a testing environment the additional
limitations become a part of the intended use of the product.



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: Wednesday, May 23, 2007 1:25 PM
To: TEITAC General Interface Accessibility Subcommittee
Subject: Re: [teitac-general] timed responses

Testing was only the start, and consider this scenario:

In a testing environment a user may have a user profile, the profile is
approved either by their organization or by the testing organization.
The profile basically is a one time preference set, then is used during
the test.

Another similar notion would be for security and timed responses, if a
user needs additional time, security can accommodate that through policy
supported in profile and then it just works once set.

I think this could be a much more holistic approach to this sometimes
problematic requirement.



Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie Cook
Sent: Wednesday, May 23, 2007 1:21 PM
To: TEITAC General Interface Accessibility Subcommittee
Subject: Re: [teitac-general] timed responses

I think timed responses for testing and for general applications should
be handled differently. Some types of testing may be normed against the
timed response or ability to perform required functions may be
predicated on meeting timing requirements. In those cases you would have
to meet the timing requirements with or without reasonable
accommodations and extending the time would not be reasonable. So I
think testing should be handled differently from other applications.
Maybe for testing the user should not be able to independently extend
the time. But for everything else should be able to do so indefinitely
or for as many segments as needed.
----- Original Message -----
From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, May 23, 2007 10:13 AM
Subject: [teitac-general] timed responses


All:

Had an interesting discussion with Cindy Rollins of Utah State/WebAIM
etc. We were discussing timed response requirements as they related to
e-learning, and her concern was that continuously asking for more time
during testing can be problematic, and that this needs to be something
users configure at the beginning of the session. So, I then
extrapolated.

My thinking is that timed response preferences should be a required user
preference option for OS(s), platforms, etc. Then, applications must
respect them as is already in the standard. I think this would really
deduplicate this requirement.

Thoughts?

Has this been proposed already?


Allen Hoffman
DHS : CRCL & OCIO;
DHS Office On Accessible Systems and Technology
v: 202-447-0303; c: 202-213-1835; tty: 202-401-0725
email: = EMAIL ADDRESS REMOVED = or = EMAIL ADDRESS REMOVED =

This communication, along with any attachments, is covered by federal
and state law governing electronic communications and may contain
sensitive and legally privileged information. If the reader of this
message is not the intended recipient, you are hereby notified that any
dissemination, distribution, use or copying of this message is strictly
prohibited. If you have received this in error, please reply
immediately to the sender and delete this message.
Thank you.





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

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