logic in specification writing [was: Re: summary attribute required? history.]

Here is a topic that is closely linked with the vocabulary we use in writing
our specifications.  It's highly technical in a sense but it makes most sense
to apply any practices we decide on across the board.  This is a topic for the
W3C QA activity if there is one, as well.

There have been a lot of examples of difference in interpreting the
specifications as far as understanding what is normative or definitive and
what
is descriptive or illustrative.

The definition of 'equivalent' in WCAG 1.0 being a celebrated case in point.

In the 'is SUMMARY _required_' debate we have a similar example where many
readers will unconsciously promote an example to rule status.

This is how regulations get to be written in stilted prose.  But writing in a
mechanical, very overt style, will reduce the incidence of people reading the
same words to mean different things.

What I am particularly thinking of is field labels for the sub-parts of a
paragraph which introduce and mark the sub-parts that are in different modes.

Possible parts are:

[paragraph index] [paragraph title]

[contextual setup]

[definitive statement of the clause or rule 'created' by this paragraph]

[examples of application of this rule]

[other notes.  Notes do not extend or restrict the rule as stated, but clarify
the rule or its interaction with other rules.]

Note:  The definitive statement of the rule may depend on things said of a
declarative or descriptive nature in the contextual setup section.  The
definition of what is required may not depend on the examples or other notes.

Al

At 10:41 AM 2001-03-05 -0500, Leonard R. Kasday wrote: 
>
> Al wrote:
> quote
> The argument against requiring a value of the SUMMARY attribute per se for
> all
> tables is that the SUMMARY is supplementary to the caption element or TITLE
> attribute for the table.  
> unquote
>
> However, WCAG 1.0 says
>
> quote
> 5.5 Provide summaries for tables. [Priority 3] For example, in HTML, use the
> "summary" attribute of the TABLE element. Techniques for checkpoint 5.5 
> unquote
>
> That seems to say that summary is required. 


AG::  But it does not.

>
> Personally, I'd agree with Al that summary isn't always needed.  There's the
> case Al mentioned where  title and caption might suffice.  There's also
> another case: where the text of the document happens to describe the table. 
> In other words, I see summary like a longdesc: a longer explanation that
> isn't always needed.
>
> Anyway, the next time I'm rating a page for triple A, do I need to require
> summary?  I'd look to the folks doing HTML techniques to answer this for
> 2.0... we can then issue an errata against 1.0 if necessary.
>
> In the meantime, I'm going to have to go by what I see as the plain meaning
> of the words and require a summary for triple A compliance even in cases
> where I have say that it isn't really necessary.  I hope this gets resolved
> before I run across this in a real case.


AG::

I have to object to your reading of the "plain meaning" of the English.  

It does not say "for [any] HTML use the SUMMARY attribute on [all] TABLEs."

What it says is, 'For example, in HTML, use the "summary" attribute of the
TABLE element.'

This leaves plenty of room for "in HTML, use the CAPTION subelement within a
TABLE" to be yet another conforming example.

What it says, in plain English, is that it provides an illustrative example,
and not "a rule for all HTML TABLEs."

Al

PS:  This illustrates a general pattern I am picking up.  People make lots of
quantifier errors in reading English.  Probably natural language in general. 
People don't reliably understand the difference between the restrictive effect
of i.e. and the non-restrictive effect of e.g.  Even when you spell them out,
for example as "for example."


>
> Len
>
> At 12:14 AM 3/1/01 -0500, Al Gilman wrote:
>>
>> At 03:46 PM 2001-02-28 -0800, you wrote:
>> >I found this in the archives and am curious as to why people were opposed 
>> >to requiring "summary" attribute with tables? Also I wonder what the "HC" 
>> >group is/was?
>> >
>> >ASG:: FWIW you can track this starting at 
>>
>>
>>
>> ><<http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/thread.html#
>> start>http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/thread.ht
>> ml#sta
>>
>>
>> rt><http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/thread.html
>> #sta>http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/thread.htm
>> l#sta
>> rt 
>> >So far of the three HC participants we have heard from there are three
>> >'no' indications on the required? question.  Makes consensus the other
>> >way unlikely... On the other hand it would be good to implement his other 
>> >suggestion
>> >and put in a non-trivial 'summary' value in the example tables. -- Al
>> >
>> >
>> >--
>> >Love.
>> >                 ACCESSIBILITY IS RIGHT - NOT PRIVILEGE
>> > 
>>
>> HC was a group to do an accessibility review of HTML 4.0 and CSS 2.0 as
they
>> were approaching W3C Recommendation status.  You can find a summary of the
>> results before we re-treaded the group with a more long-term charter as PF
>> at
>>
>>
>>
>> <<<http://www.w3.org/WAI/HC/report.html>http://www.w3.org/WAI/HC/report.h
>>
>>
>> tml><http://www.w3.org/WAI/HC/report.html>http://www.w3.org/WAI/HC/report
>> .html>.
>>
>> The argument against requiring a value of the SUMMARY attribute per se for
>> all
>> tables is that the SUMMARY is supplementary to the caption element or TITLE
>> attribute for the table.  See the discussion of CAPTION, not SUMMARY in
HTML
>> 4.01.  In other words, the caption or title may suffice, you don't always
>> need
>> an expansion on these in a SUMMARY attribute.  That is the theory as I
>> understand it.
>>
>> Al
>>
>> c.f.
>>
>> <<<http://lists.w3.org/Archives/Public/w3c-wai-ig/2000OctDec/0553.html>ht
>> tp://lists.w3.org/Archives/Public/w3c-wai-ig/2000OctDec/0553.html>http:/
>> /lists.w3.org/Archives/Public/w3c-wai-ig/2000OctDec/0553.html>
>
>
> -- 
> 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)         
> <mailto:kasday@acm.org>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/>http://www.w3.org/WAI/ER/IG/
>
> The WAVE web page accessibility evaluation assistant:
>
> <http://www.temple.edu/inst_disabilities/piat/wave/>http://www.temple.edu/
> inst_disabilities/piat/wave/

Received on Monday, 5 March 2001 14:58:12 UTC