[Bug 14107] Non-conformance of the summary attribute for the table element makes WCAG 1.0 compliance impossible

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14107

--- Comment #16 from theimp@iinet.net.au 2012-01-29 18:58:30 UTC ---
> produce new or updated web content that conforms to WCAG 1.0 rather than 2.0

Generally:
* Old "sites" remain at WCAG 1.0 if they are archived (receive no more changes)
before the deadline (currently anywhere between the end of 2012 and the end of
2014).
* Old sited are to be upgraded to WCAG 2.0 if they have not been archived by
the deadline (currently anywhere between the end of 2012 and the end of 2014).
* New "sites" start at WCAG 2.0 if they were created after $date, which varies
from government to government and agency to agency, and is usually the
beginning of 2011 or the beginning of 2012. Sometimes, these will have to
continue to meet WCAG 1.0 until the NTP implementation phase has started, or
sometimes until it has ended, or sometimes not at all.
* And the large "other" category, that have unique rules on a case-by-case
basis.
* Oh, and the occasional possibility of other commitments to WCAG 1.0 unrelated
to these laws and policies (i.e. websites for international events such as the
Commonwealth Games).

So potentially WCAG 1.0 may remain required up until 31 December 2014 in the
general case. As at right now. But as these dates are vulnerable to shifting,
as some already have, this could very possibly be a big problem by the time
HTML5 achieves Recommendation. A single schedule slip - which I can
(unofficially) assure you is at least being discussed right now - and the
implementation deadline will sail far past the current HTML5 target. Not that
HTML5 isn't subject to delays also...

But that's just Australia. I'm not up-to-date, but I believe the UK roadmap
extends way, way past 2014 (they're still waiting for the EU+Latvia to confirm
a timetable before they update TG102; so you could also add most of Europe to
the list). Would you like me to reaffirm this?

New Zealand is, as far as I know, the only other country that is likely to have
migrated their WCAG 1.0 legislative/regulatory requirements to WCAG 2.0 before
the end of 2014. Conversely, as far as I know, every government that has
(fully, so, no the US) endorsed WCAG 1.0, has announced their intention to
migrate to WCAG 2.0, and at least begun to do so in some way (consultation,
studies, etc., if not actual technical changes).

> Even if they did, I disagree it's a critical problem if it takes a few governments a couple more years to migrate to HTML5 because they are slow to work out how to deliver web accessibility using new technologies.

Er, I don't think that there's any class of such major organizations that are
so strongly committed to accessibility, as governments. I don't think that
their issues should be considered so cavalierly.

It's not an issue of being unable to use other techniques - it's about being
required to use certain techniques. Nothing stops you using other
technologies/techniques, as long as they do not prevent you meeting WCAG 1.0.
But right now it seems that HTML5 will be one of those technologies that cannot
be combined with WCAG 1.0.

It is a great thing that governments, where they have, have committed under law
that they will improve accessibility in the way the W3C, and the experts that
the W3C has worked with, have recommended to them. That they move slower that
the speed of the web is not a fair reason to be so dismissive of their efforts.
This is lightning-fast by the typical expectations for these kinds of
government projects - mostly sped along by the dedicated hard work of technical
leaders who are personally committed to following the W3C wherever they lead,
in deference to pure technical merit.

I find the suggestion that they should be cast away to flounder for a few years
just because they can't heave the titanic bulk of their bureaucracy as fast as
you think they should be going, to be particularly unworthy.

> Not upgrading to HTML5 markup wholesale is not a blocker to accessibility repairs since:

Governments, like many organizations large and small, do not always have
internal IT departments with the scale and expertise required to write custom
software for their websites (and even those that do, rarely utilize them this
way). Frameworks and toolkits and templates from major software vendors are
already moving to HTML5 en masse, which can increase the cost of reworking or
maintaining those tools in ways that will meet their needs. This has especially
been seen over the last two or three years, with JavaScript libraries and
templates that have been optimized for trendy modern mobile devices, which
break irrecoverably on legacy browsers, that vendors have altogether stopped
testing with. Even though those legacy browsers have a disproportionate
representation among disabled users due to the incompatibility of essential AT
without paying significant money for the new version that works with their
"free" browser upgrade (IE6+JAWS, etc.).

This might not be a problem that can be helped anyway, but anything will help,
and I think that compatibility should remain a priority wherever it is easy to
do.

> I think encouraging best practices for the entire web over the next decade is more important than speed of government adoption.

I absolutely agree.

But is @summary really such an a critical barrier to best practice? Is removing
it, when it's supported by browsers anyway, such an advantage? Is "best
practices for the entire web over the next decade" truly what you're getting
for the price you're paying?

> The Toolkit's claim that you need to provide a @summary for every table looks like a misrepresentation of WCAG 1's normative requirements

The toolkit was one of many such examples. The authorship, if nothing else, of
that particular example does not suggest to me that that is a
misrepresentation, but rather merely a reasonable interpretation - one that I
explained in comment #4. How many examples do you want in order to be convinced
that this is not an uncommon interpretation?

Or can anyone else show where the opposite conclusion has been reached?

> and HTML5 does suggest alternatives:

<offtopic>

Speaking of alternatives, not a single alternative to "use @summary" is offered
in the "Techniques for Web Content Accessibility Guidelines 1.0" informative
companion to WCAG 1.0.
http://www.w3.org/TR/WCAG10-HTML-TECHS/#table-summary-info

That does suggest that, at the time, any other techniques were not considered
appropriate, or were simply not considered.

Things change over time, I'm not saying that there aren't viable alternative
techniques now, and I wouldn't even say that some of them, for some tables in
some documents, couldn't have worked then (though they would not have met the
standard as written). But to go from the position that @summary is, if not in
all cases the superior method, then at least the only universally appropriate
method, of conveying a table summary, to the position that @summary at best is
useless and perhaps actively harms accessibility and must not be used under any
circumstances, is on heck of a backflip, even if it's correct.

</offtopic>

> (providing a summary and providing a @summary attribute are not necessarily the same thing)

I was asked if the specification actually said to use the summary attribute,
and it does (comment #1 and comment #2).
> in HTML, use the "summary" attribute of the TABLE element.

Then I was asked if that interpretation is actually used by anyone, and it is
(comment #9 and comment #10).
> Checkpoint 5.5 requires that tables use the SUMMARY attribute.

What more do you want?

> To put it another way, if your task requires @summary and markup validity, then HTML5 is not "appropriate for [the] task" so WCAG1 does not require you to use it.

I suggested something similar in comment #0; but is this really the preferred
response?

If someone is prepared to say something like "the authors of HTML5 do not
consider that compatibility with WCAG 1.0 is possible and is not worth making
this change in an attempt to achieve it", then I will agree to close this bug
and not raise the matter again. Because unless that is what you are saying,
then some other resolution must be achieved. Conversely, though, if WCAG 1.0
compliance is genuinely considered insufficiently important to make changes to
@summary for, then there shouldn't be any problem saying that, and I can just
pack up and go.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 29 January 2012 18:58:34 UTC