Category Archives: Web Standards

What constitutes a good website?

Dear readers, friends and fellow web creators, I need your help. I would like to ask for your suggestions in the form of comments to this post.

The problem is the stigma attached to the term “accessibility”. Now we know that web accessibility achieves more than simply facilitating access to web content. But a lot of government organizations and businesses don’t see the need to even try and conform to accessibility guidelines.

As part of a group of organizations (the advisory group for the Dutch Web Accessibility/Quality Guidelines) concerned with changing this way of thinking, several of us are trying to compile a list of themes/categories/factors which can be considered building blocks of really good websites, or less-obvious benefits of accessible websites. I’m aware of many, but lots of people in this industry are so incredibly smart; it would be such a pity not to ask.

So I’m asking! The idea is to create a list of things like “interoperable”, “search-engine friendly/findability”, “archivable” etc. to help convince government organizations and businesses that there are lots of non-obvious benefits in conforming to web accessibility guidelines. “Cuts down on bandwidth usage” is fine. I’ll parse the list and try to group like-minded suggestions together to come up with some high-level themes. I will post the results and link to any known follow-up usage or derivative of the resulting list.

Even if you can only think up one thing, please add it to the comments! Ask your friends (but don’t spam :) ). Don’t worry too much about accessibility, just quickly note whatever you think makes a great website.

Care to chip in? What constitutes a good website?

Coping with CSS vendor prefixes

Peter-Paul Koch drops a PPK-bomb on CSS vendor prefixes, the latest post in what seems to be a series of rants which get everyone thinking and talking: not necessarily agreeing. But if you know PPK, then you know that’s probably not the point.

You should read the post. Then form an opinion. Mine is that vendor prefixes are no fun and quite annoying, but a necessary evil. At least for now. There’s no need for me to go into why, as Jonathan Snook makes the point well.

My biggest problem with vendor prefixes is the repetition (read: not the amount of typing), and the fact that I’ll one day need (okay, want) to go back and clean prefixed rules up once they’re no longer necessary or when the implementations change, which they can. I just want a clean style sheet.

A few workarounds, or deal-withs, were mentioned in the comments of the aforementioned posts:

  1. A single “beta” prefix
  2. CSS preprocessors
  3. A separate style sheet

I like the last option the most, hat tip to Bridget Stewart for beating me to it. A separate style sheet fits my current practice of giving each element of design language its own file (I know about the performance implications, but there are plenty of solutions to that). So a generic group of style sheets for a given website might look like this:

  • layout.css
  • type.css
  • color-img.css
  • vendor.css
  • ie[x].css

This is clean. Non-prefixed properties are entered into the normal style sheets, and will (hopefully) be ignored by browsers which don’t understand them. Prefixed properties are placed in vendor.css. And what I would really love is for CSS3, Please! to generate vendor.css for me (That was a hint, guys). Sure, there’s the risk of the spec changing, so it’s up to the designer/developer to be wise in deciding which things should be specified without prefix in the normal style sheets.

Why not the other two?

To be honest, something like -beta- might not be a bad idea, but as of yet, the fact that vendor prefixes are browser-specific is the only useful thing about them. A universal prefix is just that, universal, which could potentially introduce the same problems we would have with no prefixes at all.

I’m not a big fan of CSS preprocessors, or at least I haven’t seen one I’ve liked. We’re talking about CSS; it’s not all that hard to deal with. My problem is not with typing things out three or four times. And I don’t need a preprocessor to do that for me, as prefixes and things like rgba fallbacks are easily accomplished in any decent editor through snippets or scripting. And for those without a decent editor, just use something like CSS3, Please!.

How do you cope?

You only need to subscribe to www-style for about a week before realizing it’s going to take more than three people calling “-beta- prefix!” to get browsers to do it. When you dig down deep enough, there are some very, very smart people who have thought a lot about certain things (and admittedly less about others). It would be a good practice to research or ask why something is as it is, and perhaps participating in www-style and submitting ideas.

You could also try vendor.css. If you hate prefixes, at least you’ve gathered them all together in their own little prefix hell.

How do you deal with vendor prefixes?

Dutch translation of WCAG2 in public review

The Dutch translation of the Web Content Accessibility Guidelines (WCAG) 2.0 went into public review on November 2, 2009. It will be in review for 30 days. If you are Dutch (or are fluent in Dutch), and especially if you have knowledge in web accessibility, web development or web technologies in general, you might consider taking a look and submitting your comments. Everyone is welcome to participate.

I’m assuming that readers of this website are at least vaguely familiar with the WCAG. If not, you can read more about them on the WAI website, as there is no reason to repeat that information here.

26 organizations worked in varying capacity on this translation, including Cinnamon, represented by myself. The translation was coordinated by Stichting Accessibility, and follows the official procedure for authorized W3C translations.

After the review period, this candidate translation will be modified where necessary. It is expected that a finalized version will follow in December 2009. The current draft is not the finalized version, and may not be published as such.

Please help us review!

If you would like to review, you’ll need both the original English version as well as the candidate Dutch translation. Please send all comments to

Please note that the review is intended to ensure the correctness of the translation. The actual content of the draft will not be changed.

Please help out if you can! If you can’t review yourself, perhaps you can spread the word about it.

A Dutch-language press release is available (PDF, 72kB).