Re: Summary of Thursday's IRC conversation about @summary

Jonas Sicking wrote:
> On Fri, Jun 5, 2009 at 3:44 PM, Shelley Powers <shelleyp@burningbird.net> wrote:
>   
>>>> I asked in the IRC, what are alternatives, and what was a little
>>>> uncomfortable was that the folks who really want this attribute gone,
>>>> really
>>>> have no alternative solution in mind. Well, other than smoosh it into
>>>> caption, which is bad mistake, and a bad design decision (you don't want
>>>> to
>>>> start redefining the context and meaning of existing elements).
>>>>         
>>> Why not? Especially if the change in semantic is such that
>>> compatibility with existing content is still maintained.
>>>       
>> Every DBA and data person in this list just winced at that one. You're not
>> maintaining existing "semantics" when you change what is allowable data in
>> the container. And you don't change the meaning of a data container after
>> it's been in the wild for a time. You can clarify the information about the
>> container, but you don't literally change the meaning.
>>
>> If you must, you deprecate the old, and replace it with new. But that would
>> mean pulling both caption and summary. Are you all willing to pull both
>> caption and summary?
>>
>> Seriously, if you all insist on "merging" the data, the only appropriate way
>> to do so would be to deprecate both and replace them with something new. But
>> deprecating table caption -- I'm not sure that's a particularly feasible
>> idea.
>>     
>
> This doesn't seem to answer my question "Why" above.
>
> / Jonas
>
>   
I would prefer to let the folks who have been fighting for accessibility 
on the web receive most of the questions, as I'm a latecomer to this 
particular debate. I'm concerned my own ignorance of the issues will 
then be used as an "argument against" support for the accessibility 
markup, which would be unfair to those who have tirelessly toiled for 
accessibility, undermine the rigor of this working group's process, as 
well as be potentially harmful for the future of accessibility in HTML5.

But you did ask a specific question.

Right now we have two different fields of data (one attribute, one 
element) with two different purposes, both of which can be used with a 
table. When you combine them, you no longer have a way of separating out 
the content--you no longer have a way of knowing if the data contains a 
caption, a summary, or both. Within DBA circles, this is known as a loss 
of precision (and data) and is very frowned upon. Why? Because there 
will never be a way to gracefully separate the data if, at a later time, 
this decision is reversed.

Typically the only time separate fields of data (columns) are merged in 
database refactoring is when its determined the data is the same, or the 
usage of the data would not be impacted by the merge.

Addressing usage next, from a web perspective, right now people have the 
ability to specify two pieces of information about the table. One piece 
is a short title, which is printed out with the table; the other is 
descriptive information about the table specifically targeted to 
assistive technology, in order to help those who are blind. It is not 
meant to be printed out because the data provided would be considered 
redundant to the actual physical display of the table, and such 
redundancy could decrease both the efficiency and the effect of the 
table display.

By merging the two, web designers/developers have lost the ability to 
fine tune what is, or is not, displayed in the web page. So now you're 
looking at a usage loss (of functionality, options, choice, capability) 
in addition to a loss of precision (data).

Though I specifically mention "database" in this discussion, but note 
that this applies to persistent, organized data structure.

Hopefully this answers your "why".

As a personal aside, the accessibility folks are aware of the concerns 
about summary, and have meticulously and carefully explored new options, 
including the addition of a new summary element, which seems an elegant 
longer term solution. The advantage to the solutions they propose is 
that there is no loss of data precision, nor loss of data usage.  The 
document and web page that Laura points out acknowledges the concerns 
expressed by members of this working group, and is providing some 
difficult-to-refute points of logic, specifically the one that reads:

"Most of the debate around providing a summary mechanism has been about 
misunderstanding its purpose, so trying to merge its purpose with 
another element's purpose may be problematic leading to more confusion. "

In other words, if the concern is that summary is being improperly used, 
merging it with caption is unlikely to suddenly cause the web 
designers/developers to reach an epiphany about its use.

I looked through several of the examples that Philip's program extracted 
that contain the summary attribute. I've not yet found one example that 
is actually using the table element properly. Not one, in all of the 
examples I looked at (and I looked at over 50, randomly picked). 
According to the HTML5 document on using tables for layout purposes:

---

This usage is non-conforming, because tools attempting to extract 
tabular data from such documents would obtain very confusing results. In 
particular, users of accessibility tools like screen readers are likely 
to find it very difficult to navigate pages with tables used for layout.

...

User agents that do table analysis on arbitrary content are encouraged 
to find heuristics to determine which tables actually contain data and 
which are merely being used for layout.

---

In all but a few cases, summary was given as summary="", which since the 
tables were being used for navigation seems to actually be correct usage 
of the summary attribute. So in a way, Philip's data has demonstrated 
incorrect usage of table, but correct use of summary. But I digress.

Whether the summary attribute is used correctly is somewhat moot, as the 
use of table in most of these instances will probably be discarded, in 
some way, by the user agents. This tends to undermine the statement of 
the harmfulness of the attribute, leaving only the plaint that it's use 
is not widespread.

However, we've also been told that number of uses is not a factor in 
determining the viability of this type of data--only percentages of 
correct use within the domain of usage. As can be seen with the data 
that Philip has helpfully provided, incorrect usage tends to be paired 
with incorrect usage of HTML tables, and it all comes out in the wash, 
so to speak.

As for the other metric, those who should be using it, but are not: 
again, collapsing the purpose of caption and summary together is not 
going to improve this situation. If anything, it will only make matters 
worse. And frankly, we don't have a way to determine if people who are 
using it aren't using it correctly -- we just don't have complete access 
to the Internet (as has been eloquently noted elsewhere), in order to do 
such research.

In addition, using such empirical data to determine whether to keep 
summary or not is not necessarily the best tool of choice. If one counts 
the number of empty handicap parking slots we see at stores at any given 
time, combined with the the number of slots filled by cars that don't 
have a handicap parking pass, in conjunction with the numbers of passes 
given out to people who don't need them, one can conclude that handicap 
parking is also a "failed" initiative.

The document that Laura has supplied provides a course to take in the 
future to ensure both wider use of table summary, and ensure a proper 
use of table summary--to go with the new emphasis on the proper use of 
HTML tables. The document Laura points out displays a great deal of 
thought, planning, and rigor, as well as acknowledgment of concerns and 
responses to same. As such, the document deserves respect, and the same 
thoughtfulness and rigor in return.

Again, though the above is my opinion, based more on my being a former 
DBA, and current web developer, than being an accessibility expert. I 
will be happy to continue answering questions based on my personal 
opinion, but I believe that the discussion would be better served by 
directing responses to recent questions that Laura has asked.

Shelley

Received on Saturday, 6 June 2009 13:48:04 UTC