The WaSP DOM Scripting Task Force proposes to solve this problem by the adoption of unobtrusive DOM scripting, a way of thinking based on modern, standards-compliant, accessible web development best practices.
While both front end and back end developers will profit from this change of perspective, the most important benefits will accrue to our end users, whether they use the latest and greatest desktop browser, assitive programs like screen readers, or other devices.
Let’s start by defining the problem.
Interpreted scripting language
This simple statement contains a few serious problems.
- “Language“: Web developers who come from CSS development tend to shy away from programming languages because they are “difficult” to learn.
Solving these psychological problems requires a new way of thinking that is more in line with modern, standards-compliant web development practices.
Unfortunately this purpose more often than not was an excuse for programmers to display their technical knowledge by inflicting pop-ups, scrolling status bar messages, animated layers, and other GUI elements of questionable value on unsuspecting end users. Worse, these sites’ accessibility efforts were too often limited to saying “Sorry” to users of the wrong browser.
Enter unobtrusive DOM Scripting.
DOM scripting — unobtrusive or otherwise — is not new. Any useful client side script needs to access or change the XHTML structure by way of the Document Object Model. A script that doesn’t do anything with or to the document doesn’t interact with the site’s visitors and has no purpose.
As a practical matter, DOM scripting works well so long as we use the W3C DOM. As we saw, though, serious psychological problems remain unsolved. It’s here that the “unobtrusive” bit comes in.
Unobtrusive DOM scripting
An unobtrusive DOM script draws as little attention to itself as possible. In doing so, it provides a number of benefits:
- The usability benefit: An effect created by an unobtrusive DOM script does not draw the attention of the user. It is so obviously a good addition to the site that visitors just use it without thinking about it.
- The graceful degradation benefit: An unobtrusive DOM script does not draw the attention of its users when it fails. It never generates error messages, not even in old browsers. An unobtrusive script first asks “Does the browser support the objects I want to use?”. If the answer is “No”, the script silently quits.
- the accessibility benefit: The basic functionality of the page does not depend on the unobtrusive DOM script. If the script doesn’t work, the page still delivers its core functionality and information via markup, stylesheets and/or server-side scripting. The user never notices that something is not there.
Implementing unobtrusive DOM scripts
Unobtrusive scripting is not a coding style, it’s a way of thinking. So the question becomes: how do you think unobtrusively? You should take three steps:
- The first step is asking the right questions before creating a new script. Is the effect the script causes worthwhile? If the effect doesn’t work, what happens to the page? If the answers are “Yes”, and “Nothing, except that it loses a bit of usability”, respectively, you are creating an unobtrusive script.
- When you start programming, make a list of the methods or properties your script cannot do without. Check for the existence of these methods or properties, and if the browser indicates it doesn’t support them all, end the script.
Even if they don’t want to write scripts themselves, they should be able to weigh the pros and cons of including a bit of unobtrusive DOM scripting, to decide whether it will be an asset or a liability. If it turns out to be an asset, they can always ask someone else to implement it.
We need to fundamentally rethink our approach to writing large scripts. The first step is to admit that any script-heavy site, no matter how large or complex, can be made accessible.
Despite these serious technical problems, and despite the fact that large applications won’t become accessible overnight, we should make a start. Once we acknowledge that accessibility is possibile for all scripts, strategies for incorporating it into large applications will present themselves. Actually creating best practices for accessible applications, and writing scripts that incorporate them, will take several years, but that’s all the more reason to commence our project right now.
Front end and back end
Unobtrusive thinking is a good starting point for knowledge sharing between front end and back end programmers. For instance, its insistence on separation of behavior and structure mirrors the separation of concerns used in the development of large applications.
Front end programmers can learn a lot from back end programmers. Front end programmers largely lack knowledge of application architecture and design patterns, while back end programmers practice them as automatically as breathing. Knowledge sharing in these areas will markedly benefit the front end, especially when writing large web applications.
Knowledge sharing works two ways, though. It should be an exchange between equal partners.
Back end programmers can learn a lot from front end programmers. Back end programmers largely lack knowledge of browser incompatibilities and performance, as well as accessibility, while front end programmers practice them as automatically as breathing. Knowledge sharing in these areas will markedly benefit the back end, especially when writing large web applications.
Unfortunately, the will to cooperate seems to be lacking on the back end sometimes. The main reason is that front end programming is such a lowly occupation. This essentially social factor causes two delusions:
Front end technology can never replace for back end technology, or vice versa, because the two have different purposes. Back end technologies search for, collate, and serve data and business logic. Front end technologies present this information to the user. The two need to be properly separated, and that separation can use ideas taken from unobtrusive scripting.
Knowledge sharing on the basis of unobtrusive scripting will allow front end and back end programmers to do away with outdated ideas, and to learn some tricks they wouldn’t have discovered on their own. Because of the increased understanding for each other’s purposes and methods, they will start to cooperate better than is the case nowadays.
That’s no reason not to start, though.
The Web Standards Project is a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all.