JavaScript and Accessibility. Pt. 1.	3.0/5.0 (6 votes total) Rate: Select 1 - Terrible 2 - Poor 3 - Average 4 - Good 5 - Outstanding
Jonathan Fenocchi February 17, 2006

Welcome to the year 2005! If you’ve been wondering if you’ll see less JavaScript with the increased awareness of web standards and W3C compliance, think again. The year 2005 will bring with it practical and standards-compliant use of JavaScript – functionality and usability will be its primary concerns. Over time, this author feels that the flashy animation effects will fade away into history.

In the past, JavaScript has been used for drop-down menu navigation, changing the title of your document, generating dynamic content, and controlling the style and position of elements (known as “DHTML” or “Dynamic Hypertext Markup Language”). Is this putting the JavaScript technology to good use? Are we being practical? In actual practice, many of the ideas themselves are practical, but the classical methods of designing them are not.

An Introduction to Web Standards

What are web standards, and how do they affect the web developer? The World Wide Web Consortium (W3C) is the organization that regulates existing web technologies, including the web itself, and presents candidate releases for new ones. Since they’re the managers of the Internet’s technologies, it’s necessary to follow their recommendations, otherwise our web pages won’t work in all cases.

Let’s focus on simple HTML 4.01 (the latest version of HTML) for a moment. The W3C released HTML 4.01 as an official W3C recommended technology on December 24th, 1999. Despite its age, HTML 4.01 and all previous versions of HTML will always be W3C standards. This means if you use the correct document type declaration (DTD), you can still use HTML version 2.0! However, since older versions of HTML are so limited, it is best to choose the latest version of HTML (new versions of HTML were also released for other various reasons, including separation of presentational and structural markup – that is, removing tags such as the FONT tag and replacing them with the SPAN tag, which can be manipulated through Cascading Style Sheets). You will notice that there are three DTDs for HTML 4.01: Transitional, Strict, and Frameset. The DTD specifies the HTML tags that are allowed, the attributes each tag is allowed to have, and other properties of tags, such as “non-empty” tags (tags that have no closing tag, for example “<img>”). The Transitional DTD allows the valid use of presentational markup. That is, you are allowed to say: <font size=12 face=Arial>Hello, World!</font> and get away with it.

Upon closer examination, you’ll notice that the FONT tag is not in the Strict DTD. Why is that? The Strict DTD separates content from presentation. In other words, there is no “FONT” tag or “CENTER” tag, or any other presentational tag that affects the web page displays (with the exception of tables). You can’t change the color of your text with HTML in 4.01 Strict. As of late 1997, you shouldn’t use HTML to make your page look good. You use HTML to give meaning to your text. For example, you put each paragraph in a P tag; text you want to emphasize should be marked up with EM tags; and when you want to yell, use STRONG tags. The “B,” “I,” and “U” tags simply have no meaning to them. They might look good in your browser, but that doesn’t mean it will mean the same thing universally. In user agents for the blind, such as JAWS, the user agent reads the web page text aloud to the person at the computer. If you use presentational tags, it’s not going to do any good for people who cannot see it – the JAWS user agent will render the text normally and no emphasis will be apparent. If you use STRONG or EM tags, the user agent will read those words with emphasis or stronger emphasis. Also, there are some reasons why you shouldn’t use tables for layout. The last DTD, the frameset DTD, is essentially the Strict DTD. The only major difference is that it allows for tags such as FRAME and FRAMESET (which are not in the Strict DTD); these tags are necessary for any frameset document, but not its individual frames.

Now that you know not to use FONT tags to color your text or specify a different font face, let me explain why you shouldn’t. On December 17th, 1996, the W3C published their CSS version 1.0 recommendation. CSS, which stands for Cascading Style Sheets, is “a simple style sheet mechanism that allows authors and readers to attach style (e.g. fonts, colors and spacing) to HTML documents. The CSS language is human readable and writable, and expresses style using common desktop publishing terminology.” In short, who needs FONT tags, when you can control the global visual appearance of your document in a separate file? There is no need to add all of the TABLE, FONT, CENTER, or other presentational tags. The more HTML you use, the more your visitor has to download each time they visit your web page. This eats up extra unnecessary bandwidth, steals time from your visitor, and costs you (and possibly your visitor), more money. By specifying the location of an external file – a separate CSS document – user agents can cache the external file. This way, the user agent doesn’t have to download the CSS file every time, and you just have to specify the content of each page – the rest is already downloaded! In addition, you can specify classes in which different elements behave in a different manner. For more details, have a look at the latest version of CSS.

What Does This Have To Do With JavaScript?

This is related to JavaScript in many ways. To begin with, the W3C published a DOM recommendation by which JavaScript should abide, since it’s become a global scripting technology. If it isn’t in the recommendation, then you shouldn’t use it. That means it is technically invalid to use Internet Explorer proprietary code, such as “document.all” or “innerHTML” as there is no guarantee that it will work with all conforming user agents.

In addition to using valid JavaScript, there are other rules to abide by. On May 5th, 1999, the W3C published their Web Content Accessibility Guidelines version 1.0. This specification “explains how to make web content accessible to people with disabilities.” In a humanitarian gesture, developers would be wise to study these, as learning these specifications assist those who suffer from disabilities.

Web content accessibility can sometimes exceed the W3C’s reach and get into the governmental realm. In the United States, Section 508 “requires that Federal agencies' electronic and information technology is accessible to people with disabilities.” This is recommended for all web sites in general, although this was only required for Federal agencies at the time the article was written.

According to December 2004 statistics, approximately 10% (5,273,741) of the people on the Internet do not even have JavaScript! If your web page doesn’t work without JavaScript, it’s time to look into accessibility.

Responsible Scripting

When you have an idea for a JavaScript, you should ask yourself a few questions:

1. Is this practical, or am I just trying to add something else to my web page?
2. Do I need JavaScript to do this, or can I do it a different way?
3. Will this work if someone doesn’t have JavaScript available? If not, how can I provide an alternative?
4. Am I designing this with the user in mind? e.g., will this make my web site difficult for people to see or read?
5. Is it guaranteed to work cross-browser and cross-platform? If not, what can I do to provide an alternative?

JavaScript isn’t evil, but if you’re going to write a JavaScript it’s helpful to keep these questions in mind. Many advocates of web standards either resent JavaScript because of its improper use in the past or do not understand it and therefore assume that it should not be used at all, but this year to change all that. In order for this to happen, those who currently use JavaScript need to learn to abide by content accessibility guidelines. Another positive aspect of using standards-compliant JavaScript coding techniques is that you are following a standardized system. That means there’s no need for “browser sniffing.” You can write your script once, and it’s much more likely to work in all browsers than it would be if you first wrote it in IE using Microsoft’s MSDN reference.

Allow me to reiterate two important points here. First, JavaScript is not evil! Many of those who practice the proper use of HTML and CSS tend to think otherwise, but this is false. JavaScript is part of a W3C recommendation and is encouraged to be used responsibly. Improper use of JavaScript has become common, just as table-based web layouts have, but that does not mean that neither should be used. Tables have their purpose, otherwise the W3C would not have put them into a specification in the first place. A table should be used to display tabular information with rows and columns, and JavaScript should be used to enhance usability and functionality. It doesn’t exist to make text flash, scroll, blink, glow, enlarge or animate in any other way.

Second, while it seems like I’m bashing Microsoft and its Internet Explorer browser (and to an extent, I am, because of its failure to comply with W3C standards), there are better avenues for support and extensibility.

Mozilla Firefox has better debugging for scripts and error reporting than Internet Explorer (IE) and is a better browser overall; I highly recommend that it be added to the web developer’s arsenal of tools. Microsoft explored some nebulous territory in its 5.5 and later IE versions; such as the inclusion of non-recommended tags like the EMBED, MARQUEE and BGSOUND. Its MSDN reference also gives examples of invalid scripts – scripts that are only likely to work in Internet Explorer. Lastly, Microsoft added some CSS properties that aren’t helpful at all, such as the properties that allow one to color the scrollbar. Luckily, you can disable this annoyance.

The W3C encourages new ideas for its already existing technologies – new scripting ideas, new CSS properties, and so on – but most of Microsoft’s ideas were inaccessible or unnecessary. The W3C rejected many of their ideas and provided accessible alternatives instead. For example, the BGSOUND and EMBED tags have been replaced by the OBJECT tag – which still causes difficulty for Internet Explorer. On the positive side, there were some properties and scripts that had some applicable use, such as the different methods available to show transitions between various images, or the “overflow-x” and “overflow-y” properties of CSS. A few of these, I feel, could make it to the next level of DOM and CSS, with a good push in the direction of accessibility.

Now, let’s turn our attention to what we love and cherish – JavaScript

Classical Techniques; How to Fix Them

Let’s analyze a few classical JavaScript design methods to see why they don’t work, then find a way to approach the ideas with accessibility in mind.

Opening a New Window

Opening a new window is among the most common of classical ideas. There are many classical methods for this idea; most have shortcomings of some kind, often in the HTML rather than the JavaScript itself.

The Script.
<script type=”text/javascript”><!—
  function openWin(url, name, props){
    var w = window.open(url, name, props);
}
//--></script>

The HTML.
<a href=”javascript:openWin(‘page.html’, ‘myWindow’, ‘width=400,height=400’)”>Click here</a>

This JavaScript code is acceptable, but there’s no need to run the function through the HREF attribute. This will cause problems, because if the user has JavaScript disabled, the link won’t work. Also, the text within the A tag says, “Click here.” If you don’t know what this link is supposed to do out of context, then you’re using the wrong text to describe the link’s action. Following our order of questions: the script is practical; it cannot be done without scripting (JavaScript is the best choice for a scripting language because of its universality, whereas other scripting languages such as VBScript only work in a specific browser). This won’t work without JavaScript, so we need to solve that problem.

<a href=”page.html” onclick=”openWin(‘page.html’, ‘myWindow’,
‘width=400,height=400’); return false”>Open page.html</a>

The above method solves all of the problems. If JavaScript is not available, the browser will go to page.html. If it is, a new window will be opened. The “return false” statement is necessary, because it stops the browser from going to “page.html” and opening a new window as well. We also changed the text within the A tag. We can make this more user-friendly by saying “in a new window” if the visitor has JavaScript enabled. We can do this by adding a “document.write” statement – visitors without JavaScript just won’t see it. This is because JavaScript will generate the text.

<a href=”page.html” onclick=”openWin(‘page.html’, ‘myWindow’,
‘width=400,height=400’); return false”>Open page.html<script
type=”text/javascript”><!—
document.write(“ in a new window”);
//--></script>.</a>

This solves the problem and is user-friendly.

Button, Button, Who’s Got the Button?

Here’s another common issue. We use buttons to add functionality to our site. Let’s say you want to run a function when you click a button. Classically, it may look something like the following:

<FORM>
<INPUT type="button" value="Hello, World!" onClick="hello()">
</FORM>

The problem with example 2 is that the button has no action if JavaScript is not enabled. Also, the FORM has no action or method. If we want to use JavaScript to run a function with a button, we must check its vitality. Can we omit this button, and still use the page without any problems? Since we don’t know what this function does, we cannot tell, but we do want to solve the problems we can see. As an example, let’s assume that this brings up an alert box with the current date. Basically, we just don’t want non-JavaScript users to see this form. They don’t need it. How can we do that? Let’s use document.write.

<script type=”text/javascript”><!—
  document.write(‘<form>’);
  document.write(‘<input type=”button” value=”Hello, World!” onclick=”hello()”>’);
  document.write(‘</form>’);
//--></script>

Suppose, though, that we want to give the date to non-JavaScript users. How could we show the non-JavaScript users, but not those who do have JavaScript? Luckily, the NOSCRIPT tag was invented for browsers without JavaScript enabled. We can use the document.write method and NOSCRIPT tag as inverses of each other. To give the current date without JavaScript, you must have some sort of server-parsed web page, which dynamically creates its content. In other words, there are cases when alternate content is generated through your server. Since this article is focusing on JavaScript, I won’t go into the basic definition of a server-side language. If you are serious about web design, though, you should buy a domain and some reliable hosting with server-side languages available.

<noscript><p>The date is [insert date code here].</p></noscript>

Next week, we're going to cover issues concerning Form Validation and Rollovers.