Re: Movement on @summary

At 07:56 PM 8/6/2009 +0300, Henri Sivonen wrote:
>On Aug 6, 2009, at 03:16, John Foliot wrote:
>>At this time, the 'warning' remains undefined and unwritten.  *If*
>>@summary is ultimately deemed obsolete but conformant (again, simply
>>another undecided possability at this time) then this 'warning
>>language' will need to be determined (hopefully by consensus, and not by 
>I don't like the idea of HTML 5 prescribing UI strings for any class
>of product, but what would you write (max 2 sentences) as the message
>(let's avoid the word "warning" for now) emitted by a validator upon
>seeing an attribute called summary on an element called table?

Henri, I agree with your predisposition to avoid prescribing UI strings.
Nonetheless, it could still be useful to indicate the elements of a message
that may be appropriate for different classes of 'problem'

As I have mentioned elsewhere/elsewhen, I really think that there should be
a subdivision of classes for which messages are appropriate. Moreover,
I think that it would be helpful to design a message hierarchy so that 
can be switched from delivering every message in its most verbose form,
to only emitting Level 1-3 messages in succinct form. We could suggest
English-language variations of succinct and verbose messages as examples
and leave it up to the developer to implement the messages as they see fit.

In this case, the presence of a summary attribute might provide some/all of 
the following advice:

         - The location of the <TABLE summary="..." ...>  use.
         - The [importance] level of the message, for recognition and 
         - Message ID

         - For now, mention that this attribute is expected to be phased 
out of HTML in future
              in favor of other markup mechanisms, which could be listed as 
they become available.
         - When the future arrives, mention that @summary is now obsolete, 
and list alternatives.

         - A verbose message might include a paragraph that exorts authors 
to exhaust all
           other approaches before resorting to the use of @summary, and to 
avoid using
          @summary except as recommended in [URI TBD].

I would find it especially helpful to collect all accessibility-related 
messages for debugging.
Thus, I am in favor of designating one class of messages for QA over 
Moreover, I am not precluding the notion that some messages belong to more 
than one class.

I have not had much useful feedback on this idea, and while I am not 
offering to do
the work for you, I would appreciate your constructive criticism of this idea.



Received on Thursday, 6 August 2009 18:15:37 UTC