A good rule of thumb for web design is that indulge your interests in nifty tools–DHTML*, Flash, whatever–but your navigation should never be made up of anything other than a hypertext link, and you should never make your critical content accessible primarily (or only) through a mouse.
Lately, I’m seeing more and more sites use technologies, Flash in particular that violate these rules. As nice as they look, I always wince when I see a dependency on a specific product, focused at a specific audience: internet hip, sighted, and attracted to bright, shiny things.
Learning from DHTML
I didn’t always resist the shiny geegaws myself. When we were studying DHTML after it first came out, we all started using it to create our navigation buttons, and felt pretty cool and very web savvy. Mouse over a top-level button and a small little box would slide out underneath with all your options to click. After static content, this was heady stuff.
Of course, mouseover wasn’t always reliable. Sometimes you’d have to move quickly from the top-level to the sub-topics because leaving the top-level would close the sub-topic box; it then became a game of who could move faster–you or the browser.
This was all until we started running into cross-browser differences and the nightmare that followed for a good 2 or 3 years until Mozilla came along and routed Internet Explorer.
(What do you mean someone is still using IE?)
Then someone came along and said, well, what about blind people or people who can’t use a mouse? After all, it’s pretty difficult to try and tab through a lot of nonsense that doesn’t do anything in order to get to a working link. And if the work is DHTML, well that just mucks with the page reader’s electronic mind, and it doesn’t know what it’s dealing with.
After Google made web search fashionable and especially after it added a thing called pagerank, we found that not using hypertext links to manage our site navigation was actually working counter to seeing our pages show up in the search results, and as highly placed as possible. Pretty geegaw lost its attraction really quick on this one.
Especially when you add in the costs. In the dot-com job I had before it became dot-gone, I was brought in to lead a re-design of an application after another firm had spent close to two million dollars and basically had very little to show for it; all except for a really cool DHTML navigation system. No backend development. Half the pages needed unfinished. No database. No database design. But there were some really cool DHTML and pretty graphics.
Well, we kept what we could and yanked the DHTML and put a system out on the street in about five weeks. With plain old hypertext links.
But still, designers say when showing their latest frufrah, look how cool this all is?
(When I as at that dot-com, I shared an office with the lead web page designer — an art school grad. He was a nice guy and did the Burning Man thing and was all that was hip among designers, and very talented, too. But I still felt like I was sharing the office with someone from another galaxy, especially when it came to priorities. I know he must have felt the same way. Companies should do that more often–house the backend developers with the front-end designers. If both survive the experience, they might learn something from it.)
Let’s see: on the one hand we have cool. On the other hand we have cross-browser compatible, easier to build and maintain, search engine friendly, and accessible.
Bottom line, we came to understand that using DHTML to manage navigation, or to display critical content, was very uncool.
Next Big Thing
Of course, now we have the Next Big Thing in website design, which is Flash and its various incarnations. And it’s true, Flash can help you do some nifty stuff — but it still brings in the same burdens and problems on a page. You have to install the plugin; you have to have special readers for the content; you have to provide an alternative link structure for webbots if you want your pages search engine friendly; and it costs a lot more to design and maintain a Flash navigation system then it does plain old hypertext links.
To work around the accessibility issues one can use page readers that can read Flash, and one can install the plugins to access the navigation buttons; still each of these methods require that the web page reader go through extra effort to access your webpage content; content that supposedly you really want them to access. Site purpose and accessibility, in this case, is sacrificed to site design.
But isn’t design meant to enhance a site, not obscure it? In other words, if Flash and JavaScript hinder access, never use Flash, or JavaScript, or any moving part other than a hypertext link for site navigation–in fact any content that is critical for the site. If you must, have a separate Flash site, but make sure it’s secondary.
The Payoffs in Accessibility and avoiding the Geegaws
I’m not a web designer and I don’t pretend to make the prettiest pages and or use the best CSS and hippest styles; but one thing I have learned over the years is, if you design for those with accessibility challenges in mind, you’ll find that you’ve also created the easiest to build, easiest to maintain, cleanest, most valid, less fragile, and more forward compatible site design. In other words — designing for accessibility ends up being the best approach to designing for style, validity, durability, and economy.
*DHTML is Dynamic HTML, or using scripting language, usually JavaScript to manipulate a page’s contents after it’s been downloaded to the browser.
