- From: <bugzilla@jessica.w3.org>
- Date: Sun, 29 Jan 2012 12:28:48 +0000
- To: public-html-a11y@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14107 --- Comment #14 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2012-01-29 12:28:47 UTC --- (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.) -- 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 12:28:56 UTC