W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2001

Re: Proposal for Guideline 2 as well as a proposal to trim WCAG 2.0 to 3 guidelines (won't william be glad?)

From: Leonard R. Kasday <kasday@acm.org>
Date: Thu, 04 Jan 2001 12:53:38 -0500
Message-Id: <4.3.2.7.2.20010104125142.00bd3f00@pop3.concentric.net>
To: Charles McCathieNevile <charles@w3.org>, Wendy A Chisholm <wendy@w3.org>
Cc: <w3c-wai-gl@w3.org>
Is there a typo here? You say

>"  Guideline 2 should say, "Design content that can be navigated and
>   presented according to the needs and preferences of the user."


But under "rough reformulation" Guideline 2 is "device independence"


Len



At 11:02 AM 1/4/01 -0500, Charles McCathieNevile wrote:
>The proposal works for me.
>
>Charles McCN
>
>On Wed, 3 Jan 2001, Wendy A Chisholm wrote:
>
>   Happy New Year!
>
>   This e-mail contains some reasoning about why, how, and where I ended up at
>   a proposal for trimming our draft to 3 guidelines.  At the end is a 2
>   question questionnaire that I would appreciate responses to.
>
>   There were several proposals about how to reword Guideline 2, as well as a
>   couple threads about the myth of separating content from
>   presentation.  I've been trying to synthesize all of this information into
>   the new draft.
>
>   Another aspect I've been considering is ensuring that we answer the "who,
>   what , why, where, how" questions.
>
>   If we look at Guideline 1, I think it generally states "what needs to be
>   done."  The checkpoints under Guideline 1 state "how to do it" and the
>   explanatory text of the checkpoints elaborate on the "how" as well as "why
>   do it" and "what it means."  The techniques will further describe "how to
>   do it" at a technology-specific level.
>
>   Therefore, in looking at Guideline 2 it currently reads:  "Separate content
>   and structure from presentation."  This sounds more like a "how" than a
>   "what."  I am also concerned about the myth of separating presentation from
>   semantics, but I won't discuss that here.  I want to focus on the mechanics
>   of the document.
>
>   We are also trying to create something that is easy to understand by
>   less-technical or non-technical people.
>
>   With all of this in mind, it seems that Guideline 2 should describe what
>   needs to happen to make the structure accessible.
>
>   The checkpoints describe how:
>   1. Use markup languages according to specification
>   2. Use style languages to control layout and presentation.
>   3. Use markup or a data model to provide the logical structure of content.
>
>   What do these things accomplish?  We are asking the designer to expose the
>   structure of the document.  What is structure?  Structure primarily
>   describes relationships between different size "chunks" such as a heading
>   to a paragraph,  n number of chunks that make up a chapter.  Hierarchy.
>
>   The "what" is that we need to know the logical order in which to navigate
>   the relationships of the document or application.
>
>   While Guideline 1 says, "Design content that can be presented visually,
>   auditorily or tactually, according to the needs and preferences of the
>   user."  Guideline 2 should say, "Design content that can be navigated and
>   presented according to the needs and preferences of the user."
>
>   Checkpoint 2.2 really falls under Guideline 1.  In fact, I think everything
>   can fall into 3 basic categories:
>
>   Guideline 1: Presentation (combine with parts of 5 - device independence,
>   and 6 - graceful transformation)
>   Guideline 2: Interaction (combine with 4 - browsing and navigation and
>   parts of 5)
>   Guideline 3: Comprehension
>
>   In a sense this is separating presentation from structure, behavior, and
>   content along the lines of the Model/View/Controller paradigm.
>
>   Therefore, here is a rough reformulation of WCAG 2.0.  I have combined some
>   of our existing checkpoints, subsumed others.  I have not made a map
>   between them.  The checkpoints are probably not technically complete.  The
>   idea is to test the new structure not determine if the wording of each
>   checkpoint is exactly as it should be.  If the structure seems ok, then I
>   propose to take another pass at wording, adding back the examples and
>   rationales.  This is just a sweep to look at the mechanics and structure of
>   our document.
>
>   Guideline 1. Graceful transformation. Design content that can be presented
>   visually, auditorally, or tactually, according to the needs and preferences
>   of the user.
>
>   checkpoints:
>   1.1. Provide a text equivalent for all non-text content
>   1.2. Synchronize text equivalents with multimedia presentations (captions).
>   1.3. Synchronize a description of essential visual info with multimedia
>   presentations (auditory descriptions).
>   1.4 Use style languages to control layout and presentation (create for
>   specific devices if able).
>   1.5 Ensure that content transforms gracefully (no matter what technology
>   the user has or doesn't have, they are able to interact with your content)
>
>   Guideline 2. Device independence. Design content that can be interacted
>   with without a mouse, only with a keyboard, only through voice, without
>   voice, or with or without other devices, according to the needs and
>   preferences of the user.
>
>   checkpoints:
>   2.1 Use markup languages according to specification.
>   2.2 Use markup or a data model to provide the logical structure of content.
>   2.3 Minimize the use of or give the user control of content that may
>   interfere with their ability to focus (animations, blinking text, scrolling
>   banners, etc.)
>   2.4 Give the user control of mechanisms that cause extreme changes in 
> context
>   2.5 Provide consistent interaction behaviors (navigation mechanisms,
>   interface controls)
>   2.6 Provide various search options
>   2.7 Give users control over how long they can spend reading or interacting
>   with content.
>   2.8 Use device independent event handlers
>   2.9 Design assistive-technology compatible user interfaces
>
>   Guideline 3. Comprehension. Design content that is easy to understand.
>
>   checkpoints:
>   3.1 Use consistent presentation
>   3.2 Emphasize structure through presentation, positioning and labels
>   3.3 Divide information into smaller, more manageable chucnks
>   3.4 Write clearly and simply
>   3.5 Use graphics to illustrate concepts
>   3.6 Summarize complex information
>   3.7 Define key terms, abbreviations, acronyms, and specialized language
>
>
>   Please complete the following questionnaire:
>   Question 1: Does this proposal oversimplify the guidelines, creating
>   something that is too general to understand?
>   yes __
>   no __
>
>   Question 2: should we proceed with a trimmed down structure similar to the
>   one proposed in this e-mail in the next draft?
>   yes __
>   no __
>
>   reason:
>
>   </questionnaire>
>   Thank you,
>   --wendy
>   --
>   wendy a chisholm
>   world wide web consortium
>   web accessibility initiative
>   madison, wi usa
>   tel: +1 608 663 6346
>   /--
>
>
>--
>Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
>W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
>until 6 January 2001 at:
>W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, 
>France

--
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple 
University
(215) 204-2247 (voice)                 (800) 750-7428 (TTY)
http://astro.temple.edu/~kasday         mailto:kasday@acm.org

Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
http://www.w3.org/WAI/ER/IG/

The WAVE web page accessibility evaluation assistant: 
http://www.temple.edu/inst_disabilities/piat/wave/
Received on Thursday, 4 January 2001 12:53:43 GMT

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