RE: obsoleting and the text/html MIME type (re Taking another round at @summary)

John Foliot, Thu, 7 Jan 2010 13:05:13 -0800 (PST):
> David Singer wrote:

This has become a permathread much because we have failed to operate 
with principles. The principles we should operate with are the WCAG 2.0 
principles.

@aria-describedby is not compatible with the principles of WCAG because 
@aria-describedby doesn't let AT 'programmatically determine' [1] the 
element it points to as _a table summary_. Of course, the 
@aria-describedby element can programmatically be found. But whether 
the description actually points to a table summary is not evident.

Feel free to disagree - but please justify why @aria-describedby is in 
accordance with the principles of H73! 

*If* a current ARIA attribute should be considered fitting for the 
task, however then I would argue that it would have to be 
@aria-labelledby - as @summary is a specialized kind of label.

But unless we add very specific rules for how @aria-labelledby should 
be used and interpreted, then @aria-labelledby or any other ARIA 
attribute is not the solution for this.

>> [...] If a specification feature has existed for years, and has
>> got little adoption, then I think we should ask whether we'd better try
>> something else. 
> 
> Nobody has suggested that other possible solutions cannot be attempted.
> Aria-describedby may in fact be one of those better solutions, and if so
> then great. [...]

Where is the *criteria* for evaluating whether e.g. @aria-describedby 
is good enough? 

>> Arguing "it just needs education" is not good enough, after
>> years have passed.

> education, first and foremost, is truly the only real solution
> to the larger problem.  
> 
> In this regard, @summary *might* have a slight leg-up on newer techniques,
> only because as a technique for success it has been around longer: it has
> already been incorporated into other 'teaching' materials both within the
> W3C (http://www.w3.org/TR/WCAG20-TECHS/H73.html) [...]

Regarding your pointer to WCAG 2.0 technique H73: If H73 is so well 
known, then how come we don't apply its principles to the debate? We 
could perhaps find a way to recommend one or several new techniques 
instead of - or in addition to -  @summary. But then we must  construct 
and evaluate these techniques according to the principles behind 
technique H73.
 
[...]
> The financial impact of that decision cannot be dismissed: there is a
> significant and real cost to asking governments to go back and re-open
> policy documents; there is a financial burden to translating guidelines
> and other educational materials into French, Spanish, German, Russian,
> Chinese, and on and on...

That's a reason to ensure that any new solution is compatible with the 
principle of H73!

> And for all of that, what do we gain?  We replace:
> 
>  <table summary="Description here">....</table>
> 
> ...with this:
> 
>  <table aria-describedby="tableDesc">....</table>
>  <p hidden id="tableDesc">Description here</p>
>  
> [Jonas Sicking:
> http://lists.w3.org/Archives/Public/public-html/2010Jan/0158.html] 
> 
> Has anyone actually done a cost-benefit analysis? (I doubt it) It seems
> instead that the argument keeps coming down to one of religion and
> opinion. 

It is not necessary to do any cost-benefit analysis because that 
technique is not compatible with the principles behind H73. (IMHO, of 
course.)

>> Yes, if the position is (and I don't have the evidence) "summary is
>> rarely there when it's needed, and when it's there, it's unhelpful
>> (and thus 'polluting')" then we need evidence to that effect.  
> 
> Ian Hickson has published data that purports to support that claim, but
> how much real value does that claim bring? [...]

I personally think that Ian has a point. However, the solutions that he 
has offered, are not compatible with the principles behind technique 
H73.

>> I think that we are trying very hard to make conforming HTML4 pages
>> 'valid' even if they contain deprecated features.  If we are not, we
>> should be.  My perception if that one of the cornerstones of HTML5 is a
>> "don't break things needlessly" -- either the existing web, or break
>> from the HTML legacy of specifications.
> 
> ...and retaining @summary as a viable attribute of the table element,
> without the 'editorialization' of a warning which may or may not be
> appropriate, allows us at least one means to achieve those goals. [...]

I am concerned that we have become so focused on removing the 
'editorialization' that we are willing to accept - as alternative 
solutions - techniques that are incompatible with the principles behind 
why WCAG 2.0 technique H73 recommends using @summary.

In my view, the best way to introduce a new feature would be to - 
FIRSTLY - make sure that the solution can _also_ be found via 
heuristics. This can be assured by following WCAG 2.0's advice: [2]

]]
The text description should be near the information it is describing 
(when the page is linearized), such as in the parent element or in the 
adjacent element.
[[

SECONDLY - we make sure that the solution will make _supporting_ 
clients 'programmatically determine' it as a table summary. I wouldn't 
hesitate to support such a solution.

[1] 
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#content-structure-separation-programmatic

[2] 
http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/content-structure-separation-programmatic#content-structure-separation-programmatic-intent-head

-- 
leif halvard silli

Received on Friday, 8 January 2010 01:54:37 UTC