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.

Otherwise the draft’s abstract and introduction are vague and leave room for interpretation what this is exactly about. What I have understood is:

1. This module defines a new element with the name access.
2. The element can be used to define an access key for any other element.
3. Another usage could be as a skip link as there is a targetid and targetrole attribute.

For me it remained unclear whether this element belongs in the head like link elements, or in the body like anchors or label elements. Anyway, among other Common attributes it can have a title plus a few new attributes: key, targetid, targetrole, and activate.

• The key attribute is optional and defines an access key in a generic way. So far there was only the accesskey attribute for anchors and form elements, now any fancy Web 2.0 div element impersonating something else can receive focus by striking a key. Browser vendors are encouraged to emphasize the responsive character in a word, like underlining it. Also the working draft provides a description what user agents should do if there are conflicts with existing shortcut keys. So the team paid attention to the discussions about the reasonableness of the accesskey attribute.
• The targetid and targetrole attributes assign targets by id or role. There can be more than one of each, comma separated. I imagine that’s like tabbing through elements, but with a shortcut key.
• The last new access attribute is activate. I must admit I have no clear idea what “activate” could mean or what this attribute is good for. An element receives focus, so there should be a perceivable effect, some sort of feedback to the user. If an author does not want this, there are ways to suppress default renderings by CSS. If she doesn’t want the focus event to trigger something, there’s JavaScript to cancel it.

I thought of playing with the new element, but it’s too early for a test implementation. The working draft still lacks a XML Schema that could be used in namespaces. It would be possible to extend a DTD without much conflicts, alas the module doesn’t come in one box, but in two (again). So you would need to append both the qname module and the access module instead of simply adding the access module. I don’t understand the rationale for this separation, but I see it’s more painful for an author to implement it that way.

However, the access element provides a better and more generic functionality than existing alternatives, it fills the gap of missing access keys, and if I got it right it defines a standardized method for skip links, although this could be expressed clearer. Apart from the usual suspects there is Google’s accessibility specialist T. V. Raman on the team, and Richard Schwerdtfeger from the team that built more accessibility into Firefox, the Open Document Format, and IAccessible2 as an accessibility interface for screen readers. So my bet is we will see support for this element in our favorite browser as soon as this draft is more mature. Your turn, Microsoft.

Speakers

• Richard Schwerdtfeger (IBM)
• Marian Oosting (anderslezen.nl)
• Chris Heilmann (Yahoo!)
• Miguel González-Sancho (European Commission)
• Michael Cooper (W3C WAI)
• Dominique Hazaël-Massieux (W3C Mobile Web Initiative)
• Dave Wilton (Legal & General)

Richard Schwerdtfeger works for IBM and is a member of the W3C WAI and the HTML working group, among others. I assume he had been invited because the organizers only knew him for having developed IBM Home Page Reader back in the 1990ies. But his current work involves the W3C working drafts for Accessible Rich Internet Applications (ARIA) and other core technologies that his team developed in cooperation with vendors of Assistive Technologies (AT, e.g. screen readers) and the Mozilla Foundation.

There’s a paradigm shift in the usability and accessibility of Web 2.0 applications. ARIA adds meaning, importance, relationships, fills the gaps in (X)HTML, and increases usability for all users through familiar navigation models from desktop applications.

From Marian Oosting (anderslezen.nl) I learned about DAISY. It’s a library standard mostly used for talking books for the blind. Based on MP3 and the W3C XML standard SMIL, it combines strong compression with superior navigational features. Quite intriguing to use that format for audio books, and since 2006 it’s becoming available and more attractive for non-disabled users. For example, talking books are quite popular with elderly people who constitute about 60-80% of public library users.

In his presentation Chris Heilmann (Yahoo!) emphasized the need to ask people with impairments because they use assistive technologies in other ways than a non-disabled developer might foresee. Don’t assume, integrate their advice!

Miguel González-Sancho (European Commission, Information Society Directorate General) presented the European programs for e-Accessibility, e-Aging, and e-Inclusion. ICT is becoming essential for socio-economic participation, yet 40% of the European population is left behind. Functional limitations and disabilities increase due to aging. About 20% or 100 million of the European population is concerned. Thus accessibility is gaining relevance and becomes a social imperative.

In “Web Accessibility in the Future” Michael Cooper (W3C WAI) was rather giving the big picture and avoided to announce a release date for WCAG 2.0. Although the updated version will definitely play an important role in the future of accessibility, so does the development of a common Accessibility API or authoring interfaces that generate accessible content (ATAG). Think of user contributed content where the authors are usually unaware of accessibility requirements. Moreover, professionalization of accessible design, programming, and manual and semi-automated evaluation will gain importance. We must keep an open eye on developing technologies (MathML?, Second Life?), advocate accessibility in early stages, and keep accessibility awareness in legislation and society.

Dominique Hazaël-Massieux (W3C Mobile Web Initiative) talked about the mobile web, of course. There are more mobile phones than computers, they are cheap, and about 80% of the world population has mobile network coverage. Mobile access is everywhere, will become ubiquitous. There are some limitations like the tiny screen, the lack of a proper keyboard, diversity is large and access slow. In fact mobile and impaired users have so many challenges in common that Dominique estimates an accessible website already meets half the requirements of the Mobile Web Best Practices. Bad news for militant accessibility advocates who keep emphasizing the differences between accessibility, universal access and device independence.

Dave Wilton from the large British financial services supplier Legal & General gave some real world examples why it literally pays to become accessible:

There are nine million people with disabilities in the UK. If 1% just bought a £300 policy, his company will make £27 million: “The cost of making the site accessible pales into insignificance.” If people can’t buy from Legal & General, they will go to their competitors. In surveys, helpdesk and logfile analyses they found 10% of their visitors don’t make it past the home page. That’s equivalent to slamming the door into the faces of 20,000 visitors each month. 30% never open a PDF file. Besides, every third Briton is older than 50, and as we have heard before, the incidence of disabilities increase with age. There are not only people with cognitive impairments, but also 3 million people who speak English as a second language, 1.5 million people lacking basic language skills, and 5.2 million adults who have sub-GCSE level English.

Next time somebody tells you “disabled people are not our target group” show ‘em these results:

• Online traffic surged with a 50% increase in natural search engine listings.
• The number of visitors receiving quotes increased by 100% within three months.
• The new content management system cut site maintenance costs by 66% with an annual saving of £200k.
• Without changing products or prices, conversion rates improved substantially, ranging between 26% and 300% increase with an average of 200% (something Jakob Nielsen seconds).
• The entire project delivered 100% return-on-investment (ROI) within just 12 months.
• Customer satisfaction was improved (not one accessibility complaint!)
• It was great PR!