Sample page using semantic mark-up as viewed in Firefox.

Sample page using non-semantic mark-up as viewed in Firefox. Give or take a few pixels these look pretty much the same.

Sample page using semantic mark-up as viewed in Internet Explorer 6. As you can see, the banner breaks in IE 6 but everything else looks pretty much as expected. The page also breaks in IE 7 and IE 8 though the IE 8 version looks different. I've included these samples as a reminder to always check sites in multiple browsers.

Sample page using non-semantic mark-up as viewed in Internet Explorer 6. Again it looks almost the same at the semantic version, even breaking in the same manner.

The other day, Aaron Rester posed this question on Twitter: Webbies: any advice on explaining semantic HTML to non-webbies?

I wrote back that I usually show them some source code and walk them through things like using h1 and so forth for headers. That is what I usually do. In fact I'd just done that the other day when I was showing someone the changes I would recommend for search engine optimization (SEO).

But the question made me wonder if my explanations were adequate. If someone doesn't know anything about HTML or other mark-up languages, will such an explanation make sense? Or is there a better way to explain the differences between structural and presentational mark-up to clients and new Web designers?

Why do clients and other non-webbies need to know about semantic HTML?

Typically this topic comes up most often when one is discussing issues related to search optimization and accessibility. If a client needs to enhance their site for SEO, I may be recommending changes to the code that they won't even see when looking at the page in their browser. Understandably they will want to know why they should pay me to do things to their site that they won't notice. The changes we make may not be visually apparent, but they will convey additional information to Web browsers and search engines that can aid accessibility, usability and searchability.

What is semantic HTML?

Semantics is the study of meaning. Merriam-Webster's Online Dictionary provides us with a definition that relates closely to how the term is applied to HTML "3 a : the meaning or relationship of meanings of a sign or set of signs; especially : connotative meaning." HTML uses elements that convey structural meaning to Web browsers and other user agents such as search engine crawlers.

Writing a page in semantic HTML simply means that you are applying the appropriate structural elements to the various bits of content on a page. Huh? Code elements act like labels that tell the Web browser what each section of content is. HTML gives us structural elements to indicate headers, paragraphs, lists, tables and so forth. If I want to tell the browser to start a new paragraph, I'll type <p>. If I want to start a new subhead, I'll type <h5>.

Then isn't all HTML semantic?

You would think so, but no. Web browsers can be both fussy and forgiving. I can code the same content in multiple ways that will each look very similar when viewed, but will actually convey differing amounts of information to user agents.

Instead of using an <h5> I could use <p><strong>in front of my subhead and make it look the same as it would using <h5>. Such usage would be considered presentational mark-up. It can affect how the header looks, but it is not semantically correct because it doesn't let user agents know that this is a subhead. If a Web designer applies the incorrect elements to page content, the site may look perfectly acceptable. But it is not passing on vital information that user agents may need to:

• Help a visually impaired visitor navigate the page using screen reading software.
• Tell Google and other search engines what topics are the most important ones on the page.
• Show that you are citing a reference document such as a book.
• Indicate that you are presenting computer code, etc.

Same content, different mark-up

To illustrate this point I've created 2 very simple Web pages, one uses semantic mark-up and one using non-semantic mark-up. Basically the non-semantic version uses <p> for just about everything. When you view the pages through a regular browser you'll see that the semantic and non-semantic versions look pretty similar. They both look normal in Firefox, Safari and Opera, and they both break in various versions of Internet Explorer. You don't see the difference visually until you look at the pages in the text browser, Lynx.

When viewing the semantic page on Lynx, we can see that there is order to the page; it looks a bit like an outline. The menu looks like a menu and the headers standout to provide an introduction to the other text.

HTML elements in action, offering added information to user agents

Text readers for the visually impaired and search engine spiders are getting even more information than we can see in the Lynx semantic html example. They know that each menu link should be distinguished from the next. The use of an unordered list for the menu tells user agents to separate these links in a way that use of <p> does not, and allows users of screen readers to jump through or skip these elements to proceed to the main text. In the non-semantic version this is not clear, a text reader may speak all of those links together, making it more difficult for the user to navigate.

These user agents can also tell that the first header is more important than the second because it has been coded as an <h3> while the second header is an <h4>. Headers are ranked in order of importance from 1-6. Here we're using an <h1> for the site name, the most important header on the page. Search engine crawlers will see words in an <h1> as being more descriptive of the page as a whole. This is useful for search engine optimization, because we can include our keywords and phrases in our various headers to let the search engines know that core topics we are covering on the page. Thus on this page you'll notice that I've used the phrase "semantic HTML" in both the text and subheads (which in this case are <h5>'s.) That said I've not used it in every subhead because having these headers make sense to you, the reader, is still more important than SEO. People come first, then robots.

In this example I've focused on just a few a few of the many HTML elements that are important to semantic mark-up, but hopefully these will give you a clearer sense of how such usage can help SEO and accessibility. Other elements such as address, cite and blockquote can add additional meaning to a page's code. You can learn more about other elements and related issues in the reference links below.

Semantic mark-up, validation and content

It's always a good practice to validate your code to check for errors and potential problems, but site validation doesn't guarantee that you've used the best mark-up for the site. While the validator can make sure you've used allowed elements, it has no way of knowing if you've them in the most appropriate manner. Both the semantic and non-semantic page samples used in this post were produced using valid W3C standards compliant XHTML and CSS. One is clearly better formed than the other, but both also break in Internet Explorer.

Thus it's also important to check sites in multiple browsers and to simply think carefully about how visitors will read the site. If my samples were for real sites, I'd fix the IE problem, but I used it here to remind us that using valid semantic code is just the beginning. There will always be additional details we must consider.

It's also worth noting that, when it comes to SEO, a semantically well-formed site is not a substitute for good content. Search engines such as Google are designed to help users, like you and me, find the most relevant pages for the information we seek. With that goal in mind they have to accommodate a wide variety of coding differences. If your competitor has great content and plenty of good inbound links, while yours does not, then his/her site will still win out, even if the code is atrocious. But if you can produce great content and present it in the appropriate format you will be off to a good start.

Semantic HTML Resources

• The Elements of Meaningful XHTML (presentation showing examples)
• Fangs Screen Reader Emulator
• Guide to Semantic Use of HTML Elements
• Illinois Information Technology Accessibility Act Implementation Guidelines for Web-Based Information and Applications 1.0
• More than one H1 on a page: good or bad? (Video by Google's Matt Cutts)
• Semantics in HTML 5
• W3C Semantic Data Extractor
• W3C: G115: Using semantic elements to mark up structure

The above Flash animation file is a mini-Web site used for demonstration purposes. Were it standing on its own a user would see it as a multi-page site with an image on the front page that is used to navigate to interior pages.

For those of you who don't have, or cannot see Flash content, the introductory page has a photo with an image of 2 mausoleums. Clicking on the left mausoleum takes you to a page with photos and clicking on the right one takes you to a page featuring Author Rimbaud's poem, Ballad of the Hanged.

A few weeks back, in Is Flash evil? No, but Flash-based sites can be a marketing nightmare, I discussed some of the potential problems Flash-based sites can create in regard to search optimization and accessibility. Today I'd like to continue the discussion with a focus on usability. Before I start discussing examples, I do want to make a few things clear.

Not every Flash-based site suffers from every problem I'll address. There are many very talented designers who are doing interesting things with Flash, while also working to keep usability in mind. This article isn't for them. It's for the designers, either new to Flash, or less well-versed in HTML, usability and accessibility who may not realize these problems could be lurking on their sites.

Also, if you are a designer who is producing Flash based-sites that overcome these challenges, please feel free to share your tips and examples with us in the comments below.

The Flash user experience: don't let design interfere with usability

Flash has some cool features. It let's us control typography, offer interactivity, make things move and is scalable. These features are all quite handy, but they also provide us with opportunities to confuse and annoy our site visitors. To illustrate this I've included some examples of typical Flash problems in my sample sites, Angst Space and Shapes.

Note: I found many real world examples I could have used for this article, but rather than publicly criticizing the designers—by pointing out that site X is really cool, but broken—I thought it would be more tactful to create my own samples.

1. Introductory animation.

Many sites, even HTML sites will begin with some sort of Flash splash page. This could include an animation, video, company motto, etc. Hopefully it also includes a "skip intro" button because in most cases these intro pages take time to load and don't offer informative content.

Back in 2002 when I took a Flash class at the Cleveland Institute of Art, I too succumbed and made Flash intro pages. I did a site for a concert series called Thursdays in the Park, and the intro page had moving colored dots (from the event logo) and included the names of the bands which fell into a list one by one. The intro then directed users to the main static page.

I built the page that way because I wanted an excuse to put my new Flash skills to work, but the animation didn't offer any value. I thought it looked cool because things moved, but most users, especially those under 30 who grew up with the Internet are not impressed by shiny moving objects. They've seen it all before. All they want is to get the information they need as quickly and as appropriately as possible. All I accomplished with the page was to show that I knew Flash.

The Shapes site includes a short animation of shapes morphing into one another. It gives the user a visual clue that the site is about shapes but animation wasn't required to convey that idea. Mostly it's just shapes moving about for the sake of movement.

If your subject requires animation to illustrate the topic, then it makes total sense to incorporate motion into the project. But if you're sitting at your computer, scratching your head as you ponder what what you might animate to introduce topic X, then you probably don't need animation at all.

Graphical navigation

Designers are often looking for new ways to present navigation beyond the traditional menuing system. This can be fun, but if users don't figure out the system immediately they may leave before they get a chance to see your content. Our attempts to be clever may instead hinder the visitor experience.

I once saw a site that had a row of colored squares under the primary navigation menu. It also had a left side menu, so I thought the squares were just decorative. Then I happened to mouse over one. Lo and behold it opened up another secondary menu (different from the side menu). I only discovered this hidden menu because I was moving my mouse around the page. I suspect many people never saw it and were stuck grumbling at the page trying to figure out how to find what they were looking for.

Traditional menus are boring, but they're familiar. Site visitors are used to the way they work. If you're targeting an audience that is more likely to go mouse-exploring, a unique navigation system may be just fine. But if your audience is more mainstream, don't hide or camouflage the menus, they may not know where to look. Offering a familiar interface can help make sure you don't confuse your visitors.

In the Shapes and Angst Space sites I used graphic elements, such as shapes, photographs and icons for navigation. I didn't put a lot of content on these sites, so most of you probably figured it out, but some of the sites I've seen in the wild are much more confusing.

The Shapes site also includes sections of hidden content that designers sometimes include on Flash sites. If you mouse over things or click in places that don't seem obviously clickable you'll discover an easter egg and extra bits of information. That's fine for Shapes, because none of this content is important. But if I were promoting a degree program or trying to sell widgets I'd want to make such information easier to find.

When designing for the real world, I find it is safer to err on the side of simplicity. If I want to make sure that all visitors can navigate to X and Y and can easily read B and C, I'll offer text-based options for familiarity and accessibility.

Sizing and scrolling

As mentioned, Flash is scalable. I can make a .swf file of any size then publish it large in one place and small in another. The only things that don't scale well will be raster images (such as photos) included in the file and some type elements (depending on your settings.)

Alas, there seems to be a secret cabal of designers who create Flash sites and embed them in their HTML at sizes, that probably look superb on a 24" cinema display, but don't fit in the browser window on my Mac. And for some reason these sites don't offer scrollbars. I saw one last week that did this. I could navigate using the links in the top menu, but I couldn't read the text on the bottom of the pages or view the footer. I went to the contact page to try to let them know about the problem…but the submit button for the form was below the fold. Since I couldn't scroll down to it, I couldn't press it, and they never got my message.

This is a troubling issue because if visitors can't easily navigate, or even read all of the content on a site, then they will leave. This site was for a Web design firm, so they're potentially losing clients due to this one, easily fixable issue.

As an example, take a look at Angst Space at full size. When viewed on my computer I can see just the top part of the photo of the mausoleums. I can click on those and get to another page, but then I can't read the full text on the poetry page, or interact with the images on the photos page.

I come across such sites at least once a month, but I find it mystifying, because this situation is quite easily prevented. I use swfobject 2.0 to embed Flash .swf files (and videos, etc.), and when I use it normally, as I did for the medium-size version of Angst Shape, the scrollbars are readily available whether you need them or not—just as they would be in any normal page.

To remove the scrollbar for the full-sized example of Angst Space I actually had to add overflow:hidden to the body element in the CSS file. I don't know if the sites I find are disabling scrolling on purpose or if it's a result of using invalid code to embed their .swf files, but if you're building sites in Flash, be sure to test them on a variety of computers to make sure you're visitors aren't experiencing the same problem.

Flash and the Mobile Web

As I was writing this I sent out a Tweet asking if anyone had any Flash pet peeves they thought I should include. Interestingly the first two replies related to hand-held devices. Given the wide array of mobile devices and their respective browser platforms it is still a challenge to create sites that work well on a wide variety of gadgets, but Flash adds to this challenge.

1. As interactive strategist, Kati Davis (@katidavis) points out, Flash doesn't work on an iPhone. And it doesn't look like it will anytime soon. If your audience includes iPhone and iPod Touch users, you will want to provide some way for them to access alternative content. I see more and more friends browsing sites via iPhone now that they never would have tried to view on mobile phones a few years ago.

Developers used to focus on providing mobile support for specific types of sites: event schedules, news, directions, store hours, etc. But now people could be browsing anything from Amazon to your blog on their iPhone, so it makes sense to keep these users in mind.

2. Mobile devices that support Flash are still small hand-held gadgets with tiny screens. Designer Alan Houser (@alanhouser) said, "I'd say there will be a ton of issues when using flash content on mobile devices. Literal fat-finger issues." This is a rather important point. If a site like Angst Space was reduced to fit a mobile device that supported it, the icons and thumbnails that users click would be super tiny. Thus it would be tricky to click on such items using a touch screen device.

Admittedly I don't know that much about Flash and the mobile Web, but Adobe does. They've created Flash Lite specifically to generate content for mobile devices and are working with manufacturers to implement this on many different devices. If you're a Flash designer who wishes to offer support for mobile devices, visit Adobe's Mobile and Devices Development Center to learn more.

Flash Usability Conclusions

The issues I've addressed today seem rather obvious and simple, yet I still come across many Web sites don't address these problems. As Web designers/developers we're creating communications tools. We're trying to convey some message to our audience so that they can respond by buying our products, applying to our universities, reading our blogs or whatever else we hope that they will do. If that's our goal, then we just need to put the user foremost in our mind when we design our sites. Whether we're developing in HTML, Flash, Silverlight or something else we'll all be better served if we make sites that are easy for our visitors to use, read and navigate.

Flash and Usability Resources

• Adobe Flash Developer Center: Testing and Usability
• Alertbox: Jakob Nielsen's Newsletter on Web Usability
• Flash Resources Listing (Univ. of Minnesota, Duluth)
• Usability experts are from Mars, graphic designers are from Venus (old but interesting)
• 50 Beautiful Flash Web sites - Some of these sites are astoundingly cool to look at, yet some also have usability issues.

The above Flash animation file is a mini-Web site used for demonstration purposes. Were it standing on its own a user would see it as a multi-page site with an introductory animation and a menu used to navigate to interior pages.

For those of you who don't have, or cannot see Flash content, the introductory page has a circle that morphs into a square, triangle and back again. The shapes careen up to the menu offering a choice of a circle, triangle and square to click on. When clicked each page takes you to a page with a bit of motion and simple definitions for the shapes.

Flash is a powerful tool. As designers we can use it to create motion, control typography, animate objects, create scalable graphics, embed videos, create slideshows, etc. Some find it so useful that they design entire sites using Flash.

I don't.*

Flash offers great control for designers but it also poses obstacles for users and hinders our Web marketing strategies. Adobe has made great strides in terms of making Flash files both more accessible and searchable, but there is still more progress to be made. Today I'd like to discuss why I advise against using Flash for overall site architecture.

Remember the problems with frames?

Years ago, before we had better tools available, designers flocked to frames because they made it easy to include constant headers and menus. Once you built those fixed unchanging files, all you had to do was create extra files for the content. This seemed cool until we noticed that frames broke the user experience. Individual pages couldn't be bookmarked because the address never changed. While the content would change within the page, the visitor technically remained on the same page of the site.

This was bad from a marketing standpoint, because it inconvenienced visitors and made it difficult for them to link to specific pages on our sites from their own sites. As site owners we rely on incoming links to drive traffic directly to our pages and to enhance our search results. Google and the other search engines consider these links in their algorithms, so more links mean higher placement in search engine results pages. While some may still debate the issue, it didn't take long for most of the design world to conclude that frames caused more problems than they solved.

Flash is like frames— on a Flash based site the address never changes

When we create Flash based-sites, we do so by embedding a Flash file within a regularly constructed HTML file. When we include a Flash file, such as the animation on this page or a YouTube video, it's easy to see that it's just one element within a page. On a Flash-based site, the Flash element is the only thing the visitor sees.

All the navigation and interaction happens within the Flash animation itself. Visitors may click on menu links to visit new pages, just as they would on a regular site, but they don't actually go to a different page. The content changes so the page appears to be a new page but as was true with frames, the page address doesn't change. (One could build a Flash site using separate .swf and .html files for each page, but it's not common practice.)

Shapes - Taking a closer look at a Flash-based site.

I've published the Shapes Flash file from this page separately as a stand-alone site, so you can get a better sense of how this works. If you visit http://www.heidicool.com/flash/shapes.html you will see that it acts like a typical 5 page Web site with a home page and internal content pages. It begins with a simple animation of shapes then you are presented with a menu of a circle, triangle and square. If you click on a shape you go to a page with a short definition of the shape you clicked.

But if you watch the address bar you'll see that the address never changes. If you blog about squares and want to link to the page about squares you can't. Instead you'd have to link to the main page and include a note for users to follow the square link. If including such a description is inconvenient, you probably won't bother to link at all.

The Flash SEO conundrum

If you look at the analytics for your own site you will quickly realize that your incoming links do not all go to your home page. Instead site owners link directly to the page that will be of interest to their readers.

Thus, each page on your site gives you a new opportunity for search engine optimization. If I'd built the Shapes site in HTML, I could be sure to use the keyword "square" in a header element as well as the text on the square page, focus on triangles on the triangle page, etc. Doing so would make it easier for the search engines to find these pages and would also make it possible for other site owners to link to individual pages. This is one aspect of SEO that is a numbers game. A site with more pages creates more opportunities for links and keyword searches—thus resulting in more traffic.

A one-page Flash site has a distinct disadvantage for SEO.

As with any site, I built the Shapes site with SEO in mind. The site validates as XHTML 1.0 strict, and I included a page description and keywords (which Google ignores but others may use) and gave it a unique title. I know that Google has improved how it indexes Flash content, so it will index the text within the pages (since I didn't break apart the text), but it won't know which text elements are most important—since Flash doesn't use semantic mark-up such as headers and paragraphs. I could have included a header element in the HTML, but like the title and page description it would remain the same on each page and wouldn't help me optimize for the individual page topics. These details may help my SEO but they aren't enough to compensate for the sites key weakness. It is still only one page.

Flash and accessibility

Adobe provides an accessibility resource center for Flash and other Adobe products. It provides a number of useful tips and guidelines for making Flash more accessible to those with visual and hearing impairments. If a designer follows the guidelines, and the site visitor has the right browser or screen reader, this can greatly enhance the Flash experience. But some of these guidelines are complicated—there's far more to it than providing alternative text for audio and visual elements— and I suspect there are many of us who don't understand them fully. I don't know how many users have the appropriate screen readers to take advantage of Adobe's accessibility features, so I also have to assume that some do not.

When I use Flash, I try to stick to the basics and offer some sort of alternative content. In my photo gallery pages, I use Flash, javascript and xml to display my photos as a navigable slide show. Each slide show includes alternative text describing the types of photos I've included. That seems the most direct way to handle purely visual elements such as photographs.

On the Shapes site I wrote a description of the site as my alternative content. Users who can't use Flash will see the description instead. This is adequate for this project as it conveys enough information to let visitors know what the example includes. But it would not be sufficient for a larger site. My alternative description applies to the whole site, because the whole site is contained within one page. If I had more content to describe I'd be better served by providing an alternative HTML version of the site, so that I could provide each pages text content individually. By building sites in HTML instead of Flash I can avoid this problem and just build one version of the site.

Conclusion

Flash is great when used in the right context. Whether we're embedding slideshows or making animated cartoons, Flash lets us add some very useful features to our sites. But if you want to attract visitors and increase readership, building the entire site in Flash can be more trouble than it's worth. I'll discuss Flash further in my follow-up article pertaining to Flash and the user experience.

Flash SEO and Accessibility resources

• Accessibility and Usability of Flash for Users with Disabilities
• Adobe Flash Accessibility: Best Practices for Design (Added Aug. 28, 2009 - nice walk through of accessibility issues)
• Adobe Flash CS4 Professional accessibility
• Adobe Search Engine Optimization Technology Center
• Flash and SEO - Compelling Reasons Why Search Engines & Flash Still Don't Mix
• Flash as a choice, not a default
• Search-Friendly Flash?

* There are of course limited exceptions. I built the Commencement March animation in Flash because the project required movement to convey what was happening. The site was built primarily for use as a training presentation and was linked to from the commencement site so it didn't have the usual marketing requirements.

Last week's entry on outbound links spawned a lot of discussion, including the question of whether one should have outbound links open in a new window (or tab depending on the user's browser and preferences). Although many others have already written about this topic, it comes up often enough that I think it is worth discussing. Disclaimer: links that open in a new window or tab—when that wasn't my choice—are a pet peeve of mine, but I will attempt to explore the topic objectively.

What is the intended purpose of having links open in a new window or tab?

Those who recommend having links open in a new window do so with the intention of making it easier for users to return to the original site. Anyone who surfs the Internet knows that it is easy to get lost down a rabbit hole of links. For example, if I provide you with a link to Chuck Palahniuk's Web site, you might:

• follow the link
• peruse the section on author interviews
• read Dennis Widmyer's latest interview with Craig Clevenger
• then decide to add The Contortionist's Handbook to your Amazon shopping cart.

By now, the theory goes, you will have either forgotten where you were before or forgotten how to get back. If I'd set the Chuck Palahniuk link to open in a new window/tab (this is the only link on the page that opens a new window), you could just go back to your original window/tab and you'd be back where you started. Of course if the link opens in the same window, and you are using a current browser such as Firefox, you can simply click the down arrow next to your back button to navigate back through the series of links you just followed.

So which is better? Is it easier for a user to go back to a different window or to just use the back button?

I've always found it easier to use the back button. With one click I can go back and read another interview or I can choose to go all the way back to the original blog. To me that seems far easier than wading through a sea of windows, or looking at an array of tabs to find the one you want. But everyone is different. In researching this article I discovered a Get Satisfaction page in which a user actually requested that links on Pownce open in a new window. Two of the responders agreed that they would prefer new windows, while two others (including Pownce/Digg designer Daniel Burka) disagreed. I saw these differing opinions in many places.

Where does that leave us? Preferences vary, so unless you survey the users of your particular site it may be difficult to determine if your audience likes or dislikes it when a link opens in a new window. Pownce was able to solve the problem by giving users a setting that lets them pick which behavior is the default while they're on Pownce. But that's not an option for most sites and blogs. With that in mind, I think it is most appropriate to leave it in control of the user. If a user wants to open a link in a new window he can do so by right-clicking (Windows) or ctrl-clicking (Mac) the link in question. I often open links in a new tab if I know that I'll want to flip back and forth between them. I just don't want them opening up new tabs spontaneously.

Standards and accessibility issues related to opening links in new windows

If you're in the pro new window camp, I've probably not yet changed your mind. But there are more issues to consider.

W3C HTML and XHTML Recommendations

The traditional way to have a link open in a new window is to include target="_blank" in the link. The target attribute is not included in the recommendations for HTML and XHTML strict, therefore sites using target with a strict doctype won't validate. From what I've gathered target is not included because not all browsers support the attribute, particularly when it comes to browsers running on mobile devices. (This may change in XHTML 2.0 as the attribute may serve new needs as mobile browsers evolve. A valid alternative is to use javascript.

W3C Web Content Accessibility Guidelines 2.0 (WCAG)

According to the WCAG Success Criterion 3.2.5, "Individuals who are unable to detect changes of context or may not realize that the context has changed are likely to become disoriented while navigating a site. For example: individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected." To avoid this confusion they recommend that users should be notified if a link will open in a new window and if possible be given the choice to not have it open in a new window.

Kant's Categorical Imperative: What if everyone did it?

While writing this I kept having a vision of wandering the Internet in a world where every external link opened a new window or tab. In this vision it was only a matter of minutes before there were so many tabs open in my browser that I had to use the left and right arrows to scroll through them. Worse yet, instead of tabs windows began spawning as quickly as Tribbles and suddenly my desktop was impossible to navigate. This made me think of Kant. In his first formulation of the Categorical Imperative he states that one should "act only in accordance with that maxim through which you can at the same time will that it become a universal law." While this idea was meant to deal with issues of morality, it's easy to see how it could be applied to lesser situations such as links opening in new windows. If links always opened in a new windows it would pose significant usability challenges.

Naturally most sites don't open everything in a new window or tab. If they did we'd all be swimming in windows. Instead, most site designers choose to open new windows only in particular circumstances. Some designers do this only for external sites while others reserve the technique for opening up .pdf files. While I'd still prefer that links open in the same window, giving me the choice of whether or not to open them in a new tab, I understand that many may disagree. Most people have committed one way or another with few remaining undecided. But, whatever your preference may be, I hope this discussion will help the next time you're debating where a particular link should open.

Learn more about opening links in pop-up windows or tabs

• Accessible Pop-up Links
• D. Keith Robinson's Gorilla Web Tips: Launching New and Pop-up Windows
• Don't let your web site fall out of the window: opening new browser windows
• How evil is the target attribute?
• New-Window Links in a Standards-Compliant World
• Open New Window Still Has Usability Issues
• The target attribute and opening new windows
• Top Ten Mistakes in Web Design
• WCAG 2.0: H83: Using the target attribute to open a new window on user request and indicating this in link text
• WCAG 2.0: SCR24: Using progressive enhancement to open new windows on user request

Until recently I was one of the only nerds who had yet to upgrade to Firefox 3. I'd been waiting until I could find an easy way to install it alongside (rather than in place of) Firefox 2. When I'd tried doing this a few months ago—with the beta version of Firefox 3—it hadn't worked properly, so I'd put the idea on hold.

I mentioned this in a meeting, when a colleague piped up with a simple solution. He suggested using the PortableApps version, a standalone version of the program that can be installed on a Flash drive—for portability—or simply in a directory you designate on your computer. This was so obvious I immediately wondered why it hadn't occurred to me before, but then, practical ideas are like that.

PortableApps.com offers a plethora of portable software solutions—including Firefox—for Windows

Once I got back to my office I hopped over to http://portableapps.com/, looked for Firefox 3, then proceeded to download it. Within minutes it was installed, separately and independently of Firefox 2. When I tried to start it up I discovered that you can't run them both at the same time—I had to close out of 2 to open 3, then close out of 3 to reopen 2—but you can run them on the same computer. This will be tremendously useful if I discover some quirk in Firefox 3—such as an add-on that no longer works and has yet to be updated—or if I need to see how a Web page renders in each version.

That solved the problem for the Windows P. C., but what about the Macintosh?

FreeSMUG: Portable Applications for OSX

Firefox 3 from FreeSMUG (Mac)

A quick Google search turned up FreeSMUG's portable applications section. FreeSMUG offers a portable version of Firefox 3—in several languages—as well as other popular open source programs such as Open Office and Audacity. Those new to many of the Open Source programs available through FreeSMUG can learn more about them through a variety of helpful tutorials available on the site.

FreeSMUG says of its portable applications, "OS X FOSS portable applications are packaged so you can carry around on any portable device, USB thumb drive, iPod, portable hard drive, memory card, other portable device (or also on your internal hard disk), taking your preferences with you." This of course could be handy for any number of reasons, but the ability to run multiple versions of browsers to use for testing Web sites, is particularly useful to me.

Why test in multiple versions of the same Web browser? Why not just upgrade?

As a Web developer, you probably upgrade your browsers fairly often. That's not true of the average user. In many cases the people who visit your site are using the same browser that came with their computer.

The most popular browsers used by visitors to the Web Development Blog this month are:

• Internet Explorer 7.0 - 24.6%
• Internet Explorer 6.0 - 24.3%
• Firefox 3.0 - 12.7%
• Firefox 2.x - 17.8%
• Safari - 5.4%

Interestingly .5% were still using Netscape 4.0, which is over 10 years old!

To ensure that you, my site visitors, can view and use this site with ease, I need to make sure that it works properly in the browsers that most of you are using. This requires testing in multiple browsers and versions.

When a browser releases a minor upgrade, this isn't a big issue. But when a Web browser makes a significant upgrade it can make a big difference. A site that looked fine in version X, may look horrible in version Y.

When Internet Explorer 7 came out, users and developers quickly noticed that many pages didn't render properly in the new version. I.E. 7 was actually more standards compliant than I.E. 6, but developers who had used I.E. hacks to make pages look right in I.E. 6 found they didn't work with I.E. 7. This led to a lot of sturm und drang about I.E. 7 "breaking the Web," as those developers needed to modify those hacks to make their sites work in both I.E. 6 and 7.

Here at Case our templated sites don't rely on many I.E. hacks so they transitioned smoothly from I.E. 6 to I.E. 7. But when I'm building new sites, I may sometimes incorporate new styles or features that I've not used before. This is when I make a point of testing in multiple browsers. Tredosoft's Multiple I.E. Installer provides a convenient way to run different versions of Internet Explorer on Windows XP. They also provide information for running I.E. 6 natively on Vista.

Must your site work in every browser available?

No, the Web has evolved enough since 1993 that making a site backwards compatible with every browser version is pretty much impossible. But if you adhere to Web standards, build sites that degrade cleanly in older browsers, and test in the browsers used by most of your readers you should be able to provide a good user experience for all of your visitors.

Web Browse Testing Resources

• Browsershots
• Browser testing CSS and JavaScript
• Browser Tests, Services and Compatibility Test Suites
• CSS: Browser testing order
• Why your site should work on multiple browsers

On the Web it is preferable to place your
caption in the HTML. If that won't work and
your captions are long, you should also link
to a place providing a description of the image
and an alternative rendering of the text.

Colleagues of mine are involved in a project that involves adding captions to photographs. Like many of you, they aren't full-time designers and haven't spent a great deal of time using Photoshop. While they know how to crop and resize photos, they've not yet worked with type. For those of you who may someday face the same situation, here is a quick tutorial on adding text to images.

Establish your project parameters—size matters

Are your captioned images going to be used on the Web, on hand-outs produced by your office printer or in commercial print work such as a magazine? At what size will they be used? When editing your photos you will want to start with the largest image file available, crop it as necessary then resize it to your project specifications before adding your text.

As I mentioned when discussing image formats, your usage will impact your size specifications. Generally you will want an image that is 300 pixels per inch (ppi) for commercially printed pieces, one that is 125-250 for desktop printing (refer to your user manual to determine the maximum dots per inch (dpi) your printer will produce) and somewhere around 72 to 100 for the Web.

Note: measurements for print are exact; if your photo is 300 dpi and 1 inch square, it will be printed to be exactly 1 inch square. If you print it at 72 dpi and 1 inch square it will still be exactly 1 inch, but will have less detail. Measurements for the Web are relative because they are determined by your display. On my Dell there are 77 pixels in an inch, while on my Mac there are 98 pixels in an inch. Your display may be different. As a rule of thumb I just use 72 (which was common for most monitors back in the 1990's) and keep in mind the fact that a 3 inch wide photo at 72 ppi will appear smaller on the Mac than it will on the PC. Either way it is 216 pixels, but the pixels on my PC are bigger than those on my Mac.

Consider the amount of text you are supposed to add to the image. Try to make this as brief as possible, especially if your project will be viewed online. While you may be able to use tiny type on printed matter, that type will be harder to read online. Fewer pixels mean fewer details, so 6 point type online will be tiny and jagged.

Also ask yourself if the text needs to be on the picture itself or if it can be read as a caption underneath the image. If the project is for the Web you can include captions underneath a photo in the text rather than in the image. For situations where that won't work, such as HTML e-mail, just be sure to repeat your caption text in the alt tag of the image.

How to add text in Photoshop

For this example I'll walk you through the steps used to caption the image used in this entry. We'll add text on top of the image and below.

1. Open your image file in Photoshop. For practice you are welcome to use this sculpture photo.
2. Resize your photo by going to the image menu and choosing image size. Make sure that "constrain proportions" and "resample image" are checked. Set the resolution appropriate to your project. I'm using 72 for the Web. Choose the appropriate width for your image. I'm using 240 pixels.
3. Click on the foreground color and use the picker to select a color for your type.
4. Select the type tool, click and drag on the image to create your type box, and start typing your content.
5. If it is not already open, go to the window menu to open your layers window. Note that your type was created on a new layer.
6. Switch to the selection tool to reposition your type as desired.
7. If your background is too busy, you may find that your type is hard to read. Try adding a drop shadow or outline to it. To do this double click on the type layer in the layers menu (click to the right of the layer name). This will open up the layers style menu. Check drop shadow, then click on the words "drop shadow" to see your parameters. Drag the menu somewhere to the side—so you can still see your type—then adjust the angle, spread, size and distance until your type looks clear. You can experiment with drop shadow and other options to create different effects. You can also try changing the color. Just try to keep it simple. (Hot pink type with a lime drop shadow is usually a no-no—unless you're competition is "Hello Kitty.")
8. Sometimes a drop shadow isn't enough. In this case you may want to experiment with darkening the background behind the type. You can use the burn tool to just darken an area (paint over your background with this). Another option is to create a rectangular area behind your type that is darker than the rest. To do this, create a new layer above your background image, and create a rectangle with your selection tool. Using the paint can fill it with black. Now you can leave it as is to call greater attention to your caption, or you can adjust the opacity to the layer to make it semi-transparent. In the sculpture photo I've set the opacity of the black square to 50%.
9. If you've tried a few of these options and your type still doesn't look right, you may want to put the caption below, instead of on, the image. If your project is going on the Web you can do this in your HTML. If you are sending an HTML e-mail though you will want to include it in the image file. To do this, you will need to increase the size of the image. First set your background color to be the same as that of your document. In this example I'll use white. Next go to the image menu and select canvas size. Click on the center top square in the grid then increase your height measurement to an appropriate size. I've added .5 inches. Now just add your type to this area. If you've added too much space you can crop accordingly.
10. Save the file in Photoshop format (in case you want to make edits) then go to the file menu and choose "Save for Web." Select JPEG as your file format then click save. If you would prefer a .tif file (for print) you would instead flatten image (under the layers menu) and save as .tif.

Alternative Text for Captions

Captioning images can add value, but will also pose accessibility challenges. If your caption is short, you should copy it into the alt tag of your image. This will make it available to those who use screen readers or other user agents that don't show images. If your caption is too long, you may also want to link to an alternative copy of the text, either on the same page, as a footnote, or wherever you deem appropriate. Read Andy Clarke's article, Accessible alternatives, to learn more about these techniques. For this example I've linked to a description of the image and text and placed it here on the page:

Photograph of part of a sculpture featuring a man holding an umbrella next to a dog whose nose is pointed at the mans's knee. Captions built into the image read as follows:

• Spot, can't you find a squirrel to chase? You've been sitting here panting on my leg for years now.
• What, and you think this is my idea of the perfect view?
• This caption is part of the image file, but sits below the picture.

In Conclusion

As you've seen, it's pretty easy to add text to an image. The tricky part is making it look right and ensuring that the content is available to all. But with a bit of experimentation you can accomplish both tasks.

I've recently come to the conclusion that a great number of Web developers either don't know about Web standards, or simply don't care. For those who aren't already aware of the standards I'll offer a brief introduction along with resources for additional information. For those who don't care, or who are anti-standards, I'll offer some examples as to why I feel they're important. For those of you already in the know, feel free to add your own advice, examples or pet peeves in the comments section.

The reason for Web Standards

According to the Web Standards Project Mission, "The World Wide Web Consortium (W3C), along with other groups and standards bodies, has established technologies for creating and interpreting web-based content. These technologies, which we call "web standards," are carefully designed to deliver the greatest benefits to the greatest number of web users while ensuring the long-term viability of any document published on the Web."

Think of these as the rules of the road. When you are driving a car in Ohio you know you have to drive on the right side of the road, stop at stop signs, not enter an intersection unless there is room for your vehicle on the other side, yield to pedestrians, etc. If you are driving in Hong Kong you know to drive on the left and follow the various rules relevant to that jurisdiction. Following these rules makes the driving experience more pleasant for everyone; whereas ignoring these rules will, at best, annoy other drivers and, at worst, cause a traffic related fatality.

In most cases, a non-standard Web site isn't likely to cause fatalities, but anything is in the realm of possibility. Errors in formatting can cause content to render incorrectly. Imagine if the word "Never" wasn't visible to users reading the sentence "Never pour gasoline on an open fire." A reader unfamiliar with the combustible nature of rising gasoline vapors could easily immolate himself. That's an extreme example, but whether your site is about fire prevention or your book club, you probably don't intend to misinform or confuse your readers.

Following Web standards lets you increase the odds* that your site will be properly rendered by most browsers and user agents and that your information will be more accessible to users and search engines.

* I say "increase the odds" rather than "guarantee" because there are still differences between the way browsers interpret the standards.

What are the Web Standards?

Different standards are available for different purposes, but for the most part standards will define the type of coding that you should use when creating a Web page or stylesheet, or the procedures or policies you should consider when creating the site. Thus if you are building a site in HTML using Cascading Style Sheets, and want to ensure your site is Section 508 compliant for accessibility, you might follow the standards for HTML 4.01, CSS 2, and Section 508.

For example, HTML standards specify using <p> to start a paragraph, <h1> for a primary header and <em> for emphasis. CSS standards specify things like color and position, so that a purple header could be defined in a stylesheet by: h1 {color:#571963}. Using a descriptive word or phrase in the alt tag of images conforms to accessibility standards (both 508 and WAI).

One of the most overlooked HTML standards seems to be the inclusion of the correct document type. For example, if you are building a site using XHTML 1.0 (as is true of many Case sites) you would include this document type:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"  
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

This small piece of code tells browsers and user agents what version of HTML you are using, so they don't have to guess when rendering the site. This is like telling Babel Fish whether you want to translate a phrase from Dutch to English or from German to English. If you don't give it the right information you may not get the right result. I'm amazed by the number of sites don't include this basic information.

Another important standard for HTML 4.01 and XHTML 1.0 is the separation of format and presentation. <h3>Headline</h3> is an example of format, indicating that something is a header. Styling the <h3> with CSS, either in the document or in an external stylesheet, to be a certain size, color and font would be an example of presentation. In the old days of the Web this was done within the HTML using the now deprecated <font> tag. In the past one might have typed <h3><font color="33ff33" size="5">Headline<font></h3>. This not only filled up your page with a lot of extra code, but it also meant that if you decided later to make all of your <h3>'s a different color you would have to go and change all of the font codes one by one. When using a style sheet you can define how your <h3>'s will look in one place. To change the color you just make the one change in the stylesheet and you are ready to go.

Separation of format and presentation isn't a particularly new idea, but adoption has spread slowly. CSS 1 was first introduced in 1996 and the CSS 2 recommendation has been around since 1998. While many sites use CSS, it is still not uncommon to stumble upon current sites that are still using older codes such as <font>.

Why this has been on my mind

A few weeks ago a friend sent me a link to a pretty cool looking site for an online magazine. Alas the site wasn't standards compliant and therefore didn't work properly. This particular site was Flash-based with dimensions too big to fit my screen. The page had no scroll bars so I couldn't get to the menus to navigate through the site. I could see the whole site on my Mac, but not on my Dell, and I'm pretty sure I'm not the only one to have had that problem. Since I couldn't navigate the site, they might as well have posted a page that said "Do Not Enter. We don't care about your business." If they had built a compliant site they would have ensured greater accessibility to users and not had this problem.

I've found a number of other non-compliant sites while working to compile a list of local Web developers. Departments without Web staff often look to outsource their Web projects and turn to me for referrals. Thus I'm trying to put together a list of local (to support the regional economy) developers who I can trust to build compliant sites that follow the Case design scheme, maintain a logical navigational structure and support the goals of the client. This has not been an easy task.

The problem is that almost anyone can learn to build a Web site, but only a few can do it well. There are a lot of firms out there, but the quality of work varies dramatically, and only a handful build standards compliant sites. Sites with major compliance errors don't end up on my list. This isn't just because I'm persnickety. If a site fails validation because of a few stray &'s or they've forgotten to close a few <p>'s I'm not worried. Such errors are easily corrected and don't disturb the overall functionality of the site. But if a site uses <font> tags, doesn't include a doctype, leaves alt tags blank on all of their images, etc., then I will conclude that its designers are not professional and will not be able to offer the client the advice or service necessary to implement a successful site.

Conclusion and Disclaimer

If you've ever built a Web site, you've followed at least a few of the standards. The site wouldn't work if you hadn't. For example if you left out the <body> tag your page wouldn't render. Since we're all following some of the standards anyway, I would just encourage everyone to learn and apply more of them. As you become more familiar with them you'll find that your sites become both easier to use and easier to build. To learn more about Web standards visit The Web Standards Project and the resources below.

Standards compliance is an ongoing goal of mine, but I'm only human. Not every site I've built is standards compliant, and the errors become more egregious the older the pages may be. Since I readily acknowledge this you don't need to go hunt them down, they are out there, and I know it!

Web Standards Resources

• Asterisk Web Standards Archive
• Designing With Web Standards, Second Edition by Jeffrey Zeldman
• Jeffrey Zeldman: King of Web Standards (Business Week)
• Section 508: The Road to Accessibility
• The Web Standards Group
• The Web Standards Project
• W3C Cascading Style Sheets, level 2 CSS2 Specification
• W3C Cascading Style Sheets, level 1
• W3C HTML 3.2 Reference Specification
• W3C HTML 4.01 Specification
• W3C XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)
• W3C Technical Reports and Publications
• Web Accessibility Initiative (WAI)
• World Wide Web Consortium (W3C)