Accessibility from the ground up

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.

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 effectof 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.