javascriptaccessibilitybackbone.jsjavascript-frameworksproutcore

Accessibility and all these JavaScript frameworks

I've been investigating a few of the JavaScript frameworks such as Backbone.js and Batman.js for a while and whilst I really like them, I have one niggling thing that I keep coming back to. That issue is accessibility.

As a web developer I've always tried to make my websites and applications with accessibility in mind, especially using the idea of progressive enhancement.

Clearly out of the box these new JS frameworks don't gracefully degrade, so I was wondering what are other developers thoughts on this issue and what are you doing about it. After all the accessibility of a website / app isn't really an optional thing as it's part of the law in many countries.

Maybe I'm just being overly zealous on this subject, and not appreciating how far things have come in terms of accessibility.

Solution

  • I use a js-framework (spine.js in my case) in my latest site. Still I make sure that non-js browsers (certainly not over zealous: think SEO) can navigate my site and digest the contents.

    As an example I'm going with a search-page with products being shown. Products can be paged, filtered, sorted. Of course this is an example of the generalized idea.

    PREREQ: use a template-engine that can both render server-side and client-side. (I use Mustache) . This makes sure you can render models without js- through server-side templating, and render models with js through client-side templating.

    1. Initially: render the products using server-side mustache-template. Also include a 'bootstrapJSON'-object which contains the same products in JSON-format.

    2. Initially: all links (product-detail page, paging, sorting, filtering) are real server-side urls (no hashbang urls)

    3. The end-result is a page which can be navigated 100% with paging, sorting, filtering without the use of JS.

    4. all paging,sorting, filtering urls result in a request to the server, which in turn results in a new set of products being rendered. Nothing special here.

    5. JS-enabled - on domload:

      • fetch the bootstrapJSON and make product-models from it (use your js-framework features to do this) .
      • Afterwards rerender the products using the same mustache-template but now doing it client-side. (Again using your js-framework).
      • Visually nothing should change (after all server-side and client-side rendering was done on same models, with same template), but at least now there's a binding between the client-side model and the view.
      • transform urls to hashbang-urls. (e.g: /products/#sort-price-asc ) and use your js-framework features to wire the events.

    6. now every (filtering, paging, sorting ) url should result in a client-side state-change, which would probably result in your js-framework doing an ajax-request to the server to return new products (in JSON-format) . Rerendering this again on the client should result in your updated view.

    7. The logic part of the code to handle the ajax-request in 6. on the server-side is 100% identical to the code used in 4. Differentiate between an ajax-call and an ordinary request and spit out the products in JSON or html (using mustache server-side) respectively.

    EDIT: UPDTATE JAN 2013 Since this question/answer is getting some reasonable traction I thought I'd share some closely-related aha-moments of the last year: