On Mon, 17 Mar 2008, Jonathan Rochkind wrote:
> My general philosophy is still always to put as _little_ Javascript as
> possible. Thus my way-too-clever idea to have some javascript which
> actually sends the Google (or similar) API response back to my server
> via AJAX for _real_ processing. :)
I've had the same philosophy -- even in the case where I have javascript
tree-like menus, the server renders them as fully opened, and then
javascript collapses them to leave the appropriate portions
expanded:
http://sdac.virtualsolar.org/cgi/search?provider=1&instrument=mdi&version=current&build=1
(I'd be happier if the HTML were a series of unordered lists, but I'm far
enough behind with my
> But if you DO want or need to do javascript-heavy stuff, I _highly_
> encourage you to take a look at some of the various Javascript client
> libraries that are out there, like Prototype. Such libraries can
> provides support for easy 'inheritance' in Javascript (implemented
> through behind the scenes fakery), as well as ways to see what
> versions/functions of javascript are supported in the browser.
Don't worry -- I have no intentions of recreating the wheel. I've been
using Prototype for about two years now, and for this recode (displaying
large tables of data, but giving the user the ability to rearrange / sort
on the various fields), we're going with ExtJS.
Unfortunately, although the functionality all works well with scripting
on, it generates some horrible DOM (every row it its own table, and
multiple DIVs down ... I assume to deal with the IE box model issue)
> But if you are trying to make things available without client javascript
> at all... if a given API like Google _requires_ it, well, then there's
> no way to have Google results used by the interface in a non-javascript
> client. That's obviously just a syllogism. [It's interesting to know
> though that, contrary to popular belief, recent versions of JAWS _do_
> support javascript. But only some kinds of javascript done in certain
> ways. Doing javascript that will work for JAWS is yet another layer of
> complexity, yet another headache. Added headaches and layers of
> complexity is why I try to minimize my javascript altogether. And JAWS
> is just one kind of 'accessibilty'. And the rules you have to follow
> whether you like it or not for 'accessibility' may or may not actually
> be rationally related to actual accessible use cases, like it or not.]
I still wish that there were a good free alternative to JAWS ... I mean,
they've decided to add CSS support, but not the 'aural' media type, if I
understand their website correctly :
http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=1165
They also think that passing validation is a viable test for
accessibility:
https://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=488
I would love to test some of my sites in JAWS (okay, and the sites I'm
forced to use at work that I'm pretty sure aren't compliant and those
where I have to forge my user agent string so it doesn't complain that I'm
not using IE), but I'm in a Windows-less environment.
I also haven't been following the WCAG2 efforts ... other than Joe Clark's
complaints about what was wrong with the process:
http://www.alistapart.com/articles/tohellwithwcag2
-Joe
