Note: I am aware of the very long history of this decision (http://www.w3.org/html/wg/wiki/SummaryForTABLE), but the impact on Web Content Accessibility Guidelines conformance is one that I haven't seen discussed.

html5-diff is just a summary of what changed. Reassigning.

Does WCAG have specific requirements regarding the means of which the summary is provided? If not couldn't you use other means of providing a summary? Such as a <p> after the table or using aria-describedby?

> Does WCAG have specific requirements regarding the means of which the summary is provided?

Probably, but maybe not. It explicitly references the summary attribute by example in a normative section:
> For example, in HTML, use the "summary" attribute of the TABLE element.
To me, that's explicit. But since it's an example, whether it counts as explicit or merely suggestive is a question that could be argued by anyone with enough interest in the outcome.

> If not couldn't you use other means of providing a summary? Such as a <p> after the table or using aria-describedby?

Maybe, but ARIA is far, far less well-supported, currently. WCAG must be used in the context of an accessible end-result; you cannot meet WCAG 1.0 even if you follow every point, if the end result is not accessible.

While this would probably, typically, be as accessible, in respect of itself, it may trip up other accessibility issues. For example, it doesn't do much good, to a non-visual reader, at the bottom of the table - which is where you just suggested putting it, and where the majority of authors would put it (because that's where it would traditionally go in a print publication), if they chose to put one at all. You would want it before the table, so that you can then skip the table; you couldn't skip the table if you didn't know that there was a summary after it, though. Consider WCAG 1.0 Checkpoint 13.8:
> Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

It seems to me that forbidding the summary attribute would make it much harder for authors to use the technique of table summaries, generally, properly.

(In reply to comment #4)
> > Does WCAG have specific requirements regarding the means of which the summary is provided?

It does not.

> Probably, but maybe not. It explicitly references the summary attribute by
> example in a normative section:
> > For example, in HTML, use the "summary" attribute of the TABLE element.
> To me, that's explicit. But since it's an example, whether it counts as
> explicit or merely suggestive is a question that could be argued by anyone 
> with enough interest in the outcome.

That sentence is awfully bad spec writing. There are two ways to argue the meaning of the sentence. One is that it gives one example of giving table summaries in HTML implying that the sentence is non-exclusive and there are other possible ways. The other potential meaning is that HTML is given as an example of a vague larger set of possible formats but in HTML, using the summary attribute is unqualified.

If you want to argue the latter, I think it's unreasonable to construe "HTML" to mean any flavor of HTML in 1999 and forever thereafter. I think it's more reasonable to construe it to mean HTML as HTML existed in 1999. If we take the "for example" to imply that there are other non-HTML formats that WCAG tries to apply to, why would it be reasonable to have a special lock-down for future flavors of HTML?

Also, the WAI made a special effort to make WCAG 2 technology-independent precisely because WCAG 1 was too closely-coupled with the technologies of 1999, so I think it doesn't make sense to try to treat WCAG 1 as normative over the design of specs that are on track to supersede the technologies of 1999. I think it's particularly unreasonable to read checkpoint 11.1 to mean that all of WCAG 1 restricts all future specs without reading it to mean that you should stop using WCAG 1 and use WCAG 2 instead.

> It does not.

Just to be clear; I have no interest in how this is resolved, except that I am bound to follow most of WCAG 1.0, however it ends up being interpreted (and probably, that will mean interpreted by lawyers, not the W3C).

> That sentence is awfully bad spec writing.

Absolutely. It's not the first such example, and it won't be the last. Ambiguity is a criticism that was frequently leveled at the WCAG 1.0 spec.

> There are two ways to argue the meaning of the sentence.

I'm not so sure; but it isn't really for me to argue one side or the other.

> One is that it gives one example of giving table summaries in HTML implying that the sentence is non-exclusive and there are
other possible ways.

If the (non-normative) companion documents are to be believed, there may be other ways (the caption element or the title attribute, and maybe the also-to-be-obsoleted abbr attributes on th elements), but only in some circumstances; the nature of some tables requires the summary attribute.

> The other potential meaning is that HTML is given as an example of a vague larger set of possible formats but in HTML, using the summary attribute is unqualified.
> If you want to argue the latter, I think it's unreasonable to construe "HTML"
to mean any flavor of HTML in 1999 and forever thereafter.

I have to disagree there. While it's probably unreasonable to attempt to *follow* WCAG 1.0 if that's what it means, I nevertheless believe that this is exactly what it was intended to mean; given that there is effectively an entire checkpoint stating that this is what it means (11.1).

> If we take the "for example" to imply that there are other non-HTML formats that WCAG tries to apply to, why would it be reasonable to have a special lock-down for future flavors of HTML?

Perhaps because it was considered that, for backwards-compatibility reasons if no other, that particular attribute would always exist? My following of the decision to remove the summary attribute seems to indicate that it's a knife-edge choice either way, and that in the end simplicity for authors won out (user agent vendors have to support it anyhow).

Maybe it's just that it was considered that another version of WCAG would be published before another version of HTML (it was), but did not anticipate that regulations would force following WCAG 1.0 and not itself be updated before the next version of HTML (at the time, I believe it was not expected that there would ever be another version of HTML).

> Also, the WAI made a special effort to make WCAG 2 technology-independent
precisely because WCAG 1 was too closely-coupled with the technologies of 1999

Indeed.

Just the same, those bound by law are stuck with WCAG 1.0 - maybe this will be fixed by the time the HTML5 spec is formally finalized (it's got a few years to go), but maybe not.

> so I think it doesn't make sense to try to treat WCAG 1 as normative over the
design of specs that are on track to supersede the technologies of 1999.

Unfortunately, not all of those (in fact, probably none of those) who are required to follow WCAG 1.0 explicitly, get to choose to disregard certain requirements as impractical.

> I think it's particularly unreasonable to read checkpoint 11.1 to mean that all
of WCAG 1 restricts all future specs without reading it to mean that you should
stop using WCAG 1 and use WCAG 2 instead.

Unreasonable or not, some people have no choice.

***

I agree with you almost completely. WCAG 1.0 is problematic. Even so, the W3C authored and recommended it, and has not retired it. It's a current recommendation, even if there is also a more up-to-date recommendation.

Of course, legislative problems for authors are not strictly the concern of the HTML5 working group. Except that, I understand that widespread and rapid adoption of HTML5 is one of the main priorities of the HTML5 working group.

I wonder, if the issue might be neatly resolved for everyone by making the summary attribute conforming (obsolete or not). Authors can use it, or not, as needed, and as far as they cannot use another solution. Vendors have to support it anyhow. Hence, this bug.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: summary's demise was a conscious decision and does not make pages less accessible

Sorry, I must have been unclear.

This bug is not "tables without @summary are inaccessible". I have plenty to say on that subject, but this is not the forum for such discussion.

This but is not even "@summary should not be removed" - that is simply a suggested resolution.

This bug is that, a normative section of a current W3C Recommendation, implemented in legislation around the world, says: 
> […] in HTML, use the "summary" attribute of the TABLE element.

The current state of the spec. contradicts this directive and needs to be reconciled.

If the Editor disagrees that there is a spec. contradiction, unrelated to the merits or lack thereof regarding the summary attribute, then that is the Editor's determination to make in respect of this spec., but I was pointing out that regardless of any determination made in this spec., some major stakeholders will no doubt be making their own determination in regards to the meaning of the other mentioned spec.

Despite the assertion that removing @summary does not make pages less accessible, keeping @summary does not make pages less accessible either, nor does it cause any other significant problems. But removing @summary, at this time, does cause at least this problem. Legislation is much slower-moving than the web, even in spite of the relative slowness of some major specs.

(In reply to comment #6) 
> > I think it's particularly unreasonable to read checkpoint 11.1 to mean that all
> of WCAG 1 restricts all future specs without reading it to mean that you should
> stop using WCAG 1 and use WCAG 2 instead.
> 
> Unreasonable or not, some people have no choice.

Can you point to an example of legislation that forces this interpretation of WCAG1's own requirements? I'm not sure how W3C can guard itself against such secondary interpretations.

> Even so, the W3C
> authored and recommended it, and has not retired it. It's a current
> recommendation, even if there is also a more up-to-date recommendation.

I'm not sure what you mean. In addition to WCAG's own text on the matter, WCAG2 states:

"WCAG 2.0 succeeds Web Content Accessibility Guidelines 1.0 [WCAG10], which was published as a W3C Recommendation May 1999. Although it is possible to conform either to WCAG 1.0 or to WCAG 2.0 (or both), the W3C recommends that new and updated content use WCAG 2.0. The W3C also recommends that Web accessibility policies reference WCAG 2.0."

Can you explain what "retiring" WCAG1 would mean in terms of the W3C process? Are there any W3C specifications that are "retired"? Or, failing that, can you point to any examples from other specification-recommending organisations?

i.e. What can W3C do to retire WCAG 1?

> Can you point to an example of legislation that forces this interpretation of
WCAG1's own requirements?

In 1997, the Australian Human Rights Commission (at the time, the Australian Human Rights and Equal Opportunity Commission) endorsed WCAG 1.0 as being consistent with the requirements of the Disability Discrimination Act 1992.

The first case law in the world, on this matter, McGuire vs SOCOG, affirmed that position, in 2000.

The Council of Australian Governments, including the federal government, all of the state governments, and the Australian Local Government Association, agreed that all respective state legislation also implied a requirement of compliance with WCAG 1.0; all produced policy documents asserting this, and mandated compliance by their own agencies.

An example of this interpretation is found in the latest version of the Victorian Government Accessibility Toolkit - the manual provided for explaining requirements to various agencies in that state. The authors consider that "Checkpoint 5.5 [of WCAG 1.0] requires that tables use the SUMMARY attribute."

http://www.egov.vic.gov.au/pdfs/accessibility-toolkit-v3.1.1-mar2011.pdf (p.122)

(See also the introduction for some examples of the rationale, from a compliance point-of-view, for not using WCAG 2.0 at this time)

> I'm not sure how W3C can guard itself against such secondary interpretations.

It could:

* Retire superseded specifications.
* Update the specifications (say, WCAG 1.01).
* Publish Errata.
* Not publish contradictory Recommendations.

The first option is not viable, as explained below. But either of the other three would suffice.

Keep in mind that, because WCAG 1.0 is not re-implemented in legislation (such as is the case with the US Section 508 of the Americans with Disabilities Act), but merely referenced by legislation, formal errata would automatically supersede interpretations unless affirmed by the High Court, in the case of Australia at least.

> I'm not sure what you mean. In addition to WCAG's own text on the matter, WCAG2 states:
> "WCAG 2.0 succeeds Web Content Accessibility Guidelines 1.0 [WCAG10], which was published as a W3C Recommendation May 1999. Although it is possible to conform either to WCAG 1.0 or to WCAG 2.0 (or both), the W3C recommends that new and updated content use WCAG 2.0. The W3C also recommends that Web accessibility policies reference WCAG 2.0."

That is non-normative, and in fact reinforces that WCAG 2.0 does not supersede WCAG 1.0, but is rather simply a superior choice for the kinds of web content being generated in 2008, than for the state of the web in 1999.

Remaining consistent with WCAG 1.0 - at least where it does not cause any problems for anybody - should therefore be a priority for the W3C, I believe.

In late 2010, the Australian Human Rights Commission did actually endorse WCAG 2.0. However, it has not yet been implemented in policy: implementation has just been delayed again, until the end of 2013, and unofficially at this stage, it will soon be delayed yet again until the end of 2014 as a minimum. After that, who knows? It is very possible that HTML5 will be completed while WCAG 1.0 is still being required. And that's speaking just for Australia, and not other countries who's implementation schedules I know rather less about.

> Can you explain what "retiring" WCAG1 would mean in terms of the W3C process?

I do not actually know how Recommendations could be made obsolete within the W3C; in fact, I suspect they currently can't be, under ordinary circumstances.

But WCAG 1.0 has not been superseded and should not be retired, I think.

> Are there any W3C specifications that are "retired"?

"Specifications"? Yes, a large number of Working Drafts and Group Notes which never made it to Candidate Recommendation (and typically were never supposed to) have been obsoleted with the status "Retired". Usually, when they are subsumed wholly withing other specifications, but sometimes it is just because they are not, strategically, useful any longer.

> Or, failing that, can you point to any examples from other specification-recommending organisations?

I could; in light of the above comments, would if still be helpful for me to research that and post it in this bug?

> i.e. What can W3C do to retire WCAG 1?

I don't know. I don't think that they have to. All instances of interpretation of W3 specifications, that I know of, (by governments, as opposed to vendors, who can be rather creative) are simply practical clarifications in an area where the W3 has not made such clarifications, yet. That is, they have read the specification as it makes sense to read it, and asserted a reasonable meaning. If something different is intended, it must be clarified.

I believe that this interpretation will evaporate if appropriate Errata is published - assuming that this is in fact what the editors of WCAG 1.0 intended, or at least what the stakeholders understood their intention to be.

Would you like for me to take this to the Web Content Accessibility Guidelines Working Group?


In any case, in respect of this bug, if the Editor is prepared to assert that his interpretation is that there is no inconsistency, then that will solve the bug itself. But that will not change the WCAG specifications, nor the interpretations made in the absence of such changes. And I have raised this issue because I think that potentially forcing a schism between governments and the W3C is a very dangerous thing to do, in light of the years of work the W3C has done to encourage government involvement, for the sake of an attribute that seems to have been removed for not much better reason that "it looks neater this way".

I should be clear, again, that the implementability of the W3C specifications is my goal, and not the preservation of any particular feature. I will absolutely withdraw my protest here, if the consensus (from stakeholders within and without the W3C) is that there is no inconsistency between the standards mentioned here.

(In reply to comment #10)
> In late 2010, the Australian Human Rights Commission did actually
> endorse WCAG 2.0. However, it has not yet been implemented in policy:
> implementation has just been delayed again, until the end of 2013, and
> unofficially at this stage, it will soon be delayed yet again until
> the end of 2014 as a minimum.

Do you have a citation for this?

The Victorian and Austrialian Governments both appear to require WCAG2 compliance by 31 December 2012:

    http://www.egov.vic.gov.au/victorian-government-resources/standards-victoria/accessibility-standard.html?sid=964059446

    http://webguide.gov.au/accessibility-usability/accessibility/

(That's not to say they will achieve it, of course!)

In general, the mismatch between providing best practice guidance to developers on rapidly changing technologies and encoding implementation specifics, rather than end-user requirements, in law is a problem that goes way beyond the @summary attribute. Witness the recent thread on public-webapps about adding obsolescence notices to legacy DOM specifications:

   http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0245.html

The debate about even adding a pointer to more relevant documents is suggestive of why the W3C has never used its own procedure for formally rescinding a Recommendation:

    http://www.w3.org/2004/02/Process-20040205/tr#rec-rescind

(In reply to comment #11)
>     http://www.w3.org/2004/02/Process-20040205/tr#rec-rescind

Sigh, talking of versioning, that should have been:

http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind

> Do you have a citation for this?

As you could guess, it's a complex answer.

The National Transition Plan gives a wide span for implementation, and it doesn't technically have to be completed before 2014. The 2012 number is for completely new websites (but with exceptions).
http://www.finance.gov.au/publications/wcag-2-implementation/work-plan.html#phase3

Various agencies also have further relaxed dates, under the Australian Government (Financial Management and Accountability Act 1997) (FMA Act)
http://webguide.gov.au/accessibility-usability/accessibility/

Also, state governments can to some extent vary the schedule. For example, the Western Australian (state) government has said that it will be following the Website Accessibility National Transition Strategy, but that the timelines are different, with a (currently) final date of 2013:
http://www.publicsector.wa.gov.au/AgencyResponsibilities/Accessibility/Pages/Approach.aspx

And so on. I have literally hundreds of pages of documents, both web and physical, that go into detail about which agencies are doing what, and when. The information is recorded with different dates in a lot of different places, only some of which have the latest versions online. Would you be interested in an infodump here in this bug?

It's all still also subject to change, since, as you observe, (choosing my words carefully here) there is not much visible progress towards having this implemented across the whole government by the end of this year (2012), my efforts and the efforts of many other hardworking people notwithstanding. Also note that every state government reduced their IT budgets last year (one war or another) due to global economic reasons, and the commonwealth budget only increased because of a major focus on the National Broadband Network and related policies.

And keep in mind that, with all due respect, Australia is one of the most progressive countries in the world, in terms of mapping strong disability legislation to website accessibility. This is an undeniably good thing, even if it creates problems of its own, but this issue could well come up again with the UK, Canada, and other countries (for whom my knowledge is rather less up-to-date), as they move towards the future.

> In general, the mismatch between providing best practice guidance to developers on rapidly changing technologies and encoding implementation specifics, rather than end-user requirements, in law is a problem that goes way beyond the @summary attribute.

I agree, though reservedly. As I said though, it is still a good thing that governments take accessibility and standardization seriously, and back it with the force of law, than going off and doing their own thing, or worse, doing nothing. As I said, implementability is key: governments can be left to making things as easy or as hard for themselves as they want, but things shouldn't be deliberately made harder for them without a critically important reason. When they're stuck in an impossible quandary - whoever got them there - it's the users who suffer.

If the WCAG WG won't publish errata, and the W3C won't rescind the spec., then it falls to whomever is producing new standards to interpret old specs. But this should be done in careful consultation with stakeholders, not unilaterally.

For example, the previously linked Victorian Government Accessibility Toolkit was originally written by Gian WILD, one of the foremost web accessibility experts in the world, and a member of the WCAG WG for many years.

@summary being essential is likely a very common interpretation by experts in the web accessibility field, and the governments and businesses and charities and standards organizations who listen to them, and it should be carefully considered how it will impact the development of HTML5 - hence this bug.

But in this case, the problem seems to have a trivial solution: make @summary conforming to at least some degree (such as obsolete but conforming).

HTML has never before obsoleted any standard element or attribute, without first deprecating them for an extended period of time. Indeed, I think @name is the only case of an attribute that has been made fully obsolete (even then, only on a and map), and even that took nearly ten years and three full HTML versions between compliance, deprecation and obsolescence - and it had a directly substitutable, widely-supported, sideways-compatible, and clearly superior, drop-in replacement: @id.

The argument that authors won't/don't use it right is phooey; it can currently be applied to alt (look how many people *still* use it for tooltips, or don't use it at all), and in fact, almost any feature in discussion of accessibility (sadly). The argument that non-AT users of graphical browsers can't benefit is unimaginative at best: a simple custom stylesheet is all that's needed (this is one of several user stylesheets I use during testing):


table[summary] > thead, table[summary] > tbody, table[summary] > tfoot, table[summary] > tr {
    display: none !important;
}

table[summary]:after {
    content: "Table Summary (hover to show table): \00000A" attr(summary) !important;
}

table[summary]:hover thead {
    display: block !important;
    display: table-header-group !important;
}
table[summary]:hover tbody {
    display: block !important;
    display: table-row-group !important;
}
table[summary]:hover tfoot {
    display: block !important;
    display: table-footer-group !important;
}
table[summary]:hover tr {
    display: block !important;
    display: table-row !important;
}
table[summary]:hover:after {
    content: none !important;
}

table table:not([summary]) {
    display: block !important;
    display: table !important;
}


(Even this is far more complicated than is realistically needed, simply to handled nested tables and legacy browsers better. It could also be trivially modified to, for example, show both the table and the summary when printed, or not rely on a mouse, etc.)

But, for THIS bug, these technical points do not matter. What is critical is that allowing @summary, transitionally if not otherwise, would prevent a major problem from forming, and does not create any new problems.

> the W3C has never used its own procedure for formally rescinding a Recommendation:

Yes, but obsoleting WCAG 1.0 wouldn't be helpful under any circumstances. There is nothing wrong, technically, with WCAG 1.0 - it's just old and not as useful as WCAG 2.0, which, I might add, everyone is rushing towards as fast as they can (which is unfortunately not very fast). Saying "don't use this spec." does not magically change the reality that law, policy, and similar, sometimes mandate an exact spec., in the same way that having an outdated spec. does not change the reality that vendors and developers may be ten years ahead of the Recommended specs.

WCAG 1.0 is not (at least as far as this bug goes) critically blocking the grand vision for HTML5. It is interfering with a tiny feature that has a few dozen proponents on either side, and that will make basically no material difference to the nature of either author usage in the main, nor, in particular, to user agents, however the matter is ultimately decided. We can fairly, if sadly, say that whether included or not, 99% of authors for the foreseeable future will either abuse or ignore it, that major user agent support will be the absolute minimum or less, and that no algorithm, philosophy or other part of this spec. or any dependent spec. depends syntactically or technically upon it existing or not existing. And that is why I think that the correct resolution, for THIS bug, is making @summary at least obsolete but conforming: a tool for those who need it and know how to use it. Usefulness beyond that is simply beyond the scope of this bug.

(In reply to comment #13)
> > Do you have a citation for this?
> 
> As you could guess, it's a complex answer.
> 
> The National Transition Plan gives a wide span for implementation, and it
> doesn't technically have to be completed before 2014. The 2012 number is for
> completely new websites (but with exceptions).
> http://www.finance.gov.au/publications/wcag-2-implementation/work-plan.html#phase3
> 
> Various agencies also have further relaxed dates, under the Australian
> Government (Financial Management and Accountability Act 1997) (FMA Act)
> http://webguide.gov.au/accessibility-usability/accessibility/
> 
> Also, state governments can to some extent vary the schedule. For example, the
> Western Australian (state) government has said that it will be following the
> Website Accessibility National Transition Strategy, but that the timelines are
> different, with a (currently) final date of 2013:
> http://www.publicsector.wa.gov.au/AgencyResponsibilities/Accessibility/Pages/Approach.aspx
> 
> And so on. I have literally hundreds of pages of documents, both web and
> physical, that go into detail about which agencies are doing what, and when.
> The information is recorded with different dates in a lot of different places,
> only some of which have the latest versions online. Would you be interested in
> an infodump here in this bug?

I'm probably missing something but scanning those documents none seem to legally require government employees to produce new or updated web content that conforms to WCAG 1.0 rather than 2.0, so I don't see how these documents are blocking migration to WCAG2 or HTML5?

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. 

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

   (a) UAs don't care which version of HTML you are targeting.
   (b) There's a W3C-published grammar for HTML4 + ARIA if you want to upgrade your markup.
   (c) Many of HTML5's shiny new features (e.g. new form features, new sectioning features) don't have broad accessibility support in UAs and AT yet, so they are best avoided by governments for now.
   (d) You can always upgrade the DOM when JS is available - which is often required to sniff support for HTML5 features anyway.

I think encouraging best practices for the entire web over the next decade is more important than speed of government adoption. (Whether encouraging other methods of providing table summaries than @summary is a better practice is, as you say, not the subject of this bug.)
 
> HTML has never before obsoleted any standard element or attribute, without
> first deprecating them for an extended period of time. Indeed, I think @name is
> the only case of an attribute that has been made fully obsolete (even then,
> only on a and map), and even that took nearly ten years and three full HTML
> versions between compliance, deprecation and obsolescence - and it had a
> directly substitutable, widely-supported, sideways-compatible, and clearly
> superior, drop-in replacement: @id.

The Toolkit's claim that you need to provide a @summary for every table looks like a misrepresentation of WCAG 1's normative requirements (providing a summary and providing a @summary attribute are not necessarily the same thing) and HTML5 does suggest alternatives:

    http://dev.w3.org/html5/spec/the-table-element.html#table-descriptions-techniques

(Again, it's not the purpose of this particular bug to discuss the suitability of those alternatives.)

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.

> 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.

(In reply to comment #0)
> The summary attribute for the table element has become non-conforming, but
> should be obsolete but conforming, because:
> 
> Web Content Accessibility Guidelines 1.0 Guideline 5.5 ("Provide summaries for
> tables") requires that summaries are provided for tables, and for "HTML", that
> means the summary attribute.
> 
> Furthermore, WCAG 1.0 Guideline 11.1 ("Use W3C technologies when they are
> available and appropriate for a task and use the latest versions when
> supported") requires that the latest versions of W3C technologies, including
> HTML, be used. So, once HTML5 is standardized, it will have to be used. (There
> might be some wiggle room on the "appropriate for a task" and "when supported"
> qualifiers; but I imagine that you wouldn't want people to recommend against
> HTML5 usage specifically due to this reason).
> 
> The summary attribute can't just be used in violation of the specification,
> because that would violate WCAG 1.0 Guideline 3.2 ("Create documents that
> validate to published formal grammars"). Custom Doctypes and similar solutions
> are likewise stymied.
> 
> While people should meet WCAG 2.0 rather than WCAG 1.0, there is currently
> significant legislative requirement around the world to use WCAG 1.0, which has
> not been updated.
> 
> Is there any special reason to retire the attribute? Most major browsers ignore
> it right now; is there a compatibility issue? It seems safer to keep it.

I consider that your argument is based on a mis-reading of the WCAG 1.0 guidelines.

1. WCAG 1.0 states

"5.5 Provide summaries for tables. [Priority 3]
For example, in HTML, use the "summary" attribute of the TABLE element.
[http://www.w3.org/TR/WCAG10/#gl-table-markup]

The checkpoint does not normatively require the use of the summary attribute it normatively requires the provision of summary information for data tables. The example of the summary attribute is from the techniques document which is non normative.

The abstract of the techniques document states:

" This document is intended to help authors of Web content who wish to claim conformance to "Web Content Accessibility Guidelines 1.0" ([WCAG10]). While the techniques in this document should help people author HTML that conforms to "Web Content Accessibility Guidelines 1.0", these techniques are neither guarantees of conformance nor the only way an author might produce conforming content."
[http://www.w3.org/TR/WCAG10-HTML-TECHS/#table-summary-info]

the most pertinent part of the above quote is;

"nor the only way an author might produce conforming content."

So authors can still provide summaries for tables that do not involve the use of the summary attribute, but can be considered as conforming to WCAG 1.0.

(In reply to comment #0)
> The summary attribute for the table element has become non-conforming, but
> should be obsolete but conforming, because:
> 
> Web Content Accessibility Guidelines 1.0 Guideline 5.5 ("Provide summaries for
> tables") requires that summaries are provided for tables, and for "HTML", that
> means the summary attribute.
> 
> Furthermore, WCAG 1.0 Guideline 11.1 ("Use W3C technologies when they are
> available and appropriate for a task and use the latest versions when
> supported") requires that the latest versions of W3C technologies, including
> HTML, be used. So, once HTML5 is standardized, it will have to be used. (There
> might be some wiggle room on the "appropriate for a task" and "when supported"
> qualifiers; but I imagine that you wouldn't want people to recommend against
> HTML5 usage specifically due to this reason).
> 
> The summary attribute can't just be used in violation of the specification,
> because that would violate WCAG 1.0 Guideline 3.2 ("Create documents that
> validate to published formal grammars"). Custom Doctypes and similar solutions
> are likewise stymied.
> 
> While people should meet WCAG 2.0 rather than WCAG 1.0, there is currently
> significant legislative requirement around the world to use WCAG 1.0, which has
> not been updated.
> 
> Is there any special reason to retire the attribute? Most major browsers ignore
> it right now; is there a compatibility issue? It seems safer to keep it.

Also it should be noted that 5.5 Provide summaries for tables. is a 'Priority 3' checkpoint.

WCAG 1.0 states:

"[Priority 3]
A Web content developer *may* address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents."
http://www.w3.org/TR/WCAG10/#priorities

the key word 'may' as defined in http://www.ietf.org/rfc/rfc2119.txt:

"MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional."

> The checkpoint does not normatively require the use of the summary attribute it normatively requires the provision of summary information for data tables. The example of the summary attribute is from the techniques document which is non normative.

I've been over this, in comment #4 and comment #6 primarily - there is no indication within WCAG 1.0 as to how such examples are to be interpreted. However, the example is in a normative section (Checkpoint 5.5), and is not written to indicate that other techniques might be usable (as most such examples are).

If the reading that I've described in this bug is a mis-reading, then it is a mis-reading that the world's top web accessibility experts and senior policymakers have been making for over ten years.

> The abstract of the techniques document states:

That, on the other hand, is completely non-normative.

Furthermore, as I mentioned in comment #16, no alternatives are actually offered in that document or in any other related document - which does not mean that none exist, but combined with the normative text, it does indicate why such an interpretation could be reasonably drawn.

> Priority 3

No, because the Priorities are organized into Conformance Levels, and these are the levels specified by policy.
http://www.w3.org/TR/WCAG10/#Conformance

The Priorities do not specify Conformance: they specify the impact of conformance.

(If they did, you'd have the ridiculous situation where claiming conformance to Level AAA would require meeting only Level A checkpoints).

Bug triage sub-team marking as verified because we don't believe conformance to WCAG 1.0 Priority 3 is something we need to push. The summary issue is still open but dealt with by other bugs.