Universal Design for Web Applications

Chapter 4. Structure and Design

It is the pervading law of all things organic and inorganic,
Of all things physical and metaphysical, 
Of all things human and all things super-human,
Of all true manifestations of the head,
Of the heart, of the soul,
That the life is recognizable in its expression,
That form ever follows function. This is the law.

—Louis Sullivan

Of all the advice we have to offer in this book, this chapter is most central to successful universal design. In fact, it is possible to follow the rest of this book and still encounter real trouble reaching more users.

Although we show examples of design using CSS, we are not visual designers by trade, and this is not a CSS design patterns book. There are many books that cover how to use CSS to style semantic code. The Zen of CSS Design (Peachpit Press) by Dave Shea and Molly Holzschlag is one great example. We hope to complement the creative guidance books such as theirs offer by giving you the tools to discover and overcome the universal design problems you may encounter in modern web design.

First Principles

Universal design depends not on a pixel-perfect representation of a given document or application across all screens, devices, and user scenarios, but on a structure that can be interpreted and rendered on all web-enabled devices in a manner that is faithful to the original. This means different things for different languages, as we discuss later in the book, but for HTML, it means using the document-based origins of the language to turn it into an application framework. To do that requires a strong understanding of both HTML and HTTP, and the meaning that each element and transaction carries.

GET and POST

HTTP has two primary methods of communicating with the server: GET and POST. There are other methods, but GET and POST are all that most web developers will ever need to fully understand.

A GET is a simple request containing the Uniform Resource Identifier (URI) of a specified document (in the case of the home page of a given site, the browser issues a GET request for “/”). Any other variables in this transaction are in name-value pairs as a query string, after a question mark in the URI:

http://www.example.com/index.php?page=news&articlename=atom

GETs make up more than 99% of all web requests. The default behavior of an HTML link results in a GET request being sent to the server. The rest (at least as far as those HTTP 1.0 requests issued by humans) are POSTs.

In a POST request, there are still name/value pairs sent to the server, but they are communicated differently, and with good reason. A GET request doesn’t change the world around it. For example, loading up Porsche’s site 1,000 times won’t send 1,000 Cayennes to your door. (If you’re looking to impress your colleagues, you can refer to this phenomenon as idempotence—in this context, it means multiple iterations of the same action have the same effect as only one.) A POST, on the other hand, can change the world. So, when you are registering, logging in, checking out, or doing some kind of action that cannot be undone or requires some kind of privacy or protection against happening multiple times, you must use POST.

One pattern that you should be aware of and know when to use is POST/Redirect/GET, sometimes called PRG. Nearly all blogs, for example, use PRG. The reason is so that when you change the world (in this case, by leaving a comment), that information is sent as a POST, and as a response—instead of showing you a confirmation page—the server redirects you to a GET request to send you back to the page you just posted to. This comes with a URI in your address bar that you can then copy to friends or bookmark, without mistakenly ending up in some posting routine, which will throw you an error.

Semantics

Â	[S]emantic HTML frees authors from the need to concern themselves with presentation details.[16]	Â
Â	--Wikipedia, “Semantic HTML” (retrieved September 9, 2008)

At its core, HTML is a very capable semantic language. It was designed with a wide range of expressiveness at its command. But it’s only good if you, the author, use it to express what you mean rather than to create a visual presentation.

Please repeat after us, “Separate structure and presentation.” To do this, the first step is ensuring you mark up your content with meaningful HTML. There are two HTML 4.01 elements that we will use sparingly in our examples: div and span. Along with the class and id attributes, these two elements, according to the HTML 4.01 spec, “offer a generic mechanism for adding structure to documents.” That makes div, span, id, and class critical to styling with CSS. However, they don’t communicate any semantics of their own. Avoid using div or span in place of an element that communicates the correct message: blockquote for quotes, p for paragraphs, ul and li for bulleted lists, and so on.

In addition, there’s one element, font, which you will not see anywhere in our examples. The font element is a semantics antipattern. Used frequently to set the size, face, or color of the text, font leaves a hole where semantics often should be. There is no reason to use the font element on the Web. Ever. Even in some of the most restrictive design environments around, one of which we discuss later in the chapter.

Most of the time we see font still in use, it’s as a replacement for a heading element. That’s tragic in a number of ways:

• Using font is semantically no different from using div or span—which is to say, it’s nonsemantic. So, where there could have been some clear structure to the document, in a place it is clearly warranted, there remains none.

• Many browsers and screen readers allow users to navigate long documents using headings, but font blocks are not headings, so those users have no heading structure to rely on.

• Worse still is the damage those sites are doing to themselves. Search engines are starving for semantics. And in a world with such poor markup practices, they are often reduced to some serious analysis simply to divine the structure of a given document. But when the engine can be certain that something is a heading, that carries weight, and as long as you don’t abuse them by overloading or stuffing them, using headings along with the other structures available to you in HTML is always the best search engine strategy.

After your semantic HTML is in place, you’re ready for style.

Â	A semantic HTML document can be paired with any number of stylesheets to provide output to computer screens (through Web browsers), high-resolution printers, handheld devices, aural browsers or braille devices for those with visual impairments, and so on. To accomplish this, nothing needs to be changed in a well-coded semantic HTML document. Readily available stylesheets make this a simple matter of pairing a semantic HTML document with the appropriate stylesheets.	Â
Â	--Wikipedia, “Semantic HTML” (retrieved September 9, 2008)

We touch on style later in this chapter and on behaviors in Chapters 8 and 9.

---

^[16] http://en.wikipedia.org/wiki/Semantic_HTML#Semantic_HTML