Yesterday I was speaking at my first Ignite event at Frankfurt/Main. It was a special edition of the Webmontag which happens at the Brotfabrik every two months.

“Fast-paced, fun, thought-provoking, social, local, global—Ignite is all of these and more. It’s a high-energy evening of 5-minute talks by people who have an idea—and the guts to get onstage and share it with their hometown crowd. Run by local volunteers who are connected through the global Ignite network, Ignite is a force for raising the collective IQ and building connections in each city. And, via streaming and archived videos of local talks, local Ignites share all that knowledge and passion with the world.”

I had a lot of fun with my talk and the other talks I’ve seen. I had to leave the event early, to get back to Essen, during the break, but I’m sure the other talks were great, too.

My talk was about web accessibility basics, here are the slides:

The video and transcript will follow, when released by the Ignite Frankfurt team.

Images by ScreenOrigami and patricklenz on flickr.

Just got that email:

Hi,

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. WAI-ARIA 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 sill 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 new 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 some 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 to track your progress.

To wrap this up, there will be an online publication which moves along those lines some time in spring 2010, follow me on twitter (which is mostly German chatter, I know) for the latest news.

CSS expert Eric Meyer is releasing a series of articles providing feedback on CSS3 for the Web Standards Project. Every article is as you’d expect a good and insightful read. In the latest part of the series Meyer writes about the need of a layout sys­tem in CSS:

“How do we get those abilities in a form that im­ple­men­tors will, y’know, im­ple­ment? I don’t know. I don’t care. We just need it, and have need­ed it for a good decade or so. With­out it, CSS is a styling lang­uage but not a lay­out lang­uage. We’ve bent it into being some­thing close to a lay­out lang­uage, which is nice but not really ideal.”

Un­surprisingly Meyer is right. We are using stop gap solutions for layout since the beginning of the web. Tables for layout — stop gap solution. CSS float — stop gap solution. CSS position­ing — stop gap solution. CSS tables as well.

All CSS solutions work great for certain tasks. Floats are a great con­cept, position­ing and even CSS tables (beat me!). But they don’t fit together in a usable way. We are tinkering those bits and pieces together, struggling be­cause it’s com­pli­cated as hell as those pieces where never deve­loped for the use case of com­plex lay­outs.

CSS layouts are the best solution out there, but they are far from perfect.

We need a new approach to layout on the web. An easy to use solution with maximum flexibility has to be de­ve­loped, inside or outside the W3C, in­side or outside CSS, it does­n’t matter to me. We are waiting far, far too long for a good solution.

And we don’t need it on a piece of paper or in the mind of some de­ve­loper. We need it im­ple­men­ted across browsers as fast as possible and as good as possible. It can’t be more difficult then supporting all those half-arsed solutions that are out there.