![[Skip the navigation bar]](../graphics/dot.gif)
| |
|
The web gives companies an affordable way to offer customers immediate access to information and products. At the same time, poorly designed sites inhibit browsing and quickly give people poor impressions of the firm. This article discusses several web design mistakes webmasters make and presents ways to accomplish the same ends without the pitfalls.
JavaScriptOkay, let's get down to it by covering the biggest flub out there today: over reliance on JavaScript. Client side JavaScripting offers a wide variety of functionality. At the same time, many people are using browsers that don't handle JavaScript or have disabled it for security reasons. Here's a short list of some JS exploits:
Even though these particular bugs have been patched, it's clear that problems will continue popping up. Speaking of "popping up," avoiding pop-up ads is a good enough reason to keep JavaScript turned off, yes?
Thus, JavaScript should not be used for critical operations like presenting information, navigation or form submission. Such matters are more appropriately done in HTML or processed on the server. In fact, federal regulations mandate this approach. Section 508 stipulates web pages adhere to Web Accessibility Initiative guidelines, in which the following is a requirement:
6.3: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
Using JS for navigation is even bad for the webmaster, since it inhibits web indexing programs from navigating the site, so the site won't show up in search engines.
In addition, programming in JavaScript leads to duplication of effort. First, the syntax needed for proper execution varies between different browser types, let alone between versions of the same browser. Thus, obtaining consistent results can require programming the same code in several different ways. Second, if you're performing form input validation in the browser, you'll still need to perform the validations on the server to ensure your system doesn't get hacked. Thus, you're spending time maintaining two sets of validation scripts.
Below, you'll find several examples of things programmers use JavaScript for. Following each are means to accomplish the same ends using via universally accessible means. If you don't need to check out these samples, feel free to jump to the next section.
Duh:
<script language="javascript1.2">
document.write("<p>Not seen by people without JS.</p>");
</script>
Done:
<p>This will be seen by everyone.</p>
Duh:
<script language="javascript1.2">
window.location.href="http://www.foo.org/";
</script>
Done:
<head>
<meta http-equiv="refresh" content="0; URL=http://www.foo.org/" />
</head>
Duh 1:
<a href="javascript:openNewWindow('http://foo.org/pop.htm','popup')">link</a>
Done 1:
<a href="http://foo.org/pop.htm" target="_blank">link</a>
Duh 2:
<script language="javascript1.2">
function lame(thepage) {
alert("You clicked the " + thepage + " link.");
window.location = thepage + ".htm";
}
</script>
<a href="javascript:lame('code');">Code</a>
Done 2:
<script language="javascript1.2">
function better(thepage) {
alert("You clicked the " + thepage + " link.");
}
</script>
<a href="code.htm" onclick="better('code');">Code</a>
Duh:
<script language="javascript1.2">
function searcher() {
var searchtext = document.stool.sterms.value;
searchtext = searchtext.replace(/[\s,]+/g, "+");
window.location = "search.htm?terms=" + searchtext;
}
</script>
<form method="post" name="stool">
<input type="text" size="8" name="sterms" /><br />
<input type="button" name="button" value="Search" onClick="searcher()" />
</form>
Done:
<form action="javatest.htm" method="get" name="stool">
<input type="text" size="8" name="terms" /><br />
<input type="submit" name="button" value="Search" />
</form>
Duh:
<script language="javascript1.2">
function dumb(selObj) {
eval("window.location='"+selObj.options[selObj.selectedIndex].value+"'");
}
</script>
<form name="form1">
<select name="oingo" onChange="dumb(this)">
<option value="page1.htm">Select a page...</option>
<option value="page1.htm">Page 1</option>
<option value="page2.htm">Page 2</option>
</select>
</form>
Done:
<?php
# WATCH OUT!
# Make sure NOTHING is sent out before the header() function.
# Thus, you need to remove the spaces before the opening PHP tag, above.
if ( isset($_GET['TheButton']) ) {
$oingo = ereg_replace('[^!#-9:;=?-Z_a-z~]', '', $_GET['oingo']);
$oingo = substr($oingo, 0, 300);
header("Location: http://domain/$oingo");
} else {
?>
<form action"test.php" method="get" name="form1">
<select name="oingo">
<option value="page1.htm">Select a page...</option>
<option value="page1.htm">Page 1</option>
<option value="page2.htm">Page 2</option>
</select>
<input type="submit" name="TheButton" value="Go" />
</form>
<?php
}
?>
That example uses PHP. Similar functionality can be obtained through any server side scripting language.
Duh:
<script language="javascript1.2">
function annoying() {
schlok = window.open("test.txt", "garbage", "width=200,height=300");
}
</script>
<a href="javascript:annoying();">Lame Test</a>
Done:
<a href="text.txt" target="_blank">Good Test</a>
Font SizesMany designers feel compelled to hard code the size of fonts in their pages. This flies in the face of both the intent behind HTML and the federally mandated Web Accessibility Initiative (WAI) guidelines.
The HTML language was created so documents could be rendered the way the person reading them would be most comfortable. So, for example, a person with poor vision can use large fonts. If you set the point size significantly smaller than the one a reader normally uses, they'll have to squint to read the page. Is that really what you want?
For these reasons, the WAI's Web Content Accessibility Guidelines state:
3.4: Use relative rather than absolute units in markup language attribute values and style sheet property values.
Also, in cases where declaring absolute units is necessary, be careful not to use px. That means pixels, which will be rendered differently depending on screen resolution.
Duh:
<head>
<style type="text/css">
body {font-size: 9px}
footnotes {font-size: 6pt}
</style>
</head>
Done:
<head>
<style type="text/css">
footnotes {font-size: 80%}
</style>
</head>
Duh:
<font point-size="6">Way Too Small Text</font>
Done:
<font size="-1">Smaller Text</font> or <small>Smaller Text</small>
Body ColorsAuthors often set background colors or images for the body of a document without telling the browser what colors to use for the text and links.
Such designs backfire on visitors with browser preferences rendering text/links in a color of a similar light level to the background, though have not selected the option to override document colors. The solution here is if you set any color attribute in a body tag, you need to set colors for every element.
The way to properly set colors depends on if you're setting them in <body>
tags or through Cascading Style Sheets.
Duh:
<body bgcolor="#FFFFFF">
Done:
<body bgcolor="#FFFFFF" text="#000000" link="#00CC00" vlink="#6699FF">
Duh:
<head>
<style type="text/css">
body {background-color: #FFFFFF}
</style>
</head>
Done:
<head>
<style type="text/css">
body {color: #000000; background-color: #FFFFFF}
a:link {color: #00CC00}
a:visited {color: #6699FF}
</style>
</head>
Font and Table ColorsMost browsers have an option allowing the user to override colors set in a web page with the colors they prefer. But, different browsers, and even different versions of a particular browser, handle this option differently. The following table provides some examples:
| Browser | <body> | <table> | <font> | <div> | Method of Setting Override |
|---|---|---|---|---|---|
| Navigator 4.06 | Yes | No | No | No | Edit | Preferences | Colors | Always use my colors |
| Navigator 4.7 | Yes | Yes | No | No | Edit | Preferences | Colors | Always use my colors |
| Explorer 4.72 | Yes | Yes | Yes | Yes | View | Internet Options | Accessibility | Ignore colors specified |
| Explorer 5.5 | Yes | Yes | Yes | Yes | Tools | Internet Options | Accessibility | Ignore colors specified |
Considering these differences, if you set a color in a table or font tag, how can you guarantee the text and backgrounds will be readable? That's right. You can't.
Similarly, if you use <font> tags to set the color to black, how do you
know that the person isn't using a dark background? Ahh, you're catching on...
There's only one way to guarantee legibility: don't set colors in
<div>, <font>, <table>,
<tr> or <td> elements.
Along these same lines, be careful when creating
Cascading Style Sheets. If you
have color properties, make sure to establish
background-color properties as well. Do note, that while
most browsers understand CSS, Netscape 4.7 only implements them when
JavaScript is turned on.
If you're dead set on a particular color scheme, the only way to
relay it is through graphics. But, remember, they slow download times
and the lettering therein won't be visible to those who turn off graphics
or are blind. Adding Alt text attributes can help.
Transparent ImagesImages with transparent backgrounds are very sweet, allowing objects to be their own shape rather than rectangular. But, if the person looking at your site has their background color preference set to a color which is close to the color of your image's subject, the subject won't show up well. This most frequently is a problem when images are used to transmit text or logos. If they don't stand out against the background, reading them is very difficult. One work around is to not use transparent backgrounds. Another is to place a thin border of contrasting color around the non-transparent portions of the image.
Alt TagsBlind people use the web. Your web pages need to remember that. Are you using graphical buttons for navigation? If so, do your buttons have alt text associated with them? If they don't there's no way for the blind person to figure out where the button goes to. Hey, and don't cop out after providing alt tags for the navigation buttons. They really should be used for all images.
Duh:
<a href="foo.htm"><img src="foo.gif" /></a>
Done:
<a href="foo.htm"><img src="foo.gif" alt="Foo, Inc." /></a>
CookiesThe same principle applies to cookies. Relying on cookies for purposes such as session management, preference handling and/or passing variables renders your system useless to a portion of the public. URI Query Strings are the most reliable way to handle these matters.
Plug-insExternal programs which can be plugged into the web browser provide really neat capabilities. But, not everyone has every plug-in. Just because the plug-in is easily available, doesn't mean people are going to get it just to look at your home page. Home pages and basic company info need to be in plain HTML. Demands for plug-ins should only come deep into the website, when you've got the person seriously interested in the subject and need to relay something which can be transmitted in no other way.
The issues discussed here are but a few of the innumerable ways websites can be inhospitable. The main point is never assume anything about the people using your website. Hey, if you're going invest the time and money to build a site, why not build an excellent one?! It's really worth the little bit of extra effort to make your site work for everyone. Heck, in several of these examples, it's easier to do it the right way!