W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: Breaking Dependencies - @summary (FW: Call for Review: German WCAG 2.0 Candidate Authorized Translation)

From: Leif Halvard Silli <lhs@malform.no>
Date: Tue, 04 Aug 2009 20:59:33 +0200
Message-ID: <4A788515.1020905@malform.no>
To: "L. David Baron" <dbaron@dbaron.org>
CC: John Foliot <jfoliot@stanford.edu>, 'HTML WG' <public-html@w3.org>
L. David Baron On 09-08-04 19.44:

> On Tuesday 2009-08-04 10:16 -0700, John Foliot wrote:


>> L. David Baron wrote:
>>> I'd like to further understand the definition of contradict here:
>>>
>>>   (1) Does HTML5 contradict WCAG if it removes a feature whose use
>>>   is recommended or required by WCAG?  (I'm pretty sure the answer
>>>   to this one is yes.)
>> Yes, and this is the partial case with @summary today.


I disagree with John. I would say that option (2) that is the 
particular case with @summary today:

>>>   (2) Does HTML5 contradict WCAG if it improves a feature whose use
>>>   is recommended or required by WCAG, and the improvement makes what
>>>   is required / recommended by WCAG no longer conforming?
>> Can you provide an illustration/example here?  I cannot see how making
>> something better would at the same time make it non-conforming.
>> (Improving the taste of Diet Pepsi does not make it any less "diet" does
>> it?)

However, I think that option 3 is the most /relevant/ option to 
your question about what would (not) constitute a contradiction:

>>>   (3) Does HTML5 contradict WCAG if it improves a feature whose use
>>>   is recommended or required by WCAG, but the improvement leaves
>>>   what is required / recommended by WCAG as conforming?


If we rule out the question of whether the feature has actually 
been improved, and if HTML 5 would consider it as conforming for 
*authors* to use "what is required/recommended by WCAG" then HTML 
  5 would not, per the letter, be contradicting WCAG.

Currently, though, for @summary, HTML 5 tells authors to not 
follow WCAG. That is a direct contradiction.


> So my example here is actually summary.  Suppose we define "feature"
> a little more broadly, so that instead of saying the feature is "the
> summary attribute on the table element" we say the feature is "use
> appropriate HTML markup to provide an overview of the structure of
> data tables".
> 
> Ian's claim is that HTML5 offers *better* mechanisms for summarizing
> tables than the summary attribute.  In other words, my understanding
> of what Ian says is that he claims summary falls into this second
> category.


I have tried to refute his current solution [1]. More than once, 
actually. But I can't say that I have seen him countering my 
arguments. May be he prefers to discuss with Janina.

 
> The best way to convince me that it instead falls in the first
> category is to explain why Ian's mechanisms [1] are not an
> improvement, preferably by showing examples where @summary works
> better than Ian's replacement for it.


See the message I pointed to above[1].

There isn't much more to "Ian's mechanisms" (why plural?) than 
"simply drop the summary text inside the caption element".

This leaves it up to the author to "invent" the summary wheel each 
time. ("What element do I use for summary today? Do I perhaps 
simply drop it inside caption without any element?") This makes it 
difficult to check if one has actually provided a summary. It also 
makes it difficult to have a default way to select the summary via 
CSS. Or to have any default styling in UAs.

The obvious solution is to replace one feature (attribute or 
element) with another feature (attribute or element). Instead, 
what Ian is proposing is little more than an authoring advice and 
a "permission" to place the summary text inside the caption.

The first sentence of the Caption text begins

   "The caption element represents the title of the table"

It doesn't rhyme with that sentence to, further down, say that one 
can use the caption for providing context. (Even if we have a 
@title attribute that is meant for "advisory information", that 
doesn't mean that a the word "title" is synonymous with "advisory 
information".)

Against the requests for a designated summary container, Ian has 
said [2]:

>> This would make sense if the summary content was rendered very differently 
>> than other content in specific media, but in practice in ATs the summary 
>> content is just read out like caption content,

I think the question here should be if they rendered them 
differently *at all* - and they do. *How* differently, becomes 
subjective. AT only need to make it distinguishable. But AT's 
ability to access the summary is not the only reason that there 
should be a designated container - as told, a designated feature 
is also a benefit for authors and, I think, UA vendors.

So, the thing that is better with @summary, apart for things 
relating to HTML 4 compatibility and compatibility with WCAG, is 
that it is a designated container. (I know, however, that many 
within WAI are interested in improving the summary feature. And a 
yes to @summary is not a no to improvements of the summary feature.)

[1] http://lists.w3.org/Archives/Public/public-html/2009Aug/0126
[2] http://lists.w3.org/Archives/Public/public-html/2009Jul/0148
-- 
leif halvard silli
Received on Tuesday, 4 August 2009 19:00:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 October 2014 16:24:50 UTC