summary attribute compromise proposal

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.

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="".

2) HTML5 will not make any flat direct statements that summary=""  
shouldn't or can't be used. Instead, it will say that authors SHOULD  
use one of the other techniques when possible and appropriate. 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.
      (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>. 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. Describing the  
structure of the table, if it is easy to grasp visually, may not be  
useful to everyone.

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.

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.

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?

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.


I'd particularly like to hear from John Foliot and Ian Hickson whether  
this would be a satisfactory outcome.

Regards,
Maciej

Received on Tuesday, 4 August 2009 18:04:19 UTC