RE: obsoleting and the text/html MIME type (re Taking another round at @summary)

David Singer wrote:
> 
> That is true for new features.  But our goal is to provide actual
> effective accessibility, I think, not merely specifications in which it
> might happen.  If a specification feature has existed for years, and has
> got little adoption, then I think we should ask whether we'd better try
> something else. 

Nobody has suggested that other possible solutions cannot be attempted.
Aria-describedby may in fact be one of those better solutions, and if so
then great.  But while we try out these new ideas, why should we kill off
(or cripple) something that, when done right, works today?  In the past 24
hours, 2 blind users (well respected and informed participants in the
subject of standards, web development, the W3C, and the current HTML5
process) have specifically weighed into this current round-robin and
stated that @summary is useful for them:

"...there is (a) a need for the TABLE's structure and organization to be
communicated to those who are parsing the TABLE non-visually, or through a
VERY small point-of-regard and (b) no reason why a user agent, an
authoring tool, or any other program cannot provide a means to expose the
content of @summary at a user's request" - Gregory J. Rosmaita
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0039.html


"... when summary is used effectively, it saves me endless time in gaining
an understanding of a table's structure and it happens enough that I would
find it a loss not to have it available." - Kelly Ford 
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0081.html 

This is not just theory; this is practical, current and effective
accessibility today.



> We're not actually improving accessibility if very few
> tables that need it, have a summary.  Again, I don't know that this is
> the case.  Arguing "it just needs education" is not good enough, after
> years have passed.  We are all striving for good accessibility in
> practice, I hope.

There is zero argument that not enough tables that need @summary content
actually have usable @summary content.  Everyone accepts that, but few are
actually pleased with that state. If education won't solve the larger
problem however, then no matter which technique is advanced it will likely
be ineffective: it's not the tool used so much as the work invested in
providing the right information to non-sighted users - <p id="tableDesc">,
<caption>, <details>, @summary: if the data value for any of those is
"Layout table" it's a failure.  So education, first and foremost, is truly
the only real solution to the larger problem.  

In this regard, @summary *might* have a slight leg-up on newer techniques,
only because as a technique for success it has been around longer: it has
already been incorporated into other 'teaching' materials both within the
W3C (http://www.w3.org/TR/WCAG20-TECHS/H73.html) - current teaching
materials that are less than 2 years old BTW, and still being translated
to other languages - and outside of the W3C (as witnessed by Denis
Boudreau's links to the Quebec mandate documents -
http://lists.w3.org/Archives/Public/public-html/2010Jan/0203.html). 

And there is also the 'non-technical' aspect related to the 'education'
piece - existing guidelines, mandates and the price of implementing any
feature (new or old). There is a cost, both financial and political, to
advancing accessibility in the real world.  Lawyers, bureaucrats, and
other non-technical stake-holders have an interest in the decisions we
make: points that both Denis Boudreau and Karl Dubost have raised this
week in the context of their own on-the-ground work with mainstream
developers, who simply need black and white solutions to specific
problems. To quote Karl, "The real world right [now] is that a series of
technical requirements are implemented in legal systems all over the
planet." And today we have evidence that this includes mandating the use
of @summary with data-tables - so not only will we need to change a
technical specification, we will need to go back and re-write numerous
other legally binding documents.

The financial impact of that decision cannot be dismissed: there is a
significant and real cost to asking governments to go back and re-open
policy documents; there is a financial burden to translating guidelines
and other educational materials into French, Spanish, German, Russian,
Chinese, and on and on... And for all of that, what do we gain?  We
replace:

	<table summary="Description here">....</table>

...with this:

	<table aria-describedby="tableDesc">....</table>
	<p hidden id="tableDesc">Description here</p>
 
[Jonas Sicking:
http://lists.w3.org/Archives/Public/public-html/2010Jan/0158.html] 

Has anyone actually done a cost-benefit analysis? (I doubt it) It seems
instead that the argument keeps coming down to one of religion and
opinion. 


> Yes, if the position is (and I don't have the evidence) "summary is
> rarely there when it's needed, and when it's there, it's unhelpful
> (and thus 'polluting')" then we need evidence to that effect.  

Ian Hickson has published data that purports to support that claim, but
how much real value does that claim bring?  I would think it would be
trivial to have Ian run a Google-crawl for images that lack @alt, or to
locate truck-loads of images that have alt="picture" or alt="button"; do
these poor implementations 'pollute' the web to the point where @alt can
be considered harmful? I doubt that very much (as I'm sure you would too).
Historical perspective is useful, but alone cannot be an arbitrator of
what we should be doing moving forward.


> I think that we are trying very hard to make conforming HTML4 pages
> 'valid' even if they contain deprecated features.  If we are not, we
> should be.  My perception if that one of the cornerstones of HTML5 is a
> "don't break things needlessly" -- either the existing web, or break
> from the HTML legacy of specifications.

...and retaining @summary as a viable attribute of the table element,
without the 'editorialization' of a warning which may or may not be
appropriate, allows us at least one means to achieve those goals. Not the
only means, but a viable and useful means, and one who's ship has already
sailed.  If we want to launch better ships, fine, but there is currently
no reason to torpedo part of the existing fleet.

JF

Received on Thursday, 7 January 2010 21:05:46 UTC