Re: [DRAFT] Heartbeat poll

> For what it's worth, it's also making me feel like maybe I should have
> trusted my original judgement and just left summary="" as non-conforming.
> I've repeatedly asked for reasoned arguments and research from the "pro-
> summary" advocates, only to be faced with accusations that I am ignoring
> due process. For many years now I have been crystal clear on the process
> that I am following: bring forward reasoned arguments and data, and I
> change the spec. The reason I don't do what the PFWG have demanded (and
> there really is no other word for it) is that there has been zero
> reasoning given, just position statements with no reasoning. My e-mails
> asking for reasoning were faced with no response. I'm _still_ waiting for
> a reply to these e-mails:
>
>   http://lists.w3.org/Archives/Public/public-html/2009Jun/0173.html
>   http://lists.w3.org/Archives/Public/public-html/2009Jul/0262.html
>   http://lists.w3.org/Archives/Public/public-html/2009Jul/0766.html
>   http://lists.w3.org/Archives/Public/public-html/2009Jul/0778.html
>
> ...that has any reasoned arguments or data.
>
> Over the past few weeks I have stopped changing the summary="" section
> because Joshue asked me to stop changing it in preparation for a vote.
> Since no vote has occured since that request, I'm going to resume
> responding to the few e-mails (two from Maciej, one from Murray) that I
> have pending on the subject in the coming days.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL


I put forth what I feel is a reasonable argument in a weblog post[1]
but will repeat here:

---------

The decision about summary was based on an analysis of data pulled
from web pages scraped from the internet[1]. What's been ignored in
the discussions related to the incorrect use of the summary attribute
is that only about one in 1,000 HTML tables reflect correct HTML table
use. So, accuracy when it comes to past use of HTML tables is just
something that one can't "accurately" assess. The raw data is
interesting, but we can't draw conclusions from it.

I found that rather than looking at raw data use, if we look at
discussions people have had about the table summary attribute,
instead, we find that the summary attribute has been taken very
seriously, but its use isn't necessarily showing up on the web, or in
Google.

For instance, this bug report is for a CMS and is directly related to
an incorrect table summary. The summary use is accurate, but the table
structure was altered, and the summary needed to be changed to reflect
this alteration. The table summary is also probably one of the better
examples of why something like summary is necessary, including the
important note that column 1 is not used. A sighted person would see
immediately that column 1 is not used, so this information is
redundant to the visually enabled. For those people who need to use a
screenreader, though, if they didn't know that column 1 is empty, they
would end up getting some variation of "blank" for every cell in that
column. The information about the second column is just as valuable,
as it informs the person that column 2 has checkboxes, again something
that a sighted person would see immediately.

Yet we won't see this accurate use of summary on the web, because the
CMS is primarily used for educational purposes, and most likely
implemented behind a firewall. In fact, it would have to be, because
most educational systems have to be protected because of legal issues
to do with students and privacy. I worked on systems at both Harvard
and Stanford, and they all involve quite complex data tables, and none
of the web pages would be available on the internet. When you consider
that both universities had government and school mandated
accessibility requirements, I'm fairly sure that both would be using
summary with data tables, but we wouldn't see this use in Google.

I found the same discussion about accurate and effective use of the
table summary attribute related to intranet use for states and
counties, other companies, and other products (Google Search on table
summary example accessibility). It could very well be that there is a
significant number of good summary uses, but we'll never directly see
them because they're behind a firewall.

This brings me back to the table examples in section 4.9.2 of the
specification. To reiterate, the summary attribute remains. However,
so do the other examples of table documentation. Providing examples is
a good way to not only help people use HTML tables accurately, but it
also enforces the importance of accessibility. In fact, I would modify
and expand the section.

By providing the differing, and I feel complementary table
documentation techniques and examples, we're also, indirectly,
enabling better data collection activity in regards to summary in the
future. If the issue with the perceived incorrect use of summary is
that people don't understand how to use summary, then in the future we
should see correct descriptions of the table using one of the other
techniques, without seeing an associated correct use of summary. I
hypothesize, though, that we'll see a positive correlation between
correct use of HTML tables, and correct use summary, most likely used
with a correct use of caption, or *figure legend.

However, I don't like the example table, and will replace it. I also
believe more example tables are needed, as multiple examples help
drive home differences in the table documentation techniques.
Unfortunately, adding more examples will make a long specification
even longer.

Because of the increased length of the table example section (and
example sections elsewhere in the HTML 5 specification), we'll need to
split out the examples into an HTML 5 Primer.

HTML 5 Specification Modifications
To **summarize: The summary attribute is maintained as a viable,
active attribute, the existing HTML table examples in section 4.9.2
will be replaced with multiple table examples, all of which will, most
likely, be moved to an HTML 5 Primer document.

Additional References
See the HTML/SummaryForTable Wiki page for more details on this topic.

[1] Ian Hickson's recent email related to the topic.

*I don't expect to see a lot of use of figure with HTML tables, and
I'm not a keen fan of figure use in this way. I'll cover figure in
more detail in a future page.

**No pun intended

-----------

Your sampling is flawed because it doesn't account for a significant
number of web pages that are not accessible to the public. And you,
yourself, have never answered the questions about why you're
eliminating summary because of its flawed use, when its been
conclusively demonstrated that HTML table usage is equally flawed, and
therefore any sampling is tainted.

Having said this, John, I would hope that you don't try to hurry
through a change document reflecting a more comprehensive view of
summary, just because of a request for publishing a new Working Draft.
In a way, a new Working Draft could be good for those who are
interested in change, because it provides a stable point we can use
for edits for other proposed sections, or even all new documents.

I can understand the concerns about publishing something as a working
draft, because browser vendors have been grabbing the working draft
and making changes to their applications based on this draft. This
means that some browsers may incorporate the API additions based on
microdata, which is unfortunate because the section really doesn't
have anything but the most lukewarm support from anyone, including the
section creator.

It also means that user agents will see the new language about
summary, but I don't think anyone will be making any significant
changes to their applications based on the text, other than possibly
some HTML 5 validators, and only edge-case geeks use these now,
anyway.

I don't believe that JAWS or other assistive technology applications
will immediately make changes to their tools based on a Working Draft
that is under a great deal of contention. And I don't believe any of
the major browser vendors will make changes based on the handling of
summary in the current text. So I don't think any permanent harm will
come from allowing this text for now. Even though it does imply
consensus of the working group as a whole, which is erroneous.

But trying to put something through quickly, in these circumstances,
could do lasting harm. It could make it difficult to propose a more
carefully crafted alternative handling of summary, based on having
enough time to do the job thoroughly, and to provide sufficient
argument to support such a change. That's not to say you won't put
together an effective argument and the appropriate document this
weekend, but that still leaves the part remaining that the submittal
will be rushed, and pushed out when emotions are fairly high, and
people are feeling rather entrenched about their positions.

Note that I will also likely be submitting proposed alternatives to
the current working draft at some later time, which also included a
changed section on summary and a re-write of the section on HTML
Tables, but I'm doing so in my own time, and in my own way, and asking
that such proposed alternatives be considered on their own merit, not
part of some other decision. From my understanding, such submissions
are viable, as long as documents are submitted before Last Call, and
that there is support from at least three members of the working
group. Now, I may not have support from three working group members,
but I'll still make the proposal, as a matter of form, and as a basis
for future actions.

I feel it would be better to submit proposed changes to the
specification when the discussion around such changes can be less
contentious, and the arguments put forth can be discussed reasonably,
and on their own merits.

This is just my opinion, though, and I will support what you decide,
John. But my preference is to allow the publication of the Working
Draft, based on as is text, and the difference document, and then use
this as a basic for my own edits, rather than try to make edits to the
Editor draft, which changes daily.

Thanks

Shelley

[1] http://realtech.burningbird.net/one-table-thousand

Received on Saturday, 1 August 2009 14:06:05 UTC