PLAIN: Princpile 2 plus Guideline 2.1 with success criteria, best practices, benefits, and examples

Plain language version of Principle 2 plus Guideline 2.1 with success
criteria, benefits, and examples

 

This document contains a series of proposals for a "plain language_
rewording of WCAG 2.0 Guideline 2 plust Checkpoint 2.1 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.1, 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 Guideline 2


Guideline 2: OPERABLE. Ensure that Interface Elements in the Content are
Operable by Any User

 


Proposed wording for Principle 2


Principle 2: OPERABLE. Any user should be able to operate all Interface
Elements that are part of the content 


Current wording for Checkpoint 2.1


2.1 [CORE] All functionality is operable at a minimum through a keyboard
or a keyboard interface.


Proposed wording for Guideline 2.1


2.1 [CORE] Make it possible for people who use only a keyboard or a
keyboard interface to operate all functionality .


Current wording for Checkpoint 2.1, SC 1


1. all of the functionality of the content, where the functionality or
its outcome can be expressed in words, is operable at a minimum through
a keyboard or keyboard interface.

 

Note:

 

refer to checkpoint 4.3 for information regarding user agent support.


Proposed wording for Guideline 2.1, SC 1


1. all of the functionality of the content is operable through a
keyboard or keyboard interface.

 

[js note: Do we have examples of a function or outcome that cannot be
expressed in words? If not, we should strike the phrase.]

 

Note:

 

refer to checkpoint 4.3

for information regarding user agent support.


Current wording for Best Practice Measures for Checkpoint 2.1


1. wherever a choice between event handlers is available and supported,
the more abstract event is used.


Proposed wording for Best Practice Measures for Guideline 2.1


1. wherever the technology that provides functionality allows a choice
between specifying the results of a user action and requiring a
particular action that depends upon a specific input or output device,
the code specifies the desired result instead of the action.  For
example, if the technology supports a choice between an abstract select
function and a function that requires a mouse-click, the select function
is used.


Current wording for Benefits of Checkpoint 2.1


* Individuals who are blind (and cannot use pointing devices) can have
access to the functionality of the Web content or site.

* Individuals with severe physical disabilities can use speech input
(which simulates keystrokes) to both enter data and operate the
interface elements on the page.


Proposed wording for Who benefits from Checkpoint 2.1 (Informative)


* Individuals who cannot use pointing devices can use a keyboard or
keyboard interface to access the functionality.

* Individuals with severe physical disabilities can use speech input
(which emulates  keystrokes) to enter data and operate interface
elements.


Current wording for Examples of Checkpoint 2.1


* Example 1: operation with multiple input devices.

 

The content relies only on focus-in, focus-out, and activation events;
these are defined in the API of the environment for which the content is
written, and are intended to be operable by a variety of input devices,
including pointing devices, keyboards and speech input systems.

 

* Example 2: examples of Web content that would and would not be
operable from a keyboard or keyboard interface

* If it's written to be operable from a computer keyboard, it conforms.
(because it is operable from the keyboard.)

* If it's written to be used on a device that doesn't usually have a
keyboard such as a cell phone and but it can be controlled by an
optional keyboard for that device, it conforms. (A person who needs a
keyboard - or alternate keyboard - can use it to control the
application.)

* If it's written to be used with a device that doesn't have a keyboard,
but it could also be used by similar devices that do and it would work
with their keyboard, it conforms. (A person who needs a keyboard would
not buy the device without the keyboard. That device may itself not be
considered accessible.

But the content can be controlled from a device with a keyboard and
therefore conforms to this checkpoint.)

* If it's written to work with devices that do not have keyboards and it
can not be used by any other devices that do have keyboards, then it
does not conform. (It cannot be accessed via keyboard.)

 


Proposed wording for Examples of Guideline 2.1 


(Informative)


[js note: The current examples require extensive reworking to make them
consistent with examples under other guidelines.  We need concrete
examples that illustrate the ideas listed here.  If someone else can
come up with those examples I'll do my best to reword for clarity and
simplicity.]

 

 


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