Every now and then I need to ask a client or another developer to save a copy of a web page and email it to me. Mostly it is because they are viewing a page that is behind a firewall and I need to see the markup. Something that happens a lot is that they send me HTML that is more or less mangled.

This HTML mangling happens when you choose “Web Page, complete” or a similarly named option in your web browser. With this option selected, browsers don’t save just the HTML source of the page – they also save any associated images, stylesheets, javascript files and other resources and change all references to those files to make them point to the locally saved copy.

Changing the references to the included files is necessary, of course. The problem is that many browsers also change some of the other markup while doing this. Some (Firefox and Camino to name two) just remove closing slashes from empty elements (<br /> becomes <br>), while others (IE, Chrome) also change the case of element names (<br /> becomes <BR>).

This may or may not be a problem depending on why you need to see the markup. Either way it is very important to realise that the markup you are seeing is not necessarily exactly the same markup that gets sent to the browser.

The safe way, as far as I can tell, to save the HTML of a page from a web browser is to choose the option that is called “Web Page, HTML only” or something similar. All browsers I have tested in seem to save the page with the original markup intact with this option chosen.

The W3C Working Group Note XHTML Media Types - Second Edition contains updated guidelines for the use of different media types with XHTML documents – text/html vs. application/xhtml+xml. The note is about a year old now, so this will be old news to some readers. Better late than never, I suppose.

The document is now more focused on the text/html vs. application/xhtml+xml media types and includes Compatibility Guidelines for ensuring that documents can work with either media type.

One of the notable differences from the previous version of this note is that XHTML 1.1 documents may now be served as text/html provided that they conform to the compatibility guidelines.

by Stoney deGeyter

The following series is pulled from a presentation I gave to a group of beauty bloggers hosted by L'Oreal in New York. Most of the presentation is geared toward how to make a blog more search engine and user-friendly, however I will expand many of the concepts here to include tips and strategies for sites selling products or services across all industries.

Heading Tags

Heading tags are certainly no magic solution to building keyword relevance. They are merely one more baby step to creating a well-rounded optimization of a page. Adding heading tags using your keywords may or may not make a difference in your keyword rankings, but nonetheless, balanced against the rest of the page, using a heading tag properly, with keywords, is going to benefit your visitors, if not the search engines.

On the search engine front, at the very least, the Heading tags (H1, H2,... H6) can be used to tell the search engines the hierarchical structure of your page's content.

When developing content, it's pretty easy for visitors to see how the page breaks down, but search engines need a bit of help. The heading tags are that help.

Think of headings as you would an outline of an important paper. At the top is the Title, in this case the H1 tag. Next would be the Main points; In an outline they would be I, II, and III. In HTML you would use the H2 for all of them. Next we have our sub-points A, B and C, or the H3, and following that sub-sub-points of 1., 2., 3., or the H4. You get the point from there.

An alternate strategy would be to use your H1 for the title as noted above and the H2 for a sub-title. Then you'd start with the H3 for your main points I, II and III, and go down form there. You can go all the way down to the H6, but its rare that you have a page with so much content that this is warranted.

One of the problems I often see with heading tags is that they are used by developers for the site's navigation. In a way it makes sense, you want to segment different areas of the navigation with headers of their own. The only problem with this is that you end up using valuable hx tags in an invaluable area and you're diluting the effectiveness of the heading tags in your content where they would otherwise be most effective.

If your developers are intent on using hx tags in the navigation elements then make sure they stick to the lower level H5 and H6 so you can use the higher level tags in the content where they'll make the most impact. Make certain that they don't use the H1 tag for the logo, that's a complete throwaway and prevents you from gaining any effectiveness with an H1 tag in your copy.

All of the tags can be used repeatedly on the page, depending on where they fall in the total hierarchy, except for the H1 tag (or H2 if you are using it as a sub-headline.) Be sure to use it only once on the page.

Alt Attributes

Alt attributes, commonly referred to as "alt tags" allow you to add descriptive text to your images. The visitors generally won't see the alt text unless, in Firefox they mouse over the image or they have images turned off.

The alt text is meant to be a replacement for the image should the image not show. Make sure your alt text reads properly and adds something for the reader who doesn't see the image. The text itself should describe the content or visuals of the image for the visitor. This text also provides much needed information to the search engine, especially if the image contains text. That text should be included in the image.

Using Alt Attributes in your image tags can help you in a number of ways. 1) it provides a greater context for the text on the page which can be factored into your search engine rankings. 2) It can help your images come up in image searches, which can drive additional traffic and conversions to your site.

Text-only browsers, or browsing with images turned off still happens, probably more frequently than we know. People on slow connections will often turn their images off in order to speed up their browsing experience. Without alt text, an important element of your pages won't be available to them.

There are also a good number of visually impaired web surfers that use screen readers to deliver the content of web pages. The screen reader will read the image alt text, which means if the image is important to the visitor's experience on the site, not having an alt attribute can be detrimental.

Finally, many people browse the web on mobile phones. These phones are almost always slower than the typical internet connection and either the phone's browsers won't display images or users will turn the images off so they can browse faster. This is generally not the case with smart phones, but there are still a lot of non-smart phone users out there.

The most important area to use alt tags is in your navigation. Whether it be your header, footer or side-bar navigation, any place images are used be sure to supplement them with alt text. Failure to do so could make your sit unnavigable to any visitor that isn't seeing images.

Plenty of JavaScript demos and tutorials that you come across on the Web note that they are implemented using unobtrusive JavaScript. While that is great and should always be encouraged, some people seem to believe that unobtrusive JavaScript equals accessible JavaScript. That is not always the case.

Unobtrusive JavaScript is normally mentioned to emphasise that a script uses progressive enhancement to cater for people who use a browser without JavaScript support. But that does not mean that a script is accessible, since two key accessibility issues tend to be overlooked – keyboard navigation and screen readers.

One example of this is most lightbox clones, which can be difficult to use without a mouse and confusing for screen reader users. There are also many widgets (datepickers, dialogs, custom form controls, etc.) that, despite being unobtrusive, do not work well or at all for keyboard or screen reader users (yes, most screen reader users have JavaScript enabled).

So, just a heads up that even though a script is implemented in an unobtrusive way, it isn’t necessarily accessible.