HTML and CSS Reference
In-Depth Information
honors accessibility by allowing clients unable to use the main application access to
a less demanding one that can more easily support their needs. Additionally, a more
lightweight, but still heavily scripted application, is available for mobile devices with
smaller screens and less capable browsers. However, providing alternate versions is
no excuse for writing sloppy code, ignoring the fact that people use different input
methods or tightly coupling scripts with the document structure.
Many developers feel that unobtrusive JavaScript is too idealistic, and that it
does not apply in “the real world,” in which projects have budgets and deadlines.
In some cases they are right, but mostly it's more about planning and attacking a
problem from the right angle. Quality always takes a little more effort than spewing
out anything that seems to work in whatever browser the developer keeps handy
for testing. Like TDD, coding JavaScript unobtrusively will probably slow you
down slightly as you start out, but you will reap the benefits over time because it
makes maintenance a lot easier, causes fewer errors, and produces more accessible
solutions. This translates to less time spent fixing bugs, less time spent handling
complaints from users, and possibly also less serious trouble as accessibility laws get
more comprehensive.
In 2006, target.com, an American online retailer, was sued for lack of accessi-
bility after refusing to deal with accessibility complaints since early 2005. Two years
later the company agreed to a $6 million settlement. I'm guessing that slightly raised
development costs outrank civil action any day.
Note that a
website
is not necessarily a
web application
in terms of the user
interface. Buying music, managing contacts, paying bills, and reading news rarely
need
functionality that cannot be offered in a simplified way without scripts. On the
other hand, applications such as spreadsheets, real-time chat rooms, or collaborative
office tools can be hard to reproduce in a meaningful way without them.
We have learned a few things about unobtrusive JavaScript, and we've seen the
manifestation of unmaintainable obtrusive JavaScript. In this section we will walk
quickly through developing an unobtrusive tabbed panel backed by tests.
To keep this example somewhat brief, we won't go into details on every step of
the test-driven development process taken to develop this solution. Part III,
Real-
World Test-Driven Development in JavaScript,
goes into the nitty-gritty of the process
and provides several complete and narrated TDD projects. In this section we will
focus on the concepts used to create an unobtrusive tabbed panel.
