August 4, 2009

Talismans, Active Listening, and a half-time show


First of all, I would like to suggest that today the @summary debate has digressed to something of a fight over a Talisman. Maybe that is in part my fault, and if so I will take the blame. I used that Talisman to force a dialog that has needed to happen for a very long time. Some people might find my tactics offensive, or childish, and others will remain trapped in arguing about what the data and research does or doesn’t say, does or doesn’t do, proves, disproves or concludes. You all need to just stop for a minute and take a deep breath.

What really needs to happen, what I think is now starting to happen, is that two very different camps, with two very different points of view, are actually starting to ACTIVELY LISTEN to what the others are trying to say. After more emails than I care to admit writing over the past few days, some members of the “scientist” camp, notably Maciej, began to understand that my concern was not over what the data said or didn’t say, but instead my issue was what we were telling content authors when the <foobar> came along, and the process by which the Draft Spec came to make those commentaries. I chose @summary, but it could have been anything really, @summary was handy and at hand so I grabbed that.

Now @summary is still contentious, and both sides of the debate have legitimate points to make. History should not be the sole judge of the future, but we must also learn from the mistakes of the past or we are doomed to repeat them – yes, I know, platitudes both, but here I believe germane. But let’s put that aside for just a minute please.

The Clock is Ticking

Right now, I have before the chairs, an alternative draft for consideration to be the next Working Draft. Specific decisions need to be made on that topic which have a time-sensitivity attached to it.

The sole difference between what I have submitted and what Ian has submitted (excluding any last minute commits he has made since Saturday) is that his document:

  1. makes @summary conformant but obsolete (actually, obsolete but conformant – is there really a difference?), which by HTML5 convention automatically triggers a ‘warning’
  2. has language that contradicts the current WAI best practices by telling authors to NOT use @summary

My document on the other hand:

  1. makes @summary fully conformant (so as not to trigger a ‘warning’, and specifically “the” warning that says to not use @summary)
  2. removes the contradicting language surrounding the usage of @summary, so as to harmonize with WAI guidance

Both documents signal that the @summary ‘discussion’ (street brawl?) is currently on-going, using advisory warnings in the draft (a.k.a class=”XXX”).

Those are the choices. If you really stop and look at them, they are actually fairly close together. However, for me, still, the showstopper is the contradictory language between HTML 5 and WAI. It is, IMHO, harmful to the ’cause’.


Maciej finally heard that, I think Ian is beginning to understand that, Sam got it a long time ago, and now you gentle reader must stop and get it too. We need to be working in harmony, and not sound like the symphony orchestra warming up 20 minutes before curtain time. It’s giving everybody a headache.

Maciej has come back with a proposal that addresses ‘how’ we should be conveying authoring guidance to authors surrounding @summary, as well as some (to me) neutral, complimentary (to WCAG) text that offers alternatives to achieving WCAG Success Criteria. He now “gets” that offering constructive alternatives, as opposed to negative instructions, not only helps both the cause of accessibility and supports the WAI efforts, but is actually very useful to the content creators – it gives them the tools to make reasonable and hopefully good decisions, and we need to also provide clear examples so that they have a ‘pattern’ to look at as well. HTML5 is actually pretty good at this most of the time, but not always, as the current @summary contradiction indicates.

Equally important, Maciej is trying to work within the W3C process and attempting to build consensus, and I think that this is an extremely important point to underscore. He has come to the mailing list (where everyone has an equal voice) with some draft text and is seeking to find common ground. No-one is likely to get everything they want, and it’s important to understand that this is the nature of compromise. It doesn’t mean settling for second best, but it means being willing to give up some smaller details for the bigger win.

[Photo - Yoda saying Table I see you writing are. Assistance you will be needing?To my thinking, any data table that does not include summary or caption or details or any summarization of any kind, using any of the available methods should generate a ‘heads up’ – call it a warning, a reminder or a dancing paper clip (oh, wait, no…) - thing is, it is an opportunity to help the content creator understand that there may be a need for this summarized information, and that the summarized information can take many different forms. Let’s not get bogged down in how it is delivered, lets offer a number of potential solutions and use-case scenarios and let the author decide which best fits his current situation. See this as a positive, “teachable moment”.

Let’s think about what we really want, and less on how we get that. @summmary has strengths and weaknesses and we need to recognize that too.

Returning to the dueling drafts:

If we can agree that TODAY @summary is neither ‘conformant’ nor ‘conformant but obsolete’ (deliberately turned around for this discussion – I know that it is obsolete but conformant), but the discussion is ongoing (something both drafts acknowledge), there remains one other issue: the author instruction language.

I think that Maciej’s return with some proposed language, as well as his overall approach, meets the bigger picture of ‘working together’. While I want to see @summary resolved as well, the proposed ‘solution’ for authoring instruction text meets with my goal, and I am inclined to say “Cool – if Hixie can live with it we are close enough”.

So friends, ACTIVELY LISTEN to what he has come with, as it represents significant movement for him (and he still needs to sell it to others in the “scientist” camp). It doesn’t solve the @summary problem completely, but it DOES address my other concern, and I for one am hearing that – can you?

I want to de-link the ongoing discussion about @summary from the fact that there are currently 2 drafts before the chairs. And I want to ask one simple question: has Maciej heard me, and have you and I heard Maciej? If the answer to that is yes, and if Ian agrees as well and makes the very minor modification to his draft that is suggested in Maciej’s compromise, then I can withdraw my draft from consideration.

And I’ll up the stakes one more: if Ian cannot see his way to agreeing to Maciej’s proposal, I will ask Maciej to help me integrate his proposal into my Draft for re-submission before Sam’s Poll deadline – because while Maciej and I might not see entirely eye-to-eye on @summary, I believe that we will have worked together – in harmony (cue the Coca-Cola singers) to produce a COMPROMISE offering. And if it comes to that, I would urge you to support that Draft, because it is the one that will have emerged in the spirit of compromise and consensus.


Returning to @summary for just one final thought. Perhaps what we need is a bit of a time-out – a half-time show to distract us for just a minute or two and allow passions to settle down. I propose that Lachlan Hunt re-visit his Spice Girls routine for the half-time entertainment, and that everybody take a health break, grab a cool refreshment and then settle back in refreshed, reasonable, and ready to work together.

Can we try that?

  1. #1 by Joseph Karr O'Connor on August 4, 2009 - 11:34 pm

  2. #2 by dw on August 5, 2009 - 12:10 am

    Thank you John. I think there are a lot of “lurkers” out there like me who are tired and frustrated by what WHAT WG have been doing collectively — a groupthink that seems to embrace the worst of the byzantine W3C and the bell jar denial of Microsoft — and individually — the mudslinging, cutdowns, alpha dog posturing, asinine behavior, and the high school clique dismissiveness of anyone who could possibly disagree with the groupthink.

    It seems like getting some of these arguments out of the way during the Working Draft phase will make life easier come Candidate phase and Last Call, especially if the “belligerents” were to get satisfactory resolution to their issues and then become advocates for HTML5. I think there’s been a lot of bad faith on all sides, and the quoting of tweets for derision in public forums and the writing of counterproductive doggerel has made things worse, not better.

    Meanwhile, us “lurkers” just want an HTML5 standard in hand already.

    So, good luck. But let’s hope there’s no need for a vote between the Editor’s Drafts, and let’s hope you and the group can come to some simple compromise. We need resolution, not more pointless rock hucking that wastes the world’s time.

  3. #3 by Stephen on August 5, 2009 - 12:17 pm

    I think @summary is less than useful, I tend to agree with the view that it’s actually harmful. I base this only on personal experience of producing websites. The suggestion on the list that tables be auto summarised by UAs seems the best solution by a mile yet it seems to have been ignored. Surely having a summary of all tables by default beats any other real world solution hands down, regardless of what the WCAG say? Can’t HTML5 innovations trickle to other W3C properties?

  4. #4 by Alohci on August 6, 2009 - 1:15 am

    It seems that Hixie has accepted Maciej’s compromise. I don’t think anyone thinks it’s perfect but that’s the nature of compromise and I think it’s a very good outcome. I congratulate you for the painstaking effort you and others have put in to get the “scientist” camp to understand that the use cases that require AT-only directed content are real, and worthy of support in HTML.

    There’s definitely a lesson to be learned about compromise in here. The key difference between Maciej’s text and Hixie’s previous draft, is that Maciej’s text is couched in positive rather than negative terms. Instead of saying “don’t do X, do Y or Z”, it says “you can do X, but hey, look at great solutions Y and Z, which if you can use, do so because that will be better for everybody”

    Saying “don’t do X” is confrontational and naturally puts people’s backs up. It’s much harder to object to positive language that simply points out the merits of alternatives to X.

    This is important because since the two sides have fought so aggressively over the issue, and having now reached a compromise, there is a significant risk that the text in the draft will be set in stone, in fear of reopening old wounds. That would be bad since there is certainly room for improvement over the guidance that HTML gives to authors in this area. So long as the draft retains the positive language it should be possible to augment the existing wording without violating the compromise.

    Lets hope HTML 5 can now move on, and get to work on delivering an accessibility solution for Canvas.

  5. #5 by John on August 6, 2009 - 10:01 am

    @stephen – While I certainly respect your right to have an opinion on @sumary, it is not entirely clear to me how your experence as a web developer alone allows you to pass judgement on @summary. Do you use a screen reader daily? Can you share the experiences you have encountered that has shown using @summary has caused harm? To be clear, I do not think that @summary is the panacea for all that is difficult with complex tables, but the role that @summary was designed to serve, when done right, is actually a graceful solution.

    As for having the UA auto-summarize a table and convey that information to users who cannot see (and thus discern) the totality of a complex table is a great idea; unfortunately at this time that is a fantasy wish – I am unaware of a User Agent today that can deliver on that ideal. Do you have proof-of-concept that illustrates how that might be achieved? Hopefully one day that will emerge, and that will be a great day, but that day is not upon us yet.

    More importantly however, I think you missed the first paragraph of my blog post – @summary is and was simply a Talisman for a larger issue that needed to be addressed: the process by which the HTML5 specification is crafted. The input of all parties must be judged by the community, and not entrusted to one person to act as the gatekeeper. W3C process requires consensus (which often requires some compromise) and that was not happening. It is starting to happen now, and I believe that HTML5 will be that much better for it.

  6. #6 by JimJJewett on August 13, 2009 - 7:16 pm

    “To my thinking, any data table that does not include summary or caption or details or any summarization of any kind, using any of the available methods should generate a ‘heads up’”

    But that again brings up the problem of needing more good examples. My tables almost always have a single row of th cells along the top. The first column may be (but isn’t always) entirely th cells. There are no other th cells.

    Should I really add a caption that is just a repeated (and therefore error-prone in case of revisions) version of the table headers?

    If so, that is so unexpected that it needs to be said explicitly.


  7. #7 by John on August 13, 2009 - 9:50 pm

    @jJ RE: good examples – I agree, I think that this is likely the single largest reason why @summary is so poorly used today: content authors don’t understand how to use it. The summary value should give a synopsis of the overall structure of the table – a visualization as it were that would likely be obvious to a sighted user. A complex bus schedule would be a good example – lots of data that the non-sighted user could process more quickly if they previously understand the table structure:
    <table summary="Service begins at 4:00 AM and ends at midnight. Intersections are listed in the top row. Find the intersection closest to your starting point or destination, then read down that column to find out what time the bus leaves that intersection.">

    However some tables are so simple that a summary might not be required: remember @summary is an optional attribute – the ‘heads up’ I speak of would not always require additional action: the advisory however would ask you – content author- if there “might” be a need to do so.

    The caption however is different, and is usually displayed on screen: it should describe the “what” of the table, and is useful for all users: an example of caption would be "Schedule for Bus Route 7"

  8. #8 by JimJJewett on August 14, 2009 - 5:26 pm

    I hate to pick too hard on a particular example, but … I still haven’t seen one that explains things to me.

    I (a sighted person) have often tried to figure out when buses start/stop running. If that 4 to midnight is true, then I want it not only visible, but emphasized. More likely, it is true for some routes, but midnight will be long past the last departure for other routes, or at least some stops… and so the information misleads.

    I would hope that the fact that the bus stops are along the top row would be available from column headers; I realize that they might not be. (But this isn’t obvious to a sighted reader either — I usually figure it out from the contents of the cells.)

    I could see some value in saying “buses run less frequently after 7pm”, but that is again something I don’t take in visually. On *some* schedules, I notice the change because the color changes, and then I try to figure out why, but I would still be happier if they just told me.


You must be logged in to post a comment. Here's Why.