W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: [DRAFT] Heartbeat poll

From: Shelley Powers <shelleyp@burningbird.net>
Date: Sat, 01 Aug 2009 23:31:07 -0500
Message-ID: <4A75168B.4040607@burningbird.net>
To: Ian Hickson <ian@hixie.ch>
CC: Sam Ruby <rubys@intertwingly.net>, John Foliot <jfoliot@stanford.edu>, 'HTML WG' <public-html@w3.org>

> On Sat, 1 Aug 2009, Shelley Powers wrote:
>   
>> 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.
>>     
>
> We can if we have sufficiently large corpuses.
>
>   
Ian, you're not answering the issue related to the correlation between 
incorrect use of table and incorrect use of summary. Your data is 
tainted, you can isolate summary sufficiently to be able to draw a 
conclusion.
>   
>> 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.
>>     
>
> It doesn't matter how seriously people take it, if users don't see an 
> improvement in their user experience. The pages people look at _do_ end in 
> on the Web; that is in fact the exact content we are concerned about.
>
>   
Sorry, you lost me here. Your original argument is people aren't using 
summary correctly. Now you're saying users don't find it useful when it 
used correctly. But you have nothing to back up your second conclusion.

You really don't have the data, or the expertise to make such conclusions.
>   
>> 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.
>>     
>
> This is a very common problem -- a problem that would not occur with the 
> same frequency if the explanatory information were visible to all.
>
>
>   
Ian, this type of problem occurs when changes are made in software, 
period. Even if there was a caption, or a legend used or whatever, 
chances are the text would have been out of sync from the program.


>> 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.
>>     
>
> I do not believe anybody is suggesting that explanatory information is not 
> useful. On the contrary, advocates in favour of encouraging alternatives 
> to summary="" have argued that the explanatory information is useful to 
> many people, not just users of ATs, and that we should not be limiting the 
> information to specific groups of people, and should instead be making it 
> accessible to all.
>
>   
Interesting that you see providing helpful material to those with visual 
impairments as "limiting" the information.  Curious, and this is off 
topic, but do you also find handicap parking slots to be limiting to 
those not physically impaired?

I don't think anyone is suggesting "limiting" information to those 
without visual impairments. What people are asking for is a way to 
provide an alternative presentation of the same information,  but 
formatted in such a way that those who perceive web pages in a different 
way can also benefit from the "same" information.
>   
>> Your sampling is flawed because it doesn't account for a significant 
>> number of web pages that are not accessible to the public.
>>     
>
> Pages that are not part of the Web do not need to use a standard 
> interoperable across the entire Web, they can use proprietary formats. 
> They can, for instance, use HTML with summary="" added back in, or the 
> Word document format, or anything else. Controlled environments are not, 
> and should not be, a particularly important concern in the development of 
> a world-wide vendor-neutral standard.
>
>
>   
Actually, pages in intranets are probably the primary reason that 
Microsoft has been extremely careful about what it does with Internet 
Explorer, so I wouldn't necessarily disregard intranets, because 
intranets have impacted on the web for some time, now.

Issues of IE6 aside, intranets use the same browsers, the same web 
technologies, have the same issues, the developers have the same 
concerns, as pages available in the World Wide Web. In effect, there 
really should be no difference in pages on either side of a firewall, if 
we want to avoid the issues we've had with IE 6 in the future.

We can't disregard intranets. Or I should say, the HTML WG should not 
disregard intranets.
>> 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.
>>     
>
> We are eliminating all the aspects of tables that make it suitable for 
> layout (all the presentational attributes) in an even stronger fashion 
> than sumamry="". While <table summary> is conforming but discouraged, 
> <table width>, <tr bgcolor>, etc, are all completely obsolete and not in 
> any sense conforming now.
>
>   
Summary is descriptive, not presentational. Interesting, again, that you 
group this with presentational attributes. Do you see summary to be a 
presentational attribute, no different than table width?
> If you have an alterantive solution for tabular data that is less likely 
> to be used for layout tables, though, I'm certainly open to suggestions. 
>
> With summary="" we can improve matters. So we should.
>
>
>   
I've not seen an alternative proposed that the relevant working groups 
seem overly happy about. And your earlier statement about "limiting" 
information shows that perhaps you may want to consider listening more 
closely to others trained in accessibility issues. I think these folks 
(and I don't include myself among them, I'm not trained in 
accessibility) provide a necessary viewpoint to ensuring web 
technologies that are accessible to all.
 
>> 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.
>>     
>
> HTML5 doesn't require any change. It keeps summary="" in the 
> implementation requirements unchanged. (In fact I would go further -- it 
> introduces implementation requirements that HTML4 did not have.)
>
>
>   
Actually, summary in HTML 5 is incredibly confusing. "Obsolete but 
conforming" -- what does that mean? It's vague, and imprecise. Will user 
agents support it? Won't they? If they won't, when will they stop 
supporting it? I can't for the life of me remember seeing anything like 
that term ever used with any technology.

And summary is not defined in HTML 5, either. There isn't anything in 
the specification that actually describes the attribute, or even 
provides information about its structure. One has to go back to HTML 4 
for that.

Shelley
Received on Sunday, 2 August 2009 04:31:53 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 October 2014 16:24:50 UTC