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

Re: summary attribute compromise proposal

From: Charles McCathieNevile <chaals@opera.com>
Date: Tue, 04 Aug 2009 17:50:36 -0400
To: "Maciej Stachowiak" <mjs@apple.com>, "HTML WG" <public-html@w3.org>
Message-ID: <op.ux5qymnswxe0ny@widsith.local>
On Tue, 04 Aug 2009 14:03:37 -0400, Maciej Stachowiak <mjs@apple.com>  

> I believe there are two different value systems in conflict in the  
> summary dicussion:
> A) HTML5 should guide authors toward choices that will result in the  
> best accessibility outcomes, based on reasoning from the best evidence  
> we have available. Argument that are not outcome-driven or evidence- 
> based are seen as irrelevant, from this point of view.
> B) If HTML5 provides advisory guidance on how to use HTML constructs to  
> make accessible documents, it should not directly contradict other W3C  
> guidance on accessibility. It's ok, from this point of view, to expand  
> on guidance, but direct contradiction is seen as giving an inconsistent  
> message.

Actually, I think this is a false dichotomy, and is not an accurate  
representation of the differences that lead to disagreement. However, that  
fortunately doesn't matter in deciding on the proposal to resolve the  
problem at hand. So...

> I don't think we can always reconcile these two value systems. Sometimes  
> there is no solution that will meet both goals.
> In this case, I believe a solution may be possible which can satisfy  
> everyone. Here is my proposal:
> 1) HTML5 will continue to list and advise use of new techniques that can  
> be alternatives to summary="".

This is perfectly reasonable. Strongly support.

> 2) HTML5 will not make any flat direct statements that summary=""  
> shouldn't or can't be used.

I support this.

> Instead, it will say that authors SHOULD use one of the other techniques  
> when possible and appropriate.

The 'where possible and appropriate here' is critical. I suspect we will  
disagree on the details of that, but I can live with that kind of  
disagreement in this case.

> In particular, it should advise authors to consider:
>       (a) Is a particular piece of information useful to the blind or  
> visually impaired? -- If not, it shouldn't be included in summary.  
> Authors must not put useless text in summary to give a pro forma  
> appearance of accessibility.

This is good advice that could be re-used in other situations too.

>       (b) Is a particular piece of information useful in a visual  
> rendering as well? For example, is it useful to people of normal  
> ability, or to other handicap groups, such as the cognitively disabled?  
> -- If so, the information should be included in a way that is available  
> to everyone, such as <caption>.

I strongly support this.

> If the information would be potentially useful, but possibly  
> distracting, it can be made available to everyone but hidden by default,  
> for example using <details>. For example, describing the conclusions of  
> the data in a table is useful to everyone. Explaining how to read the  
> table, if not obvious from the headers alone, is useful to everyone.

These are good examples and I like them.

> Describing the structure of the table, if it is easy to grasp visually,  
> may not be useful to everyone.

Indeed, this may be a use case for a summary attribute (among other  
possible methods). I don't see why a sumary attribute would in fact be  
handled any differently to the content of a details element, except that  
it is of course recognised and handled in some way by existing technology.

> In other words, rather than focusing on what authors shouldn't do, the  
> spec will focus on what they should do instead. I believe this achieves  
> the goal of promoting better accessibility outcomes, without directly  
> contradicting WCAG2.

A slight quibble, since there are times (as per the third example above)  
where a summary attribute might be the best solution as well as others  
where it is not.

> 3) HTML5 will continue to include a mandatory warning for summary="".  
> The purpose is not to completely prevent authors from using summary="",  
> but rather to bring alternatives to their attention, as described above.

I don't support this, but I can live with it.

(If there are similar mandatory warnings for canvas with no clear fallback  
content, a lack of @alt, the font element, and various other things that  
are bad style, I might move to support it. I don't see it as feasible to  
reach that agreement, so I am happy to simply compromise on this point).

> 4) The goal of HTML5 in this case is to promote good accessibility  
> outcomes based on evidence. Telling someone that the technique they are  
> using is dumb or wrong, even by implication, is not necessary to serve  
> this goal, providing relevant information is what serves the goal. Thus,  
> the spec will be changed to avoid disparaging summary in unnecessary  
> ways. For example, describing summary="" only in the "obsolete features"  
> section and not in the "table" section gives the appearance of  
> disparagement. There may not be an evidence-based reason to stop doing  
> this, but I don't see an evidence-based reason to continue doing it,  
> either. So, why needlessly give offense if the goal can be served either  
> way?

Agreed. The obvious actionable outcome being

4a) summary will be listed in the table section, with examples provided  
for what should and should not be in it.

> 5) HTML WG will propose a WCAG2 Techniques update to the appropriate  
> working group of WAI (is it PFWG or WCAG WG?) to better reflect HTML5  
> features for describing tables. I can draft a message to communicate  
> this, but I'd like to request:
>      (a) John Foliot as a co-signer (assuming he agrees with the  
> language), since he said he'd support an effort to update WCAG2, and I'd  
> like to make clear that this is a coordination effort, not an attempt to  
> pick a fight.
>      (b) I'd like to ask for some official blessing from the HTML WG for  
> this message, since WAI apparently takes official input from Working  
> Groups more seriously than input from individuals.

This makes sense... although getting a blessing must depend on the actual  
message text.

Thanks for this proposal. It includes a bunch of stuff that I think is  
good, nothing I think is new, and a few things I think are bad. But  
overall I can live with it.



Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Tuesday, 4 August 2009 21:51:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:49 UTC