Why, Blog, Why?

In a recent post, Bruce Lawson, a member of the Accessibility Task Force and notable funny-guy, gives the following pointers on accessibility:

• Accessibility is not text-only or a separate “cripples-only” site
• Disability is more than blindness
• Accessibility is not an exercise in political correctness; there are demonstrable, measurable advantages in usability for all
• Accessibility isn’t a purely technical matter; it’s to do with content as well (and is thus also the reponsibility of the non-techy people in the organisation who produce content).

He also points out Legal & General as an example of a corporate web site that is both fashionable and accessible.

In a wonderful display of irony, Bruce’s contribution to the CSS Zen Garden project (a project revolving around beautiful, usable and accessible web site design) had me laughing out loud with a call back to Geocities personal home pages circa 1996. In this case, ugly is only skin deep :)

In todays Web, tables-based designs are taboo. Because of growing support for CSS in the modern browsers and stronger push from local governments for web sites to comply with accessibility guidelines, it’s become much easier to write semantic HTML pages and let style sheets handle the design (see CSS Zen Garden for some inspirational examples), while leaving the tables for tabular data. There are other reasons for abandoning table-based designs - lighter code, faster page loading, more flexible designs, easier to move content to new designs, etc., but most importantly because the alternatives tend to be much more accessible.

Unfortunately, there is a really steep learning curve when making the switch and I think many old-hat developers are put off by this. After all, it’s not that table-based designs don’t work and most web surfers wouldn’t even be able to tell the difference between a site build using tables and one without them.

Fortunately, Mark Pilgrim at Dive Into Accessibility has a really simple trick for making sure that your table-based designs remain accessible. He gives a really great overview of the problem as well.

For a more detailed look at the practice of writing semantic HTML and how it can actually improve efficiency in your web development, see my previous post titled How well formed XHTML and CSS can save your sanity.

I came across a sort of mini-novel/case study today called Client vs. Developer Wars. In it, the author narrates the story of Brian, a project manager at a fictitious company called Electron Cowboys, and his experience with a client that hired them to build a website. The story details one of the classic problems in web development - getting the client to tell you what they want and giving the client what they really mean. I’ve been in situations just like this where a client will only give you a general idea of what they are looking for using buzz words like “cutting edge”, “sexy” , “hip” and “cool”. These terms are mostly used to describe the design or the look-and-feel of a website rather then the content (I think most clients focus on style over substance) , and it’s because of this that the design process is the longest part of the development process. After all, the words “sexy” and “hip” are relative terms that can be interpreted differently by each and every person. What one designer thinks is sexy may just look like a complete mess to another. So, if a client can’t tell you with absolute certainty what they are looking for, how can a designer ever be expected to nail a design on the first try? The truth is that they can’t, and if a client could tell you exactly what they wanted then they probably could have just done the design themselves and saved time, money and many, many headaches on both sides of the hallway.

Read more