W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2003

PLAIN: Proposed rewording for Guideline 3.2 with success criteria, best practices, benefits, and examples

From: John M Slatin <john_slatin@austin.utexas.edu>
Date: Thu, 6 Nov 2003 15:03:50 -0600
Message-ID: <C46A1118E0262B47BD5C202DA2490D1A1DFC00@MAIL02.austin.utexas.edu>
To: <w3c-wai-gl@w3.org>
Plain language version of Principle 3, Guideline 3.2 with success
criteria, benefits, and examples

 

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


3.2 [E7] The definition of abbreviations and acronyms can be
unambiguously determined.

 

Editorial Note: The CKW reorganization suggested that this checkpoint be
combined with checkpoint 1.4.

[I#442]


Proposed wording for Guideline 3.2


3.2 [E7] Make it possible for users to learn the correct meaning of
acronyms and abbreviations

 

Editorial Note: The CKW reorganization suggested that this checkpoint be
combined with checkpoint 1.4.

[I#442]


Current wording for Checkpoint 3.2, SC 1


1.    acronyms and abbreviations do not appear first in standard
unabridged dictionaries for the language or define the first time the
first time they appear or are available in a glossary on the
site.[I#330]

 

Editorial Note:  If a standard format for doing it can be achieved, we
might require that linkages to glossaries for all abbreviations and
acronyms that are created by the author or site be provided.  We could
also recommend that linkages to any abbreviations, acronyms, etc. used
by the authors also be provided.  We could also have a weaker
recommendation for acronyms and abbreviations appearing on the site that
linkages to glossaries explaining all abbreviations acronyms, etc. that
appear in any documents on the site be provided.

 


Proposed wording for Guideline 3.2, SC 1


When acronyms and abbreviations are used, at least one of the following
is true:

a.     The acronym or abbreviation is listed in at least one unabridged
dictionary of the natural language of the passage in which the acronym
or abbreviation appears.

b.    The full meaning of the acronym or abbreviation is defined the
first time it appears in a resource that can be accessed independently
(for example, froma Search Results page).

c.     The full meaning of the acronym or abbreviation is available in a
glossary on the Web site.

I#330]

 

Editorial Note: If a standard format for doing it can be achieved, we
might require that linkages to glossaries for all abbreviations and
acronyms that are created by the author or site be provided. We could
also recommend that linkages to any abbreviations, acronyms, etc. used
by the authors also be provided. We could also have a weaker
recommendation for acronyms and abbreviations appearing on the site that
linkages to glossaries explaining all abbreviations acronyms, etc. that
appear in any documents on the site be provided.


Current wording for Best Practice Measures for Checkpoint 3.2


1. a list is provided on the page or home page of URIs to cascading
dictionaries that can or should be used to define abbreviations or
acronyms. [I#350]

2. the content has been reviewed, taking into account the following
strategies for determining the definition of abbreviations and acronyms,
applying them as appropriate.

A. provide a definition or link (with the first occurrence) of phrases,
words, acronyms, and abbreviations specific to a particular community.

B. provide a summary for relationships that may not be obvious from
analyzing the structure of a table but that may be apparent in a visual
rendering of the table.

C. if contracted forms of words are used such that they are ambiguous,
provide semantic markup to make words unique and interpretable.

 


Proposed wording for Best Practice Measures for Guideline 3.2


1. The resource includes a list of links to cascading dictionaries that
can or should be used to define abbreviations or acronyms. [I#350] 

 

[js note: I don't think I understand this.  Is the list in question here
a list of URIs that identify cascading dictionaries where the meaning of
abbreviations or acronyms can be found? ? What are "cascading
dictionaries"?]

 

2. the content has been reviewed, taking into account the following
strategies for determining the definition of abbreviations and acronyms,
and applying these strategies  as appropriate.

A. When using words, phrases, abbreviations, or acronyms that have
special meanings for certain groups of people (for example,
psychologists, engineers, musicians), make definitions available.

 

 [js note: The item below (b) is out of place here.  This is now a list
of success criteria for a guideline that deals specifically with
disambiguating acronyms and abbreviations. I agree that we need a way to
shoehorn the idea of using the <table summary> back in here, but this
isn't the place to do it!]

B. provide a summary for relationships that may not be obvious from
analyzing the structure of a table but that may be apparent in a visual
rendering of the table.

C. if contracted forms of words are used such that they are ambiguous,
provide semantic markup to make words unique and interpretable. [js
note: If we're going to leave this item in the document, the Guideline
should be rewritten to refer more generally to shortened forms of words
or phrases, not just abbreviations and acronyms]


Current wording for Benefits of Checkpoint 3.2


* Defining key terms and specialized language will help people who are
not familiar with the topic.

* Providing the expansion of abbreviations and acronyms not only helps
people who are not familiar with the abbreviation or acronym but can
clarify which


Proposed wording for Who benefits from Checkpoint 3.2 (Informative)


[js note: Neither of the benefits proposed below has specific
application to people with disabilities.  If acronyms and abbreviations
create particular problems, e.g., for people with learning disabilities
or cognitive impairments, let's say so and say how disambiguating will
help.]

* Defining key terms and specialized language will help people who are
not familiar with the topic.

* Providing the expansion of abbreviations and acronyms not only helps
people who are not familiar with the abbreviation or acronym but can
clarify which meaning of an abbreviation or acronym is appropriate to
use. For example, the acronym "ADA" stands for both the American with
Disabilities Act as well as the American Dental Association.


Current wording for Examples of Checkpoint 3.2


None provided


Proposed wording for Examples of Guideline 3.2  (Informative)


Needed!

 

 


"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 Thursday, 6 November 2003 16:03:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:26 GMT