Script or Noscript – that is the question

With apologies to the Bard for horribly mangling the first line of one of his most famous soliloquies, this has probably been the most discussed and recurring topic of conversation that we’ve had in recent months within the accessibility team. Like the dilemma facing Hamlet, the choice and options available to us were equally as wrenching and paradoxical. How do we provide a rich interactive experience to all consumers, but make sure that the web experience is delivered in a way that it can be consumable on the broadest range of browsers, and in addition, support the broadest range of user configuration choices made within those browsers?

Scripting, the backbone of a rich internet experience, continues to be one of the most contentious points of discussion for Accessibility. Until fairly recent versions of JAWS, the most commonly used screen reader solution today, scripting was unsupported. Even in the current version of JAWS (11), while javascript event support has now been a supported feature for a number of years, ’official’ AJAX support continues to be patchy – despite the large number of companies and accessibility interest groups looking to close the gap between rich internet technologies and accessibility devices by augmenting features in JAWS, Windows Eyes and other applications. There are other statistics that give food for thought. The number of accessibility device users that routinely switch off javascript in their browsers - is thought to be anywhere between two to five times  the rate of consumers not using an accessibility device – some 25% of users (10.4% saying that they switch off scripting, the remaining 14.7% not knowing if scripting is enabled) , according to a recent survey by webAIM (http://webaim.org/blog/screen-reader-user-survey-results/).

The accessibility standards also muddy the picture. 508, introduced in 1999 and WCAG 1.0, introduced in the same year, were introduced when javascript usage was in its infancy. While 508 referenced (in 1194.22(l)) provisions for making scripting accessible to a script reader, WCAG went one step further, requiring that pages gracefully degrade when javascript gets turned off. WCAG 2.0, introduced last year, softened those requirements to require that any events fired through scripting components were keyword accessible, but we’ve certainly seen that some customers are slow to move to WCAG 2.0, partly because of that standard’s complexity in relation to the earlier version. Graceful degradation, in particular, is still a goal of a large number of people working in the accessibility and usability space.

So, stuck between a rock and a hard place, what choice did RightNow make?

Our out of the box reference template requires javascript to be enabled. We feel that the entire web is heading in this direction (albeit not at the same pace) and that this was the best place to spend our development dollars.  To that end, we’ve been investing heavily in ARIA support, rather than working to duplicate standard widgets, controllers and other Customer Portal assets to work with NOSCRIPT. Does that mean that it isn’t possible to build a NOSCRIPT experience in Customer Portal? Absolutely not! While the out of the box reference template requires javascript to be enabled, there is nothing stopping you as the customer using the power of the Customer Portal framework to build out widgets that don’t require our YUI libraries or utilize logic.js components within widgets. It would be a large amount of work to replicate current functionality, particularly with elements that heavily use YUI – like our dialog controls, but it certainly is an avenue you can take if ‘graceful degradation’  is a goal for your web initiative.

Is the ‘No to NOSCRIPT’ decision on our out of the box pages and widgets a decision that we are unlikely to revisit? No. In fact, in an initiative that we are starting to work on for mid-2010 we will be releasing a set of page-sets within CP that are designed for mobile devices. As well as supporting ‘grade A’ browsers on the latest generation of mobile devices, we are looking to support older mobile devices with browsers that do not support scripting.  That should open an avenue for you to very quickly add NOSCRIPT support to your web experience, as you can look to direct customers to that page set when their browser identifies that scripting is disabled, or even thinking more creatively, look to consume the widgets created for that experience to make them part of your standard Customer Portal web experience.

So, while we have made our decision, you do have choices open to you - thankfully all of them a little more appealing that the options open to the indecisive Hamlet ….