Magic Torch

This article on northtemple says a lot of what I was trying to say in the previous post, except a lot better. And it hits the most important point, which I totally missed.

Accessibility starts with empathy. As just about everything in web design and development starts with empathy. If you have no empathy for your users, you are going to fail. You are particularly going to fail if, at the first sign of things getting tricky (“we need to think about accessibility”), you switch off your empathy for a user and reduce them to someone you can afford to have not use your site. Not least because it is never “a user”. It is the user you thought of and the literally tons of users, doing things almost the same way, who you have no idea about, because you really aren’t that clever.

Note: This entry was originally published on the mother-blog of EquatorLive. And when I say “originally”, I mean about 5 minutes before I put it up here.

Accessibility on the web has always had a bit of an image problem. Being sensible at the cost of interesting. You could be one or the other and most people went with interesting. And even when it was taken seriously, it was always presented in the same way as accessibility is presented in the real world: As an add-on that sat on top of the original and ruined its lines. If you didn’t want to compromise on your main site experience, you would have to go to the trouble of creating a “text-only” version that you could divert disabled people (because who else needs special access?) towards.

That was then. And in between then and now things have definitely improved, but the feeling remains. That in properly addressing accessibility you have to compromise the user experience.

“How to increase the text size on your browser!”

At Equator we take accessibility seriously. It’s something clients almost always ask for and something we deliver. We have the checklist and we tick all the boxes on it. Alt tags on images and other non-text media (at least most of the time). Well-ordered content, arranged by importance and priority on the page (almost always). Semantic, structural markup (apart from the markup that isn’t, but there really isn’t much of that). Good job, pat on the back.

I imagine this way of looking at accessibility isn’t too different from the way most other people (who care) think about it. It’s all about compliance. You’ve got to be compliant! It’s a pain, especially when you forget about it until the last minute (Yes, hands up who has been to that special place). But you do it, write the blurb for the accessibility policy page and maybe even put some kind of tick-based logo in the footer.

Meanwhile, in the 21st century

This attitude is missing the point entirely. Accessibility is not a checklist or a chore. It’s not washing your hands before you eat dinner. It’s a fundamental part of how you make the web work.

Accessibility is about letting as many people as possible experience as much of the web as possible. Even the useful and complicated parts. Especially the useful and complicated parts.

It’s simple: If you don’t consider accessibility as a fundamental part of your design and development process, you are making bad websites. Not just inaccessible websites. But straight-out crap websites.

Compromised websites, most importantly. Long gone are the days when the only way to build interesting websites, using tables to lay out and presentational markup to style content, was at odds with the principles of accessibility. We can do both now. We have to do both now.

The web is not novel anymore. It has matured at a tremendous speed and users no longer expect to be passive consumers of what it has to offer. It is a massive toolbox of stuff that helps them get things done. We’ve noticed it ourselves. We don’t really create websites anymore. We develop web applications. Hopefully for as many people as possible. If we leave out a group of users because it was too much bother or we forgot, then someone will take the time and take those users. A compromised website nowadays is one that isn’t accessible.

Everybody needs an accessible web

Today, the way to creating an accessible web experience is actually pretty straightforward: Get out of the way. If people have a need for web content to be presented in a certain format, they will generally handle that certain format themselves. What they need from you is content and functionality without any conflicting formatting from you.

This is where Web Standards comes into play in a big way, and also why accessibility is a fundamental effect of a well-built web experience, as well as an important feature.

Web Standards treat content, presentation and behaviour as separate pieces of an overall experience. Therefore, a user can pick and choose which of these elements they require and which they can replace with their own, custom versions. Such as converting text content to audio, instead of applying all that carefully crafted CSS to it.

You keep the content and presentation separate and you really don’t have to do much more to make it all accessible. It’s all about giving the user control. The trick is that if you understand how the web is meant to work, which is what the Standards are all about, that is exactly what you are doing.

Growing your own guidelines

It’s always a bit more complicated than that, of course, but luckily the experts at the WAI have done the hard work for you, in producing the guidelines for achieving good accessibility. Sort of.

At the beginning of the year, the working draft of version 2 of the guidelines was published after approximately a lot of years in development. And they were certainly different from version 1. The original guidelines focused on the technologies that the W3C set the standards for, HTML and CSS being the main ones. So there was a fairly well-defined list of things to tick to achieve a certain rating.

The new guidelines are bit more general purpose. They don’t deal in specific technologies, but are rather focused around a set of 4 principles. An accessible website or application, built using any technology, should be: Perceivable, Operable, Understandable and Robust.

How you achieve these principles is trickier to nail down. What you have to do, to some extent, is create your own set of guidelines based on the what you use and how you use it. There is plenty of content provided by the WAI, covering the kind of things that the 1.0 guidelines talked about, but it’s just a stepping off point. You need to understand and fill in the blanks yourself.

This is pretty daunting, but doing it will give you a deep understanding of how to create better solutions to complex accessibility problems, not just complying with a list that someone else cooked up.

Show me the money (or nearest equivalent)

This is all very interesting, I’m sure you’ll agree, but how about an example of how accessibility really matters in one of the most important ways people use the web. It’s to do with the web’s biggest user and the fact that they are disabled.

Picture a typical web user for whom accessibility is an issue. Of course, there isn’t a typical one, but try anyway. If you are like me you are maybe picturing somebody blind, using a screen reader to browse the web? The biggest user of the web isn’t too different from that stereotype. They are called Google and they really appreciate accessibility.

Google browses more sites and more content than any of us will ever find in our whole lives. It notices when it can understand a site because the content is presented in an accessible way and when it can’t because the content is dependent on JavaScript (which it doesn’t run) or lacks alternative descriptions for non-text media or is just badly organised. It has an opinion about this, too. This opinion affects where your site ends up in a Google search. And it’s only going to matter more in the future.

In the future there will be robots

Google is an extreme example of how the web is going to work more and more in the future: most of the actual surfing isn’t going to be done by people at all, but by software acting for people. There’s already too much content out there for us to deal with. We already need RSS-based aggregators and software agents to pull content to us in a form that we can digest more easily. We are all becoming, more and more, disabled users. Our disability is a lack of attention and time. The result will be simple. Accessible content and functionality will eventually be all we have time for.

I’m just finishing off “Designing for the Social Web” by Joshua Porter. It is an excellent primer of the kind of things you need to be thinking about if you are building a web app that contains even a small amount of the “social”. Although if your web app is the most socially unconnected and closed-off piece of software out there you still need to know the sea you are swimming in, because social web applications are already the standard for what most users expect the web to be like.

Any kind of social feature is tapping into deep human wiring, millions of years old. This is the kind of stuff that got us past all those saber-tooths and mammoths. It’s very powerful and hence very terrifying to contemplate resting the success of a website on understanding it correctly.

More to come on this.

We Interface Developers have been talking recently about the range of browsers we support and test our sites against. IE8 is threatening to be released any day now, and almost as importantly it is definitely not threatening to kill off substantial use of IE6 and/or IE7 anytime soon.

So we have a trilogy of different Internet Explorer browsers doing things their own, interesting ways. Plus the Webkit and Gecko-based alternatives, like Safari, Firefox, Camino and Chrome (I would call these necessities rather than alternatives, but I’m still in the minority according to the stats).

It means a lot more work for Interface Development. In the same amount of time. So instead we need be smart and not just keep the smartness to ourselves.

Up until now we’ve been able to support a fairly generous production process, in terms of what the client has been getting. That is, sites that work and present themselves pretty much identically in all the browsers we support, IE6 included. Working that way is the result of many things, not least the fact that our team really knows what it’s doing when it comes to wrangling angry browsers.

But a new perspective is needed. One that recognises that treating all browsers the same actually does more harm than good in the long run.

I’m a bit obsessed when it comes to clean, semantic markup. It’ll tend to the be the first thing I look at when studying a site. You may be rocking the best visual style the world has ever seen, but you’ll not get any opinion from me until I’ve hit “view source” or fired up Firebug and checked out the DOM. At which point it can all go horribly wrong.

Of course, being an inhabitant of the real world, an attitude like this is tough to maintain when you are actually making web stuff, and compromise is never a bad thing when a deadline is approaching or an extra bit of markup gives a more robust finish.

But priorities and expectations about the web have changed radically in the last couple of years, such that compromise on markup standards has become a luxury rather than a necessity. We don’t have time to keep hauling struggling browsers along at the same speed as the pack leaders. We have to accept what has always but which we’ve been able to ignore up until now: All browsers are not equal so they should not be treated as equal.

We need to adopt a approach of Progressive Enhancement and make this the core of our process. We need to allow flexibility in the user interface to give enhanced functionality across all browsers.

The best browsers today can do amazing stuff given the chance. The worst browsers today can provide better functionality and speed given the chance.

How to achieve this is simple: don’t try and apply a one-size-fits-all interface, because actually it doesn’t fit anybody. The old browser struggles with the extra markup, styling and images. The new browser is stuck handling a legacy implementation it could run rings around given something fresher to work with.

And then the future turns up and things really get bad.

Let’s go the other way. It has frickin’ lasers and everything.

There’s a bit of team renaming going on the office right now. The front-end crew (of which I am a member), who previously had the awful title of Build Team, are now the Interface Development team.

I think there is something to be said for having a cool-sounding team name. I’d previously voted for Science Ninja Team but Interface Development is pretty decent. There is plenty of space in there to fill up with a heady mix of abstract ideas and 7-browser-tested bulletproof solutions. It’s something to live up to. Something to be owned.

The main thing I dislike about being a ‘Builder’ is that it doesn’t imply much in the way of… well, much of anything beyond the mechanics of putting the code together. All the deep thought having already been taken care of by the Design team. All the fiendish logic being hewn from the very living rock by the Back-end Application Development team. We in the middle, just stacking the bricks.

Well, f*ck that.

You want semantic information architecture so cunning you could brush your teeth with it? You want accessibility bleeding from every nook and cranny of a site, not just a crappy compliance icon in the footer? You want dynamic behaviour that works as much for the people who aren’t interested in it, as for the people who are?

Then speak to a Science Ninja Interface Developer at your earliest convenience, peoples.

John Gruber has an seriously exhaustive UI critique of the Safari 4 Beta over at Daring Fireball. I agree with most of it. I’ve recently moved back to using Safari as my main Mac browser after about 6 months of Firefox (I was in a forensic mood and Firebug kicks the Safari web inspector’s ass for hot code-perusing action).

But, Safari (3, at least) just feels part of the OS in a way Firefox doesn’t, and I was getting enough Firebug action at work so back I went.

But the nice feelings have pretty much evaporated with version 4. Mac UI conventions have been abandoned left, right and centre, and I’m having to exert substantial mental effort just to re-orientate myself with the bloody thing every time I use it.

Here’s one thing. A tiny, little thing that is driving me nuts.

I, like most people, love my browser tabs. I don’t go crazy, but I generally have 3 or 4 open at a minimum. With version 4, Safari has combined the tabs with the normally sacrosanct window toolbar. Many of the reasons why this is knob-headed are detailed over at the Fireball, but my one tiny thing is this:

When I click to switch tabs I clearly make some kind of a minute downward motion with the mouse. Previously this had no effect on the window as a whole. But now about 50% of the time, because tab and toolbar are one, the window gets dragged down a few pixels instead of the tab being switched.

I like my windows right up against the menu bar. Just how much is becoming clear to me, because I am starting to make strange moaning noises when the 3 pixel drag occurs.

UI anxiety is a laughably crap thing to have, so please stop giving it to me, Safari 4.

UPDATE: I gave in and changed the tabs back to the v3 configuration using the hidden preferences. The downside to this is that Safari no longer asks you the “Close multiple tabs?” question if you click the “close window” button. One thing replaces another.

ANOTHER UPDATE: Looks like the “Close multiple tabs?” warning does appear, after all. Must have unchecked the option at some point. Huzzah!

I headed back to A List Apart this afternoon to have another look at the examples from that Fluid Grids article. Except the URL got mucked up somehow and I ended up at the ALA 404 error page. Most of the 404s I’ve seen pull you straight out of the front-end of site and into the back-end code. Error, buzz, beep, string of unintelligible characters if you are really lucky. But not in this case.

Something has gone wrong but what you get are a couple of reasons why you are maybe where you are, a reassurance that this isn’t just some unnoticed hole in the site and a couple of sensible exit strategies. And an illustration. An error page watercolour.

It’s great. Not too serious, but also not dismissive. It’s matter of fact and doesn’t dead-end you. Most of all it sounds authentic. Written by someone to explain the real, human situation you are in (surprised and a bit lost), not the contents of a variable chucked onto the page by a bit of code. No “Error. This page does not exist.” bollocks.

After seeing this and experiencing it in the wild, I can’t see why you would do it any other way. A little thought about where the user is, and the best language to engage them, and… hours later, I’m possibly more impressed with the site for failing so well than anything else (the Fluid Grids article does rock, though).

My lunchtime reading today is going to be this ALA article by Ethan Marcote on creating fluid grids. That is layout grids that maintain their proportions whilst scaling to the browser window size. Very slinky they are too.

It got me thinking about the layouts we use here at the Equator. They are almost universally fixed-width and centre-aligned. Is this an artifact of the type of relationship we have with our clients, which is visual design-focused to a large extent?

As does the mock-up, so shall the site sit neatly in the middle of the page/window?

We should maybe embrace the slink. I have my calculator standing by.

Bit of house-keeping as this is my first post.

I’m Jamie. I’m a front-end web developer at Equator in Glasgow. I’m part of small-ish team that is devoted to producing the best-coded front-end web interfaces known to humanity (nothing wrong with aiming high, after all) and helping to understand the frankly weird and esoteric world of web user experience.

Right now I’m thinking about the evolving understanding of just what it is that people do with the web and what the web does with people. My general feeling is that assumptions based on other types of media aren’t going to get us very far. The curve is getting steeper, the strange, chaotic, emergent nature of the interwebs is ramping up. Best to hang on tight, because the human brain really hasn’t had anything to compare to this. It’s the future, after all.

But thinking about that kind of thing all day doesn’t really lead to much in the way of practical creation, except maybe for a small puddle of dribble, threatening to short-circuit your keyboard when you run out of metaphors. So I also like to think about (or wrestle with) the nitty-gritty.

Forms, for one thing. I have a bit of a love/hate thing going on with them. Nothing nittier or grittier than wrangling form elements across 5 or 6 different browsers. I’m sure they’ll crop up here fairly regularly.

Also the fact that web pages can be brittle if you hold on too tight to their design. One second they’re gleaming, aligned collages of design perfection, then a word count creeps too high or a typeface causes a funny reaction and, crunch, bones snap, limbs flail wildly and the whole thing just goes… off.

That antagonises me so much. If there is perfection to be found on the web, it certainly isn’t in the interactions of bits of software. So don’t bother looking for it there.

Anyway. That’s a fair amount of fluff to start with. Hopefully things will get a bit more comprehensible and useful as we go along.

So. What’s next?