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?

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?

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 public-auth-trans-nl@w3.org.

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).

It’s for this reason that Eend and Cinnamon have spent a lot of time putting together a workshop which we feel will help clients, their project leads and/or managers to get the best out of the web shops they hire. The two-day workshop has been designed to expose clients to the potential success factors and pitfalls on their side of the project, and to give them the tools to use this knowledge to their advantage. The entire project process from bidding to post-launch evaluation will be examined. We’ve got great speakers with very high-level, client-side web project (management) expertise, as well as a few on the development side for a well-rounded whole.

Grip—or rather Grip2009, as this first workshop is called—will be held on November 17 and 18, 2009, at the very posh (no, not that POSH) Grand Hotel Karel V in Utrecht, The Netherlands.

While there are plenty of workshops and conferences for developers on building better sites, there is little practical information for clients on how to ensure a successful web project. We’re excited about Grip2009. We hope it will give clients the tools they need to engage with their web contractors like never before.

Unfortunately, this first edition of Grip will be completely in Dutch. We haven’t ruled out an international (English) event for the near future.

For any Dutch readers, here’s the press release (feel free to distribute):

BEGIN PERSBERICHT —

Grip2009 – Tweedaagse workshop voor webprojectleiders

Op 17 en 18 november 2009 wordt in Grand Hotel Karel V te Utrecht een tweedaagse workshop voor opdrachtgevers van webprojecten gegeven: Grip2009. Het programma is samengesteld door ervaren internetprofessionals en levert, naast nuttige tips, bruikbare kennis en vaardigheden uit de praktijk om grip te krijgen op webprojecten. De nieuwe workshop, die dit jaar voor het eerst wordt gegeven, richt zich op opdrachtgevers die hun internetprojecten beter willen begeleiden.

Voor opdrachtgevers van webprojecten bij het bedrijfsleven, not-for-profit-organisaties en de overheid is er momenteel weinig concrete en in de praktijk bewezen informatie beschikbaar hoe deze projecten tot een succes zijn te maken. Dat verandert met de komst van Grip2009. De workshop is bij uitstek geschikt voor mensen die aan klantzijde betrokken zijn bij de inkoop, de ontwikkeling en het beheer van internetprojecten, of mensen die een carrièrestap overwegen in deze richting.

Er zijn maximaal 60 plaatsen beschikbaar voor dit unieke evenement. Snelle beslissers kunnen tot 16 oktober profiteren van een flinke korting. Meer informatie vindt u op: www.grip2009.nl

EINDE PERSBERICHT —

As with any usability or accessibility guidelines, there are some myths which keep rearing their heads. These myths came to be in the minds of clients, mostly because because of what these clients have been told by hack, unprofessional front-end developers. You know, the kind who design websites based on what their framework or CMS is able to handle in its more or less standard form; god forbid these developers should know the faintest thing about decent markup. I’m tired of hearing what’s not possible within accessibility guidelines, especially when it’s simply untrue.

We’ll be talking about that.

For the Dutch among you, read more on the Zinformatie website.

Jeff says that never having to touch the markup, and only having to adjust the CSS for a redesign, is a myth. With this, I agree. If I’ve said it once, I’ve said it a million times: design is not decoration. So while I agree that most redesigns will involve changing markup, I disagree with the underlying premise that a redesign is a purely visual undertaking, and I disagree with the whole idea that one should never have to touch the markup. Which law is that? I would encourage anyone thinking that content/presentation separation or semantic markup (two completely different things) means that you’ll only need to change the CSS, to challenge this thought. They’re missing the point. This type of thinking reduces design to simply mean decoration. I didn’t study decoration for four years. My clients’ websites aren’t MySpace. We’re not skinning here. Since markup is structural, changing the structure of a design will certainly demand markup changes, and there’s nothing wrong with that.

Which brings me to CSS frameworks. Hmmm. Building a site so that you “only” need to change the CSS. This is pretty neat from a geek standpoint: can it be done? Is my framework better than your framework? But in reality, these CSS frameworks dictate to a certain extent how you’ll set up your structure. But shouldn’t the content dictate that?

Structure and meaning

The separation of structure/content and presentation is meant to manifest itself to the end user, not to the developer. When a site is stripped of all visual elements, the structured content of the site should still be accessible to the end user. There are two kinds of structure: document structure and visual structure. Document structure is the structure of the content itself. Visual structure is the physical structure of a page. We can distinguish these elements from each other through the use of semantic markup.

Semantic markup is all about meaning. When I say something is an “attention block”, I know what that means. Most importantly, fellow or future developers can figure out what an attention block is fairly quickly, even sans documentation. I can distinguish an attention block from an “urgent block” semantically, as opposed to only visually. But with all due respect to Jeff and others, what the hell is a span-4 or a pull-2? And how does this help future developers? Colleagues when I move to another company? Or portability, when the client wants a DocBook PDF of the entire site?

The new WYSIWYG

CSS frameworks are a nice idea, but they introduce the same problems the JavaScript frameworks or app/CMS frameworks introduce: they try to make things easier for the current developer, and in doing so make it terribly easy for less-experienced developers to create terribly scary, unruly HTML and CSS, while they don’t yet fully understand the basics. Sound familiar? Isn’t this the exact reason we hate WYSIWYG editors? Could CSS frameworks perhaps be the geek equivalent of WYSIWYG? With most frameworks, you must first get to know the framework if you want to work with it effectively. But we already know HTML and CSS. So what happens when client X asks me to do a redesign of site X, which uses CSS framework X? I either have to learn how framework X works and rework the site that way (focusing on implementing new elements using the framework, which will translate into costs for the client), or I’ll have to rebuild the whole thing. Rebuilding the whole thing is very tempting, because restrictions will be removed, and I can approach the site based on content, structure and visual design using the very basic tools of semantic HTML and CSS. The site will be portable and maintainable: anyone knowledgeable in HTML and CSS can maintain it; semantic markup is understandable markup. The site will be fairly future-proof, independent of framework version changes.

I’m not saying that frameworks are bad, but I challenge the reasons often given for using them. I consider them mainly beneficial to the initial developers. I also challenge any excuses designed to defend the discarding of semantic markup. I just don’t buy that span-4 and pull-2 are necessary. You have to use class names anyway, why not make them meaningful?

Use CSS frameworks if you will, but really consider your reasons for using them. Weigh the pros and cons. Not only for yourself, but for the site, the end users and your client, which also means future developers. Think about portability. Think about the fact that visual design is not simply decoration. Consider that visual design and document structure, although separated for portability/durability and the accessibility to the end user, are in fact inseparable.

As designer Paul Rand once said, “Design is a method of putting form and content together”. Our methods should involve embracing and strengthening this relationship, instead of working against it.

One of the article’s comments brings up an interesting point. While I don’t own a large company, we do serve some very large clients. And one thing I’ve learned from them is something anyone who sells anything could probably tell you: if you want to sell something, whether it be a product, a service, or an idea, you’re best chance is to first speak the language of the person to whom you’re selling. Once you’ve done that, you need to show the buyer what’s in it for them. At big companies, it’ll usually come down to the subject of money.

Peter-Paul makes an interesting point. Developers at big companies speak the language of other big-company developers. They have different work environments, often high-stress and high-profile projects, and they often work on one aspect of a project (e.g. only HTML/CSS/JavaScript). While this could be a great first step, we need to remember that getting large companies to embrace web standards will not only involve convincing the developers, but also the management of these companies. What’s in it for them? How’s this stuff gonna make them money? Got your pitch ready? Sell it.