- From: <bugzilla@jessica.w3.org>
- Date: Sun, 29 Jan 2012 11:26:38 +0000
- To: public-html-a11y@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14107
--- Comment #13 from theimp@iinet.net.au 2012-01-29 11:26:36 UTC ---
> 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.
--
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 11:26:48 UTC