Perhaps it’s having come out of the other side of a nearly year-long programming project, or perhaps it’s the abundance of blogs to which I now subscribe, but I’m finding myself increasingly obsessed with the design angle of what I do. Specifically, I’m thinking (and reading aplenty) about web standards and CSS.

One of the great things about running one’s own business in this field is the opportunity to dabble in as many areas of the design and production process as it’s comfortable to manage. I get a massive kick out of the programming and site development angle; I’m fascinated by information architecture and theory; and I really enjoy the craftsmanship of a good-looking site. At least, as good-looking a site as my limited artistic ability can conjure.

Now, I’ve always considered site accessibility to be at the forefront of the Article Seven design process. As I’ve already described, I very much see accessible design as the result of bearing in mind the technical limitations and content flow issues of non-visual browsing contexts. At its most basic level, it’s not a case of jumping through hoops to make sure a site is accessible so much as not jumping through hoops to make sure that it isn’t, in pursuit of a “killer site” in IE.

And — you know what? — I’ve been coding like it’s 1998 pretty much since 1998. I’d like to think that I’ve been a bit more tuned-in to the ideals of semantic markup and presentational separation than some, but at the end of the day, I still used nested layout tables and a bunch of alt="" images. There were reasons for this:

I was careful with the tables so that when they got linearised, the contents still made sense. In fact, nesting the tables actually helped with this.

No browser on RISC OS supported CSS, and I had a persistent nagging feeling that those browsers represented the bottom line to which I should be coding. A touch naively, I just didn’t want to see a wholly unstyled page on the Acorn.

Similarly, I hadn’t realised properly that people were starting to use Mozilla and its cousins in serious numbers. I felt that IE and Netscape 4 were the only browsers with CSS support in common use, and I knew that CSS2 didn’t work on Netscape 4.

Browser bugs frustrated me into a twitching mass (and they still do)

I have two main (read: 80% of my time) clients. Until not too long ago, Woking Borough Council used Netscape 4 in-house. And FISITA are quite particular about things looking just-so (and quickly) in IE.

I was under a bunch of misapprehensions about CSS, that I’ve only just resolved. For example, I had it in my head that some browsers would treat width: 100% as referring to the width of the viewport rather than the parent element, always. I didn’t get the difference between position: absolute and position: fixed (I thought absolute always positioned with respect to the top-left corner of the viewport, but I wished it didn’t). And, most criminally, I didn’t know that you could have a selector like ul.links li a {}. Gah.

The preceding are all feeble excuses — although, it has to be said, standards-based design (a grand term for “not misusing HTML for presentational effect”) is very much a forward-looking exercise in ‘best practise’; it’s not yet shoddy workmanship to produce accessible design that nonetheless uses presentational markup. The real killer reason is that I’ve been so focussed on getting my Perl, mod_perl, MySQL, XSLT and general XML skills up-to-scratch that I’ve simply neglected the design angle.

Well, the time has come to redress that. I’m setting myself two challenges. First, to redesign article7.co.uk using pure semantic markup + as much CSS as I can master. The second, greater challenge, is to redesign woking.gov.uk as close to that model as possible — whilst still keeping the access framework relevant and worthwhile.