by Andrew Kirkpatrick

 Comments (4)


May 22, 2006

This post is subject to Adobe's Terms of Use.

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.


  • By anon dudr - 6:02 PM on June 15, 2006  

    Wow, great resource. All the links on your old blog are busted.
    Is this what Adobe thinks of its accessability initiative?

  • By AWK - 9:48 PM on June 15, 2006  

    Anon dudr,
    I checked the first 10 links I found on the old blog and they all worked. Can you be more specific? We definitely plan to keep that resource alive for the foreseeable future, so please let us know what you’re referring to!

  • By Accessibility - 1:35 PM on July 3, 2006  


    Were transitioning to an Adobe blog system where well talk about Flash, Flex, Dreamweaver, Acrobat This b…

  • By Dan Gleneck - 12:05 AM on July 24, 2010  

    Accessibility should be an “option” for the spry framework. However, it should be in a “extended” version — not the base version — just like there is a “packed” and “minified” include version. There should be a “Accessibility” include version.

    Accessibility should be “automatic” if my total development environment is Adobe. For example, if I
    (A) use ADOBE Coldfusion as my server back end,
    (B) use ADOBE Dreamweaver for my coding and development and
    (C) use ADOBE Spry,
    then Accessibility should be added automatically