Yes, I don’t think that (most of) the CSS experiments are meant to be practical. I also agree that they are have entertainment value, though I think they have even greater value as an educational resource. As long as these things are generally understood, then there’s really no issue, and if things had stayed that way, I would probably not have written the article at all.

However, when we actually start charging money for these icons – as with the Peculiar set – that places everything in an entirely new light, which I have termed the implication of cost. As long as everything remained in in the experimental stage, all this unique CSS work remained could be understood as primarily theoretical and conceptual. The moment we put a price tag on it, though, the implications change.

Charging people for the icons is essentially a means of sanctioning their use in a production environment and are stepping firmly across the line between the experimental and the implementable. When this happens, I think that there is an argument, because we are no longer just in the realm of the experimental, and the message we are sending is the wrong one.

I totally agree, and any web developer worth their salt will be wary of implementing any of these experimental techniques in a production environment. Font replacement techniques like Cufón and sIFR have their detractors, but at least these techniques degrade gracefully – even @font-face is designed to degrade so that it doesn’t interfere with the browsing experience served up by unsupported technology. But as soon as you start to use wild CSS for the design of graphical icons, or start fudging dingbats to convey visual context where it doesn’t belong, you create horrendous accessibility problems and degrade the user experience ungracefully.

During the design phase, being able to tweak the pixel look and dimensions of an icon should be as simple as possible; adjusting many lines of CSS code to do this is not it, especially if you didn’t write the CSS originally. You want that icon a little bigger? Tough luck, it was created by someone else at 32 by 32 pixels, now it’s up to you to figure out how to make it all work for 36 by 36. Similarly, implementing an icon should be as simple as writing a CSS background property or adding an <img> tag. It shouldn’t involve adding six meaningless HTML elements nor twenty lines of CSS per icon.

Each of these experiments takes a different approach. Some, like the line graph, have some practical applications in the real world, while others like the CSS fail whale are completely and entirely impractical. It’s certainly interesting to know that it can be done, but that doesn’t necessarily mean that it should be done.

This trend for the use of CSS as a design tool has been bugging me for a while now, and Matt hits on the very heart of the problem, drawing parallels with table-based layouts:

If you’ve been around the web design and devlopment industry for very long, you probably already know how much of a faux pas table-based design is considered. Well, when it comes to CSS icons, consider these thoughts:

1. Bloat – All the necessary CSS declarations will really bloat up your style sheets, making them an absolute nightmare to manage. Wait, didn’t I just write those same words? Also, depending on how the icons are achieved, you might find your HTML bloating up with extra elements too.
2. Inflexible – Again I admit that people have done some really incredible things with CSS, but compared with a real graphics program, CSS generated graphics are incredibly limited in what they can do.
3. Purpose – As we’ve already discussed at some length, CSS wasn’t designed as a tool for creating graphics, despite the fact that people are able to do some pretty amazing things with them, like the Peculiar and social media icons we’ve already looked at. Impressive? Yes. The right tool? No.

Many of these CSS experiments are very worthy exercises to show the possibilities and extremes of what the technology can do – but most aren’t practical for production use. CSS is a technology for defining rules about how content should be visually presented; it’s not a tool for generating graphics.

Instead of the traditional method of using images to display icons on web pages, Pictos uses a font, in the style of Dinbats or Webdings, which can be implemented using @font-face.

It’s an interesting concept. The main advantages appear to be improved speed and better scalability (the icons will scale just like any font). But there are some serious accessibility flaws. Since the font characters appear to be mapped to the standard alphabet (i.e. the “refresh” icon is mapped to the letter “C”), using this technique is a horrendous headache for anyone using a screen reader, and will be very bad for your SEO. One of the examples shows an example using CSS :before selector to prepend an icon to content, which kind of gets around those problems, but still feels a bit clunky to me: the whole HTML/CSS stack seems to be broken.

A good effort, but I’m not sure this technique is ready for the mainstream.

UPDATE: The guys at Filament Group have done some casual testing of the accessibility of this technique with a range of proposed solutions. Sadly, the results aren’t promising – even the “:before” technique breaks things. My gut feeling is that this still isn’t a particularly graceful technique, and the only viable fix is to map the Pictos “alphabet” to appropriate unicode characters. But, even then, the implementation would be tricky for anyone who lacks a rudimentary grasp of unicode.

UPDATE 2: Looks like the very talented Jon Tangerine has come to similar conclusions: the only way this can really work is by mapping the icons in the font to sensible Unicode code points. But identifies still more problems with the technique, even if the semantics discrepancies were dealt with: more accessibility gripes, the reliance on @font-face support and the difficulties of a graceful fallback.

Drew suggests you can kind-of wrangle the markup into something sort-of semantic. However, it starts to fall down fast. For example, a check mark (tick) is mapped to ‘3’. There’s nothing semantic about that. Clever replacement techniques just hide the evidence. It’s a hack. There’s nothing wrong with a hack here and there (as box model veterans well know) but the ends have to justify the means.

Jon explains things far more eloquently than I can, so I suggest you read his balanced and reasoned post.

Adobe and Typekit are teaming up to bring some of the world’s most popular, recognizable, and respected fonts to the web. Starting today, you’ll be able to use classics like Adobe Garamond, News Gothic, Myriad, and Minion plus many more on your website — all of them newly optimized and hinted for the screen.

Although there are only twenty-six fonts being added to the collection, they include some of the most popular and elegant fonts in use today. The fact that Adobe have taken the effort to ensure they are properly hinted for screen use is another bonus:

We’ve been using these fonts internally here at Typekit for a few weeks and the quality is simply amazing. These are the original cuts of the celebrated typefaces you’ve been waiting for, not reproductions or knockoffs of their designs. That means you can use them with the assurance that your creative work is being presented with all the accuracy and technical detail the print world has known for decades.

I’ve been watching the evolution of Typekit for a while now, but haven’t used it in any production work yet. This may just be the tipping point where many people take a second, serious look at Typekit as a viable tool for bringing elegant typography to their web designs – $49 per year is a pretty good deal, particularly when you compare the cost of the average font license.

Ask any PC-loving computer nerd why Apple products have become the de facto choice of the masses, and you’ll likely hear something like, “People buy Apple products because they’re pretty.” That may be true for many, but one group of consumers who care little for Apple’s prodigious aesthetics are the blind.

They care more about how Apple products actually work. And while the iPad may be Apple’s most controversial launch in recent memory, the blind community is unanimous in its support.

This resonates with what I wrote recently in a piece about adaptive accessibility. Apple really do take accessible, functional design seriously – not just as an afterthought, or a secondary consideration. Accessible functionality is built right in to the very core of their design of software and software interaction. The very fact that Apple invested time and energy in making Voiceover a core element of OS X at an early stage, has allowed the technology to improve and proliferate, so that it can be seamlessly integrated into cutting-edge devices like the iPhone and, now, the iPad.

I would even go so far as to say that this kind of attention to accessibility for all is what makes Apple’s mobile products so successful as market-leaders: the benefits of accessible design are experienced and appreciated by all; accessible design enhances everyone’s experience.

First, consider what an e-reader represents to the blind community. The concept of an affordable, portable device that allows the visually impaired to consume media easily and without special consideration is an exciting proposition, but one never fully realized.

The iPhone and the iPad are both adaptive devices. Most people will never use the accessible features they provide; probably never even know that they exist. But the ability for users to adapt their use of the device to meet their own specific needs is what is so empowering. These aren’t specialist, assistive devices: they are desirable, cutting-edge consumer products. They make disabled people feel included; perhaps even makes them no longer disabled. This is a really fantastic thing.

Computer nerds, tech columnists and the general public may not know where the iPad fits into the existing media consumption landscape–but the blind and visually impaired see it as the only e-reader worth owning. Call it further proof that Apple is more than just a pretty face.

And I don’t think it’s just blind users who are going to benefit from these kinds of advances in consumer technology – touch interfaces might be a huge win for people who have been constrained by having to use a mouse and keyboard. Gestures can be a much quicker and more intuitive way to navigate within a digital space – why do you think the scroll-wheel became so popular?

Let me get this out of the way at the start: I’m a disabled web user, registered as severely sight impaired. I’m also a web designer and developer – have been for over 10 years. I’m not just a tinkerer: I’ve worked for the likes of Audi, Levi’s, Adidas and even won a few awards for my work with U2.

In the early days, like many of us, I didn’t take issues of accessibility as seriously as I ought to have done (I committed my fair share of usability sins and implemented some really bad design decisions). But, I saw the error of my ways, and nowadays I’m a loud advocate for good standards and better accessibility. And, as both a disabled web user and a web practitioner, I think I have some useful insights to offer on how we might make the web a more accessible place, not just for those who are disabled, but for everybody.

We’ve come a long way

There have been fantastic advances in improving access to the web over the past ten years or so. The wider adoption of web standards by both browser vendors and web practitioners has bought huge benefits to all types of disabled users. These advances have helped to inform trends in web design and development in a myriad of positive ways.

Personally, I’m finding that my web experience is steadily improving thanks to these adoptions, which is a fantastic thing. There is still some way for us to go though. I still occasionally stumble across high-traffic sites which are terribly inaccessible: code soup which makes a site unintelligible to screen readers; design treatments which bewilder anybody with learning difficulties; tiny hit areas which make for horrible target practice amongst those with motor disabilities. These aren’t old, creaking relics of a by-gone cyber-era either: they are new, high-profile commissions.

Sure, not everybody is signed up to web standards, nor is every web designer or developer experienced enough to appreciate the importance of accessibility. But from my experience, it seems that public sector and cultural organisations are the ones who are failing the most. This always baffles me a little, as you’d expect publicly-focused bodies to have a commitment (and in many cases be required) to ensure accessibility to all. Ignoring disabled members of society in the physical world is wholly unacceptable, so why do we still tolerate it in our virtual world?

Well, part of the reason, I think, is due to a slightly skewed way we think about disability. It’s often quite easy to fall into the trap of thinking of someone with a disability as part of a generalised group: someone who is blind, who is deaf, who is a wheelchair user. The fact is that not every disability is the same, and the acuteness and intricacies of a disability can affect people in so many varying ways. This misconception makes it a complex and confusing subject to understand, especially for people with deadlines.

But I think there’s something else we need to address.

There’s a bigger problem

Our industry isn’t innovating enough. We’re simply not being intelligent enough with our design of the web.

Now, that reads as quite a bold assertion, so I’ll try to explain where I’m coming from.

I’m a firm believer that good design should be both beautiful in it’s aesthetics and in the way it functions. But it seems that a lot of the time, when it comes to designing for the web, aesthetics and functionality are treated as two very separate disciplines. I’m generalising, but I’ll bet that the approach to the design of most web projects is still either: a great visual style which needs to function well; or a functional architecture which needs to look good. One generally informs the other.

I’d like to see the wider adoption of a new, emerging type of web design, where style and function are embraced as a single, integrated discipline. Gone are the days where a designer’s job stops when they hand over a Photoshop mockup to a site builder. And similarly, gone are the days when site builders try to design in the browser and then a visual style is conjured up around markup. Both of these approaches have their benefits, but equally, both have their failings. Can we not be a bit more inventive?

Accessibility can be beautiful

I think this is where accessibility could step in. I think accessibility can be a killer tool for some amazing design. But it needs us to look at it in a new way. As much as any of us claim to take it seriously, how often do we think about how it can be done _better_? The tendency is to just tick the boxes and then move on to another pressing task.

Rather than being a secondary consideration in the design and build of our web experiences, we can better use the disciplines of accessibility and usability as tools to inform and inspire beautiful aesthetics and functional design.

Good accessibility doesn’t just have to be something which _assists_ people with a disability. We need to flip that idea on it’s head. Accessibility should be embraced as a way to allow us _all_ to adapt our online experience to fit the way we use the web – disability or no disability. Better access to the places we visit on the web doesn’t just benefit people who are disabled, it benefits everyone.

We’re already heading there

Apple are a rare example of a company who take good design seriously and who are already doing amazing things in this field, albeit with installed software.

I have very low vision due to a rare form of albinism. My distance sight is really bad; I wouldn’t be able to recognise your face across a room. But my near vision is exceptionally good; I excel when working with pixels and detail. I predominantly do most of my work on OS X because it has so many low-level accessibility aids built right in: I can zoom the screen with keyboard shortcuts; well-adopted UI guidelines make it easy for me to understand a new app; standard controls and focus help me to navigate without a mouse; finding files, running applications and searching can all be done swiftly and easily using the keyboard.

I adopted an iPhone for the very same reasons: not because I’m an Apple fanboy, but because it brings with it the same accessible features as my operating system, features I’ve struggled to find in any other mobile device.

For me, these are amazing productivity tools. I tend to work faster and with more efficiency than my well-sighted peers, and that’s purely down to my use of accessible tools. I’ve _adapted_ my working world to not only achieve an equal footing, but my adaption allows me to be _more_ productive than many able people.

But these enhancements haven’t been developed for the sole use of people with a disability. They are elements of good, well-considered design, beautiful in both aesthetics and function, which are available to all. Try it right now: if you’re using a fairly modern version of Safari, hit CMD-F, then start typing a word, and you’ll see a perfect example of what I mean. If you’re using another browser, chances are you’re missing out on the advantages of a piece of simple, but clever, assistive design.

A subtle, but important distinction

Assistive accessibility means providing add-on tools which help people. My local Co-op print braille labels on their wine bottles: a nice bit of assistive design which helps us visually impaired lot choose our tipple. A worthy amount of effort goes into the transcription of subtitles and closed captions for TV programmes and DVDs: a service many of us don’t use, but which is an invaluable assistive tool for the hard of hearing (and incidentally a tool which is only now appearing as a feature in mainstream online video services).

Adaptive accessibility is about building things into our everyday world which aren’t used by everybody all of the time, but are available as a helper to everybody all of the time. It can be something as simple as a handrail on a stairwell: the more sprightly among us may bound up stairs two-at-a-time; those who are more elderly need the extra support; sometimes children use it; if you’re tired, lazy, carrying something heavy you might use it. You adapt your behaviour through use of the tools around you, depending on all sorts of factors.

I see no reason why this analogy can’t be translated into our experience of our online world. We’re moving away from the desktop, to devices in our pockets, on our laps, in our cars. We can go online virtually anywhere, with different distractions; different demands for our attention. We’re moving away from navigating with the keyboard and mouse, to using touch, gesture, using our voices, using our ears. This might come as a surprise to you, but us “disabled” lot are way ahead of the game when it comes to alternative ways to navigate the online world.

I don’t have any answers

So how do we start building more adaptive online experiences?

I do not have a simple answer as to how we achieve this, I’m merely posing the question and acting as an advocate for the discussion of ideas. Perhaps it involves rationalising the UI design of the web (the adoption of iPhone design conventions shows an early example of what this might mean); perhaps it means decoupling data and presentation even more than we already have, and looking at a more ubiquitous approach to design; perhaps it means we’ll see the emergence of new creative workflows, and a new breed of designer (there are plenty of “creative technologists” emerging who fit the mould). Perhaps we’ll invent new tools, services and devices which change the way we experience, and perceive, the web.

Or perhaps we’ll just keep plodding on for the next ten years, pontificating and prevaricating, waiting year on year for the ratification of standards, stifling our creativity, innovating by increments, never really being progressive, never being bold. History has taught us that freedom and inclusion can reap huge rewards for all members of our society. The world wide web has shown us an inkling of it’s potential. But unless we take a good, hard look at one of it’s core principles: access for all – then that potential may not have a chance to blossom.

As part of the North project we’re developing in partnership with folly I needed to produce a new web presence. It was quite a quick job, as time and resource were at a premium, but I thought it would be fun to do a screen capture of the design process. I’ve condensed the entire process, which was about 5 hours spread over 3 days, into just under three minutes.

You can watch it below, or head over to Vimeo to see it in glorious HD.

This was a really quick job, implementing a design which is flexible and which can be developed over time. The foundation is a fairly rigid grid system with a strong emphasis on typographic style. I went through three different iterations before arriving at the final blue/green version. Most of the work was done in Photoshop, with some of the graphical elements sketched in Illustrator.

I really liked the second iteration, with the paper plane sketches, but it just wasn’t cutting it with the rest of the team. I’ll shelve that idea for a future project though, as I really like the aesthetic.

I hope this is an interesting little insight into the way I develop concepts when working on a new design. Feel free to let me know what you think, and whether you found it useful/interesting.

If you want to see the finished design in all it’s HTML markup glory, or just want to know more about North, then head over to the website.

Al in all, I consider myself to be a pretty responsible practitioner of web standards and web accessibility. It’s something which I consider to be of great importance and it’s become an integral part of my design and development processes. It’s not an afterthought, it’s slap-bang in the middle of every design decision: whether technical or aesthetic.

So when I came to think about what else I could do, I was at a bit of a loss. I fell like I’ve ticked all the boxes for being a responsible web practitioner, but where can I go from here?

There’s been some tremendous work carried out over the years by various working groups and researchers, to raise the bar on web accessibility. It’s great to see that good accessibility has become an example of best practice within our industry, which in turn has had a positive impact on the workflows of designers and techies alike. Some might say that accessibility has dumbed-down creativity and made the web bland – I’d argue that we just haven’t been creative enough.

I came across this note recently, from an article written by Brian Kelly, summarising a paper he has co-written:

Disability is therefore a social construct and not an attribute of an individual. In particular, resource accessibility is the matching of a resource to an individual’s needs and preferences – and is not an attribute of a resource.

That really got me thinking about our perception of accessibility, and in particular the ways in which we view the people we are trying to help.

Accessibility is generally considered to be a way of helping those members of society who have a disability. We often think of users of websites as use cases, rather than individuals: a particular demographic, in a particular geographic location, or a group who behave in a particular way or have common interests.

And it’s often quite easy to fall into the trap of thinking of someone with a disability in a similar way – as a generalised group: someone who is blind, who is deaf, who is a wheelchair user. The fact is that not every disability is the same, and the acuteness and combinations of a disability can effect people in so many different ways.

For example, it may well surprise anyone who knows me to learn that I’m registered as blind. That doesn’t mean that I have no vision, it means I have low vision. Technically, I’m referred to as “blind/severely sight impaired” – there is a point at which my clinical diagnosis puts me into a particular group and classifies me as disabled.

But I’m a web designer, I make films, I do all sorts of outdoor pursuits my doctors cringe at – how can this be? Well, the fact is that because of the complicated nature of the various eye conditions I have, although my distance sight is useless, my near vision is pretty damn good: I might not be able to see a face across a room, but when I’m working with pixels, I’m on an equal footing.

I don’t really consider myself to be disabled, because I’ve spent my whole life learning to adapt and compensate. Out of necessity and downright stubbornness, I’ve had to shape my world to make it fit my wants and needs.

And that, I think, is a good starting point for a new way of looking at web accessibility, and why Brian Kelly’s words struck home so hard.

We, as practitioners of the web, should be creating experiences which are not just accessible to all, but which are intelligently designed to be adapted to a user’s own specific preferences.

And I think this is important to start thinking about now, because the way in which we all engage and interact with the online world will continue to evolve at a rapid pace. Our experience of the web is changing: from one where we visit websites, to one where we access services and information through our personal choice of digital devices. Our experience of our online world will become ever-more personalised and ubiquitous. And if we don’t consider the wants and needs of people with disabilities, then we run the risk of marginalising huge swathes of our society.

As we develop new devices, new applications and new experiences, there’s going to be a need for a more integrated, considered and downright innovative approach to design. But by taking that leap, by daring to think about inclusiveness and allowing the design process to be informed by more than just aesthetics and one-size-fits-all usability, there might be huge benefits to be gained by everyone, able and disabled – we will all be enabled on a level footing.

If you’re sceptical about these yoghurt-knitting ideas (and yes, they’re vague, but they’re just that: ideas) then head over to the Accessibility section of Apple’s website, have a good browse around, and then ask yourself: why would one of the premiere designers of digital technology commit so much time and resource to building accessibility into their products?

North is a series of events and activities taking place throughout 2009 and 2010 aimed at inspiring creative professionals to do things differently. We’ll be announcing more details, and info on how to get involved when the website launches.

While we weather the transition from the old (lacklustre, temporary) site to the new, it’s necessary for us to put up one of those really annoying “under construction” messages. I wanted to keep it brief (all efforts are on producing a fully fledged website with lots of whizz-bangs) but still pleasant to look at.

So, I ended up throwing a few web conventions out of the window and implementing a “stretchy” design. You can see the current holding page here, and if you resize your browser window, you’ll see the whole background resize with it.

“Holy heck Phil, how the devil could you conjour such wizardry, when CSS doesn’t support scaleable backgrounds?” I hear you cry. Well, lawks, it was quite easy really: I cheated.

The background is actually just a div containing an img with it’s CSS dimensions set to 100%. Backgrounds don’t stretch, but elements do, y’see.

Then I bunged in a PNG fix, so that the logo could be rendered with an opaque PNG file, set up some quite simple rules for centering everything, and there you go: a nice stretchy page which goes against some CSS conventions, but looks nice, is semantic(ish) and accessible.

here’s the CSS code for this witchcraft, if you’re interested

body {
  margin: 0;
  padding: 0;
}
#background {
  width: 100%;
  height: 100%;
  position: absolute;
  left: 0px;
  top: 0px;
  z-index: 0;
}
.stretch {
  width:100%;
  height:100%;
  vertical-align: middle;
}
#content {
  position: absolute;
  top: 50%;
  left: 50%;
  margin-top: -75px;
  margin-left: -139px;
}