- From: <bugzilla@jessica.w3.org>
- Date: Sun, 29 Jan 2012 18:58:31 +0000
- To: public-html-a11y@w3.org
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 on the CC list for the bug.
Received on Sunday, 29 January 2012 18:58:42 UTC