• Part 1 (Contracts, Site Requirements,Information Architecture)
• Part 2 (Hosting and Security)
• Part 3 (Navigation, Scent)
• Part 4 (Semantics, Structure vs. Design, Universal design)
• Part 5 (Interaction, Errors, and Administration)

So, we’re finally getting to the meat of best practice web development. This is what people are usually thinking of when they ask about best practices in web design or web programming: actually building the web site itself.

Web design best practices encompass a wide range of needs — everything from the visual look of the design and use of well-chosen markup to the implementation of alternate styles for mobile devices or print shows up in this area. Covering it in one article is, perhaps, ambitious. Fortunately, I’ve written on parts of this subject frequently in the past, so I’ll be providing a lot of links.

It’s important for best practices to clearly separate the structure of your web design (the internal labeling and definition of page elements) from the design elements (the appearance of these elements.) In the last article in this series, I discussed a few key elements of design: not in terms of color, layout, or typography, but in terms of communicating information.

Best practices ultimately leads to creating a universal or accessible design, and this practice hinges on two key concepts: web semantics and the separation of your structure from your design.

The Semantics of HTML

You can argue for days (or years, if you take look at the search results for “HTML semantics” or “web semantics”) on the detailed semantics of how HTML tags should be used. I’ve written on this several times, myself, including articles discussing the value of empty elements, the age-old debate between table-based or CSS layout, among many others.

Semantics are very important. However, when you really look closely at HTML you’ll inevitably notice that it’s not a strongly semantic language — the mark-up language doesn’t even come close to describing all possible uses of the tags. Many tags end up inevitably serving multiple functions.

So what web semantics really require is interpretation. The HTML specification provides one version of this interpretation, with suggested uses and meanings for elements. I’ve provided my own interpretation, as well. There are without question differences of opinion between those documents.

Obviously, you can argue very convincingly that any interpretation which disagrees explicitly with the HTML 4 specification is wrong. Feel free. The core of best practices in web semantics is to use them and make decisions: it’s about thinking, not specific rigor.

We need to differentiate, however, between the semantics of HTML and web semantics. The semantics of HTML are specific and defined: meaning as applied to the elements of HTML. This is a finite list of items, although the complete definition of meaning is less so. Web semantics, on the other hand, describe the application of meaning on the web. This is a more global concept, and applies to all aspects of your web development process.

Web semantics includes everything used to add meaning to your site, providing better comprehension of code and content. Using describe class and ID naming conventions, descriptive function names in server or client-side scripting, or providing helpful comments within your code can all be considered points of web semantics. Best practices means providing a site which is meaningful in both the front and back end.

For specific suggestions about element use, refer to my guide to semantic HTML.

Separation of Structure from Design

This is such an old question to harp on, but the importance of separating the organization of your page from the way it looks has never really flagged.

At a superficial level, it may appear that any markup you use has an effect on the appearance of your site. After all, there’s a clear visual difference between unstyled text marked as a heading and unstyled text marked as a blockquote! However, this visual difference only truly exists because the description “unstyled” is truly a misnomer.

If you disable stylesheets on a web site, you’ll see an extremely plain view of the site. It is not precisely “unstyled,” however — the design has simply been reduced to the default styles applied by the browser. In general, every browser has very similar defaults — but they’re not exactly the same. This is one of the reasons that it’s common to begin a stylesheet with a set of reset styles.

If you conscientiously remove the browser default styling, it can make your own development easier: the slight differences between browsers can then be ignored.

The point is that you should never place anything in your markup which exists purely to create a different appearance. Attributes or tags which define font faces, colors, or styles are obvious problems — but the use of small or strong can also be problems. It’s not that you should never use small: but your use of the element shouldn’t depend on the text being rendered smaller than the surrounding text.

It might not happen, after all.

This is one of the key complaints about using tables for design layout. A table is designed to organize information by providing easy access to it in a matrix. The columns and rows visual appearance of a table is a formality used because it is an expected way to view this type of data organization.

When you take a table and use it to layout your design, you are violating the separation of structure from appearance: your design is now dependent on the default organization of tables. Should somebody attempt to re-organize your table (for example, to linearize the information,) they may encounter a radically illogical data structure.

Fundamentals of Universal Design for the Web

The goal of universal design is very simple: make the information in your website available to every person or device which attempts to access it. This includes mobile devices, search engines, assistive technology, disabled users, and standard desktop browsers.

Universal design is where we bring everything above together. Attention to web semantics and a strong separation between structure and design give your web site at least a fighting chance of being universally usable. Obviously, you can still screw things up!

In the same way that following web standards doesn’t mean that you’ve made a web site accessible, following best practices for general web development doesn’t mean that you’ve made a site which will be great on a hand-held device or with a screen reader.

Different devices (like people) have different special needs.

Creating a web site which is truly universal requires you to be aware of the special needs of every device you’re working for — but a few basic principles will get you 95% of the way there.

The Principles of Universal Design provided by The Center for Universal Design at North Carolina State University are a good guideline for thinking about universal design. Although these principles are truly designed to be universal, in that they are intended to be applied well outside the realm of web development, the basic principles are sound in any context.

If you break the concept of universal design down to a single core issue, it could be that dependencies break access. Whenever you set up a situation in which a specific technical or design element must be present (a dependency on Javascript, a requirement that a control matches the description provided, or a requirement that a user must see a given image, for example,) then you are creating the potential for design failure. Avoid creating anything which depends anything out of your control.

Knowing what is and isn’t in your control (and, more importantly, what seems like it’s in your control, but really isn’t) is critical to best practices in web development. Acknowledging that although you can set the color of the text, you can neither guarantee that a visitor will be capable of seeing that color nor that the text will in fact be that color at the point that a visitor sees it is a critical step in understanding universal design.

Best Practices in Web Development: Part 5 (published on Friday, September 5th) covers interaction design, error management, and long-term site administration.

Best Practices in Web Development: Part 4
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

This is part 1 of 2. Part 2 is my Guide to the use of Semantic HTML Elements

I’ve seen a lot of articles discussing the importance of HTML and XHTML semantics. I’ve seen articles describing what it means for a document to be semantic. Most of these articles, however, don’t provide a serious overview of what HTML elements actually may be considered semantic — and what those semantic elements actually mean.

And, even more particularly, why it matters.

Semantics is an erudite area of study. Literally, semantics can be fairly defined as the study of meaning in communication. Communication can readily be extended to cover symbolic notations, representations of language, organization of language, body language and information structures. In developing a web page, we are organizing a means to communicate the content of that page: ideally, we are organizing the page in such a manner that it will be understood regardless of the method by which the page is accessed. It should be equally understandable whether seen, heard, or felt.

The semantics of HTML structure, then, are clearly an important part of web design. Sending mixed signals to the user agent or the user by using a blockquote purely for it’s native indentation is an abuse of semantics: even the visual impact is dependent on the assumption that user agents will consistently render a blockquote in an indented manner.

It’s not precisely an issue that you’ve used a semantic element for presentational means, because, in fact, you’ve done more than that: you’ve presented a block of text which is not quoted material as if it were.

Semantic elements of HTML carry meaning regardless of your knowledge of that meaning. The result is that the misuse of an element creates the potential to mislead or confuse an end-user.

The most obvious examples in common use are those which make use of elements with semantic meaning which also offer a browser-contributed default presentation in order to use that presentational style. The blockquote example above is not uncommon; similarly, the use of empty p elements to create extra white space or heading elements used as a questionable SEO technique in substitution for normal paragraphs.

Other examples which bear mentioning include the use of empty anchor elements to trigger Javascript events — in this case, it’s partially a limitation of the identity of an anchor element, but an empty anchor element should always be considered an error, as it results in a behavior-less anchor if the Javascript is not available.

Now, you may point to the following paragraph, from the HTML 4.01 specifications, as a response to my opinion:

Authors may also create an A element that specifies no anchors, i.e., that doesn’t specify href, name, or id. Values for these attributes may be set at a later time through scripts.

The fact that it is allowed by the specification does not make it a best practice. With all due respect to the W3C, this should not be permitted. For reference, the HTML 5 specification currently reads:

If the a element has no href attribute, then the element is a placeholder for where a link might otherwise have been placed, if it had been relevant.

In addition, although I won’t quote everything, the specification states that an anchor which does have the href attribute must specify a URI as the value of that attribute. It appears to essentially state that an anchor element should have no semantic meaning if the href attribute is not set and valid. But I could be wrong.

The best means to avoid the misuse of elements is to have a clear understanding of when and why a given element should be used in web development. To hopefully expand on your knowledge in that respect, I’m attempting to provide a semantic guide to HTML elements for your reference and rich disagreement.

Be aware, however, that semantics are largely a matter of opinion. It’s not a question of blindly following the guidelines set by a group; it’s a question of interpreting those guidelines to the best of your ability and belief. This guide reflect how I think HTML elements should be used; and I welcome your opinions.

Other HTML Semantics Articles

• Guidelines from WCAG 2.0 on the use of HTML for semantic structure
• Traditional HTML Semantics (Part I of a three-part series on web semantics by John Alsopp)
• HTML: The Foundation of the Web – Niels Matthijs
• Semantic HTML and Search Engine Optimization – From the Opera Developer Community, by Joost de Valk
• Who will read your semantic HTML? – Jesse Skinner
• When semantic markup goes bad – Matthew Paul Thomas
• Semantics – why bother? – Mel Pedley at Accessites
• HTML Semantics from Western Civilization, Pty.
• Graph the Semantic HTML Structure of your Web Page – Joe Dolson

Why use semantic HTML?
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Standards (software)

Software standards enable software to interoperate. Many things are (somewhat) arbitrary, so the important thing is that everyone agree on what they are. Software standards is one of the Unsolved problems in software engineering

On the whole, the article at Wikipedia is a good example of what isn’t so great about Wikipedia — poorly written, incomplete: the article is more a collection of notes in preparation for writing an article than it is a real document. Nonetheless, the above definition contains a gem of perception concerning exactly what it is that standards actually do. Standards enable software to interoperate. Standards increase the ability of various programs to cope with what is fed to them.

And, fundamentally, that’s all they do. Standards, by themselves, are not in any way equivalent to “appropriate” or “good.” Web standards enable one program to understand what has been notated in another program. An HTML document may be an incredibly simple and basically inert program, but it is essentially a software program.

But they don’t actually dictate a lot about how that code is actually used, or what elements go into the program.

Let’s try a comparison to cooking. If you’re cooking, you’ll follow a recipe. The recipe dictates units (cups, teaspoons, liters, etc.). The recipe also dictates ingredients, sometimes with substitutions. However, some aspects of a recipe are actually pretty imprecise — cooking on “medium heat,” “beat until stiff peaks form” or “use one large egg” are all examples of specific directions which do not necessarily convey the information needed to perfect a recipe.

Furthermore, a recipe does not necessarily include every detail of creating the meal — it may leave out key pieces of information which it assumes you know: stirring the sauce, checking the internal temperature, or removing the pits. These are necessary aspects of preparing the meal right, but which require external knowledge to comprehend.

If you want to bake a cake, you do need to follow the recipe (mostly.) If you substitute baking powder for flour, you will not end up with a particularly appetizing cake — but you’ll also have problems if you ONLY follow the recipe, and include the eggs with their shells.

Molly Holzschlag mentioned this idea recently, and I’ve certainly written about it before, but it’s a valuable point and worth reviewing.

Besides, I thought of this analogy to cooking the other day while I was making dinner, and just had to get it out of my system…

Using standards doesn’t make it right
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

I’d love to be able to produce graphs where I chose the color coding pattern for particular tags. I could set all non-semantic tags to be bright red, to easily spot the condition of a site in that respect. I could focus my attentions on inline versus block elements, or I could differentiate between different levels of headings.

More recently, I received comments on that post from a visitor who thought my idea to change this was a good one — so, at long last, I’ve gotten around to doing it.

Semantic HTML Graphs

And here’s an example of output:

The graph pictured here is for Metrolinx, the Greater Toronto Transit Authority — and Joe Clark’s failed redesign of the year. It makes for a pretty interesting case study. I know the output is small; but bear with me.

In this graph, you can clearly see long strings of orange nodes, which indicate nested table elements. You can also see significant clusters of bright red nodes, indicating deprecated tags. Altogether, the site is a maze of primarily long wavelength colors. In general, in the color scheme I’ve set up, greater densities of long wavelength colors (red, orange, pink) shows a dependence on tables for layout and presentational elements. Short wavelength color (blue, green) indicate more semantically meaningful structures.

I made a number of small changes to the script which I think add value. First, I added the ability to change the root node you’re mapping. I don’t know that this is incredibly valuable, but it does provide an interesting alternate piece of information. The node switching is limited; it will only check the first node specified of that particular content type.

The second change is to provide a variety of color schemes. The default is pretty complicated, although I drew the line well before attempting to provide a subtly different shade for every single element. I hope that the colors provided at least give you an idea of what you’re looking at, however. The alternate color schemes (two, at the moment) are much simpler: one which simply differentiates between allowed and deprecated elements and another which highlights all inline elements (a, dfn, samp, etc.).

Now, I’ve never programmed in Java before, and although the changes I made to Sala’s source code are relatively slight, it’s highly probable that there are bugs; and I’ve certainly not managed to remove any bugs from the original code.

The last thing I need to mention is concerning the accessibility of this applet. It’s just not accessible. In fact, I know little about how to make Java accessible in the first place; but even so, the entire concept of this applet is highly dependent on color. There can be no question that if you are color-blind or otherwise sight impaired this will be a problem. Additionally, there is absolutely no means present for any screen-reader to understand the input. I do hope to change this at a later date, and author a text-based output which will provide a separate, accessible interface with the information, but that just hasn’t happened yet.

Also worth looking at:

• Validation Graphs – a stand-alone Java application also based on the HTML graph script which spiders pages and checks them for validity.
• Web2DNA – same basic idea, different implementation.

Graph the Semantic HTML Structure of Your Web Page
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

One root of current standard accessibility practice is conformance to the HTML or XHTML standards set by the World Wide Web Consortium (W3C). This is a fine practice, and certainly should be maintained. Using correct syntax and following a standardized method of communicating information is always a solid best practice. However, this should absolutely not be taken to mean that following these standards is the same as applying the principles of web accessibility.

Web standards only provide accessibility to the degree that they have been designed to do so — and the guiding principle behind standards development (excluding accessibility-specific standards, of course) has not generally been to support accessibility. Web standards have been designed purely to establish a set, correct method of using the underlying code — whether presentational (CSS), structural (XHTML) or behavioral (ECMAscript.)

In many (most) cases, web standards do not in any way require best practices — they merely require conformance. Take HTML, for example. Web standards would permit the usage of table elements for layout, because they do not define semantic usage for the table element. Web standards also permit a variety of presentational elements, such as font, strike, or u. It all depends on what standard you have chosen to follow.

HTML5, most recently, is considering such contrarian steps as removing the requirement that alt attributes be required for images. This ensures the existence of a valid HTML5 web site which can radically fail basic accessibility guidelines. On the other hand, it may reduce the likelihood that some so-called “accessible” web sites will be littered with alt="this is a spacer graphic".

Does this necessarily mean that the standard is wrong or right? No, not as such. Different standards support different needs — it is important to keep distinct the purpose of the standard. Conforming HTML is just that: Conforming HTML. It means nothing more.

Nonetheless, as an accessibility advocate, I feel that it’s important to support accessibility issues within the development of new standards. Taking the alt attribute issue in HTML5, for example, the lack of any perceived benefit to not requiring the attribute suggests to me that the better path would be to continue to require it. There are numerous examples of important accessibility aspects in HTML5 which are not yet included.

There seems to be a strong element of specious judgement: elements which are not supported by current user-agents are considered not to be needed. This seems a ridiculous expectation: after all, if unsupported elements aren’t needed, than why develop a new specification at all? What we’ve got must work just fine!

Practically speaking, user-agent support and developer use should both be only marginal issues when trying to decide what elements are most needed in a specification. The fact that elements are unused on either end are not a judgement on the value of that element; merely a judgement on the awareness of the element, on the clarity of the existing specification, or on the complexity of the implementation.

Nobody (or almost nobody) uses the q inline element. Does this mean that the element isn’t valuable, and should be discarded? No. It means that Internet Explorer should add appropriate support for it. The same is true for accessibility issues. The standards should support them to their best abilities: if an element or attribute could hypothetically add to the accessibility of a site, then the fact that it is little used or poorly supported should be entirely irrelevant. Support should follow the standards; not the other way around.

At the root of things, my stance is that I am unwilling to support a standard which specifically excludes features which are needed in order appropriately provide best-practice accessibility. HTML5 is still a long way from being done; and even further from being implemented (if it ever is,) but the removal of such attributes as the header from table markup, the inclusion of defined non-semantic elements such as b1, and the “WYSIWYG exemption” on the font element strike me as decisions badly in need of reconsideration.

1. In point of fact, I can accept the inclusion of one inline non-semantic element (span) and one block level non-semantic element (div). I feel there’s ample justification to allow elements which are not specifically defined on the grounds that not all situations can possibly be covered by the specifications of the language. I see no justification, however, for the inclusion of additional explicitly non-semantic elements.

Supporting Standards that Support Accessibility
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Interestingly, it appears that some of the ideas discussed in this article are actually being actively tested by Google.

As of September 2009, it appears that Google is actually putting this concept into practice.

An interesting thought in indexing and handling page structure is the concept that different areas of a single page can be identified and considered independently from surrounding bodies of content. This particularly applies to specific and readily identifiable data-types, such as phone numbers, postal codes, or abbreviations; but can also be extended to include broader content labeling.

A well-structured XML document has an absolutely clear labeling system for data built into the structure. If you take any RSS feed, for example, the elements which identify <title>, <link> or <managingEditor> can’t readily be mistaken.

A well-structured, semantically sensible XHTML or HTML document doesn’t offer nearly the same degree of data particulation — the higher level data elements can sometimes be fairly clear, as is the case with <address> or <cite> elements, but other potentially valuable elements end up providing relatively neutral value: <h2> or <div>.

For users, you can readily provide some parts of this needed structure by using in-page references to provide a table of contents, when a document requires significant structure. (This is provided normally for screen readers; but no such equivalent is available in most standard browsing methods.) Giving a content heading or content section a unique id and providing a link to it can provide value for your users by enabling them to quickly access areas of your document with a greater specificity to their needs than the document may provide as a whole.

This kind of content particulation could be leveraged by a search engine to provide immediate access to a specific point within a resource.

Additional specificity can also be achieved through the use of Microformats. These externally defined mini-standards for content identification can enable various tools to better understand and interact with your site content.

From an accessibility perspective, this is not currently receiving any kind of meaningful application that I’m aware of — but it’s an interesting concept. I like the idea that the use of microformats (or any method of explicitly labeling and defining data) could allow any user agent to make immediate use of that information.

The whole idea of dividing your semantic content into labeled and defined sections provides a great deal of value for any user scanning over your document. Dividing your content into areas with relevant headings makes that document more scannable, and also allows search engines to better understand the overall relevance of your document at a more specific level.

I’m not sure I have a real “conclusion” to pull from these thoughts. Basically, the underlying concept is “identifying your information is a good thing.” That’s a well-known issue in accessibility when it comes to visual, audio, or video content, with audio description, transcriptions, and captioning filing in those spaces. However, with more finely particularized elements of data, it seems that the same principal has the potential to provide an overall better user experience simply by enabling the user-agent to quickly realize the best method to deal with the information.

Thoughts for this blog post inspired by Bill Slawski during a PubCon session…

Thoughts about Content Labeling and Data
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

This module describes integration of grid-based layout (similar to the grids traditionally used in books and newspapers) with CSS sizing and positioning. Document Abstract

Semantically, the grid layout system is a nice development — it is a system explicitly and exclusively designed for layout, which has no required HTML component. An excellent companion to the div element.

The concept of a grid framework has been applied in many graphic and typographic media for many years; including the web. Resources for constructing grids using CSS abound:

• Blueprint CSS
• Yahoo! Grids
• 5 Simple Steps to Designing Grid Systems (Mark Boulton)

The deal with constructing a grid system using CSS is that it’s very difficult to do without using very complex code. The main new addition to CSS construction offered by CSS3 is the ability to align document elements across grid columns. This is a pretty nice additional feature, far more powerful and flexible than the feeble float construction.

The major changes evidenced in the CSS3 grid-layout, at the moment, are the additional CSS elements grid-columns and grid-rows. However, the grid-layout also takes significant advantage of extensions to the float element, which carries new attributes allowing you to specify the target location for the floated object, and a new measurement unit — the “grid unit” — equivalent to the distance between two adjacent grid lines.

An interesting thing about this measurement unit is that not all grid units will be equal — since you can specify a different measurement for columns (content bearing grid elements) and column-gaps (the space between columns.) An object given the width in grid units will span the appropriate number of grid units, regardless of the specific size of those units.

It looks complicated. There are a lot of new possibilities and new ways of approaching layout which will become available with the maturity of CSS3. However, assuming equal, standards-based implementations, I see no reason that this shouldn’t ultimately be far simpler than existing CSS layouts. A grid standard will enable, ultimately, far more consistent and reliable site design methods.

I just wish we didn’t have to wait so long…

CSS3: On Grid Positioning and Layout
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

On the whole, I think this discussion is an old, worn-out subject: those who won’t use tables generally don’t use them out of principle, and those who do use them out of pragmatism and a justified awareness that principles don’t build websites. I want to review the question once more, however, ignoring the entire question of principle.

The Argument Before Us

The question at hand in this forum discussion has been whether tables have a fundamental, universal flaw which should make them unacceptable. Many arguments have been offered, but don’t satisfy the true question.

Answering the question is actually very difficult. It needs to be an inherent characteristic of tables, rather than a factor which depends on a specific use of tables or a facetious argument about which one is “easier” to use or maintain.

I’m opposed to using tables for layout — but now I want to look very closely at why. I want to find a reason outside of my own biases and beliefs, which can be simply stated and demonstrated.

Is it possible to use tables for layout and provide an equally usable and accessible web site?

For the best analysis, we have to assume that these tables are being used in a respectable manner. Bad code is bad code, whether it’s applied to <div>s or <table>s. Twenty-eight layers of nested anything is bad news.

So, there are three rules which must be met in order to be a definitive advantage:

1. I’m not willing to accept minor design limitations as meaningful for either option. Whether there are certain design choices which you don’t have open to you with tables or with CSS-based layouts is irrelevant to me: you choose a tool, and work with the capabilities of that tool.
2. I don’t accept ease of maintenance of development as being relevant. These are personal opinions and personal choices.
3. I’m not going to consider semantics except as it may effect the user experience. A context in which the use of tables for layout causes problems because the device assumes any table is purely tabular data is a problem; the argument that tables are “wrong” for layout is functionally meaningless.

The only acceptable argument is whether there are ways in which the use of a table for layout inevitably damages the user’s experience with that site.

Examples of perceived weaknesses of tables

Speed of rendering. Unless table widths are specified explicitly, the entire content of the table must be rendered fully before the browser can completely render the page. This slows down the overall loading time of the page.

This does not fulfill the requirements. First, this is also true of CSS based websites. Second, it’s avoidable.

In order to provide an accessible website order, you have to arrange your data cells very carefully, due to table linearization.

Partial pass. The only real difference is that with tables, whatever will appear on the left MUST be before what appears in the center. Of course, there are easy workarounds for it. There are, in addition, many other ways of navigating around a page which make the whole concept somewhat irrelevant — it doesn’t ultimately matter that much whether your navigation appears before your content, if you’ve made effective use of other key structural elements or skip links.

Adaptability with variable browser widths

Tables can only become as narrow as the content they contain, even if they are constructed using percentage widths, etc. Div based layouts can re-flow content, so that sidebars slip to the bottom as the screen width narrows. The question is: which behavior is worse? Would you rather have to scroll to the bottom to see sidebar or navigation content, or scroll horizontally for the same? I’d rather not ever do horizontal scrolling, but this isn’t a clear pass.

Compatibility with mobile devices.

Technically, the same problem as above. However, many modern devices don’t really have this problem. There are four basic methods of rendering sites in mobile devices: linearizing, zoom, rewrite, and “try and interpret the standard styles on a tiny screen.” The 4th method is the only one which is likely to really run into problems with tables — and it’s fundamentally identical to the previous described problem.

Ability to accomplish radical redesign without altering HTML code.

Depending on your definition of radical, this is a total winner for CSS layouts. Tables fix the fundamental placement of elements where CSS based layouts allow those fundamental elements to be moved more or less at will. Whether this is seriously important, however, is a matter of personal opinion. Arguably, this is a question of design capabilities, and fails rule #1.

That’s all I can think of off the top of my head, although I’ll happily accept suggestions from the comments.

Before I move on, however, I want to approach this from the opposite direction. What are the advantages to using tables for layout? The same rules apply: only a situation where not using tables for layout damages the user’s experience will absolutely qualify the table as a superior method.

The main reasons people have so far espoused as benefits to using tables for layout include:

Easier to learn and use

Matter of opinion. Doesn’t qualify.

Easier to create a multi-column layout with full-length columns.

Yes, it’s easier. But the fact that with CSS this is quite difficult is not a huge advantage — although we ALL agree that CSS will benefit greatly from more advanced support across browsers.

Certain layouts are only possible using tables

This is extremely difficult to prove. In the Cre8asite thread, Ron Carnell suggested a specific layout which he believes is not possible to accomplish without using a table. The challenge is to present a poem with a heading where the lines of the poem are left-aligned, but the poem as a whole is centered under the heading. The poem and heading should be able to have lines of any length and still remain centered correctly. (See “flush left” sidebar.) Although CSS appears to fail this test, the test itself comes under rule #1, as well. It does not substantively effect the user experience.

Browser Compatibility

Older browsers have lousy support for CSS. This is pretty much a no-brainer. Older browsers (Pre-IE 5.5) pretty much just have to receive style-free versions of CSS-based layouts. Still, it’s a very valid question whether providing support for Netscape 4.8, IE 4 or similar relics is actually valuable. As of today, statistics for August 2007 at theCounter show that all versions of Netscape 7 and below plus all versions of Internet Explorer version 5 and below accumulate to approximately 1% of browser market share. Versions of IE in the 5 range account for over half of that – but it’s still less than 1%. (Browser Statistics for August 2007 as of August 23rd, 2007.)

In Conclusion

The conclusion, so far, is inconclusive. Tables, when used with a high level of consciousness concerning how and when they can be used, can provide a perfectly flexible, fast, web site. Though there are definite flaws with tables and how they present information, many of these problems are paralleled by related problems when using CSS based layouts.

There don’t appear to be any serious benefits, however, to using tables for layout. Although the table may make layouts easier for certain contexts: particularly when using centering and fluid widths or establishing full-length columns, these aren’t, in my opinion, issues which are capable of selling the table as a tool for layout.

In the absence of any definitive benefit for either tool, I will choose not to use tables for layout. I am, however, interested in this argument, and would be glad to hear your own arguments for or against either method. I have little doubt that I’ve missed cogent points for both sides!

Why not tables? Is CSS really better?
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

It’s embarrassing to mispronounce somebody’s name. Outside of a personal introduction, however, it can be very difficult to know how to pronounce personal names because of these numerous deviations from the rules of pronunciation. (Which, in English, are already pretty nasty.)

But using language to markup a personal name may be somewhat deceptive or inaccurate.

First, there’s the semantic content of the personal name: does the name really represent a portion of another language because of it’s pronunciation? Then, there’s the choice of language — “J” is pronounced as “Y” in several languages. When there’s a clear intent, due to family origin and known parental choice, I suppose you could choose fairly easily. However, the number of people you know well enough to select the correct language on the basis of their family origin and how their names were chosen is probably pretty small.

In fact, I think it’s fair to say that I cannot say with absolute certainty that I know how to pronounce 99% of the names I reference on the web. If I were to attempt it, I would not actually be capable of marking an appropriate language for most names.

Nonetheless, I find it frustrating to be unable to pronounce something consistently and correctly, and would certainly not mind if there was some meaningful technique to mark pronunciation. There is, of course, the Pronunciation Lexicon Specification from the Voice Browser activity group of the W3C. This is, however, not something which is applicable to XHTML or HTML to the best of my knowledge.

Anyhow, this is a question which struck me as interesting. Correct pronunciation in screen readers is one of the reasons for using language markup for a block of text. The same logic extended to personal names makes for a curious anomaly.

Personal Names and Language Choice
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

In particular, it’s nice to see people from the web standards community discussing search optimization. There’s no question that creating a website which applies web standards and the principles of accessibility also creates a nice landing spot for search engines. When you build accessibly, you remove barriers to access for search engines as well as users. Although accessibility and web standards are certainly not necessary for search engine success, they can be an excellent way to kickstart your campaign. New websites in particular are likely to benefit from the crawlability and easy navigation aided by conscientious construction.

Robert comments on the fact that there are a lot of shady SEO companies out there. It’s important to mention that, but also important, as he does, to acknowledge that there are large communities of enthusiastic search marketing companies who won’t use those methods. A solid search marketing company will emphasize long term results — and will therefore avoid these methods which leave your site open to future condemnation.

There are a lot of interesting questions he raises on how logical web design and implementation questions can influence search engine considerations of your site. Does hidden text which is part of a DOM-manipulable interface raise red flags? What about use of <em> to highlight an entire block of text, such as an introductory paragraph or preamble? They may be sensible decisions, but they may also raise undesirable red flags with a search robot.

My opinion is that search engines are out to find your content. If you’re providing unique, valuable content, they’ll persevere until they find and index your content. If you’re using a particular technique for a good reason, you should be OK.

Should be OK. That deserves repetition. You may NOT be OK — like I said, I’m not an authority. However, if you keep the basic premise that search engines want to find your unique information, then they’ll discard the red flags as long as they continue to find value at your site. Algorithmic decisions will always create conflicts, however. Whether the weight of your content is greater than the flags raised by your design decisions is an open question.

To generalize, if you’re making a decision on the basis of a semantic decision or to provide added functionality, you should be all right. If you’re making a decision because you’re trying to influence search engines, you should think again. A search engine should never be your sole reason for a coding decision.

Standards, Accessibility, and Search Engine Optimization
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design