Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

CSS is Visual

December 04, 2003

Quite a high-threshold discussion happening on fellow Canadian Jeremy Shield’s weblog.

Nothing really too new here, except for the observation that, with everyone’s help of course, we’ve more or less made it impossible to argue that CSS design is inherently ugly.

…tableless design transforms the web into a library and less of a visual spectacle…

This is an interesting point, since, yeah actually — that’s exactly what’s happening. And it’s good, remarkably good, for this to happen. Not only are table-less sites not boring, they’re accessible. Keep in mind that all CSS Zen Garden examples validate to WAI AAA-level accessibility, although the individual designs can be more and less accessible depending on techniques used. Not only are they accessible, search engines love them. The Zen Garden is insanely high in Google thanks in part to well marked-up content. Not only are they search engine optimized, but they are, contrary to what you say, far less bandwidth hungry than tables. The average conversion of a site from tables to CSS-based chops the HTML file size roughly in half, reduces the number of server requests necessary, and generally reduces the number of images needed. All for the same design.

Anyway, the rest is worth a look. §

update: Okay, so I guess we’re not talking about that. Looks like the comments got hijacked into a thread on triple-A accessibility instead. Not that there’s anything wrong with that. Discuss. §

Reader Comments

December 04, 03h

Firstly, I’ve got to say that I have never seen better designs with tables than with CSS. The Zen Garden is quite a phenomenal example of what can be achieved - and I think pretty much any vision a designer has can be achieved with CSS.

The only problem I have with the Zen Garden is that it states to be WAI AAA when it isn’t. I don’t think it matters that it isn’t AAA, it just shouldn’t have such a claim.

The WAI guidelines are flawed and the CSS Zen Garden is highly accessible, but to state compliance with a certain standard it must meet those guidelines whether they are flawed or not.

The Zen Garden does pass through Bobby but Bobby is not very clever and a lot of the WAI guidelines can not be tested by an automatic validator such as that.

Just quickly browsing through the WAI checklist ( ), the Zen Garden doesn’t comply with the following Priority 3 checkpoint:

“10.5 … include non-link, *printable* characters … between adjacent links.”

It also doesn’t necessarily pass these Priority 2 checkpoints:

“2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.” which is dependent on the CSS of each design


“3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values.” and some designs certainly use absolute units.

I want to say again that I love the CSS Zen Garden. But the main point of the site is not to highlight accessibility issues - it certainly can’t accommodate the WAI guidelines without a few minor changes and strict rules for the contributors. Although it *is* accessible, it can’t claim to be WAI AA, let alone AAA. Unfortunately.

Dave S. says:
December 04, 04h

Oy, it never ends. There’s always something else. Nothing personal Patrick, but nitpicks drive me crazy, and if I catered to every single one I’d end up taking the whole damn thing down.

10.5 was written in 1999 to cater to older screenreaders that then tripped up on adjacent links. It’s just about 2004. I’d imagine this to be an obsolete rule.

Assuming all designs have to be WAI-compatible is black and white thinking. I believe that if a site has one stylesheet that meets 2.2 and 3.4, then all others can use light grey text on light grey backgrounds, and 7px fonts for all I care, and still pass WAI.

I’m surprised you missed FIR, while we’re at it. That’s probably the biggest stumbling block.

December 04, 04h

I didn’t mean to ‘nitpick’, but should you not comply with something if you explicitly state you meet that standard?

I’m not saying it *has* to be WAI compatible, as you say, I am saying that it simply *isn’t* WAI AAA. A page with such a statement should comply - you can’t just have one compliant page and claim that for the whole site.

By your logic I could use font tags in most of my HTML pages and put a big ‘valid XHTML1.1’ tag on them. This clearly isn’t right. If we want to promote standards and accessibility we can’t pick and choose which bits of the standards we like. That misses the whole point.

Dave S. says:
December 04, 04h

Okay, since you’re walking the straight and narrow, suppose I take the notice off.

How do I communicate the degree of accessibility the Zen Garden accomodates? I can’t change the text at this point.

“Here boss, look at this site. Accessible design doesn’t have to be ugly.”

“Nice. But how is that more accessible than our site?”

“Uh… well, just take my word for it.”

If they even get that far, which most won’t.

Is the hit to awareness worth the purity in this case? Nothing else will make as big an impact as one-click validation.

December 04, 05h

I apologise if I have caused any ill-feeling. It was certainly not my intention - I thought it was a valid point. Maybe I am unnecessarily taking the hard line.

I do see your point.
‘WAI AAA’ is wrong but if such a statement can be exploited to deceive for the greater good, then yes, the accessibility awareness is more important than the purity. Although there is the side effect of confusing those new to accessibility when a well respected web design resource contradicts the guidelines it claims to adhere to.

If a designer were to choose to be hard line and accurate in such a situation though, they could link to their own accessibility statement, claim ‘Bobby compliance’ or simply something more vague such as just ‘WAI’.

Dris says:
December 04, 08h

I would have to agree that the accessibility rules are outdated.

I mentioned this once before, but here goes. The guideline for making every form input have a default value when the page loads is next to impossible for web applications, especially when editing old sets of data. If a field was left blank when a set of data was created, shouldn’t that be reflected later? It would make accessibility worse rather than better by causing confusion. You’d have to put an explanation to the tune of, “Fields which were left blank before have been filled with default text to comply with accessibility points. Please delete this text to return the values to their actual states.” Ridiculous.

The point I’m making is that the accessibility rules weren’t written with much of the future in mind. A lot of them were written to smooth things out for buggy browsers. The rule above is for old browsers which do not display empty text fields. This in mind, the current rules expect us in a lot of cases to make sites accessible to inaccessible user agents. In my opinion, if a user agent is inaccessible (a form rendering bug that bad would definitely mark it inaccessible), it’s the problem of the developer to fix, not the web designer.

Just another quick, extreme example. Let’s say a browser had a bug that caused pages without a DOCTYPE at the top to completely fall apart. Would they put that in the accessibility rules? “Until user agents are fixed to correct this, omit the document’s DOCTYPE.” Of course not.

I may sound unsympathetic to the end user who’s using said browsers, but since when do you see deaf people listening to books on tape? If a piece of software breaks something so badly for the user, it’s kind of their responsibility to change their software.

This has all been an elaborate scheme to justify my own omissions in my application of the accessibility standards. :)

Michael R. Havard says:
December 04, 09h

I would say that accessibility comes in three parts.

1. The underlying site html structure accessibility.
2. The css accessibility.
3. The scripting accessibility.

With 2 or 3 turned off the site should be accessible. So we might be able to call that WAI-AAA-1. Next level the site with 3 turned off is WAI-AAA-1.1 then highest level WAI-AAA-1.1.1. :)

or maybe we just put a little banner graphics that have different combinations like:

Javascript X

Each technology takes care of displaying it’s own level of accessibility and that way if you swap a compliant CSS file for a non-compliant or less compliant style - the style sheet itself lets the user know. Likewise with script.

I think, as stated before, so much of accessibility is about the user agent and the technology on the users end as much as it is about the HTML/CSS. We could very easily code some vanilla HTML/CSS/Scripting to be compliant in IE5 but what about IE2/3, SpyGlass Mosaic, WAP enabled cellphones, non-WAP cellphones, Windows CE IE, or someones homebrew aural browser that recognizes only HTML 3.2 and chokes on HTML4 tags and XHTML.

So in that way the WAI and Section 508 are a lot like interpretive dance. Some people are good at interpretting and it looks pretty and some people will try to interpret a little too far and leave others scratching their head.

I’d say at the base level zengarden is on the money, interpretively. With some of the CSS it remains so, with some of the CSS it doesn’t. It still retains the ability to revert to an accessible state - which does fit within the guidelines - because it’s the CONTENT that needs to remain accessible. So if I have 50 pages with the same content on it and each page formatted and catering to a specific accessibility issue haven’t I technically fullfilled the guidelines. Couldn’t a person with a particular accessibility issue cycle through some of the options on CSSZengarden and find at least one or more that fit their needs and kept the content readable?

Faruk Ates says:
December 05, 02h

I agree with Dris entirely. Esp. on the part where he says that the Accessibility rules are not written with the future in mind, not as well as they should have, anyway.

Another thing I want to point out is that in w3m (a basic text browser on unix) the CSS Zen Garden works flawlessly (with each design, as the CSS is omitted). I browsed the Garden in w3m which is grey/white text on black backgrounds, and it worked fine.

Michael says:
December 05, 03h

I know Patrick’s post was a nuanced response and was more indicating agreement than disagreement, but I still think it worth pointing out that when he quotes from Section 3.4:

“Use relative rather than absolute units”

he only quotes *part* of that section. In one of Dave’s earlier discussions here, I already pointed out that the Guidelines also *explicity* mention accessible designs that use absolute units:

“If absolute units are used, validate that the rendered content is usable.”

Yep: “If absolute units are used…” So you can.

And, so far as that goes, I sincerely hope that the Nielsenites are also taking the trouble to check that their “content is usable”.

The point gets a bit laboured. But it is an important one, because so many designers like and use absolute units, and I really don’t think the accessibility movement wants to go alienating designers on the basis of a *partial* reading of the WCAG.

Zeldman says it eloquently:

AkaXakA says:
December 05, 04h

Seeing how the Zen Garden is accesible with a black/white non graphical browser, it is safe to asume that the Zen Garden is indeed as accesible as it needs to be.

Throughout this argument, I’ve found that the general consensus is that the current WAI requirements are rather outdated and allthough very much backwards compatible, they aren’t really forward looking.

So, instead of debating whether it’s right to ignore sections of the WAI, wouldn’t it be more constructive to edit the WAI. Make it more forwards-compatible, and throwing out the ancient-compatible parts?

On a side note about using relative messurements:
The only time when it really matters is with the height of
horizontal navigation. That is the most commen mistake made with current sites, anyway.
Likewise, the width of vertical menu’s is also an issue, with it’s height coming in third.

Just try some websites using Mozilla/Safari and then zooming the text up quite a bit. You’d be surprised as how often it brakes up the page.

December 05, 05h

“Then your choices are all geared around the content and not anything about you. “

Don’t forget that content has it’s own identity, and that this identity hooks into our appeals and or our own prefered “Then your choices are all geared around the content and not anything about you. “

I can’t subscribe to this point of view. Don’t forget that content has it’s own identity, and that this identity hooks into our appeals and or our own preferred or projected image of ourselves. Content itself doesn’t do anything, it is us that makes the choice. We select the content that we believe that fits into our own identity, however real or unreal that identity may be.

A good website would reflect a certain identity of which the content is a part of. The choice of the user is tied into there own identity and that of the site itself. So if you chose a particular content then it has everything to do with the you because you identify yourself with that site and it’s content.

This has always been the case and is not something that will happen in the future because it happens everyday and is all around us. Marketing and Public Relations is not just some fad and so what I’ve mentioned isn’t anything new.

If ever we would want a giant aggregation of information it will have to be devoid of any context and identity. This will, in my view, never happen, and nor should it.

December 05, 06h

Yes my Zen Garden entry in one that breaks when text-zooming especially when viewed in MOSe mode, and I beleive I’m not the only one but I’ll stick to lambasting my own work for the moment. For example I use absolute units. Also the design itself is pretty poor when it’s come to usability. Colours and typography are complicated and text can be difficult to view. Navigation is also tricky because I make use of a homemade rollover effect.

Although such issues as accessibility and usability should be inclusive when building any webpage I chose not to reiterate my design to some level of compliance in these areas. In retrospect I do have some concern in being slightly flippant when it came to accessibility and usability.

The main point was to show off what CSS can do and this is the main priority of the Zen Garden. Any flaws should be not taken lightly but lets not forget the beauty of the Zen Garden, weeds and all.

AkaXakA says:
December 05, 07h

Egor, my comments about relative units are not so much about using them in design sites, but sites where information is the main point of the website should focus on making it scalable.

Which actually does bring me to your CZG design Egor, as it has massive waste of screen-estate. But I guess that’s a main part of the design. Still, it’s a really nice design and the rollover effect is really well thought out.

Michael R. Havard says:
December 05, 08h

I think I wasn’t perfectly clear with “At a basic level you have two choices for “what type of person are you” - Child - Adult. Then your choices are all geared around the content and not anything about you. “

Simply we agree on the matter.

Basically what I meant is that content in a library is categorized first by the type of person that would be using it (identity) and then secondly by a generalized category (fiction/non-fiction/reference) and then further categorized. So the content categorization doesn’t carry identity with it except to the point of the child/adult identity.

As you stated content has an identity and that identity isn’t something that you could categorize in the same way that you categorize library content.

For example I love science, poetry, cooking, art, and bad sci-fi movies. I could go into the library and decide to pluck out 50 books on those subjects. Most of them would be unappealling either for lack of good writing style, not enough imagery, too broad of subject matter, too narrow of subject matter, disorganized, etc. Maybe there are a couple that I find appealling because I can identify with the content, it resonates with my personality. But it’s not just the content, it’s also the visual aspect of that content.

So now we have the web and instead of identifying my likes dislikes maybe I can identify myself by a name that others use for my kind. Suddenly I’m opened up to a whole broad range of content that the previous system of categorization wasn’t able to identify. But today people are aggregating that content into blogs and newsites. Being a visually geared person I can then use CSS to style the content in a manner that befits me.

Michael R. Havard says:
December 05, 11h

Oh but Dave what’s more keen on accessibility than a library - the ramps, the large type/braille/audio books.

We can come full circle on this topic. :)

I think the original topic is correct in that the web does become more like a library. Notice how many sites are carrying the same content via RSS/XML feeds and aggregating them. Then they style them to look a certain way.

It’s kind of like being a kid and having a story book. The story books all had the same stories “Snow White”, “Swan Princess”, etc. And for the most part all the words were the same but I had my favorite book that had beautiful artwork along with the stories. The web can and is becoming something similar to that.

The benefit for the web is that the user has a lot more control over the library of information and how it can be presented. This means the audience can be much broader for a piece of information.

For example the team I work with has begun to collect all their technical information into XML format. They can then take that information and shoot it out to a non-technical format of summary information for the suits, or show it as a technical reference for developers, or mangle it into high level technical diagrams for the sysadmins and architects. The library of information is all there but the presentation method and styling is geared toward the specific audience.

Like today you go into a library looking for a book on farming. At a basic level you have two choices for “what type of person are you” - Child - Adult. Then your choices are all geared around the content and not anything about you. Maybe as the web attempts to engage people we’ll have information directed and categorized in relation to the type of user. Or styled visually based on their needs/whims.

Then someday we’ll have the encyclopedia interconnectica, where someone just does a giant aggregation and categorization of all information on the internet.

Anne says:
December 06, 02h

Triple A is _not_ possible, but I think Joe Clark has told us that before. Especially in CSSZG it is impossible, since there are too many different designs, where some have used px units which is against the specification.

Although it is debatable if that is a valid point of the specification, you can’t claim to be valid. As much as my website shouldn’t claim ‘valid CSS3’ :-), but ‘well-formed CSS’.

Michael says:
December 06, 03h

I didn’t know it had been suggested that it wasn’t possible, Anne; but that may well be true, depending on how the guidelines are interpreted, at any rate. (On px-sizing, see my earlier post above.)

But, of course, web design isn’t different from any other activity in life. Joe Clark has certainly pointed out that once I have colours at all, I’m unable to *guarantee* that those colours will not cause a problem for someone. But the guidelines advise me to use different font-sizes and different colours to aid reading comprehension for sighted viewers, which is good advice … and I have to do something.

I’m sure conflicts could actually arise between the recommendations made in different sections of the WCAG, though I’ve never specifically looked to see if they do. But again there is nothing new here. There are, for example, possible conflicts between the first and fourteenth amendments of the U.S. Constitution, as is shown here:

Philosophically, my view is that rules are actually an attempt to codify existing practises. People, particularly in modern Western societies, sometimes fail to see this and imagine that the situation is the other way round. But once you understand how the rules arose, you realize that what you actually have in a set of rules is a “digest” or “abridgment” of existing best practises. Guideline is the right word: what you have in a guideline is a useful guide, not something that can cover all concrete situations and not something to be taken more seriously than is warranted.

Roman says:
December 06, 07h

Off topic, I know, but your Zen Garden entry #064 doesn’t validate, btw.

zaptd says:
December 06, 09h

I can definitely see where using pixels to size a container might be problematic, and the WCAG guidelines definitely encourage the use of ems and percentages, but doesn’t the CSS 2.1 spec indicate that pixels are a relative unit of measure?

December 06, 12h

I agree with Patrick. Don’t claim WCAG 1.0 Triple-AAA compliance unless you’re, like, actually Triple-AAA compliant.

Triple-AAA is not easy to do. Let’s not spread the wrong message by saying that all that’s needed is CSS-based layout and suddenly you’ve solved all your accessibility problems.

The CSS Zen Garden is a masterpiece, and I use it in my Web Accessibility Techniques class as an example of the power of CSS to produce accessible designs. But please avoid the claims which can’t be supported. It’s great WITHOUT needing to claim AAA.


Michael says:
December 07, 02h

The same point is made here:

And the guy says, “… With this in mind, .px may be the most portable unit of measure across devices.” However, *currently* he prefers ems for fonts … because Microsoft’s current browser handles px-sized fonts inadequately.

But I suspect that the WCAG don’t mean “relative” in that sense, and the terminology seems confused as the keywords, which behave in most ways like px, are called absolute-size keywords:

Maybe I’m missing something.

By my reading, the guidelines are less interested in what is relative to the viewing device - and this is why they sidestep around pixel-sizing. I think the guidelines imply that their framers prefer (but don’t insist) that an author use units relative to *any setting that a user is likely to change* (e.g., width of a window).

I think they think this gives the user more choice and more control, but I think they’re wrong.

For most of us, if Microsoft replaced their browser, px would look like the obvious choice. But not for Todd Fahrner, nor I suspect for WAI, because … well:

I think it’s a brilliant essay, but it is written totally in l’esprit de geometrie not in l’esprit de finesse.

I really can’t set “my preference” in the browser settings, because there “size” means the height of the font, although fonts have width, too. And even “height” is something of an abstraction, because different fonts have different aspect ratios:

Yes, OK, I’ll take 16px Times. No, thank you, I don’t want 16px Verdana. So “my preference” matches my preference *some* of the time, and some of the time it doesn’t. And this is even before we start asking more concrete questions about the amount of text on a page and the particular page layout, etc.

I think WAI wants to lighten up a bit, but what do I know. :-)

Alex says:
December 07, 10h

I apologize for the interruption, but…

Looks like they’re at it again:

December 08, 08h

View source on that zensmile site, it’s table based. Looks like the point of the Garden was missed by this individual. Ha!

jgraham says:
December 09, 07h

Wouldn’t a lot of this discussion be much better on the WAI pulic mailing list? As fun as it is to have discussions about the shortcomings and difficulties of the guidelines here, it’s pretty unlikely that this discussion will be fruitful in the sense that it won’t change the next versions of the guidelines to better serve the needs of the web/design community. For example, would it be possible to mark out a subset of the spec that can be automatically validated for a particular site and produce a compliance badge relating just to this subset?

Dave S. says:
December 09, 09h

jgraham - partially moved. I’d have mentioned this earlier, but I guess I posted to the wrong list the first time.

(10.5 is the only issue I deem a limiting factor; as explained above, font size and colour combinations are on a per-design basis, and since there are so many to choose from, I don’t believe it’s as relevant)

Michael says:
December 10, 08h

I happened to ask Gez Lemon of Juicy Studio ( ) about this recently. I asked if I was right in thinking that the requirement for more than whitespace between links related to a bug in some versions of JAWS. I also asked: “if someone does that [uses list markup] do they need to hide this CSS -

#navigation ul {
   padding: 0;
   margin: 0;
   list-style-type: none;

- from JAWS using the @import hack?

He said: “I’m not familiar with versions of JAWS earlier than 4.51, so you may be correct. I’ve tested your CSS through the link element with JAWS 4.51, and it announces, “bullet” before reading the link phrase.”