Re: Summary="" spells disaster

I agree with the sentament here I would also add that checking tools need to
be adjusted accordingly.

Johnnie Apple Seed

----- Original Message ----- 
From: "Jesper Tverskov" <jesper.tverskov@mail.tele.dk>
To: <w3c-wai-ig@w3.org>; "'Michael Cooper'" <michaelc@watchfire.com>;
"'Wendy Chisholm'" <wendy@w3.org>
Sent: Monday, August 30, 2004 3:50 PM
Subject: Summary="" spells disaster




The more one thinks about the table and summary issues, the more it
becomes clear that we don't need strict definitions of data and layout
tables and that we should only use the summary attribute for complex
data tables when extra clarification is needed.

The summary attribute should only be used for data tables when other
markup like headers are not enough to make the table understandable and
usable for screen readers etc. The summary attribute should only be used
when it is going to be a real help for the blind. If in doubt don't use
it.

What happens the day we make summary="" a new convention meaning layout
table? From being virtually unknown among web page authors, the summary
attribute becomes mandatory for any table. Soon the table tag will be
born with summary="" in many web authoring tools.

Most web page authors knowing nothing about the finer details of how to
use the summary attribute will start supplying all kinds of silly
summaries for all sorts of tables. Or they will just leave the
summary="" as it is or delete the attribute.

The end result is most likely mountains of useless markup meaning
nothing or the wrong thing most of the time, making the life of the
blind even more difficult.

One of the main issues of accessibility is the Do-Gooders thinking that
if some new attribute or value for an attribute looks nice as a proposal
it also is nice when implemented in the real world by user agents, web
authoring tools and millions of web page authors.

Almost any solution also has bad or unforeseen consequences often
outweighing the believed positive effects of a solution. Solutions
believed to solve problems most often also create new problems.

Best regards,

Jesper Tverskov
www.smackthemouse.com

Received on Monday, 30 August 2004 20:09:16 UTC