- 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