Page style:

A Blue Perspective: Leave no man behind

Leave no man behind
25 April 2005

Seems like some people don't mind seeing JavaScript only applications, some do. But irrespective of which technology we argue about (CSS, JavaScript, Flash), the inherent question is: when is it worthwhile to cater to a minority?

In some respects, the answer can often be approached scientifically:

  1. How much will it cost to cater to a particular group of people?
  2. How much benefit will we receive from this group?
  3. Is the benefit greater than the cost?

Most often the cost will be monetary – paying for programmers, designers and managers – and the benefit can also take cash form, either directly (through sales revenue) or indirectly (through good will, reputation). However, there are other priorities which can affect your decision. Take accessibility, for one.

I've never been much swayed by the argument that making your site accessible will cover its own cost through gained revenue, particularly where you're performing a retrofit of an existing website, and not building it in from the ground up. It'd be interesting to see a formal case study that tested that hypothesis. But not everything we do in life is just for money. I would count one of the strong benefits of accessibility as being a moral one – enabling access to the disadvantaged. This, I think, is the driving force behind much of the World's disability legislation, so in some respects the threat of punishment by these laws could be considered a negative cost by the particularly immoral.

When including a benefit as ephemeral as moral satisfaction it is hard to exactly quantify it against the bottom line of costs, but accessibility would certainly have a high value. If we're talking about something much more cleancut – such as the ability for a user's browser to execute JavaScript – it's far easier to draw up a balance sheet and make your decisions from there.

What the costs will be and what the benefits will be vary dramatically from project to project. It depends on what you are trying to "sell", who you're trying to sell it to and how you're trying to sell it – information which a mere outsider can only guess at. But no feature should be a given at the start of a project, they are all subject to the same cost/benefit analysis as any other. And ultimately, the market will decide whether your decisions sink or swim.


1/5. 25 April 2005 @ 17:58, Lea wrote:

I think the main justification for legislation that requires accessibility is economic - the more the disabled are empowered the greater the total GDP.

So the macro-reason, that government can afford is economic.

For the individual trader, I am inclined to agree - the probability that making a given website more accessible will improve its bottom line is low.

For you, me and Joe Blow, the main motivation must be the ethical one - selfish reasons all say "don't do it".

2/5. 26 April 2005 @ 00:41, Ryan Brooks wrote:

Let's put things in perspective: 12% of the world's internet users have javascript disabled. 18-25% have flash either disabled or not installed. (These numbers were developed during my last case study, numbers may have changed)

Javascript has evolved, and I think the stigma against javascript is a little moot. Look at how the DOM has evolved.

The problem now becomes typing Javascript and Accessibilty together. If you have a multi-page form with javascript, it should work still without javascript enabled. (I.e. next/back buttons)

Personally, I find that many people who go off on the 'yes it looks nice but is it accessible' rant generally are a bit extremist in their views.

Javascript is allowing for many new applications to come to light. You know about Backbase ( I assume. The counter in flash is Laszlo ( which has recently gone open source. RIA is getting a lot of attention, and it was voted Top 10 technologies to watch of 2005.

My company uses minimal if any javascript for one reason - money.

I think that there places, and reasons to use javascript. But let's also remember that any functional requirements done via javascript can usually be done by traditional means.

Just my two cents.


3/5. 26 April 2005 @ 05:21, Charles Martin wrote:

Try balancing this with a company that wants an application that does most, if not all, of the data input validation before the form is submitted to the server.  The company is faced with a huge amount of bandwidth usage and is trying to improve performance on the database.  Thus, in order to reduce the number of page requests due to poor user input, it is deemed the best means of handling this is to use some javascript to validate dates, email addresses, web addresses, numerical values, etc.  Thus, the only page requests are for valid results.

I was faced with this same situation and was told that (because the previous developer used it) it would be necessary for me to continue using it in order to provide the best performance for their servers.

All was great until, after I'm gone, they're faced with somehow managing/creating multiple versions of said scripts to handle different international date/time/monetary formats.  More powerful handling could have been done server-side from the beginning.

So, not only does it depend on the user.. but it depends on client requirements as well.

4/5. 26 April 2005 @ 22:39, Unearthed Ruminator wrote:

I usually try to leave no one behind for altruistic reasons (it makes me feel good to do it).

Technically, for form validation, you should do both client-side javascript validation and server-side validation.  The client-side javascript validation can circumvent needless trips back to the server.  The server-side validation ensures that the data sent from a client is within the valid parameters (to check for valid data from clients who don't have javascript enables and to prevent someone from typing in invalid data in the browser URL line purposefully trying to break your code).

5/5. 18 May 2005 @ 01:06, tiffany wrote:

Remember that in some countries, not being accessible opens  you up to legal action.

The cost of legal defense alone may be reason enough to do it "right" the first time.

Post your own comments

Fields marked with an asterisk* are mandatory. All HTML tags will be escaped. http:// strings in comments will be auto-linked.