- From: Charles Pritchard <chuck@jumis.com>
- Date: Sat, 02 Jul 2011 22:05:27 -0700
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- CC: Henri Sivonen <hsivonen@iki.fi>, Sean Hayes <Sean.Hayes@microsoft.com>, "E.J. Zufelt" <everett@zufelt.ca>, Paul Bakaus <pbakaus@zynga.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, John Foliot <jfoliot@stanford.edu>, Charles McCathieNevile <chaals@opera.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cameron McCormack <cam@mcc.id.au>, Cynthia Shelly <cyns@microsoft.com>, "david.bolter@gmail.com" <david.bolter@gmail.com>, Frank Olivier <Frank.Olivier@microsoft.com>, "Mike@w3.org" <Mike@w3.org>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
> Do you not see that it is counter-productive when these conversations go > round in circles like this: > > Person A: We need to help developers make accessible web services. > Person B: Agreed. > Person A: We need feature X to support accessibility use-cases J and K. > Person B: Feature X does not benefit use-case J, but it sounds like a > good use-case to try to solve. How about feature Y? > Person A: That argument is as dumb as bricks. User agents are failing their > moral and legal obligations by not providing accessibility and enabling > competition. We need feature X to support accessibility use-cases J and > K. > Person B:<facepalm> > > Imagine another world for a second in which these conversations went > more like this: > > Person A: We need to help developers make accessible web services. > Person B: Agreed. > Person A: We need feature X to support accessibility use-cases J and K. > Person B: Feature X does not benefit use-case J, but it sounds like a > good use-case to try to solve. How about feature Y? > Person A: You're right, but in that case we'd also need feature Z. > Person B: Yeah! Let's add features Y and Z to the spec.<smile> > Person A: Cool! Now what about use-case K? > > Wouldn't that be better? > I don't think we had that kind of discussion. I stated it would benefit cases J and K, you stated it would not; and then we both decided that we know better (in a technical manner) than each other. I'd love to extend that part of it -- the technical part of it -- by providing code, examples, demos and all the rest of it. But that's costly, and it's not really gotten me anywhere in the past. If I were to create a tech demo showing that use cases J and K were solved by feature X being exposed to the scripting environment -- does that actually meet criteria? Yours has been about "practicality"; mine has been about practice. I don't think my actual, technical work, meets the bar that you're hoping to achieve. As for braille -- we have some luck working with it, as it's supported by UTF8, and so we really have a good deal of expressivity. As for synchronization -- I like synchronization, it's a difficult subject, but for all practical purposes, just as with sign language -- it need not be aligned to the tenth of a second; it only needs to be near. I've not worked enough with audio and video tags to judge; I have heard repeatedly that implementations of the audio tag are not suitable for practical use and that Flash fallback is still necessary in modern browsers. -Charles
Received on Sunday, 3 July 2011 05:06:33 UTC