PLAIN: Rewording for Guideline 2.2 with success criteria, best practices, benefits, examples

Plain language version of Guideline 2.2 plus with success criteria,
benefits, and examples

 

This document contains a series of proposals for a "plain language_
rewording of WCAG 2.0 Guideline 2.2 with Success Criteria, Examples, and
Benefits

 

This is submitted in partial fulfillment of an action item taken by John
Slatin, Katie Haritos-Shay, and Doyle Burnett during a call in late
September or early October, to generate a plain-language version of WCAG
2.  

 

This message is partial in two ways: (1) It addresses only Guideline
(now Principle) 2, Checkpoint (now Guideline) 2.2, and the relevant
success criteria, examples, and benefits.  Other guidelines, etc., will
follow.  (2) It is not really "plain language," in the sense that this
text has not yet been compared to the 1500-word "special lexicon" used
by Voice of America (or other similar lexicons).  Thus it's actually
best understood as an attempt to simplify and clarify.  We're still
working on the formal plain language issues, but wanted to put this out
to start generating discussion.

 

Items labeled "Current wording" are taken from the September document
Reorg 4, available at http://www.w3.org/WAI/GL/2003/09/reorg4.html
<http://www.w3.org/WAI/GL/2003/09/reorg4.html> .  This document was
current at the time Katie and Doyle and I took on the action item to
attempt a plain language version.  Of course the proposed rewordings
will need to be correlated with later updates.


Current wording for Checkpoint 2.2


2.2 [CORE] Users can control any time limits on their reading,
interaction, or responses unless control is not possible due to nature
of real-time events or competition.


Proposed wording for Guideline 2.2


2.2 [CORE] Allow users to control time limits on their reading,
interaction, or responses unless specific real-time events or rules of
competition make such control impossible.


Current wording for Checkpoint 2.2, SC 1


1. content is designed so that time limits are not an essential part of
interaction or at least one of the following is true for each time
limit:

* the user is allowed to deactivate the time limits,

* or the user is allowed to adjust the time limit over a wide range
which is at least ten times or default setting or average user's
preference,

* or the user is warned before time expires and given at least 10
seconds to extend the time limit,

* or the time limit is due to a real-time event (e.g. auction) and no
alternative to the time limit is possible,

* or the time limit is part of a competitive activity where timing is an
essential part of the activity (e.g. competitive gaming or time based
testing).


Proposed wording for Guideline 2.2, SC 1


1. content is designed so that time limits are not an essential part of
interaction, or at least one of the following is true for each
interaction for which a time limit has been set:

*        the user is allowed to deactivate the time limit;

*        the user is allowed to adjust the time limit over a wide range
which is at least ten times the length of the default setting [js 10/26:
deleted because there's no way for most developers to determine this];

*        the user is warned before time expires and given at least 10
seconds to extend the time limit; [js 10/26: 10 seconds isn't long
enough. MS Windows used to give you 15 seconds to accept changes to the
Display control panel, and it wasn't long enough to let me listen to the
entire dialog and then tab to the OK button.]

*        the time limit is an important part of a real-time event such
as an auction, and no alternative to the time limit is possible;

*        or the time limit is part of a competitive activity where
timing is an essential part of the activity (e.g. competitive gaming;

*        an online test must be completed within a set time which has
already been increased to accommodate people with disabilities who are
allowed by law to take additional time 


Current wording for Best Practice Measures for Checkpoint 2.2


1. any moving content can be frozen using the keyboard[

I#325]


Proposed wording for Best Practice Measures for Guideline 2.2


1.  moving content can be permanently or temporarily stopped using the
keyboard [I#325]


Current wording for Benefits of Checkpoint 2.2


People with reading disabilities, cognitive disabilities, and learning
disabilities often need more time than most people to read and
comprehend written text. People with physical disabilities might not be
able to move quickly or accurately enough to interact with moving
objects.

Content that is updated often might not be processed and read in time or
in the proper order by an assistive technology or voice browser.

 


Proposed wording for Who benefits from Checkpoint 2.2 (Informative)


*        People with reading disabilities, cognitive disabilities, and
learning disabilities benefit from additional time to read and
comprehend written text. 

*        People with low vision who use screen magnification software
benefit from improved ability to track content that moves.

*        People who do not see well, people who cannot read quickly or
follow rapidly changing events, and people with limited use of their
hands benefit from the ability to increase the time for gathering
information and interacting with the content.


Current wording for Examples of Checkpoint 2.2


* Examples of content that requires comprehension or a response within a
timed interval:

* automatic refresh

* redirection

* blinking or scrolling text

* dialog that disappears after a short period

* shutdown or deactivation of page if activity is not received in a set
amount of time

 

* Example 1: blinking text.

 

Client-side scripting is used to create blinking text. The user can
deactivate the use of scripting in his or her browser or override the
use of scripts with a user style sheet.

 

* Example 2: a news site that is updated regularly.

 

A news site causes its front page to be updated every 1/2 hour. The
front page contains minimal text and primarily consists of links to
content. A user who does not wish the page to update selects a checkbox.
The checkbox is in the "user preferences" portion of the site which is
one of the first links on each page.


Proposed wording for Examples of Guideline 2.2 (Informative)


* Content that requires comprehension or a response within a timed
interval, including (but not limited to) the following:

*        a screen that refreshes automatically every 5 seconds 

*        a pages that automatically redirects the browser to a different
page or site

*        blinking or scrolling text

*        a dialog box that disappears automatically after a short period

*        a page that automatically logs the user out if no activity
occurs within a set amount of time

 

* Example 1: blinking text.

 

Some pages on a Web site use blinking text to call attention to new
items. Users can select a single option to turn off blinking throughout
the site. 

 

* Example 2: a news site that is updated regularly.

 

A news site causes its front page to be updated every 30 minutes. The
front page contains minimal text and primarily consists of links to
content. A user who does not wish the page to update selects a checkbox.
The checkbox is in the "user preferences" portion of the site which is
one of the first links on each page.

Example 3. A multiple-choice test.

 

An online examination is scheduled to last 50 minutes.  The
administrator changes the time to 75 minutes to accommodate a student
with a learning disability. Other students must still complete the test
in 50 minutes.

 

Example 4. An online banking site.

 

An online banking site limits each session to 15 minutes. The Webmaster
increases the time limit for a customer with cerebral palsy.

 

 


"Good design is accessible design." 
Please note our new name and URL!
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/
<http://www.utexas.edu/research/accessibility/> 


 

 

Received on Wednesday, 5 November 2003 16:05:38 UTC