Re: summary attribute compromise proposal

On Aug 5, 2009, at 1:09 AM, Ian Hickson wrote:

> On Tue, 4 Aug 2009, Maciej Stachowiak wrote:
>>
>> Here is my proposal: [...]
>>
>> 2) HTML5 will not make any flat direct statements that summary=""
>> shouldn't or can't be used.
>
> I think we need to discourage use of summary="" to improve the overall
> accessibility of the Web.

I agree with the evidence you've presented that summary, as practiced,  
does not lead to overall good accessibility outcomes. I'm not going to  
quote your restatement of your argument, because I personally accept  
those premises. Let's frame the problem and potential solution in 3- 
part terms: problem, goal, and means to achieving the goal.

Problem: Summary as practiced today often leads to poor accessibility  
outcomes. Often authors include either useless information (failing to  
notice the uselessness because it is hidden) or information that would  
be useful in visual media too.
Goal: Get authors to describe tables in visible text.
Means: ???

Where we're parting ways now is on the means. Your preferred means are  
that the HTML5 spec should, by itself, take quite a strong stand  
against summary. I am proposing taking a marginally softer stand,  
because on the whole I believe it will promote better outcomes.

Let's examine the specific points of departure, so we can be clear on  
the stakes:

> By continuing to encourage summary="", therefore, we are doing a
> disservice to the AT user community.

There's a very wide range of options on the encourage-discourage  
spectrum. On the part of point 2 that you quoted, we're basically  
talking about a change from: "authors should not use summary" to  
"instead of summary, authors should use one of the visible table  
description techniques listed above whenever possible." In pure  
conformance requirement terms, these statements are formally  
equivalent. The difference is one of tone. I do not think the  
alternative amounts to encouragement to use summary.

As for why tone is important:

> In every respect other than the various places in the proposal where  
> it is
> suggested that we should not disparage summary="", I'm fine with it.

You don't have to disparage something to discourage it. It's arguably  
not even the most effective way to discourage. The most effective way,  
I believe, is to actively encourage a constructive alternative. Let's  
take an analogy from the field of language advocacy. There are people  
who have a goal to get people to stop using Perl, and use Python  
instead. I've seen this type of advocacy take two forms:

(1) Disparage Perl, by highlighting and making light of it's perceived  
flaws.
(2) Describe the strong points of Python, and how they can benefit you  
while maintaining many of the things you like about Perl.

It's been my experience that type 2 advocacy is far more effective.  
Type 1 may be more blunt and honest, but it leads people who are  
bought into Perl to close their ears and not hear the message.

One of the revolutionary and wonderful things about HTML5 is that its  
normative conformance requirements are designed to consider second- 
order effects. In other words, the spec is not written imagining how  
we hope a feature would be used in an ideal world, but rather what  
authors will do with it (or actually have done with it in practice).

I think that same idea needs to be applied to the editorial style of  
the spec. The first-order effect of the spec taking a harder line on  
summary is that authors reading the spec will be more strongly  
discouraged from using summary. But the second-order effect is that  
much of the accessibility community will be set against this  
provision, will see HTML5 as their enemy, and will take their own hard  
line in response.

On the other hand, by taking a more moderate approach, we can get much  
of the accessibility community to buy in to the basic message. We can  
get WAI to promote the message that authors should use visible  
summaries when possible. We can get the WCAG techniques note to list  
these techniques as good practices. A lot more web developers look to  
WCAG for their accessibility guidance than language specifications.  
You could keep trying to browbeat the WAI folks through logic, but for  
the past 2 years or so this hasn't worked. They simply don't share  
your basic premises about Web technology the way I do. But with a  
small change, one that is more about tone and style than material  
requirements, you can get a lot of them to actively buy in.

I think in this case, it would be against the spirit of HTML5 to only  
consider the first-order effects of stronger discouraging language,  
and not consider the second-order effects of positively framed (but,  
let's face it, roughly equivalent in terms of requirements) language  
that can get a lot more people on board with the goal. It seems to me  
that, fully considering all the effects, taking a softer stand will  
uphold HTML5 principles and do a better job of promoting better  
accessibility outcomes in practice, not just in the ideal world where  
the spec is the only thing that matters.

Thus, I hope you will reconsider.

Regards,
Maciej

Received on Wednesday, 5 August 2009 21:13:47 UTC