Pro tip: communicate to the client that shadows are a bonus feature. Your designers may disagree, but the site will not suffer considerably when special effects like box shadows, text shadows, or rounded corners are regarded as enhancements for decent browsers. However, your client’s budget will suffer when they are determined to provide the same visual effects on outdated browsers such as IE6. That said, here is the well-known method in CSS3:

1. .wrapper {
2. background-color: #fff;
3. border: 1px solid #d30d01;
4. box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
5. float: left;
6. height: 75px;
7. margin: 15px;
8. padding: 10px;
9. width: 75px;
10. -moz-box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
11. -o-box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
12. -webkit-box-shadow: 4px 4px 4px rgba(0, 0, 0, 0.2);
13. }

1. <div class="wrapper">
2. <p>CSS box-shadow</p>
3. </div>

At the same time when we rolled out the website, Robert Nyman came to the conclusion that the proprietary Microsoft filter for Shadow looks much prettier than DropShadow, so I forgot about blogging myself as his solution doesn’t rely on unsemantic markup and is more elegant:

1. .wrapper {
2. /* For IE 8 */
3. -ms-filter: progid:DXImageTransform.Microsoft.Shadow( Strength=5, Direction=135, Color='#999999' );
4. /* For IE 5.5 – 7 */
5. filter: progid:DXImageTransform.Microsoft.Shadow( Strength=5, Direction=135, Color='#999999' );
6. }

Note that you get slightly better effects when you choose a dark gray instead of black as shadow color. If you can live with the rendering of the third box below, don’t read any further.

However, applying the filter had the side effect that text inside the box wasn’t anti-aliased in IE 6-8 anymore, and the shadow still didn’t look decent enough. So we added an extra span and applied the blur filter on it.

That led to a more complex code as we needed an inner wrapper where the border and background is applied to, while the outer wrapper merely acted as a … wrapper, where the styles were reset to defaults. HTML first:

1. <div class="wrapper ms-box-shadow">
2. <div class="inner">
3. <p>Internet Explorer with blur filter</p>
4. </div>
5. <span class="shadow"></span>
6. </div>

And here’s the CSS that’s added with Conditional Comments for IE 6-8 only (as IE9 supports native CSS box-shadow, more or less). The shadow element is absolutely positioned, set behind the inner content and blown up to 100%. Not original, but it works:

1. .wrapper, .inner {
2. background-color: #fff;
3. border: 1px solid #d30d01;
4. height: 75px;
5. padding: 10px;
6. position: relative;
7. width: 75px;
8. }
9. .wrapper {
10. float: left;
11. margin: 15px;
12. }
13. /* reset wrapper styles to defaults; work-around for screwed box-model */
14. .ms-box-shadow {
15. background-color: transparent;
16. border: 0 none;
17. height: 95px;
18. padding: 0;
19. width: 95px;
20. }
21. /* Move the inner wrapper to the foreground */
22. .inner {
23. z-index: 50;
24. }
25. /* The shadow element */
26. .shadow {
27. background-color: #000;
28. display: block;
29. filter: progid:DXImageTransform.Microsoft.Blur( makeShadow='true', pixelRadius=4, shadowOpacity=0.30 );
30. height: 100%;
31. left: 0;
32. position: absolute;
33. top: 0;
34. width: 100%;
35. z-index: 0;
36. }

For some reason I got a more similar result with the shadowOpacity set to 30% instead of 20%.

Where’s the crux?

If we are willing to ignore lots of bloated CSS: IE6 only blows the shadow up to 100% when the wrapper has a fixed height. This sucks, but unless you want to add more bloated code in JavaScript I don’t know of any solution for this problem. Still IE 7-8 handle a value of 100% right, and there are many cases where the height is known. Take for example photos where you’d like to apply shadows, some buttons, or horizontal shades lying above images, like the shadow of the second level navigation on this site. Beautiful, isn’t it?

First I talked about the term of disability in a changing social and political context, then I lead to the demographic trend, hence to accessibility as an economic imperative. I showed a few barriers and techniques in practical examples as “virtual wheelchair ramps” and ended with an outlook on the challenges we currently face in the W3C HTML Accessibility Task Force.

The slides are currently available only in German at Slideshare where they can also be downloaded (15 MB). I will further adapt the slides and translate them for a Mozilla P2PU course in September, I appreciate your patience. There are also notes in the powerpoint file for a more detailed description.

But the story continues: beginning in the winter semester I’ll have a lectureship once a week at the university, teaching organic frontend development with contemporary techniques.

The goal of web performance optimization is to become faster and smaller: research at Yahoo! and Google found that just 10-20% of the perceived loading time is caused by the server. A few years ago we thought performance was exclusively connected to the server. However, 80-90% of the loading time incurs in the frontend. Thus WPO is more efficient targeting the frontend.

Two important weak points are JavaScript files and the sheer number of files: JavaScript loads sequentially and blocks subsequent code until each file is loaded. Hence it shouldn’t be located in the head, but in the foot of a page. Secondly older browsers, in particular Internet Explorer, will only load 2-4 files in parallel. Files queue up and get processed when it’s their turn. Therefore aggregation of files is used for reducing the number of HTTP requests.

Several international companies have conducted research or just tracked the effects of optimization.

Effects of slowness

• Amazon: 100 ms delay caused a 1% drop in revenue.
• Google: 400 ms delay caused a 0.59% decrease in search requests per user (earlier tests list larger numbers).
• Yahoo!: 400 ms delay caused a 5-9% decrease in traffic.
• Bing: 2 seconds delay caused a 4.3% drop in revenue per user.

Effects of speed

• Mozilla made their download page 2.2 seconds faster and was rewarded with an increase of 15.4% in downloads.
• Google Maps reduced the file volume by 30% and observed a 30% increase in map requests.
• Netflix enabled gzip on the server; simply by this single action pages became 13-25% faster and saved 50% of traffic volume!
• Shopzilla succeeded in reducing the loading time from 7 down to 2 seconds, whereby the conversion rate increased by 7-12%, they observed a 25% increase in page requests, they were able to retire 50% of their servers, thus saving energy costs.
• AOL observed the number of page views on several websites. While the fastest users requested 7-8 pages, the slowest only viewed 3-4.

As a cream topping Google recently announced to factor in the site speed as a parameter in web search ranking.

Eventually pages become faster, clients are happy, generate more revenue and page views, while power consumption and CO₂ emissions decrease. Saved the world, again! And if you’d like to contribute, start by checking the rules at Yahoo! A few tricks beyond that can be found in the presentation which will be translated soon.

1. What are the issues of accessibility in HTML 5?
2. What is the canvas element?
3. What is the difference between video built in natively in the browser or provided through a Flash plugin?
4. Why are people in the HTML 5 working group so nasty to each other?
5. Why is accessibility important in an emerging standard?
6. Can’t accessibility be added later?
7. What is the state of support of HTML 5 in browsers?
8. When can we start to use HTML 5?
9. What can geolocation do for accessibility?
10. Does assistive technology support HTML 5 features?

So please vote for it now, and while you’re at it, show your love to some other accessibility and web standards proposals as well. </thxkbay>

The rules: a haiku “is a form of Japanese poetry, consisting of 17 moras, in three metrical phrases of 5, 7, and 5 moras respectively.” I think it’s legitimate for the sake of simplicity to translate “moras” with “syllables.” A reference to a season or nature is a bonus.

A crude example, my Japanese readers may forgive me:

Show us the studies /
says hixie, experts shout fail. /
It’s about people.

And another:

For assistive tech /
canvas is invisible /
like tears in the rain.

So here is my challenge: twitter a haiku about HTML 5 and tag it with #html5haiku. There aren’t any prizes yet apart from the innocent fun of participation, but perhaps somebody would like to donate something?

The main idea is to present leading innovators and their perspectives on eAccessibility from the technical, political, and economic side. Experts on seven panels will briefly describe their own work and their view of accessibility and then discuss the issues.

There’s an illustrious line-up of speakers including Deutsche Bahn, the European Commission, France Télécom, the German Federal Ministry of Labour and Social Affairs, Google, IBM, Microsoft, Mozilla, Opera, the W3C, the Web Standards Project, and Yahoo! talking about these topics:

• Accessible Web Applications
• Mobile Access — Device-independent or Accessible?
• Comparison of National Accessibility Guidelines
• Accessible Rich Internet Applications (ARIA)
• Web Standards and Accessibility in Higher Education
• Harmonising European Accessibility Guidelines
• The Business Value of Accessibility

If you have been following my posts in the last two years this will sound slightly familiar. Furthermore I’m honored to have Linda Mauperon, Member of Cabinet of the European Commissioner for Information Society and Media (Viviane Reding) as our keynote speaker. Please see the detailed description of the panels in the conference program.

We would like to take a look on accessibility from different perspectives presenting pioneering thinkers whose organizations have established accessibility in their business and communication long since — and making serious money with it. There should be something of interest for everybody among the topics: for techies, consultants, employees from universities and companies. The conference is limited to a maximum of 200 attendees. Registration opens next week.

Of course there are various gems under the hood of the website, too. Naturally it is extensively accessible (check the cool skip links), but it is also incredibly fast because Yahoo!’s best practices for frontend performance are regarded. There are separate style sheets for printing, for iPhones, and for handhelds. The CMS is WordPress µ, having the advantage of administrating both the English and the German version with the same installation.

You can see and download the slides at Slideshare (German). As I promised to write a detailed post about ARIA enhanced tab navigation for the Webkrauts web standards advent calendar (think of a German version of 24 ways) you will be able to enjoy an English tutorial soon. Never mind the references to Chris in the slides — I had to choose an example from my flickr pictures, and I believe there are too many presentations already with kittens.

The conference was surprisingly innovative: I half expected a crowd of suits as the event was co-organized by the Austrian Ministry of Health, Family and Youth, instead there were many young faces and a fair percentage of women. Things I have learned (and tweeted about) include:

• As of January 2009, websites sponsored by the Austrian Ministry of Health will only receive funding when they are accessible. That doesn’t come as a surprise as a European Ministerial Declaration in 2006 announced that accessibility and best practices could become mandatory in public procurement in 2010.
• Artur Ortega showed examples of Dirk Ginader’s accessibility features for Yahoo! Finance, including two input fields where the labels were dynamically updated after a currency was chosen. So a screenreader read “convert pound sterling to euros” instead of “convert currency to currency.”
• One reason for JavaScript enhanced HTML controls for Flash objects like Yahoo! video is that the Flash object cannot get tab focus when the wmode param is set to opaque or transparent. Still without that param it is impossible to tab into a Flash object in Firefox 3. Or did I overlook something?
• Designer Maria Putzhuber quoted an interesting delusion: 70% of designers believe that visitors are almost always able to maintain orientation while in fact just 10% of the visitors are able to achieve this. What do you think is the reason?

Deutsche Fassung

Other conferences

The next geek meeting held in Frankfurt will be the Webmontag (Web Monday) on September 1st where I will give my presentation about canvas a short test drive.

A few days later on September 4 I have the honor of the opening talk at the Web Congress at the University of Erlangen, again about canvas, only this time a full hour.

On September 25 there’s the Best of Accessibility Symposium in Düsseldorf where I hold a workshop about hands-on ARIA (you recognize the pattern?).

On October 10-11 an internal namics conference called T-Camp is held in Basel, with my colleague Alex Stirn and me speaking about Professional Frontend Engineering.

A conference I’m looking forward to because of the many experts attending and the fair prices is the A-Tag (Accessibility Day) in Vienna, Austria, on November 21. Again I will sing praises of ARIA. This innovative technique can’t be evangelized enough! There’s no website yet for the A-Tag, but I’d recommend to book your journey well in advance to catch the inexpensive flights to Vienna. The conference itself cost only € 35 last year is free because it is sponsored by the Austrian government.

If you happen to be around, don’t hesitate to speak to me.

I started my conference program with a case study by the BBC. They did a redesign and managed to squeeze formerly 60 images into 3 sliding doors and sprites. Their home page is now under 300K and 30 HTTP requests. Nice to see Yahoo’s Exceptional Performance guidelines go mainstream. About 5% of their users access the site without JavaScript. They don’t get identical features, but they get identical care. For them accessibility isn’t a buzzword, it’s become a natural part of their daily work. So they were able to find out that blur() is not a friend with JAWS. Also the BBC plays well with the other kids: they joined the OpenID foundation, and with BBC backstage they open their content through an API. Another charming idea is their public beta where people can testdrive new features. About 60% have personalized their home page, although one of the speakers described the personalization features with “my mom’s head exploded.” They used agile development with 2 week sprints, run the website in 12 languages, but don’t have a CDN yet because of the license fees.

Another case study about the LOHAS community Edenbee wasn’t that exiting, mostly because I knew the platform since beta and didn’t get quite why I should speak with other people about changing their lightbulbs. But it’s nice to keep track of your carbon footprint, a feature that uses the AMEE open API.

I was curious about HTML 5, so I went to the presentation of Lachlan Hunt and James Graham. Still I don’t see any advantage of having a bunch of new elements that are incompatible with older browsers when I can achieve the same with ARIA attributes. But I understand the rationale behind some of their decisions, although that doesn’t mean I come to the same conclusions.

For example people use a lot of “nav” and “menu” classes. To make their live easier, the WHATWG came up with the idea to create a nav element. A block level element, so you wouldn’t have to use those <div class="nav"> any more. But every time I use something like class="navigation" it will be an unordered list! I don’t need another div, I’m perfectly happy with my ul and role="navigation". It’s truly backward compatible, it’s semantic, I can use it today, and there isn’t a steep learning curve.

Then I went to two design talks by Andy Clarke and Dan Rubin, and though their designs were beautiful, the code examples were not. Imagine the flexibility of a newspaper article and compare that with the inflexibility of absolutely positioned paragraphs with fixed heights. Exactly. Apart from that Andy’s main inspiration came from comic books. It never hurts to throw in some colorful images.

Like in comic books, usability is not about getting from A to B, it’s about the experience of getting from A to B. In comic books the size of a panel and the amount of text strongly influences the reading speed. So you can emphasize content and add dynamics in your web design. That doesn’t mean necessarily that everything has to be in boxes. Emphasis can also be added by removing the boxes.

Dan Rubin used a lot of effects on his designs, like a noise filter to add texture on monochrome surfaces. Nice idea, though that implies the designer explaining the rationale of such a feature to the front-end engineers. They would either ignore it because they overlooked the subtle texture or because they assumed it would be just noise. Some less intrusive hint I will readily adopt was using a letter-spacing of −1 on headlines to prevent tiny rivers between letters.

What slightly worries me is that Dan talked about re-using patterns for some effects in Photoshop. Re-using patterns is the same in CSS, but re-usable effects in Photoshop can mean an unusable amount of work in CSS and lots of pictures making the website slow. What I miss so far is a common understanding of effects and patterns that are both easy to work with in Photoshop and in frontend programming.

The next day started with Nate Koechley’s keynote about professional frontend engineering. He chose the topic because he thinks this is critical to the advancement of the Internet, and I couldn’t agree more. As Frontend Engineers we write software with XHTML, CSS, JavaScript, and quite some amount of PHP. Douglas Crockford calls this “the most hostile software development environment imaginable,” and if you take a look at this graphic from Nate’s slides you will understand why. There are a number of knowledge areas that can be applied in a number of ways on three operating systems and half a dozen browsers in two rendering modes. If you ever wondered why you sometimes see little clouds of smoke coming out of your frontend engineering heads, that’s why.

There are four guiding principles:

1. Availability and accessibility for all users worldwide
2. Openness: share, learn, support, advocate
3. Richness: provide, but not too much
4. Stability

Then there are three core techniques: Graded Browser Support, Progressive Enhancement, and Unobtrusive JavaScript.If you haven’t heard about those concepts, please read about them now.

At that point the presentation turned into giving advice for quite a number of best practices and tips, like using JSLint, YUI Unit Testing, or YUI Profiler to enhance the quality of your code. Or serving cacheable assets from cookie-free domains. Or anticipated preloads: sneak in your new JavaScript and CSS files a week before the relaunch. Or did you know that the iPhone 2G can keep only 19 assets in cache, and that it doesn’t cache anything larger than 25K? Uncompressed 25K? Needless to say, Nate’s presentation was one of the conference highlights.

Later I heard a few things about building applications with existing frameworks and APIs, a timely comparison between JavaScript libraries held by no other than jQuery’s John Resig, some tips on internationalization by Richard Ishida, and a panel about accessibility. The one sentence that stuck most in that panel was: “Don’t be the guy with the problems, be the guy with the solutions.” In fact it’s very hard to be passionate about your job while being pragmatic and providing solutions instead of just saying “no.” Something Richard Schwerdtfeger wrote about in a different context:

Working in the accessibility field is extremely difficult. It requires very specialized skills — including incredible persistence. Accessibility is often viewed as additional work that is not always planned for. It requires a person who is tough, committed, patient, and caring to deliver an accessible solution that is usable to our customers. To do this you must have tremendous passion for your job as there is always someone or something to trip you up.

Combining passion and diplomacy is a goal many web evangelists still have to work on… In the meantime remember that accessibility is most likely to have a sustainable impact when it is supported by senior management, when there is an accessibility policy for a company, and when smart companies realize that there is money to be made by maximizing the target audience.

1. <?xml version="1.0" encoding="UTF-8" ?>
2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/ TR/xhtml1/DTD/ xhtml1-strict.dtd">

It was obvious for me that such a declaration would be a good thing to have since XHTML is XML after all. Only later I learned that it triggers a bug in IE6 to render pages in quirks mode with a broken box model. But I was used to build workarounds for Internet Explorer bugs since IE 3.0 and never knew anything but the broken box model in IE, so I continued to use the declaration.

Until recently my colleague Thomas Junghans took the trouble to research, and found this phrase in the XHTML specification:

An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.

The declaration is not required as long as you encode in UTF-8 or UTF-16, you are only strongly encouraged to use it. Gasp!

Richard Ishida lists some advantages of using the declaration when serving the pages with an XML MIME type or viewing them offline, however I’m convinced the disadvantages prevail.

So as long we are stuck with IE6 — and people say that could be as long as 2014 when support for Windows XP ends (reminder to self: throw a party on 8 April, 2014) — I will refrain from using the XML declaration. Amen.