Why Web Standards Matter

You've just launched your library's new web site when the calls start: "I just downloaded the latest version of Netscape, and your whole top navigation is invisible"; "I am using a screen reader, and your site reads like gibberish. I can't find a thing"; "I am calling on behalf of the board of tricounty library consortium; we appreciate all the hard work that you have done, but we have a few questions about the design of the new site."

The site—despite months of work, the best software, and exhaustive quality assurance testing—has problems. What went wrong? How do you remedy the situation while insuring you don't make the same mistakes again? The key may be found in adhering to a set of well-established, internationally recognized web standards.

Simply put, the W3C guidelines for markup determine how hypertext documents should be marked up and how the receiving device—including browsers, PDAs, and Braille browsers—should display that markup.

By using XHTML for document structure and CSS for design, librarians can create sites that work over time and across current and future browsers and other receiving devices, including assistive technology. XHTML and CSS are the latest W3C standards for markup and layout and lend a rigorous structure to web sites. This is a structure that receiving devices, search engines, indexes, content management systems, and other tools should be able to take advantage of.

The use of these latest standards also greatly reduces the cost of web site production and provides significant savings when it comes to redesigning a web site. Furthermore, as a light version of XML, XHTML will help developers transition to full-blown XML, a richer markup language that will soon afford even greater interoperability to web sites.

The first step in creating accessible sites is to make sure that you are using well-formed XHTML. XHTML replaces the guideline for HTML 4, which replaced HTML 3, and so on. Each guideline builds upon the last. In general, XHMTL 1 keeps the good parts of HTML 4 and loses the bad. Many of the examples here were also a part of HTML 4; nevertheless, developers should learn the latest standard. The W3C documentation is written by and for programmers and can be difficult for those without experience. Web developers learn the guidelines to some extent directly from the W3C web site but more often from other developers, books, and articles. (For help in getting started, see "A Quick How-To for XHTML")

One of the most obvious examples of W3C standards is for the alt attribute of the image tag. This is a requirement for XHTML 1, as it was for versions of HTML. We all know that for web sites to work on nongraphical browsers—such as screen readers like JAWS or Window-Eyes—it is important to supply alternate text for an image so that the content will display properly. Valid XHTML requires that every image on a web site includes descriptive text that tells the user what the image is. This is what the markup looks like:

<img src="tiger.gif" width="245" height="46" alt="A photograph of a tiger running through the streets of New York City." />

The text insures that users with a screen reader will receive a clear description of the image.

XHTML also requires that headers, lists, and other structural tags be used so readers on assistive technology are presented with a coherent document that flows logically. This is just one example of how with XHTML developers are encouraged to use good document structure and thereby create more accessible pages.

A common misconception among many web developers, especially those in the library community, is that a web site must sacrifice a highly designed look in order to be accessible. This is not true. In fact, many sophisticated design elements—subtle use of color, multimedia, careful use of large images—that some accessibility advocates reject can be profound accessibility enhancements for a general audience. They do not diminish a disabled user's experience if they are handled properly. If developers build a highly designed site according to web standards and accessibility guidelines, the site will still be accessible.

Accessibility is not the only reason that librarians should care about standards-based markup. After all, the library profession and libraries have a longstanding commitment to creating systems and standards that support interoperability, compatibility, and resource sharing.

The MARC record is a good analogy for structural markup. Why is the author's name always in the 100 field of a MARC record? The 100 field tells a system how to punctuate and display author data properly on a variety of outputs, including printed card catalogs and computer screens. For a more sophisticated purpose, the 100 field lets us build search programs that can limit search parameters. Anyone who has limited a catalog search to the author field knows why this is a good idea. Finally, the specificity of a MARC record allows services like cross catalog searches to work.

The web would be a better place if markup monkeys thought more like catalogers. Keeping the 100 field in the back of your mind, think about the HTML <title> tag. The <title> tag is where you write the title of the document. Here is an example:

<title>Digital Web Magazine</title>

Most web browsers display the content of a title tag in the top right corner of your browser. Search engines display the same content when a page comes up in a set of search results. Back in the days of Netscape 1.0, if a developer wrote multiple <title> tags, Netscape 1.0 would cycle through each, creating a little slide show.

<title>Digital Web Magazine</title>

<title>A Magazine for Web Developers</title>

<title>Don't Miss this Fabulous Opportunity</title>

Starting with Netscape 1.0, developers became accustomed to writing markup that worked on primitive browsers and even developed markup that innovatively made use of browser's flaws. The multiple <title> tag is a classic example that has passed into HTML history. This legacy of most HTML hacks is strong, and most of the markup on the web draws upon these creative abuses. This kind of markup was fun and creative, but it was bad for the web. How were search engines, receiving devices, and catalogers to determine the real title of a document?

We don't catalog according to how records look on our particular system; we catalog according to standards. We understand the short-term and long-term benefits of using cataloging standards. Yet we often fail to see and use the same benefits afforded by web standards.

Granted, the MARC record is not entirely analogous to XHTML, but when the semantic powerhouse XML replaces XHTML, our sites may be highly structured like a MARC record. Devices and programs will be able to take advantage of this structure in ways that will make systems librarians very happy indeed. XML will afford a structure that will allow for great opportunities for interoperability and power searching.

As important as accessibility and compatibility are, savings in time and money may be an equally compelling reason to adopt web standards.

The W3C created and developed a presentation language called Cascading Style Sheet specifications. The first CSS specification was created in 1996. At that time, CSS support in browsers was simply a dream, but as CSS has evolved, browser support has improved. We are finally in a position where we can begin to use this powerful tool.

In the past, web developers created HTML designs that were controlled by spacer images, HTML hacks, and formatting tags. To redesign a site this way, each image, hack, and tag had to be edited. CSS allows creators to control the design of an entire site with just one rules-based document: the style sheet.

CSS controls all aspects of a site's design: typography, color, and page layout. CSS may even be used to create rollover effects. For example, when a user rolls over some parts of the page, the text and the background can both be made to change color. This kind of effect is usually done with images and JavaScript, but it can be done more simply and with fewer lines of code using CSS. This rollover just hints at what CSS can do. By controlling all aspects of a site's design with a single style sheet, CSS offers a greater degree of design control than was possible with HTML layout tags and with amazingly low bandwidth.

If you use XHTML for document structure and CSS for design, site redesign will involve reworking your style sheet rather than the markup on every page of your site, thus saving a library hours and money.

For example, when the popular font Verdana begins to look tired, simply change "Verdana" to "George" in your style sheet, and the change will go into effect across your entire site. Color, layout, borders, and just about any other design element can be managed and changed this simply.

The two designs on page 29 (www.roguelibrarian.net/lj/one_a.html and (www.roguelibrarian.net/lj/two.html) use the exact same markup—the same data—but each version uses a different style sheet.

If you need to alter your site, or if it doesn't work on a new device immediately, tweaking will be a less-involved process. Chances are it will involve adjusting only a style sheet or two, or perhaps creating a new style sheet.

In the last two years, web browsers have shifted from proprietary rendering to standards-based ones. Up through the 4.0 browsers, Netscape and Internet Explorer displayed web pages based on rendering engines that were peculiar to each company. Netscape's rendering engine supported some tags, while Microsoft's rendering engine supported others. Each rendering engine also had different ways of interpreting some markup. Developers often had to create two sites, one for Netscape and one for Internet Explorer. Beginning with Internet Explorer 5.0 and Netscape 6.0, support for standards has improved dramatically, and developers can predict with reasonable certainty that standards-based XHTML will work well on the current version of both browsers. Support for standards was poor in 4.0 browsers, and libraries still using that generation of browsers should consider an upgrade as part of the transition to standards support.

If you build with W3C web standards, you can be reasonably sure that your sites will work on future browsers. If you find that a design is problematic on a new version of a browser, the "fix" will involve tweaking your style sheet, not redesigning your entire site. Remember that PDAs are becoming increasingly common as a way to view web pages. Perhaps wearable computers will become the norm. If our content is well managed with standards-compliant markup, it has a better chance of displaying on the devices of the future.