- From: John Foliot <foliot@wats.ca>
- Date: Fri, 31 Aug 2007 16:30:43 -0700
- To: "'T.V Raman'" <raman@google.com>
- Cc: <public-html@w3.org>, <w3c-wai-ig@w3.org>, <w3c-wai-ig-request@w3.org>, <raman@cs.cornell.edu>
With deference to Joe, pardon the top post. Raman, Thank you for your eloquent words, especially in reference to "what was/is" [#2 & #3 below]. If you missed Raman's posting, please do read it JF T.V Raman wrote: > Not quite sure what you were looking for with respect to my comments > on > http://joeclark.org/book/sashay/serialization/Chapter11.html > > But here are a few. > > 0) It's a mistake to pigeon-hole Aural CSS as assistive/adaptive > technology -- it's a media-specific style technology for a > media that is waiting to happen on the Web at some > point. (where some point == when we're all tired of clicking > on flashing pictures) > > 1) Note the points that Joe recorded faithfuly in his article > with respect to what I said about using class values > intelligently as an author, and not worrying at authoring > time about how it might get used (today you'd call that > microformats). > > 2) The biggest risk with respect to accessibility is to define > tomorrow's authoring solutions based on yesterday's access > technology. The reason this is a downward death-spiral is > that today's access technologies were written yesterday to > work the content that was created the day-before-yesterday. > > 3) So: break the vicious circle, write clean content, use > meaningful markup, and intelligent software that leverages > your content in ways you never imagined will "emerge" -- that > in fact is the secret to the success of the Web. Arguments of > the form "no tool uses X", therefore "drop X" and "people did > Y yesterday, so bless it as the one and only solution for > tomorrow" typically lead to the death-spiral sketched out > above. > > > 4) Taking the sum total of the above, Accessibility contrary to > common belief is actually extremely easy to do if done right. > Easy: > > A) You dont need to go test your content with one or other > access tool. But then in a Web that stuck to its original > design goals, you wouldn't need to test your content in > different browsers either. > > B) As authors, make sure you *always* own your content in the > sense that your content never becomes the slave of some > authoring tool that purports to "make your life > easy". They usually dont, and only make your life more > difficult down the line. > > C) I myself came to XML/XHTML from the world of LaTeX, and *all* > my notes from graduate school that I wrote in LaTeX are > still usable and machine-processable. > Having moved from LaTeX to XHTML for a while, I now find > myself mostly creating content in: > 0) LaTeXfor high-quality print output > 1) Emacs/org-mode http://orgmode.org for pretty much > everything else > > And generate XHTML when needed for the Web -- > Using tex4ht for LaTeX and Emacs/org-mode export > facilities for the rest. > D) And for intelligent uses of class values see these > sections of the online Emacspeak documentation: > WebSearch: > > > > http://emacspeak.sourceforge.net/info/html/emacspeak_002dwebsearch.html#emac speak_002dwebsearch > URL Templates: > http://emacspeak.sourceforge.net/info/html/emacspeak_002durl_002dtemplate.ht ml#emacspeak_002durl_002dtemplate > > E) And in a final interesting twist on leveraging class > values,a few years ago if you told HTML authors to put > unique id values on containers, they would flatly > refuse. But any time you AJAX-enable your site with > JavaScript handlers, those handlers need to address > portions of the page, and authors end up putting unique > ids. As an example, see the "CNN Content" URL template in > the Emacspeak codebase. > > > Hope you found this a good read, it's Friday afternoon which is > probably why I got philosophical.
Received on Friday, 31 August 2007 23:31:30 UTC