Just got that email:


I would like to invite you to promote yatil.de on search engines
by participating in free automatic link building system – [REDACTED].


This email was sent after finding your site on Google.

So, if you find my site via google, why should I care about your service that makes me findable via google?

What annoys me the most about the Discussion about Chris Heilmann’s talk at A-Tag in Vienna is not only that Chris doesn’t want to speak at German accessibility events at all anymore, but the claim that Chris is solid against any laws. That is not what he said.

His point was that accessibility in the real world can only be so good or average as the developer and designer knowledge is. If a designer/developer is suddenly in charge to provide an accessible website he will look for a way to archive that goal with as little effort as possible. This will lead to accessible websites but badly designed ones. Additionally there may be problems with jump links which are hidden with display: none and other oddities (like text-only versions etc.).

Of course we all think: Such a person should never be in charge to make a website (as, to my understanding, we aim that all websites are accessible, right?) – but then 90% of web developers needed to change jobs, and we’d get only two websites a year online as those few agencies who do accessible websites can’t cope with the demand.

The other problem is that law hinders progress. German law, which is a (not compatible) reformulation of WCAG 1.0 prohibits the use of any scripting and other non-standard techniques. That means no youtube, even embedded on a website even if the video is completely subtitled and accessible. The accessible youtube player is nice but not allowed. WAIARIA techniques: not allowed.

The problem: German law is very old (2002), but it was also amongst the first to even implement a law about web accessibility. The now so often cited PAS78, the British accessibility law, is from 2006. And it is not undisputed either. We have to see how fast that really gets updated, the German law is about to update as well.

And then there was the claim about “eleven years of education and nothing changed, we need thumbscrews”: This is not true. Layout tables are in general gone, federal websites are accessible and even websites that are not required by law are generally better accessible. I wish that all websites are required to be accessible, but that isn’t possible as it seems. Even disability associations don’t bother to fight for it, which is the real scandal here.

There are a few tasks that a good accessibility law should do:

  • Create awareness. Only if there is awareness in companies, they will give developers time to be educated and do great stuff.
  • Do not create a climate of fear. If you have to fear that you are sued, because you made a mistake you’ll get conservative and lethargic. This shouldn’t happen as the web and accessibility technology is getting better and better every day.
  • Create mediations. If there is a problem with a website people should come together and talk (first), not sue. That works quite well in Austria. Mediations are often a lot cheaper than trials, too.
  • Reference international standard. WCAG, whatever version is current. Austria does that as well, so immediately after WCAG2 were out, web developers were required to use that. This creates again a climate of education. Germany copied WCAG1 and made that a regulation which is now outdated for over a year.
  • Be inclusive. There is no reason why public and private websites should be treated differently, so don’t.

We need laws, but we need good laws, not outdated ones. The myth of the flexible law is exactly that, a myth.

About 6 months ago I tweeted some steps for really good web sites with progressive enhancement. Those tweets aren’t available via the official Twitter search but I’ve just found them in my Tweetstats. Just click #petweet and you’ll see the original 6 tweets. Here I’ve added and clarified some points.

  1. You need to know your content first. Real content, not the Lorem Ipsum kind of content that will later out of the sudden be some kind of rich text with images and stuff.
  2. Get an overview on the different templates, identify reusable elements and make them reusable: use classes!
  3. Add exceptionally good HTML. Think about every part of the site, use the most appropriate elements, don’t get too distracted. Use table for tabular data. Keep it simple. And then simplify some more!
  4. Add CSS. Start your CSS with the basics: reset, fonts, positioning. Try not to add more elements to your HTML only because you think it can’t be accomplished with the existing structure. Often it will work and you saved not only some bytes but even more on maintenance cost.
  5. Test regularly across targeted browsers. That is important. Start your working day with an hour of browser testing, at least use some screenshot tool to look for breaking layouts. Do not fix them immediately, just note them down. If you get back to that element during the day, fix it then or as a wrap up at the end of the day. (You will feel in “got things done” mode when you leave the office!)
  6. Adding bells and whistles for real browsers, so IE7+ and the others, a website doesn’t have to look the same in all browsers, but it should at least be a consistent look and feel. If something is not supported by a browser use default fallbacks. If the fallback is not working as intended, add the feature only to browsers who support it.
  7. Use shortcuts. You don’t get paid for reinventing the wheel every time, so don’t do it. Use a JS library to get around inconsistencies in browsers and use a CSS framework if you know it very well. Typically you’ll create a flexible framework for each project and you’ll learn which parts work and which to reuse. Different projects need different approaches.
  8. Be accessible. Every part of the web site has to be accessible even if there is only the raw HTML code rendered. Everything can (and will) break, so be sure that the content is accessible. If non-targeted browsers like IE6 get something wrong, you can rely on your existing HTML structure and hide the JS from the browser.
  9. Deploy, Enjoy. (Okay, that isn’t really a guideline ;)

One reminder: You may want to backup your important data regularly, probably with time machine on the mac or with Dropbox. You may also want to use at least a local version control system like GIT or SVN to track your progress.