Thoughts on branding, design, writing and life by Kevin Potts. Established 2003.

Site Upgrade: Viewpoint Consulting

Where once stood a derelict hulk of late 90s markup processes, a gleaming, streamlined, CSS-powered monolith of standards goodness now reaches to the development heavens.

I recently had the opportunity to upgrade a client’s old site into a new standards-compliant version. Where once stood a derelict hulk of late 90s markup processes, a gleaming, streamlined, CSS-powered monolith of standards goodness now reaches to the development heavens.

Enough drama. A few highlights:

  • Increased accessibility. Clean code for screenreaders, skip navigation links, and variable em-based text. The previous version’s JavaScript and frames have been removed.
  • Drastically reduced page size. The total number of images has been reduced from 89 to 17, the average page size from 6k to 3.5k.
  • The only table on the site is for tabular data. A pure CSS-controlled layout works perfectly in just about every browser. There were some small forward-thinking techniques involved on this one, so a few CSS glitches appear in IE5, but nothing dramatic.

This particular project was made more exciting from the client’s enthusiasm, and interestingly enough, it was the accessibility “upgrades” that sealed the deal. Since my client works in the healthcare industry, it was critical to maintain as many open doors as possible, and he (nor I, when I built the original years ago) never considered that frames, JavaScript and fixed font sizes were locking out screenreaders and aggravating those with visual impairment.

This was strictly a “backend redesign.” Except for a few small cosmetic tweaks, the color, typography and imagery largely stayed the same. The client had originally just wanted to add a few pages of content, but when I expressed my wish to apply some small standards-upgrades, he insisted on doing the site the right way.

Since I already built the site years ago, I thought there would be some resistance to the idea of a simple code upgrade, but I simply explained that web technology is constantly growing, and that the understanding of accessibility has come a long way in just three years. Maybe I’m lucky to have such an understanding client, but I think the general web audience is the one that benefits long term.

commentary + criticism


wrote the following on Thursday December 30, 2004

In this article you mention that you still used table tags for your tabular data… Does anyone have a technique that they are happy with for mimicking a table layout with CSS? I’ve toyed with one, but it does not reduce code, and I’m not sure how it stands from an accessibility standpoint. Basically, I have done something like this for each row:

<div id=”tablerow”>

  <span id=”col1”>data</span>
  <span id=”col2”>data</span>

The #tablerow style defines the overall width, border style, etc., and then each col style defines font, alignment, and individual width and padding to dictate the column widths and spacing.

It’s using CSS from a technical standpoint, but clearly not very elegant. Has anyone cooked up something better?

Lachlan Hardy

wrote the following on Thursday December 30, 2004

G’day Mark

Tables should be used for tabular data. Web standards and best practices don’t mean no tables, they mean using tags for the purpose they were intended. Tables are intended for tabular data, but they are not intended for layout

In other words, it is perfectly okay to use a table where it is needed

As a side note, CSS floats were not intended for page layout either, but at least they are less of a hack, less page weight and quicker loading than tables

(Note: obviously our host could have answered this himself, but it had been over an hour so I figured I’d stick my oar in. Hope that’s cool, Kevin!)


wrote the following on Thursday December 30, 2004

Thank you, Lachlan – that is an excellent point. I am a programmer by education and professional experience, fairly new to trying my hand at design. I’m trying to take CSS a bit far by using it for everything instead of using it as the W3C intended, I suppose. ;-)

Lachlan Hardy

wrote the following on Thursday December 30, 2004

Don’t worry, Mark, it is a common misconception amongst people new to standards that a ‘tableless layout’ means a tableless site

I’m a programmer too. You’ll find it easy to pick up the coding aspects. Probably far easier than for a designer doing the same thing. Far harder is learning design itself – I still have a long way to go on that one!


wrote the following on Thursday December 30, 2004

Agreed, and thanks for giving such a great answer Lachlan. It is exactly my line of thinking—standards are for using markup as intended, that’s why the table is used for my tabular data. To be honest, I don’t want to even think about trying to recreate a table with divs. It is hard enough getting a three-column layout to work consistently across browsers.

Derek Featherstone

wrote the following on Thursday December 30, 2004

Just one quick addition—Mark, you mentioned that you weren’t sure of the accessibility of using divs and spans in place of a table.

In reality the table (for tabular data) will be much more accessible than any div/span based replacement. Screen readers actually rely on proper table markup so that people are able to use the tabular data properly. As an example, when a screen reader is reading out the data in a table cell, JAWS users hit Ctrl + Alt + NumPad 5 and it will read out the header association to replicate what we do visually when reading tabular data.

For a really good overview of tables, check out Roger’s post: Bring on the Tables at

patrick h. lauke

wrote the following on Thursday December 30, 2004

ah…derek beat me to it, but yes, to reiterate: it’s important to actually use tables for tabular data, because the various elements (headers, cells, rows, thead, tbody, etc) have strong semantic meaning and properly (and unequivocally) bind data with the respective headers. yes, you “could” use DIVs and SPANs, but they’re the most neutral elements out there, and don’t have any intrinsic meaning (let alone built in semantic connections with other elements, the way that a TD has with its associated THs).


wrote the following on Thursday December 30, 2004

Thank you for the accessibility points, too! I appreciate that – I was also curious about that aspect, too.


wrote the following on Thursday December 30, 2004

Ok, quick question to Kevin and/or others:

If you placed your navigational elements at the bottom of the (x)html code so they load and are read last, you would not need a skip nav link, correct?

Just curious…or confused, I’m not sure :)


wrote the following on Thursday December 30, 2004

Sam—this is a great question. Unfortunately, the “skip nav” link is a bit of a misnomer, but its what Mark Pilgrim defined in his excellent Dive Into Accessibility site so it has been widely adopted.

The link should actually read “go to content” and should be the first thing in the page, before the navigation. From a purely semantic point of view, no one really cares about skipping navigation because they don’t know where that link will take them, but they do care about getting right to the content.

Long story short, always include the link but disregard my error; simply make the link say “go to content.”


wrote the following on Sunday January 8, 2012

I’m always surprised by how many websites there are out there that have their images sized way to big. It takes forever to load the pages. I just recently did an overhaul on a client’s website that looked like it had been built in the early 90’s. I had to clean up the code. Add no follow tags. And decrease image sizes. They are getting ready to budget for a whole new webdesign. I’m hoping to convince them that a simple and clean design with the right on page optimization is much better than what they have now.