PLAIN: Proposed rewording for Guideline 1.4 with success criteria, benefits, examples

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

 

This document contains a series of proposals for a "plain language_
rewording of WCAG 2.0 Checkpoint 1.4 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) 1, Checkpoint (now Guideline) 1.4, 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 1.4


1.4 [CORE] All text can be decoded into words represented in Unicode.


Proposed wording for Guideline 1.4


1.4 [CORE] For text, use fonts that can be represented in Unicode.

 


Current wording for Checkpoint 1.4, SC 1


Editorial Note: The CKW reorganization suggested that this checkpoint be
combined with Guideline 3.2. [I#442]

 

1. text in the content is provided in Unicode or sufficient information
is provided so that it can be automatically mapped back to Unicode.


Proposed wording for Guideline 1.4, SC 1


Editorial Note: The CKW reorganization suggested that this checkpoint be
combined with Guideline 3.2. [js 10/28: if the proposed rewording for
Guideline 1.4 is accepted by WCAG WG, the CKW recommendation will not
work.] [I#442]

 

1. text is provided in Unicode or can be automatically converted to
Unicode.

 

 


Current wording for Best Practice Measures for Checkpoint 1.4


1. abbreviations and acronyms are clearly identified each time they
occur if they collide with a word in the standard language that would
also logically appear in the same case (e.g. all caps). (See also
checkpoint 3.1) [I#341]

2. symbols such as diacritic marks that are found in standard usage of
the natural language of the content, and that are necessary for
unambiguous identification of words, are present or another standard
mechanism for disambiguation is provided.


Proposed wording for Best Practice Measures for Guideline 1.4


1. abbreviations and acronyms are clearly identified each time they
occur if they are identical to a word in the document's language that
has a different meaning. (See also checkpoint 3.1) [I#341]

2. symbols such as diacritic marks that are found in standard usage of
the natural language of the content, and that are necessary for precise
identification of words, are present, or another standard mechanism for
clear identification is provided.


Current wording for Benefits of Checkpoint 1.4


* Facilitating unambiguous decoding of characters and words in content
is also helpful for individuals who are learning to read or learning a
second language.


Proposed wording for Who benefits from Checkpoint 1.4 (Informative)


*        People with learning disabilities and cognitive impairments,
and people using refreshable Braille displays and speech synthesizers,
benefit from precise identification of individual characters and words. 

*        People who are learning to read and people whose native
language is different from the language of the document benefit from
precise identification of characters and words.


Current wording for Examples of Checkpoint 1.4


* Example 2: an acronym in a page title.

 

In the following heading, "People of the W3C." the acronym "W3C" is
marked as an acronym. Because it has been marked appropriately, the user
agent would be able to speak the letters of the acronym one at a time
rather than attempting to pronounce it as though it were a word.


Proposed wording for Examples of Guideline 1.4 (Informative)


* Example 1: an acronym in a page heading.

In the heading, "People of the W3C," the letters "W3C" are marked as an
acronym. When the user agent encounters this acronym, it speaks the
words "World Wide Web Consortium" instead of reading the letters one at
a time. [js note: The example as currently worded just doesn't make
sense. Example 1 is missing. More substantively, JAWS alredy pronounces
W Three C" because it can't parse "W3C" as a word; tagging it as an
<acronym> has nothing to do with it.  A better example might be <acronym
title="Flawn Academic Center">FAC</acronym>, where JAWS would otherwise
pronounce "fack" because the three letters can be sounded together in
English.  But what we really need here is an example of an acronym that
is also a regular word.  For example, <acronym title="House of
Independent Democratic Executives">HIDE</acronym> And we need an example
of something where diacritics matter, e.g., in Hebrew or other language
where the Unicode mapping can be demonstrated]

 

 

 


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