- From: Robin Berjon <robin@berjon.com>
- Date: Mon, 9 Mar 2009 11:51:37 +0100
- To: Gregory J. Rosmaita <oedipus@hicom.net>
- Cc: Doug Schepers <schepers@w3.org>, SVG IG List <public-svg-ig@w3.org>, janina@rednote.net, www-archive@w3.org
Heya all,
I'd like to de-escalate from some of the negative bits of this
discussion and try to focus on things that could lead to concrete
improvements for all.
On Mar 6, 2009, at 23:19 , Gregory J. Rosmaita wrote:
> i'm not sure i understand why citing WCAG 2.0 is "unfair" or "hitting
> below the belt" -- WCAG compliance SHOULD, nay MUST (and that is an
> RFC2119 MUST)
It may not have been your intention, which is fine since we've all
made such mistakes, but your email came across as insinuating that
Doug and Cameron don't care about accessibility, which is what Doug
thought was unfair. It's an experimental tool, and they thought it was
marked up in a way that would make it accessible. It turns out that
it's not, and that's a bug, but filing a simple bug report would have
sufficed and probably been more effective than ascribing intentions.
So, in order to make this constructive, do you have concrete ideas on
how to make a n by n table of multi-valued options accessible? ARIA's
a start, but I'm not sure it is powerful enough yet to do that (I'd be
happy to be proven wrong though). I can see two things coming out of
this: either there is a good way to make this accessible, in which
case it needs to be written up and published (I'm guessing as one of
those blog posts that W3C puts out that outline specific uses for W3C
technology); or there isn't in which case the technology to do so
needs to be specified (perhaps by putting this example up as a use
case for ARIA 2.0).
> even if every one of my suggestions as regards w3c
> publication rules and accessibility are concerned are implemented,
> they
> won't really help anyone unless there is an accompanying "About This
> Document" section that describes in full what the stylistic
> conventions
> are -- for example, it is impossible for me to search for "red" text
> because i don't have any reason to believe that the text is anything
> particular color, but if i am pre-informed of the stylistic
> conventions
This seems like a low-hanging fruit that could be picked. W3C
specifications only use so many conventions, and the pubrules
validator can enforce that a given section be present in all
documents. If there is a regular issue in making W3C specifications
accessible, then it needs to be solved and enforced across all
publications. The technology side is easy, we just need a set of
agreed-upon conventions (that doesn't need to be exhaustive in its
first iteration, I'm guessing that any improvement would be welcome
here).
> if accessibility and device independence are NOT considered before a
> tool or publication rules are deployed, then the WAI and the W3C have
> failed in a crucial part of its mission -- to make the web usable by
> everyone, everywhere, no matter what modality they are using to
> interact
> with the web...
There's a difference between not considering, and considering but
failing to deliver. I'd flip the issue around: if W3C staff and chairs
who are not educated about and onboard with making sure everything is
accessible but also technically very competent fail to make at least
some parts of their work accessible, how are we going to get Joe Web
Hacker to produce accessible content?
Accessibility testing is hard and resource-intensive. The W3C has the
chance that it has a strong and vibrant community around WAI, and this
synergy should be used. You've listed two accessibility issues in this
discussion (polling and specs), how can they be improved, and where
they are how can we communicate about them?
--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/
Received on Monday, 9 March 2009 10:52:35 UTC