Posts in Category "DHTML"

May 22, 2006

Spry framework for Ajax

Adobe released the Spry framework for Ajax (Prerelease 1) on our Adobe Labs site a little over a week ago but I want to point it out as a segue into a discussion of JavaScript in web development.
The Spry framework is not finished at this time. The support for accessibility is developing, and I’d love to hear comments. Feel free to post comments here or to the Spry forum on the Labs site.
The Spry framework requires JavaScript. From a web-user who doesn’t use JavaScript’s perspective, a web application that doesn’t work when JavaScript is not used is not accessible. That user doesn’t care about, or probably know anything about “progressive enhancement” or “graceful degradation”, they just want to use the application.
So how does the non-JavaScript version of a web application get made? Progressive enhancement, which calls for using JavaScript to add functionality but that leaves all of the content and comparable functionality is one approach. In the Spry examples, the products demo is one example where this is possible. All of the data is static and under the developer’s controll and the developer could have all the content for every product in a structured (X)HTML file &#8212 when JavaScript is used the script eliminates most of the content and create the dynamic version, when JavaScript is not available the user gets the structured HTML.
Sounds pretty good, but what are the drawbacks? Page length and page weight are certainly factors to consider. If the page shows all of the data on a single page, there will be (in the case of the product demo) 150KB of images instead of 7KB and the page could be very long since it would have all of the content that is specific to each product on one page. There is the risk that the page would not be usable because of the length or page weight for some examples. Looking at the photo gallery demo I wouldn’t want all of the images from all of my photo galleries on a single page — pagination and separate galleries are useful features that help users deal with the large volume of content.
If the content is out of the developer’s control, as in the RSS Reader demo, this type of progressive enhance becomes unworkable, and the need to develop a server-side scripting alternative falls to the developer. David Powers made a PHP example of this for the products demo that works with JavaScript disabled, with the PHP parsing XML behind the scenes and delivering what is effectively a multi-page alternative version of the products demo.
Should the framework handle this? Which mechanism to use to provide content for a non-JavaScript user needs to be evaluated on a case-by-case basis. I’d love to expect that the Spry framework would handle this situation automatically, but I think that it is unreasonable to expect that. The process needs to get easier and I hope to offer some best-practice examples in the not-too-distant future to help developers. I’m interested in hearing people’s thoughts on what would be most helpful to them when dealing with this accessibility issue.

9:18 AM Permalink