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/
