After playing with HTML for a number of years, I've come to the conclusion that cleaner is better. It's easier to maintain pages without loads of easily out-dated scripts and semi-useful doo-dads that add minimally to usability. Just look at image maps: in the mid-1990s they were the rage yet they usually added little to user information and frequently caused problems for people with low bandwidth. Then there were (are) those clever mouseover scripts that were (are) easy to break (often rendering a page unreadable), and added little to the Web experience. If it doesn't make life better for yourself and your visitors, it's not worthwhile. If it doesn't make your web authoring easier, it's fritterware (Jim Seymour's term in PC Magazine, ca. 1998). I speak mostly for personal webpages, but the work on the APHA website has tended to be simple (although I've not used stylesheets there since so many members have ancient machines).
Interestingly enough, when I re-designed portions of my personal website for use with Cascading Stylesheets in 1999, I never tested the pages with older versions of Netscape 4.x, which has a buggy implementation of CSS. I was mortified to see them at a friend's home: those pages looked terrible under Navigator and text was lost. Those pages wouldn't have passed the usability test for older browsers. Some pages still don't pass the usability test, but after a while you can't want to spend hours redesigning for 10% of all users.
There are a number are key documents or websites listed below. This document started as notes in my own quest to understand usability and the remembrance of working with a very bad (crashingly bad) rip-off of Mosaic's web browser.
The World Wide Web Consortium's (W3C) Guidelines on Web Page Content accessibility is unquestionably the most important document to come along in a long time. Ostensibly about making content available to people with disabilities, these recommendations go far beyond that. The Latest Version is here. Here's an excerpt from the Introduction:
...following them [i.e. the guidelines] will also make Web content more available to all users, whatever user agent they are using (e.g., desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment, etc.). Following these guidelines will also help people find information on the Web more quickly. These guidelines do not discourage content developers from using images, video, etc., but rather explain how to make multimedia content more accessible to a wide audience.
The checklist is excellent. Here is an excerpt:
1. Provide equivalent alternatives to auditory and visual content.
2. Don't rely on color alone.
3. Use markup and style sheets and do so properly.
4. Clarify natural language usage
5. Create tables that transform gracefully.
6. Ensure that pages featuring new technologies transform gracefully.
7. Ensure user control of time-sensitive content changes.
8. Ensure direct accessibility of embedded user interfaces.
9. Design for device-independence.
10. Use interim solutions.
11. Use W3C technologies and guidelines.
12. Provide context and orientation information.
13. Provide clear navigation mechanisms.
14. Ensure that documents are clear and simple.
I am still getting rid of my bad habits, especially with using Cascading Style Sheets (CSS) more often.
I recommend Jakob Nielson's article about the guidelines and their implications for web design ("Disabled Accessibility: The Pragmatic Approach.") See further on Nielson below: his website is one of the most important on the web for usability and user studies.
Other sites about accessibility on the World Wide Web, for people with handicaps. Fascinating issue for anyone involved in public education (musuems, libraries, parks). Indeed, as professional public educators, we have an obligation to try to meet the needs of all patrons whether in-person or on the web.
A different issue is usability.
NB: Many of these links are less likely to work now (2003), than when this was first written (2000), but fundamental facts apply. Any Browser will show what your site looks like in any browser -- NS, IE, Opera, Lynx, WebTV, etc. Here's the Viewer Page. Prepare to be shocked! [NB: I have found it won't work well with systems running Windows NT servers, and lately (2002) I found that it can crash IE 6.x]
Also of some interest, a contrarian article along the same lines at N-Net's Web design area by Bill Austin.
<Sermonette>: A colleague designing a web page for a prominent New York cultural institution in 1999 was very upset after viewing the site in AnyBrowser. He had some consolation from viewing other big museums (one in New York) using the AnyBrowser browser. My response was that the sites he viewed depended on Tables and 1K spacer images:
Do not worry about HTML 2.0 without tables -- almost no one builds for it and my server logs [then at gilderlehrman.com] show no NS/IE 1.x browsers and few 2.x since early 1998. The problem with HTML2.0 was that it did not support any tables! Tables and positioning [commands] (like <P align="right">) were a Netscape extension to HTML2.x that were added to the formal standard in HTML 3.x.Cut me some slack here, I was writing quickly from memory. Next were what I felt were the biggest design problems for this site and many others:
The most common problem with sites are those that divide the screen too rigidly and design to a 17" or 19" monitor -- a real problem for a 14" or 15" monitor! I always shrink my browser window when checking a site.And I added a little bit of self-criticism here:
Also, I'd be careful with cascading stylesheets (supported in ver. 4 browsers) and <FONT> commands that don't specify two or more alternative fonts, e.g. "Helvetica,Arial" (I'm told it's better to spec the Mac fonts first -- don't ask me why! What's irritating is that the W3C has said (need to find citation) that the <FONT> command will be eliminated sometime in the next few years.... Word to the wise. Although I'm sure IE and NS and Opera will support FONTs for sometime to come.</Sermonette>.
Be careful. Be Nimble. Keep it clean and relatively simple.
Notes by Paul Romaine.
[Home] [Work] [Research & Notes > Web Accessibility] [Personal]