I’ve established a web design agency called Together London, based in Soho, London.
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.
On Saturday we launched a new website for Shlomo.
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.
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.
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.
Shlomo also launched The Babelbox Podcast, featuring backstage interviews and new music.
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.
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.
Graphic design and branding: David Caines.
My first article for A List Apart, for people who make websites, was published today. It’s called ‘You Are Not a Robot’.
We often sell web standards by explaining that using them improves accessibility. We might talk about reaching as wide an audience as possible, or about laws requiring accessible websites.
However, accessibility is only part of the story. An equally important benefit of following standards is the discipline they require.
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.
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.
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.
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.
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.
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.
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.
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.
When you build an accessible website, do you aim for code that follows standards, or for a site that is actually usable by people with disabilities?
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.
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.
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.
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.
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 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 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?
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?
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.
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.
