ON THIS year’s Blue Beanie Day, as we celebrate web standards, we also celebrate our community’s remarkable diversity—and pledge to keep things moving in a positive, humanist direction.
Racism, sexism, misogyny and other forms of foolish, wrongful pre-judging have no place in our beautiful community. As hard as we work to make sure our websites work for everyone, let’s work twice as hard to be certain we are just as open-hearted and welcoming to our peers as our designs are to our users.
Back in 2000, CSS co-creator Bert Bos set out to explain the W3C’s design principles—“to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, [and] longevity….”
Eventually published in 2003, the essay, although ostensibly concerned with explaining W3C working group principles to the uninitiated, actually articulates the key principle that separates great design from the muck we normally wade through. It also serves as a warning to Bert’s fellow W3C wizards not to seek the dark magic of abstract purity at the expense of the common good. Tragically for these wizards, and for we who use their technologies, it is a warning some developers of W3C specifications continue to overlook.
Design is for people
In his introduction, Bert summarizes the humanistic value that is supposed to be at the core of every web standard:
Contrary to appearances, the W3C specifications are for the most part not designed for computers, but for people. … Most of the formats are in fact compromises between human-readability and computer efficiency….
But why do we want people to read them at all? Because all our specs are incomplete. Because people, usually other people than the original developers, have to add to them….
For the same reason we try to keep the specifications of reasonable size. They must describe a useful chunk of technology, but not one that is too large for an individual to understand.
Over the succeeding 25 web pages (the article is chunked out in pamphlet-sized pages, each devoted to a single principle such as “maintainability” and “robustness”) Bert clearly, plainly, and humbly articulates a series of rather profound ideas that are key to the web’s growth and that might apply equally admirably to realms of human endeavor beyond the web.
The Web now runs on HTML, HTTP and URLs, none of which existed before the ’90s. But it isn’t just because of the quality of these new formats and protocols that the Web took off. In fact, the original HTTP was a worse protocol than, e.g., Gopher or FTP in its capabilities….
And that fact shows nicely what made the Web possible at all: it didn’t try to replace things that already worked, it only added new modules, that fit in the existing infrastructure. …
And nowadays (the year 2000), it may look like everything is XML and HTTP, but that impression is only because the “old” stuff is so well integrated that you forget about it: there is no replacement for e-mail or Usenet, for JPEG or MPEG, and many other essential parts of the Web.
He then warns:
There is, unfortunately, a tendency in every standards organization, W3C not excluded, to replace everything that was created by others with things developed in-house. It is the not-invented-here syndrome, a feeling that things that were not developed “for the Web” are somehow inferior. And that “we” can do better than “them.” But even if that is true, maybe the improvement still isn’t worth spending a working group’s resources on.
Shrinkage and seduction
In his gentle way, Bert seems to be speaking directly to his W3C peers, who may not always share his and Håkon‘s humanism. For, despite what designers new to CSS, struggling for the first time with concepts like “float” and the box model may think, Bert and Håkon designed the web’s layout language to be easy to learn, teach, implement, maintain, and (eventually) extend. They also designed CSS not to overwhelm the newcomer with advanced power at the cost of profound complexity. (“CSS stops short of even more powerful features that programmers use in their programming languages: macros, variables, symbolic constants, conditionals, expressions over variables, etc. That is because these things give power-users a lot of rope, but less experienced users will unwittingly hang themselves; or, more likely, be so scared that they won’t even touch CSS. It’s a balance.”)
This striving to be understood and used by the inexperienced is the underlying principle of all good design, from the iPhone to the Eames chair. It’s what Jared Spool would call usability and you and I may consider the heart of design. When anything new is created, be it a website, a service, or a web markup language, there is a gap between what the creator knows (which is everything about how it’s supposed to work), and what you and I know (which is nothing). The goal of design is to shrink this ignorance gap while seducing us into leaping across it.
What were once vices are now habits
You can see this principle at work in CSS, whose simplicity allowed us to learn it. Although we now rail against the limitations of CSS 1 and even CSS 2.1, what we are really complaining about is the slow pace of CSS 3 and the greater slowness with which browser makers (some more than others) adopt bits of it.
Note that at one time we would have railed against browser makers who implemented parts of a specification that was still under development; now we admire them. Note, too, that it has taken well over a decade for developers to understand and browsers to support basic CSS, and it is only from the perspective of the experienced customer who craves more that advanced web designers now cry out for immediate CSS 3 adoption and chafe against the “restrictions” of current CSS as universally supported in all browsers, including IE8.
If CSS had initially offered the power, depth, and complexity that CSS 3 promises, we would still be designing with tables or Flash. Even assuming a browser had existed that could demonstrate the power of CSS 3, the complexity of the specification would have daunted everyone but Eric Meyer, had CSS 1 not come out of the gate first.
The future of the future of standards
It was the practical simplicity of CSS that enabled browser engineers to implement it and tempted designers to use (and then evangelize) it. In contrast, it was the seeming complexity and detachment from practical workaday concerns that doomed XHTML 2, while XHTML 1.0 remains a valid spec that will likely still be working when you and I have retired (assuming retirement will be possible in our lifetime—but that’s another story).
And yet, compared to some W3C specs in progress, XHTML 2 was a model of accessible, practical, down-to-earth usability.
To the extent that W3C specifications remain modular, practical, and accessible to the non-PhD in computer science, they will be adopted by browser makers and the marketplace. The farther they depart from the principles Bert articulated, the sooner they will peter out into nothingness, and the likelier we are to face a crisis in which web standards once again detach from the direction in which the web is actually moving, and the medium is given over to incompatible, proprietary technologies.
In Issue No. 288 of A List Apart, for people who make websites: Margit Link-Rodrigue advises us to integrate accessibility with front-end development instead of treating it as an afterthought—an item on a checklist. And Joe Clark analyzes why some forms of writing resist being expressed as semantic HTML.
It’s time we came to grips with the fact that not every “document” can be a semantic “web page.” Some forms of writing just cannot be expressed in HTML—or they need to be bent and distorted to do so. But for once, XML can help. Joe Clark explains.
To make accessible design an organic element of front-end development, we must free our thinking from the constraints we associate with accessible design and embrace the inclusion principle. Margit Link-Rodrigue tells us how.
As in finance, so on the web: self-regulation has failed. Nearly ten years after specifications first required it, video captioning can barely be said to exist on the web. The big players, while swollen with self-congratulation, are technically incompetent, and nobody else is even trying. So what will it take to support the human and legal rights of hearing impaired web users? It just might take the law, says Joe Clark.
When broken links frustrate your site’s visitors, a typical 404 page explains what went wrong and provides links that may relate to the visitor’s quest. That’s good, but now you can do better. With Dean Frickey’s custom 404, when something’s amiss, pertinent information is sent not only to the visitor, but to the developer—so that, in many cases, the problem can be fixed! A better 404 means never having to say you’re sorry.
Join Knowbility in urging the University of Texas to reconsider its decision to close the Accessibility Institute, founded and led with distinction by the late Dr. John Slatin. Keep John’s work alive. Sign the petition.
In Issue No. 265 of A List Apart, for people who make websites: The web is a conversation, but not always a productive one. In “Putting Our Hot Heads Together,” Carolyn Wood shares ways to transform discussion forums and comment sections from shooting ranges into arenas of collaboration. Plus: Because of limited awareness around Deafness and accessibility in the web community, it seems plausible to many of us that good captioning will fix it all. It won’t. In “Deafness and the User Experience,” Lisa Herrod explains how to enhance the user experience for all deaf people.
P.S. The Survey for People Who Make Websites closes Tuesday, August 26. Don’t miss your chance to help educate the world about the practice of our profession. Please take the survey and encourage your friends and colleagues who make websites to do likewise.
[tags]alistapart, deafness, user experience, UX, accessibility, collaboration, discussion, comments, community [/tags]
The John Slatin Fund Accessibility Project matches accessibility experts with companies that would like a brief review of their site for accessibility. In return, the site owner is asked to contribute a minimum of $500 to The John Slatin Fund.
John was a wonderful man and a friend. This project will raise awareness of accessibility and help his wife Anna cover some of the expenses associated with his long illness. Spread the word.
[tags]john slatin, john slatin fund, accessibility, tribute, memorial[/tags]
The WCAG Samurai Errata for Web Content Accessibility Guidelines 1.0 are published as an alternative to WCAG 2. “You may comply with WCAG 2, or with these errata, or with neither, but not with both at once.” Published 26 February 2008. Read the intro first.
Free Mac OS X application lets you share files fast. Drag any file or folder onto the Dockdrop dock icon, then choose how you want to send it. Dockdrop uploads it and puts a URL for your upload on the clipboard, ready for pasting into an email, chat program or website.