- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 05 Aug 2009 14:13:00 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: HTML WG <public-html@w3.org>
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