With keynotes by Kristina Halvorson (author of the must-read “Content Strategy for the Web”) and Rahel Bailie, workshops by Rachel Lovinger and Karen McGrane, and presentations by Jeff MacIntyre, Colleen Jones, Erin Scime (HUGE), and Sarah Cancilla (Facebook), North America’s leading content strategists will be in the house.

There’s also a strong European contingent; I’m honoured to be presenting “A “Do It Yourself” Guide to Content Strategy”.

All of this in central Paris in the spring; it’s just too good to miss. Tickets are still available, so check out the programme and get yourself a ticket!

You’ve tried all the obvious solutions: installing a powerful, easy-to-use content management system, or demanding that the client supply content upfront, or even writing all the copy yourself; but none of them seem to have much impact.

You realize that your team could use some help from the discipline of content strategy, but for whatever reason, hiring a dedicated content strategist isn’t a feasible option. So what can you do to add some content strategy to your projects?

The answer, as with so much in web design, is: Do It Yourself.

A Do It Yourself guide to content strategy

All web professionals can engage with content strategy, whether we’re content specialists or not.

It turns out that content strategy is a core discipline of user experience design. We’ve all practiced it to an extent, but most of us have neither been doing enough, nor getting the timing right. Stay with me and I’ll show you how using the approaches and techniques of content strategy, and advocating them among colleagues and stakeholders, can substantially improve the chances of meeting your projects’ goals, through an improved user experience.

Definitions

A couple of definitions. By “content”, I mean text, images, audio, video; anything we publish online, and anything that our users expect to find on our website. For the discipline itself, see Kristina Halvorson’s “The Discipline of Content Strategy”:

Content strategy plans for the creation, publication, and governance of useful, usable content.

The pain of a broken experience

Before we learn how to use content strategy, it’s helpful to establish why we need it in the first place. So let’s talk about the problem: the pain of a broken experience.

Despite all the work we put into user experience design, the final experience often doesn’t meet our expectations, because the content isn’t right. Call it content-delay syndrome, a failure to design the words, or simply treating content as somebody else’s problem. So we try the obvious solutions.

Easy solutions that don’t work

How many of these easy solutions to the content problem have you seen?

• Design the site with “lorem ipsum”, and hope the client comes up with the content later.
• Demand that the client supplies all the content before you start work.
• Install a content management system (CMS).
• Hire a copywriter at the last minute.

Unfortunately, none of these “solutions” actually work.

“Lorem ipsum” produces a template, aesthetics-only design, which has no relationship with the actual purpose of the site. Demanding content from the client is better than nothing, but is unlikely to work unless your stakeholders have an exceptionally strong grasp of content strategy themselves. (It can work for launch day content, but the site soon goes stale.) Everyone loves a good CMS, but software isn’t magic pixie dust: a CMS without a content strategy leads to shovelware or worse. And even the most talented copywriter won’t be able to rescue your content at the last minute: content strategy isn’t all copywriting, and it needs to be practiced throughout the design process.

Wasting our time

No amount of research, information architecture, interaction design, or usability testing can create a great user experience if the content isn’t useful and usable—if it doesn’t help the user to get things done. (A possible exception is web apps, but even Gmail has a content strategy: brochure text, documentation, microcopy.) To an extent we’ve been wasting our time; trying our hardest to polish an experience, when the core of what we’re offering to the user hasn’t been properly thought through.

So we need content strategy.

The ideal: hire a specialist

How can we add some content strategy to our projects?

Ideally, we’d hire a content strategist: a specialist, who can lead a broad, upfront study, before we even sketch the first wireframe; and take responsibility for content throughout the project. She’d work alongside the information architect, designer, developer, copywriter; you name it. (Many copywriters would gladly take on the role of content strategist, if we’d only ask them.)

If you can do this, congratulations; you’re on the road to success.

The reality: you can’t

In practice, we’re often unable to hire a dedicated content strategist, for various reasons:

• We don’t have the money.
• We don’t have the time.
• We don’t know any content strategists.
• It’s a miracle the stakeholders tolerated a planning stage at all. Asking for yet another expert on board is too radical, at least for now.

But don’t despair. The internet publishing revolution is part of the “mass amateurization of efforts previously reserved for media professionals,” in the words of Clay Shirky. [1] Web professionals operate at the fast-moving threshold between amateur and professional: our professional work enables anyone to exploit the power of the web, without further help. (For example, consider blogging tools: created by experts, they empower non-experts to publish.)

So, those of us who aren’t content experts, let’s embrace that spirit, and practice content strategy for ourselves.

A core discipline of user experience design

How does “doing it for ourselves” fit into our existing practice as people who make websites? Well, I said earlier that content strategy is a core discipline of user experience design, and that you’re probably already doing some; let’s expand on that.

If you’re like me, you learned a great deal about web design from Jesse James Garrett’s famous diagram, “The Elements of User Experience” (PDF link), published in 2000. It still describes the field remarkably well, nine years on. But as Kristina Halvorson has pointed out, the diagram doesn’t treat content strategically: it’s treated like a feature, with nobody taking ownership until the last minute.

Things change. It turns out that the bridge between site objectives and user needs—the strategy itself—is content. To say it another way, people come to your site because they want content; you meet user needs by planning, creating, delivering, and governing content, and you meet site objectives in the same way. Often, the content strategy is the web strategy.

This has been obvious to some practitioners for years, many of whom have called themselves “content strategists” all along. For the rest of us, it’s a bit of a shock. What, we can’t just throw some copy in on launch day?

The good news: you’re already doing some

But since it’s fundamental, anyone who’s tried to bring order, planning, and purpose to a web design project—like you, dear reader—is already practicing a little content strategy. Maybe you’ve:

• Asked the question, “who cares?”
• Compiled a content inventory.
• Used real content in a wireframe.
• Written a style guide.
• Planned an editorial workflow.

You might have called it web strategy, information architecture, usability; it doesn’t matter.

How to practice content strategy

So we’re already practicing some content strategy. But how can we do more, more effectively? Here are some suggestions.

Make it part of your web strategy campaign

Use the principles of content strategy as part of your campaign for a grown-up web strategy.

As enlightened web professionals, one of our constant struggles is adding some strategic planning to our clients’ projects. Lisa Welchman defines two key elements of web strategy:

1. Establishing a set of guiding principles.
2. Formalizing authority for the web in the organization.

Content strategy applies directly to both points, asking:

1. What content are we creating, and why?, and
2. Who is responsible for planning, creating, and maintaining it?

Practically, this often means allocating a large portion of the project schedule to upfront planning: research, web strategy, content strategy. Anything that allows you to design from the content out, by delaying the design phase until the content actually exists, will help.

Advocate it among stakeholders

Advocate content strategy when talking to stakeholders about their web projects.

Although clients often don’t realize it, commissioning a website is a big deal; for the client as much as for the design team. Talking about content strategy is a great way to communicate to your stakeholders just how much work they need to do. (See: Understanding web design.) The aim is to get your stakeholders to think like a publisher; and ideally to either narrow the scope, or increase the budget.

In my experience, clients appreciate the value of content strategy surprisingly quickly. I’ve had more success explaining its importance than with similar efforts for user-centered design or information architecture, for example.

Apply it to your design process

Apply the approaches and techniques of content strategy to your existing design process. Here are some starting points:

• Ask questions about content, right from the start.
• Utilize user research or personas to decide what content is needed: answer the question, “who cares?”
• Establish key themes and messages.
• Carry out a content audit, and a gap analysis.
• Write a plan for creating and commissioning content.
• Insist that the client plans for content production over time (an editorial calendar).
• Annotate wireframes and sitemaps, to explain how both interaction and content will work.
• Write comprehensive copy decks, based on common templates.
• Write a style guide for tone of voice, SEO, linking policy, and community policy.
• Specify CMS features like content models, metadata, and workflow based on the content strategy.

This only scratches the surface. For more on how to start practicing content strategy within a web design team, check out these presentations: “Explaining Content Strategy” by Jeffrey MacIntyre, and “Content is King” by Karen McGrane.

Engage with the community

Finally, engage with the community.

Some people have been practicing content strategy for years; they know what they’re talking about. It’s scary dealing with content experts—they eat grammar for breakfast—but imagine how they must feel about the CSS box model. They don’t seem to bite.

There’s a lively and growing community around content strategy. A few starting points are the Google group, the “knol”, and the twitter hashtag.

The benefits: look more accomplished

So why should you care about all this? You’re not even a content specialist.

Considering how well you managed to polish that user experience before, imagine what you’ll be able to accomplish when the site has a real content strategy. You’ll see a substantially improved user experience, increasing the chances of meeting the project’s goals; with the side effect of making your design seem more accomplished. Honestly: design an experience over a solid content strategy, and people will think you’re a genius. (Well, more of a genius than they thought you were already.)

The commercial aspect: this is going to be huge

Finally, a commercial- or career-oriented reason to get involved in content strategy.

Listen for a second. That crashing sound you hear is what we used to call the media industry, collapsing around us. All that destruction leaves a lot of space for web content. Web content strategy will be in demand for years to come.

So get out there, and Do It Yourself.

References

[1] “Here Comes Everybody”. Clay Shirky, Penguin. 2008. Page 55. (UK edition)

I don’t know exactly what I expected from this book—something aimed at a design audience perhaps—but in fact the book reads more like a manifesto for the discipline of experience design—and especially for its use in corporations. At times the book is surprisingly radical, quoting non-mainstream sources like the Cluetrain Manifesto and the Agile Manifesto, taking aim at business school thinking and its obsession with efficiency and benchmarking, and scathing about advertisers’ and marketers’ view of customers as mere consumers, or sheep. They even attack the “Homo Economicus” view of people as rational utility maximisers, the part of Economics that’s always annoyed me the most.

The book’s key audience might be somebody working in a corporation who wants to improve some aspect of their users’ experience—the usability of a website or product, say. The authors’ message is that although there may be lots of improvements you can make on that little product, unless the organisation takes a holistic view of the experience—an experience strategy, incorporating design as an organisational competency—sooner or later you’re going to hit a brick wall from the point of view of the user experience.

They cite the example of being asked to work on the user experience of a banking website, when the key frustrations of the bank’s customers concerned their interactions with branches, paper statements and telephone banking—parts of the organisation that were out of bounds for the website team.

This isn’t just a moan about how clients and organisations make designers’ jobs impossible. The authors’ argument isn’t that organisations need to change in order to make design easier, but that if they don’t make design a central part of what they do, they’re going to have a very rough time trying to establish a competitive advantage.

From the first chapter:

The key to succeeding in the contemporary marketplace is to fundamentally change your relationship with customers. Once you stop thinking of your customers as consumers and begin approaching them as people, you’ll find a whole new world of of opportunities to meet their needs and desires.

A thought-provoking, considered book—highly recommended.

“Subject to Change: creating great products and services for an uncertain world” by Peter Merholz, Todd Wilkens, Brandon Schauer, and David Verba. Published by O’Reilly, April 2008. ISBN 10: 0-596-51683-5. ISBN 13: 9780596516833.

From the site:

Our approach to web design is user-centred, collaborative and strategically focused—resulting in a website that achieves the aims of your organisation, is easy to maintain, and offers a pleasurable user experience.

Read more on the Together website.

Shlomo is one of the world’s finest human beatboxers, which means he makes music using just his mouth and a microphone — or sometimes with a loop sampler or a choir to help. He’s currently an Artist in Residence at the Southbank Centre in London. He also happens to be my brother.

More content than a small corporation

Shlomo is a prominent representative of a new breed of artists that shun the record industry in favour of promoting their music themselves — and often the web is their medium of choice.

As a result, at the start of the design process for this new website, Shlomo already had more content scattered around the web than I could really believe — YouTube videos, photographs, mp3 tracks, myspace blog posts, event listings…

The design challenge was to fit all this information into one website without overwhelming the user. We came up with the idea of projects: long-term themes that group events, music and writing together to hopefully form some kind of coherent narrative.

APIs

We used tagging to glue these projects to flickr photos, YouTube videos and del.icio.us links using those sites’ APIs, and to events and tracks using a home-brew CMS. The new site also features a WordPress blog, a bbPress forum and a twitter feed.

The Babelbox Podcast

Shlomo also launched The Babelbox Podcast, featuring backstage interviews and new music.

Fluid CSS layout

One of the technical highlights for me was the fully fluid CSS layout, with Flash movies (for YouTube video and MP3 playback) that scale with the design — accomplished using JavaScript. Check out the Music Through Unconventional Means project for an example. (In some browsers you need to resize the window and release the mouse to see the effect.) IE6 gets a fixed-width version, but IE7 gets the same as other modern browsers.

More to come…

This is the first release of the site, but we have more planned, including a possible musical project that uses communication over the web to create a collaborative piece of music.

Check out the site and leave a comment in the forum or send me an email if you have any feedback.

Credits

Graphic design and branding: David Caines.

So why were these masterpieces of advertising guff reserved for the airport road? The answer was obvious. I’d assumed that the billboards were aimed at the companies’ customers — the people who bought their products — but they weren’t. Their audience was the people who pay the advertising agencies’ bills: company executives, and ultimately the CEO. These people aren’t likely to see much of a country — they’ll fly in, take a car to their hotel, and perhaps attend a conference, or tour the company’s facilities. Amid all the rush of a whistle-stop tour, they might assume that the whole country is plastered with billboards just like the ones on the airport road — and that therefore, the great international branding strategy is working exactly to plan.

Flattering the client

The billboards in HCMC were an example of flattery masquerading as marketing — a corporation paying an advertising agency to make executives feel good about themselves. This isn’t necessarily a terrible thing — many corporations can afford it, and a few fluffy posters and magazine ads don’t do any harm. But on the web, designing to flatter the CEO leads to disaster.

Ego marketing doesn’t work online

I use the term “ego marketing” to describe inward-focused, self-congratulatory marketing that takes an organisation-centred viewpoint rather than a user-centred one. With the exception of sites that aren’t supposed to be communicative, like vanity sites, ego marketing doesn’t work on the web.

The client will ultimately judge the success of a website project by user feedback and results, not personal aesthetics or preferences. Ego marketing annoys users and weakens the site’s message, so any use of it will tend to work to your disadvantage, negatively impacting the client’s judgement of success. What’s more, the client will expect you to have thought this way from the start, even if he or she didn’t, because you’re the web professional. Don’t design for the CEO — he won’t thank you for it.

The temptation to pander

During the web design process, it’s tempting to give in to clients’ personal aesthetic tastes, naive preferences, and ignorant prejudices, instead of challenging them to think from their audience’s point of view. For example, a client might ask for a colour scheme that he personally likes, an information architecture that fits his internal view of the company, or a crowded, cluttered layout because he “doesn’t like vertical scrolling”.

Paul Boag proposes some useful methods to deal with these unhelpful requests in “10 Ways To Get Design Approval” — particularly relevant are “define the role of the client and designer” and “control the feedback”.

Who pays the bills?

Design agencies get their income from clients, and so tend to be over-sensitive about doing exactly what the client asks for. Whether or not your boss is looking over your shoulder, muttering, “she pays the bills!”, there’s often pressure to do whatever the client seems to be asking for — even if it’s a stupid idea, and you know it isn’t what she actually needs. To make it worse, clients and co-workers are often accustomed to less user-centred fields, and so genuinely expect websites to be designed for the client.

Visualising how abstract concepts will work in real, living websites is notoriously difficult, especially for those unfamiliar with web design — which makes unworkable or inappropriate requests common. Processes like wireframing and prototyping help to mitigate this problem, but they don’t remove it.

Technically, the client pays the bills. But figuratively, the users pay — because if you don’t design with users in mind, they’ll be turned off, and eventually you’ll lose the client.

Success is judged by others

Although it might not seem like it at the beginning, the CEO will judge the success of the website on feedback and results. If users like the site, and it achieves its aims, he’ll be happy — but if they hate it, and the site fails, he won’t feel any better for knowing that he got his way earlier on. In fact, he’ll expect you to have advised him well from the start — even if that meant you had to challenge some of his assumptions and preferences. Nobody likes to be told that something’s their fault when it’s too late to fix it — and as web professionals, it’s our job to advocate the user’s point of view throughout the design process.

Don’t annoy your users

Suppose the CEO requests one of the all-time classics of ego marketing, the splash page, and you go ahead and implement one (with a really big logo). You know what will happen — users will be annoyed, because instead of helping them find what they’re looking for, the site is wasting their time by pushing empty marketing guff into their faces. Perhaps that’s an extreme example, but the same principle is true of all ego-marketing — users are unconvinced, and so feel annoyed — weakening your message.

Make it user-centred or pay later

In this article I’ve argued that if you give in to unreasonable client demands upfront, by designing for the CEO, you’ll pay for it later. Even if pandering to requests for ego marketing pleases the client in the short term, once the site is live she’ll judge it on feedback and results, and then you’ll be blamed for failing to advise her properly. Even though clients pay our bills, user-centred design is complicated — we’re paid to help clients communicate with their audience, not to make them feel good about themselves.

The payoff

If you manage to steer the client away from designing for the CEO, by advocating the user’s interests and resisting ego marketing, you’ll get a big payoff when the site launches and the client starts to get positive feedback from users. Ultimately, your clients will love you for thinking of their users first — which will make you more successful in the long term. And if they’re still not happy, you could always design them some big fluffy posters…

But is Facebook really the ultimate social networking site, the last one you’ll ever need to add all your friends to? Of course not: in a year’s time, some other site will be the trendy hangout that you can’t afford to miss out on. But the good news is that this constant migration from network to network isn’t going to carry on for ever — because we now have interoperable, open standards that will make the idea that all your friends need to be on the same social network seem quaint. The combination of microformats and OpenID will allow open websites to compete with the key selling points of walled gardens like Facebook — privacy and network effects — and as a result, kill their business model.

Walled gardens

As Jason Kottke says, Facebook is the new AOL — a walled garden, which you can’t access from the open internet unless you’re a signed-up, logged-in Facebook user. Signing up to yet another website, and then approving all your friends for the 14th time is clearly a pain, so why do so many people do it? Because walled gardens offer two key features that open websites don’t: privacy and network effects.

Privacy: only my friends can see it

When you add content to your Facebook profile, you can make sure that only your friends can see it. So the fact that you’re feeling grumpy today isn’t broadcast to the whole world, just to your network — and the photos from the party last night can only be seen by people you trust. This kind of privacy feature isn’t unique to Facebook, of course: you can achieve the same effect using Flickr or Twitter, for example — sites which aren’t usually thought of as walled gardens. But I argue that whenever privacy features are used on these sites, they behave like walled gardens — because in order to restrict access to a network of friends, all of your friends need a profile on that site. You effectively lock out any of your real-life friends that haven’t signed up for that website: a walled garden approach.

Network effects: all my friends are already here

The success of social networks like Facebook is clearly helped by network effects — the fact that if lots of your friends are already active users, joining looks much more attractive than if you’re the first to join. This applies equally to adding comments to other people’s photos on Flickr and writing on a friend’s “wall” on Facebook.

The business model

The business model of these walled gardens goes something like this:

1. Offer our users privacy (and other services).
2. Exploit network effects to get as many of our users’ friends as possible to join.
3. Sell advertising to our massive captive audience.

At the moment, this model works — just look at Facebook and MySpace. But notice that during the second step, the site isn’t getting users to sign up primarily because they like the service, but because their friends are already on the network. Walled gardens exploit their users’ personal relationships to grow their proprietary systems — and on the internet, that’s never sustainable.

An open alternative

So what’s the open alternative to this walled garden approach? Microformats for relationships and OpenID for identity.

Microformats

Microformats are “a set of simple, open data formats built upon existing and widely adopted standards” — often referred to as the lowercase semantic web. Jeremy Keith outlines how the existing hCard and XFN microformats could be used to create portable social networks, so that each new website you join could automatically fetch a list of friends from a URL you provide. This wouldn’t have to be hosted on a blog or personal site — a profile page on a site like Flickr could automatically provide this information, just by using microformats in the markup. But what about privacy?

OpenID

OpenID is an open, decentralised identity system. The central idea is that if a person can prove that they own a URL, that’s enough to identify them. Simon Willison describes how OpenId could be used to create decentralised social networks, “with profiles tied together across multiple sites and relationships easily portable between services” — that is, you can restrict access to your group of friends even if they’re not members of your social networking website of choice.

If a social networking site combined these approaches, you could instruct it to restrict access to a group of friends that:

1. Is defined elsewhere, without having to be manually entered, and
2. Doesn’t require your friends to be members of the site to access your content.

This is the killer combination for Facebook’s business model.

Goodbye, exponential growth

Why am I so sure this will happen? Well, it might not work exactly the way I’ve outlined, but some kind of interoperable, open standard will eventually replace proprietary, closed social networks, because open systems always beat closed ones on the internet. This doesn’t necessarily mean that the sites I’m calling walled gardens are doomed though — they just need to open up, and rethink their business model.

Once you remove the exploitation of personal relationships I’ve described above, exponential growth of users is much more difficult to achieve. Now, new users won’t sign up just because their friends’ content is in your system — because they can access it anyway using an open identity system. To get them to sign up, you’ll have to convince them that your service is better than all the others — which means you have to offer the best user experience, not the largest network.

Selling advertising to a captive audience also becomes more difficult, because your audience isn’t really captive any more. If your users’ friends use RSS to access content, for example, they won’t see your site at all — and anyway your users are free to migrate to another site whenever they want to, because they now own their data in an open format. Perhaps this will result in more targeted, niche advertising — or even a service charge (gasp!), paid in return for a well designed, pleasurable experience. Either way, the Facebook model will fail — which means that sometime soon, we won’t have to join a new social network every six months. I’m looking forward to it.

However, accessibility is only part of the story. An equally important benefit of following standards is the discipline they require.

Professionalism and self-respect

The concept of discipline that I want to introduce in this article is closely related to professionalism and self-respect.

Having discipline as a web professional requires the self-respect to admit that what we do is valuable in itself — not just as a plugin to a more legitimate activity. Once we have self-respect, we can begin to bring order to the way we work: discipline. Using web standards is a powerful way to achieve that.

Before standards there was junk

In the junk markup era, it was effectively impossible to follow web standards if you wanted visual or behavioural consistency across browsers. We had to use code forking and nested table layouts, which led to rushed websites with messy, unmaintainable code. Only a handful of pages validated.

This led to the belief that anyone could create websites after a few hours of hacking, and a corresponding lack of self-respect among web professionals. We felt powerless to influence the web, and as a result we lacked discipline in our work.

Web design: a plugin?

Part of the difficulty in having discipline comes from the tendency for clients, management and colleagues to assume that our role is a minor subset of some other activity, like graphic design or software engineering. Jesse James Garrett refuted this assumption in his Elements of User Experience, in which he argued that the essence of web design is managing the tension between web as software interface and web as hypertext space. One example of the dot-com era tendency to write off web design as a subset of graphic design is demonstrated by Adaptive Path’s decision to use the term ‘user experience’ instead of ‘design’, to avoid an association with visual stylists, who had no grasp of what we would call web design.

The problem with computer science

When faced with the lack of discipline I’ve described, many web developers have turned to computer science and software engineering as a source of discipline. They see methodologies like Object Oriented Design and Model View Controller as solutions, and use frameworks based on these methodologies to bring discipline to their work.

An analysis of the benefits of these methodologies is outside the scope of this article; clearly, many programmers find them useful. However, I argue that they can shift the focus of thought away from the essence of web design, because they assume that our main task is programming — that web design is a subset of software design. Again, this is an error: although we may do some programming, we are not primarily programmers.

The discipline of web standards

So, how can web standards give us discipline? Using semantic and valid markup, styling using CSS, progressively enhancing with widely-supported JavaScript and using clean URLs introduces a lot of discipline. And it’s not easy to do.

More difficult than it sounds

Writing valid markup is not intrinsically difficult, but correctly applying semantics to documents is not straightforward for most people. To demonstrate this, how many people do you know who are able to use Microsoft Word’s outline styles feature semantically, instead of just using presentational styles like bold and italic? Creating content management systems that allow non-technical people to write semantic markup is even harder.

The basics of CSS are straightforward; for example, it’s easy to demonstrate how to change the colour of headings in a document. However, successfully pulling off floated or positioned layouts, flexible width columns or bulletproof designs that work with zoomed text is much harder, especially when you have to support a range of browsers.

JavaScript is also more complicated than it looks. It’s straightforward to trigger an alert box when a form element is left empty, but unobtrusively adding interactivity that gracefully degrades when JavaScript is disabled requires a lot more thought.

The concept of using clean URLs sounds easy, even obvious. Implementing them well, however, requires a lot of thought — there are implications for information architecture, navigation, content management and database design.

The reward

I argue that simply by following web standards in the way I’ve outlined, you go a long way towards introducing discipline in your work. You’ve separated content from presentation, written your documents semantically, used style sheets for design, progressively enhanced behaviour for modern browsers, and used URLs to make your content easily accessible. You’re more likely to produce maintainable, reusable code, and to be able to transfer what you’ve learnt to other projects.

Standards gave us professionalism

Molly Holzschlag wrote last year about a new professionalism in web designers and developers. She talks specifically about the need to keep our skills up to date, and to be willing to learn. I argue that an equally important element of the new professionalism is gaining the self-respect to realise that what we do is not a subset of some existing field, that it is not easy — and therefore, that it has substantial value.

It isn’t a coincidence that the new professionalism arrived at the same time as the mainstream adoption of web standards; and we should use our new self-respect to argue that following web standards is a discipline in itself.

Ideally both

The obvious answer is ‘both’. The reason we follow web standards is largely to make our sites accessible to as many people as possible, and specifically to people with disabilities.

This is great in theory, but as we’re used to on the web, the practical reality is more complicated.

Writing for a better future

Remember ‘To Hell With Bad Browsers’? The Web Standards Project (WaSP) was founded at a time when there was no such thing as a standards-compliant browser. Table-based layouts were used to achieve visual consistency and code forking was required to get consistent behaviour.

The browser upgrade compaign was about using CSS layouts at a time when web designers were afraid of them, because many users still had old browsers. By separating content from presentation in 2001, WaSP wasn’t writing for the web as it was — it was writing for the web that it wanted.

Broken technology

What has this got to do with accessibility? I argue that the state of adaptive technology today can be compared to the state of the 4.0 web browsers. I’ll attempt to demonstrate this with two examples: image replacement and Ajax.

Image replacement

The current stalemate in font distrubution on the web led to innovative but non-ideal methods of embedding typography, like image replacement. The concept of image replacement is simple; use semantic markup for headings, but use CSS to hide the browser-generated text and show an image of fine typography instead. In this way devices which don’t undersand CSS, for example search engines, can still access the content, while CSS-aware graphical browsers get proper typography.

The theory was that screen readers would behave like search engines, by reading out the headings as if the image replacement had never happened. The CSS rules that hid the text were delivered in a “screen” media type stylesheet and so should not have affected the “aural” rendering of the page. It turned out that this assumption was wrong: Joe Clark demonstrated that most screen readers never read the hidden text, because they first rendered the document using a visual browser such as Internet Explorer, and then read out the resulting document tree.

Clark argued that this behaviour is justified because current screen readers are “multimodal” devices, while Dave Shea disagreed. Clark’s approach is well-intentioned, but I argue that it is the equivalent of an anti-standards viewpoint during the browser wars.

Ajax

The Ajax approach to building websites involves updating parts of a web page without refreshing the entire page. It is relatively straightforward to implement this approach on modern browsers while delivering a comparable, but less interactive, experience for older browsers or those who disable JavaScript. Screen reader support, however, is harder to predict since there is no standard way to ‘notify’ a screen reader that part of a page has changed. A recent study by James Edwards concluded that Ajax techniques cannot currently be considered accessible, while testing of the Basecamp web service concluded that it was usable but had some limitations. Both studies involved testing by screen reader users.

What is an accessibility-conscious web developer supposed to conclude? Presumably either that new approaches like Ajax are not accessible and are to be avoided, or that massive screen-reader testing is necessary to justify their use. I argue that both of these conclusions are misguided, and that if the majority of web developers accept them, they will have a negative impact on the future state of adaptive technology.

The return of angry laziness

The central question here is: how much time are we prepared to spend testing one particular user-agent’s behaviour? There are lots of variables: different screen readers, different software versions, complex user preferences and a range of proficiency among users. The current market-leading screen reader (JAWS) is an expensive piece of proprietary software, with no web developer help except for a demonstration version that requires frequent system reboots. And we’re only talking about one group of disabled users.

Zeldman related that the motivation for founding WaSP wasn’t altruism but anger: ‘angry laziness’ as he put it. I think we need some more of that.

If it’s broken, it needs fixing

If we work around all the non-standard behaviour we can find, simply for the sake of people who are using broken technology, we’re not really helping them in the long run. Adaptive technology vendors aren’t going to start following standards unless we can demonstrate that their current implementations are not good enough; and the only way that’s going to happen is if they see modern standards-compliant code that doesn’t work. This is closely related to the recent WaSP debate about how to embed Flash: should user experience always come before web standards?

New and improved

Both Apple and Sun are working on accessible operating systems that could ultimately remove the need for separate screen reading software. I don’t know how well these technologies follow web standards at the moment, but perhaps developing websites as if adaptive technology followed web standards might inspire vendors to make it a reality?

Less testing

Although the kind of testing that Clark, Edwards and others have done is clearly valuable, it’s not going to be practical for every medium-sized website. To some extent the non-testing approach is already implicity advocated; consider the unobtrusive scripting / ‘Hijax’ approach that holds that if it works with JavaScript off, it’s accessible. Since screen reader users may have JavaScript turned on, this claim is more of an aspiration than a reality, and rightly so; perhaps we need to make that explicit.

Use the sting

The recent launch of WaSP’s Assistive Technology Initiative is a positive step, but it needs to be accompanied by pressure. A good way to exert this pressure would be to continue the use of innovative techniques like image replacement and Ajax, making sure that we follow standards, but not insisting on 100% interoperability with assistive technology, if we can show that a lack of standards-compliance is the cause. The WCAG 2 debacle demonstrates that vendors don’t always act in the interests of the web and its users. If we want to stand up for accessibility, we need to show that we can still sting.