Re: Please Vote: Process for new guidelines and rules [was Re: Guidelines Implementation

Actually, I am going to vote "nay."  I think it is important that tools not
limit their ambition to mere guideline conformance.

Caveat:  This idea is really centered in the Authoring Tools topic.
Because I think that the subject areas of AU and ER do and should overlap,
I'll continue the thread here and copy there.

I don't think that the ER nominations or AU guidelines, checkpoints and
techniques should say something that conflicts with what the WCAG says,
when the WCAG has spoken.  We can extend this to "clarifications and
rulings" from the "life after REC" activities yet to be organized.  [Note:
I believe that in the IG plenary at Toronto, Judy said that WAI-CG should
take up the relationship of GL,ER,AU as regards "guidance for tool
implementation of the WCAG."]

But on the other hand, in an interactive dialog one encounters the whole
question of "warnings" and other ways of stimulating the author/user which
are new territory that the WCAG has not dealt with.

My favorite one of these at a high level is the idea that authoring tools
should transform the document-in-process in ways which emphasize logical
structure.  This logical structure is the foundation for the "transform
gracefully" techniques which are developed in the UA guidelines.  A clear
example of this is the "use hierarchy properly" concept.  One can try do do
this with formal rules about the existence and cardinality of various Hn
elements.  A much stronger strategy, however, is to offer the author an
auto-extracted internal navbar which matches what the adaptive user agent
techniques will assume in the way of hierarchy.  If the author finds this
outline view helpful in navigation, they will be likely to write in a
well-structured way.  Similarly with the internal logical structure of a
table.  If the authoring tool highlights the data:header relationships in
the default schema for the table as the user is creating the table, then
the author will fix gaps in the logical information.  Otherwise layout will
be the only semantics one can trust that the author comprehended.

<aphorism>
Do not expect what you do not inspect.
</aphorism>

<corollary>
Do not expect logical depth in a document unless the author has inspected
the deep structure by accepting multiple presentations that change the
surface details.
</corollary>

We should try to be scrupulous to adhere to the WCAG provisions as the GL
group determined them.  But ER and AU tools should by no means be limited
to implementing what is in that document.  There are lots of things that
can be done in a tool which advance the intent of the content guidelines
without being strictly derived from those guidelines.

Al

At 11:23 AM 5/21/99 -0400, Leonard R. Kasday wrote:
>Al's observation suggests the following process:
>
>1. We only include in our recommendations checks that are presently in the
>guidelines or techniques document.
>
>2. If we have a suggestion for additional rules or guidance, we bring them
>to the attention of the author guidelines (AG) group.
>
>3. When AG puts it in the document, we then add it to our techniques doc.
>
>4. Discussions about pros and cons of new guidelines/suggestions would take
>place in AG space.
>
>For starters
>All in favor email "Aye"
>All opposed email "Nay"
>

>If there are any "Nays" lets etalk about it.
>
>Len
>
>
>At 09:34 AM 5/21/99 -0400, Al Gilman wrote:
>>At 01:41 PM 5/20/99 -0400, Bruce Bailey wrote:
>>>To your Check Point 1.1A:
>>>Valid ALT text:
>>>Allowed - ALT attribute value of "" 
>>>Only IF (NOT inside of A HREF) OR link is also referenced via text.  This
>>>can be tested by algorithm, so it is either allowed or not allowed.  (Human
>>>intervention/consideration is NOT needed.)
>>
>>I believe that human consideration is always advisable for ALT="".  You can
>>test for situations where it is definitely bad, but you can't test
>>automatically for where it is good.
>>
>>>Suggested for discussion:
>>>ALT="" is NOT allowed.  (This rule is much simpler!)  ALT=" " is
>>>permissible as an alternative.
>>>ALT=" " is treated as "suspicious" and generates a warning to the effect
>>>of: "Is this graphic purely decoration and devoid of content?"
>>>
>>
>>It seems to be the small differences that generate the most heat.  This is
>>one of those.  After much digging I found what I believe to be the clearest
>>statement of the conclusion that was reached on this topic in the GL group:
>>
>><http://www.w3.org/WAI/GL/wai-gl-techniques-19980918.html#spacer-images>
>>
>>That is to say, ALT="" has not been disallowed because there are cases
>>where it is the best practice.  Admittedly some of the argument hangs on
>>the fact that we can't rely on stylesheets to make layout tables obsolete
>>until they are better supported in user agents.  But all that reasoning
>>still stands.
>>
>>The problem is, nowhere in the RECcommendation that Tim signed is this
>>explicitly stated.  It takes a) searching the working group archives and b)
>>authentication by the chairs that this decision was made and then not
>>reconsidered and overturned by a later deliberation of the group, to bring
>>the consensus resolution to light.
>>
>>This is why I was emphasizing the need for a strong GL presence in the
>>process of "life after REC" including this step of detailing the
>>automatable tests related to the checkpoints and how they are related.
>>
>>Al
>>
>>
>>>Rational:
>>>With the Lynx text browser, ALT="" hides the image (and any embeded link). 
>>>The image is completely invisible unless one issues a "view source"
>>>command.  Any associate link is likewise invisible, unless one issues a
>>>"view links" command.  (Exception: iff ALL links on a page are hidden in
>>>this way, Lynx will generate a warning message.)
>>>ALT=" " will generate [ ] in Lynx.  This might be viewed as unattractive
>>>and pointless, but at least the user knows that something is there.  If the

>>>[ ] is part of a link, it will (with the default settings) be assigned a
>>>link number and is (in any case) be able to be selected and activated as is
>>>the case with any other hypertext link.
>>>
>>>Bruce Bailey, DORS Webmaster
>>>http://www.dors.state.md.us/
>>>410/554-9211
>>>
>>>----------
>>>From: Chris Ridpath <chris.ridpath@utoronto.ca>
>>>To: WAI ER IG List <w3c-wai-er-ig@w3.org>
>>>Subject: Guidelines Implementation
>>>Date: Tuesday, May 18, 1999 1:55 PM
>>>
>>>Hello all,
>>>
>>>As part of the evaluation and repair process, we need to create a set of
>>>specifications for implementing the WAI page author guidelines. The specs
>>>would be used by A-Prompt and Bobby in the design of our software. The
>>>specs should be written with the following goals:
>>>
>>>- precise enough for use by software programmers
>>>- simple enough for everyone to understand and comment upon
>>>- complete implementation of the WAI page author guidelines
>>>
>>>I've started a document that might fulfil these goals and would like your
>>>comments and suggestions. The doc is stored at:
>>>http://aprompt.snow.utoronto.ca/Implementation.html
>>>
>>>This document is not complete and is a rough first draft!
>>>
>>>I would like to see the document finished reasonably soon (end of June
>>>perhaps) so that we can code the software.
>>>
>>>Please take a look and let me know if you have any comments.
>>>
>>>Chris
>>> 
>>
>>
>>
>-------
>Leonard R. Kasday, Ph.D.
>Universal Design Engineer, Institute on Disabilities/UAP, and
>Adjunct Professor, Electrical Engineering
>Temple University
>
>Ritter Hall Annex, Room 423, Philadelphia, PA 19122
>kasday@acm.org        
>(215} 204-2247 (voice)
>(800) 750-7428 (TTY)
>

Received on Friday, 21 May 1999 12:51:08 UTC