Re: Murky ratings (GF)

        Reply to:   RE>Murky ratings (GF)

GF:
I'm going to start at the end of the memo from Wendy:

Wendy Chisholm says:
>Summary:
>There are several guidelines that fit into a grey area between Recommended
>and Required.  Some should be Recommended today, Required tomorrow, others
>should be Required today but Recommended tomorrow, while others are
>Recommended today and gone tomorrow.  It seems that these transitions
>should be clearly stated in the guidelines, but we are unsure about the
>best way to accomplish this.  

GF:
This problem may remain with us forever simply because we're issuing recommendations in an unregulated industry.  It's difficult to encourage authors to start using a feature that is somewhat supported today (like style sheets) but which will be most likely be fully supported tomorrow because "tomorrow" has no fixed date.  Therefore, we might consider setting actual dates for features to make the transition from "recommended" to "required" and, for some features, "obsolete."  Of course, these dates will have to be determined in conjunction with browser manufacturers, which is a whole other problem.  But setting actual dates might remove the wishy-washiness of the guidelines, so I think it's worth discussing.  When these dates occur, new guidelines can be uploaded to the WAI site and an announcement issued stating that the new guidelines are now in effect.  This might also be something for the EO group to discuss.

WC:
>New (would be 13)
>[Recommended]
>Ensure that text and background colors or patterns contrast well.
>Issues:  Currently this is tucked back in the "Good Web Site Design
>Practices."  It seems this ought to be a guideline and it ought to point to
>the Lighthouse site that provides guidelines for how to do this.

GF:
I agree that this should become a guideline on its own but under the rating "required."  Ensuring good contrast is something relatively simple that authors can do today to increase site accessibility.  Offering simple solutions to authors is a good way to coax them onto our side.

WC:
>Section 6, Links
>[Recommended]
>  Create link phrases that make sense when read out of context, but that
>are not too verbose.
>Issues:
>People keep raising the issue that this should be required, although the
>argument still exists that it doesn't seem possible for *all* links to make
>sense when read out of context.  However, if we raise it to required and
>change it slightly to say, "Where possible, create link phrases that make
>sense when read out of context, but that are not too verbose."  Although it
>also makes it sound kind of iffy and fluffy (required where possible, and
>sounds contradictory).  help?

GF:
I think we are letting authors off the hook too easily here.  We should raise this to "required" because it isn't all that hard to write links which make sense when read out of context.  Today, if your link just says "Click here," you must have given the user some compelling reason to click, yes?  Summarize that reason in a few words and include them in the link.  We're asking authors to think a little bit, but ONLY a little bit.  Most of the other stuff in the guidelines is vastly more complex than this particular item.

Geoff Freed
NCAM

--------------------------------------
Date: 5/4/98 12:51 PM
To: Geoff Freed
From: Wendy A Chisholm

There still exist many concerns about how we are rating and classifying
guidelines. It seems there is a grey area between Recommended and Required,
particularly as it relates to what can be done today and what will be
possible in the future.

Each guideline that seems to posses a problem is discussed followed by the
issues.  These wordings and numbers are from the April 14th release.

1. Style and Structure

1.  [Required]
Use elements and attributes that comply with an HTML 4.0 Document Type
Definition (DTD) and CSS-1.

Issues:
should this be Required, ever?  Should the language change to say, "Use
elements and attributes that comply with an HTML Document Type Definition
(DTD) and CSS-1." so that an author can choose which DTD they want to
comply with?  However, shouldn't we nudge people towards the use of 4.0
since it includes several attributes and elements that were included to
increase accessibility? BUT, if they do not use HTML 4.0 will a page NOT be
accessible?


3.  [Required]
  Nest headings properly.
and 
4. [Required]
  Encode list structure and list items properly.

Issues:
Al asks, "if these rules are broken, [will] somebody's ability to access
the page _be broken_?"
This will depend on the user agent implementation of navigation between
elements.  It might possibly break the page for someone with a cognitive
disability, or it might break the navigation scheme for the UA.  It seems
to be a usability issue but would make things much easier, especially for
UAs. but are they required for accessing the page?

6.  [Recommended]
  Use style sheets rather than converting text to images.
and 
7.  [Recommended]
Use style sheets rather than invisible or transparent images to force layout.

Issue:  These seem to be appropriately marked as Recommended for today's
browsers.  In the future, might they might be Required?  Perhaps we create
a "Recommended today, Required tomorrow" category.  

However, (for #6) if alt-text is provided for the image of the text is this
guideline still required?  This seems to be a guideline that is the most
elegant solution, not necessarily the most accessible, so we would like to
require it on idealistic grounds.  Should we let our ideals for page design
affect our rating system?  We *could* include in the definition of Required
something along the lines of , "to satisfy our  (W3C) philosophy that
content and structure are separate from presentation."   However, it is
only recommended in the HTML 4.0 spec that authors do this, it is not
required.


New (would be 13)
[Recommended]
Ensure that text and background colors or patterns contrast well.


Issues:  Currently this is tucked back in the "Good Web Site Design
Practices."  It seems this ought to be a guideline and it ought to point to
the Lighthouse site that provides guidelines for how to do this.


Section 5, Tables


1.  [Required]
  Associate table cells with row and column labels explicitly.

and 

2. [Required]
  Avoid using tables to format text documents in columns.

Issues:
#1 is doable but not supported, #2 will most likely cause an uproar.
However, #2 is a real problem today but probably less of one in the future.
 This seems to be required today, recommended tomorrow whereas #1 is
recommended today, required tomorrow.

The issue has also been raised about exempting small tables.  There seems
to be a concensus on this, but not about where the line will be drawn.  Is
4 by 4 a reasonable place to draw the line?  How would the content affect
where the line is drawn?


8.  [Recommended]
  Ensure that alternative text does not wrap within tables used to position
graphics.

I hope this one goes away soon, but where is the line that we have to cross
for it to drop out?
It is also hard to test this since there is no way to control presentation
on the user end. Should we replace the word "Ensure" with something less
stringent?


Section 6, Links

[Recommended]
  Create link phrases that make sense when read out of context, but that
are not too verbose.

Issues:
People keep raising the issue that this should be required, although the
argument still exists that it doesn't seem possible for *all* links to make
sense when read out of context.  However, if we raise it to required and
change it slightly to say, "Where possible, create link phrases that make
sense when read out of context, but that are not too verbose."  Although it
also makes it sound kind of iffy and fluffy (required where possible, and
sounds contradictory).  help?


2.  [Recommended]
  Place non-link,  printable characters (surrounded by spaces)  between
links that occur consecutively ...

Issues:  Another one that will go away, but when?  How will we know it's o.k.?


Summary:
There are several guidelines that fit into a grey area between Recommended
and Required.  Some should be Recommended today, Required tomorrow, others
should be Required today but Recommended tomorrow, while others are
Recommended today and gone tomorrow.  It seems that these transitions
should be clearly stated in the guidelines, but we are unsure about the
best way to accomplish this.  

One option is:
 [Recommended] (in the future will be Required)  OR
[Required] (in the future will be Recommended)  OR
[Recommended] Interim

Thoughts???
The editors



------------------ RFC822 Header Follows ------------------
Received: by wgbh.org with ADMIN;4 May 1998 12:48:28 -0400
Received: by www19.w3.org (8.8.5/8.6.12) id MAA01356; Mon, 4 May 1998 12:47:40 -0400 (EDT)
Resent-Date: Mon, 4 May 1998 12:47:40 -0400 (EDT)
Resent-Message-Id: <199805041647.MAA01356@www19.w3.org>
X-Authentication-Warning: www10.w3.org: Host trace16.waisman.wisc.edu [144.92.134.116] claimed to be trace.wisc.edu
Message-Id: <199805041647.LAA07761@trace.wisc.edu>
X-Sender: chisholm@144.92.134.116
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 04 May 1998 11:47:13 -0500
To: w3c-wai-gl@w3.org
From: Wendy A Chisholm <chisholm@trace.wisc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Murky ratings
Resent-From: w3c-wai-gl@w3.org
X-Mailing-List: <w3c-wai-gl@w3.org> archive/latest/426
X-Loop: w3c-wai-gl@w3.org
Sender: w3c-wai-gl-request@w3.org
Resent-Sender: w3c-wai-gl-request@w3.org
Precedence: list

Received on Monday, 4 May 1998 14:02:04 UTC