RE: summary attribute compromise proposal

Shelley Powers wrote:
> 
> [quoting Sam Ruby] "... is finally well on its way to being closed."

Not, closed, finalized or completed, but "well on its way".

Issue 32 is *still* an open action item within the HTML5 tracker [1], and
active discussion and vigorous debate about how to ensure that the
information that @summary was designed to deliver is conveyed to the users
that need it, but are perhaps not getting today, are still ongoing.  

<critical>
The recent compromise that emerged yesterday *did not* close Issue 32, and
it is important for all to realize that point.
</critical>

As well, what is *REALLY* important to remember, for accessibility (which
is the end goal, at least *MY* end goal), is that the *HOW* we do
something is less important than the *SUCCESS* of doing something. So
perhaps we need to let go of the Talisman just a bit and broaden our
perspective.


> 
> In other words, this is being played as a solution to the summary
> attribute issue in its entirety, not just about summary attribute in
> the Working Draft.

I think that perhaps this is how you are seeing it, and while I cannot
speak for Ian, it is certainly not how I see it, and since I was very much
stuck in the middle of recent events I believe I have a pretty good
vantage point to judge how things played out.

I believe it is safe to say however, that NEITHER IAN NOR I BELIEVE THAT
@SUMMARY IS THE ONLY SOLUTION.  He thinks it's a horrible solution, I am
less sure of that assertion, but do concede that there are other solutions
that have emerged in HTML5 that *MIGHT* serve as well as or better than
@summary under certain circumstances. Others are free to hold opinions
outside of the two I just expressed. 

Ian and I also differ on how 'harmful' @summary is to the accessibility
cause, and we differed greatly on the advisory information that was being
given to authors in the previous version of the Draft HTML5 Specification.


After some discussion and protocol (and a healthy dash of diplomacy by
Maciej), the advisory text was removed from the Draft - producing a more
neutral stance (for now!) and WCAG / WAI / PFWG have been asked to provide
workable advisory to associate to @summary, which they are actively
working on. The Attribute has (for now!) been restored to fully conformant
so as to not confuse authors who currently look to WCAG's Techniques for
Success Criteria. I personally however agree that producing some sort of
advisory when authors are creating complex tables that helps them better
encode those tables for accessibility is a benefit, and others seem to be
picking up on this idea - great! Whether you call it a warning, an
advisory or (and I will repeat this from my blog, but please folks, relax)
a "dancing paperclip" is inconsequential and simply not worth arguing
over. 

There are larger issues to worry about. Like Canvas. Like Video. Like
getting ARIA integrated into the spec. (And there is activity on all three
of these fronts today).  If you *really* care about accessibility, turn
your efforts to helping solve this issues.  Don't ignore Issue 32, but
let's move on just a little please.

> 
> Now, it will be that much more difficult to achieve a real solution to
> this problem, not the least of which anyone bringing up objections
> will be seen as "not playing well", or being rigidly against
> compromise.

Standing on principle is great, fighting for real progress is commendable,
but arguing over words is draining.  I will repeat here, and people are
also welcome to review the minutes of today's WG conference call [2], the
@summary issue has not been finalized. I fought very hard for the notion
of consensus and compromise being the way forward, and to somehow suggest
that yesterday's outcome in fact blocks consensus building is both
preposterous and frustrating.

JF


[1 http://www.w3.org/html/wg/tracker/issues/32 ]
[2 http://www.w3.org/2009/08/06-html-wg-minutes.html ]

Received on Thursday, 6 August 2009 21:58:41 UTC