Equal Access

March 20, 2009

All Way Stop
I should preface this by saying that I’m not an accessibility expert but, not to put too fine on it, a lack of expertise has never stopped me from giving people advice. I’ve done some work for the Joy Maclaren Centre at Carleton, through some family and friends I’ve got some skin in that game and (of course…) I tend to get on a rant when I’m talking about stuff that I think is important. Which is, I expect, how I got roped into this.
Following a discussion about the merits of Firefox as compared to Internet Explorer (the case for IE being Sharepoint integration) I told him that above my security concerns, the main reasons for my advocacy of Firefox revolve around open standards and open accessibility. I suppose this was tipping my hand, to the manager of web development no less, but he jumped on that and pretty soon he’d roped me into making a presentation to his team on the subject.
Below is a roughly idealized (and therefore, in truth, somewhat false) transcript of that talk – it was originally delivered (at my french-language workplace) in a sort of functional english-french pidgin, switching back and forth between them to try and get my point across as best I could.
I’ve translated and block-quoted my slides here rather than providing the original PowerPoint, which would be a little inappropriate considering. So here goes:


So, let me begin by saying that I’m not an expert, and that there’s a lot more to cover than we have time for. But I’m going to try to give you an idea, I hope, of what accessibility means, why it’s worthwhile to bother at all, and where to get start.

Three Reasons

  • Social Responsibility
  • Greed
  • The Law

There are a couple of good reasons to aim for accessible websites, but these are good ones. If you’re not going to buy the straight-up social responsibility angle then greed, like the line goes, works. Greed is good. As web developers, being able to build sites that meet accessibility criteria is something you can put on a resumé, something worth money. And in our line of work, as a government-funded organization, it’s going to happen either way; website accessibility is mandatory for government agencies now, and if it’s not mandatory for government-subsidized organizations yet, it will be soon.

Generally Speaking

  • Visual impairment
  • Hearing impairment
  • Mobility impairment
  • Learning disabilities

Broadly speaking, there are four categories of disability with respect to accessible websites; visual impairment, hearing impairment, mobility impairment and learning disabilities. There are some subtleties here, and this isn’t a checklist – you don’t want to pick one to work on at the expense of the rest. Visual impairment, for example, covers everything from reading glasses and colour-blindness to macular degeneration and absolute blindness. Mobility impairment might mean an inability to do any kind of fast-twitch movement, and might equally mean that a person can’t single-click reliably or interacts with their computer only through voice-control software.
Finally, learning and cognitive disabilities, which may be the most challenging to address, but which are also more common than you’d think – dyslexia counts, but so does plain old not speaking the language the site was written in.

The Joy Maclaren Adaptive Technology Centre
Screen readers
Screen magnifiers
Braille screens
Keyboard shields
Adaptive software
( Jaws, Dragon NaturallySpeaking, others)

My own exposure to these technologies and their users comes mostly from time I’ve spent working with the Joy Maclaren center at Carleton University. We did a fair bit of work for them to get a number of these things to work together, and getting all of those things to work right or at all was often really difficult, even for experienced, fully-able administrators. I’ll get back to this in a moment, but one important point that I want to make today is that very often the installation of adaptive and mobility software can be quite a challenge, and my experience has been that upgrades are something to approach reluctantly and with quite a bit of caution.

[ Picture of a mysterious device ]

But the other side of that is that there are some really remarkable tools available in that space as well. That picture right there? That’s a laptop. And not some half-assed compromise, either; that’s a braille screen and a keyboard, runs Windows and lets you write up essays and you can connect to a network and use the web just fine. That thing is all solid-state, fits in a woman’s purse, weighs two pounds, has wifi and great battery life; aside from the fact that it doesn’t have a standard keyboard or a standard screen, it’s the laptop we all want.

[ More detailed, informative picture of the aforementioned device ]

Your information comes to you with the help of that line of braille down at the bottom there but when I met the woman using it, she claimed she could get thirty words per minute out of it. Now, she’s not going to be getting the same experience of the internet that somebody fully sighted would, but that’s fine. We’ll revisit this later, but her experience of the internet doesn’t have to be the same as yours for it to be equally valuable to her.

The disabled are not second-class citizens.

And if you take nothing else away from what I have to say today, it is this. The people for whom we are making our websites accessible are first-class citizens of this province, and of this country. They vote. They pay the taxes that, in part, pay us, and not only are they entitled to derive as much value from our efforts as any other citizen of this province, it is a personal and professional failure on our part if we don’t make that happen.
I have a blog. I take pictures. And my parents are aging. My parents already need reading glasses, and one is getting a little hard of hearing. One grandfather is essentially blind. But here’s the thing: I’m proud of what I do, of what I create, and I want my friends and family to be able to see it, to read it. To get it. And if they’re going to keep doing that, it means that I have to get better at making what I create as easy for them to get at and understand and interact with as possible.
People with disabilites cannot have the same experience of a website that fully able people can. It’s just not possible, and people who are setting the bar at “equal” are setting you up to fail. So that can’t be the goal; you need to give everyone looking at your site equivalent, but not equal, access to that content.

So what do we do?

This isn’t really a simple question, but I’m going to start with a simple answer. Well, in truth, I’m going to start with what not to do.

Don’t retrofit.
Don’t even try.

Accessibility isn’t something you can slap on a site like a fresh coat of paint. Trying to retrofit a site for accessibility, particularly in this modern age of complicated back ends and content management systems, basically means doing the whole thing again. But you’ve got a site redesign planned, right? I know you do, because all websites always have a redesign in their future. But that’s your opportunity, that’s the time to work on accessibility. When you can integrate it into your forward planning and make it a part of the process, not when it has to be a laborious afterthought.
And the benefits of that integration, in this modern age, can be huge. Not just in terms of accessibility, but for long-term productivity and asset management there are huge economies to had further down the road, when the redesign after that comes due.
So, what can you do?

Use Open Standards

  • W3C – HTML4, SMIL

Well, this. Use open standards. Please, use open standards. Well understood, publicly-documented, validated formats are the ones that are going to work reliably with accessibility software, that are going to work properly with screen readers, that are going to work right with a world full of software you might never even need to know is out there.
I know we’re a TV station, too, but there’s good news on that front. The SMIL standard, the “Synchronized Multimedia Integration Language”, is a way of adding text information along with video, so that as with subtitles, people who can’t see or hear video can still get value out of what we make. SMIL is actually better than subtitles in a lot of ways, and most modern media viewers support that format.
The WHAT-WG people, the Web Hypertext Application Technology Working Group, are busily creating the next generation of web standards, and they’re doing it with usability and accessibility very much in mind. That process is still ongoing but they have a very public development process, so if you’re interested in following along or participating, you certainly can. HTML 5 isn’t carved in stone yet, but it’s coming, and whether you’re interested in accessibility or not you’re going to need to know about it.
Use standard HTML. Use SMIL. But maybe the most important thing you can do, more than anything else, is this:

Use Text
It’s accessible to:

  • Screen readers and magnifiers
  • Braille screens
  • Other standard accessibility tools

Fallback Media

  • <alt = >
  • <title =>
  • <longdesc = >

Use text. Use text. I’m begging you, use open standards, and use text. Wherever possible and wherever you can. Text works. It works in screen readers, magnifiers, braille screens. Don’t use pictures of text, and don’t fill your screens full of spacer gifs to make it look just like the mockup you put together in Quark or Photoshop. We’ve all done it, but the world is past that now, and CSS stylesheets mean we don’t need to spend any more time wedging transparent one-pixel-by-one-pixel gifs all over the place to make things look good.
Use those three tags, for every image, every time. Most of your automated tools will generate content for the first two already, but they’ll usually just give you the filename in both the “alt” and “title” slots, and nothing at all for the long description. That’s not good enough, and won’t get anywhere near the equivalent experience we’re aiming for, but putting the work into those tags can pay huge dividends in the long term in areas you wouldn’t really expect. Good titles, good descriptive text and good long descriptions doesn’t just mean that the site becomes accessible to disabled users, it also means the site becomes more accessible to search engines, asset management tools and other automatic processes in ways that were never possible before. It means that users who don’t speak your language can take better advantage of machine translation; it means that three years from now, when you need to find that one picture you had of an afternoon at long beach you can do it in a heartbeat with a keyword search instead of having to flip through dozens or thousands of archived photos, and your asset management tools become that much more effective at actually managing your assets.
This, on its own, will get you an awfully long way. But it’s not all that needs to be done, and again, this isn’t a list of things you can cross off or some sort of accessibility pixie dust you can just sprinkle over a site to make it work, but it’s a critical part of the process.

Test. Validate.
Aim for equivalence,
not equality.

There are tons of free tools out there you can use to validate your websites, to make sure that they’re compliant to the documented standards. Test your site in that. Test by putting your hands in your lap, and trying to navigate around your site using voice control only, with Jaws. Test, validate and test, and aim for equivalence. Not equality but equivalency; make sure your site has an accessibility statement right up front that you have to live up to, and then live up to it.
Because there’s one other thing you should be aware of.

Accessible systems are often brittle

  • Installation
  • Making it all work together
  • Updating software is hard
  • Installers are a disaster

And you’re not going to like this, but it’s something you should be aware of. Even for me, an able, experienced systems administrator, making different pieces of accessibility software and hardware work properly together is hard. It’s genuinely capital-H Hard, and the people I know who rely on them are reluctant to upgrade and have to be exceedingly cautious about it when they do. The version of Jaws or Dragon that they bought and learned to use, at a substantial investment of time and money, might not survive an upgrade to XP or Vista. Software that worked fine on the version of Java they have installed might never work again if we upgrade to the latest version.
And this is going to be difficult for you, professionally. We all want to learn the latest cool new technologies and we often feel that we have to, just to keep up; if I go into that job interview saying that I’m comfortable with Flash 5 when everyone else in room is thinking about Flash 10, that’s a no-hire flag. But when your audience is legitimately wary of upgrading, because the risk of something they need just not working anymore is very real, you’d better have a damn compelling reason for forcing them to upgrade a plugin.
Because as far as accessibility goes the average software installer is a war crime. You want to brush off somebody with a disability? Force them upgrade Flash.

This is not just for the disabled.

Because there is no “them” here, not in any meaningful sense. Next time you go to an Italian or German opera, and follow along with the surtitles? That’s an accessibility technology. And I say again, these efforts ultimately pay off in lots of different ways, not the least of which are the first three I mentioned: social responsibility, legal obligations and greed.
Thanks for your time; I hope that was useful, and I’ll forward some useful reading on to you when I get back to my office. If I can answer any other questions for you, let me know.
… and that was the end of that. I closed off by playing the Four Deaf Yorkshiremen video, a play on the old Monty Python “Four Yorkshiremen” bit, which got a few laughs, and which I got to point out was only funny (or useful to the audience at all, in fact) because of the subtitles.
The two major sources for this talk were Joe Clark’s excellent Building Accessible Websites and Mark Pligrim’s also excellent Dive Into Accessibility, both available in their entirety online. And by “sources”, I mean “were largely cribbed from”. But I also referred people to the W3 Consortium’s Accessibility Quicktips page, as well as the Ontario Government’s Accessibility page.
I’m going to go over this in the next few days, add links in where I can, better (where “better” is “more than none”) footnotes and more references, but I’ve been thrashing at this for a few days, and wanted to get this first version out. Comments are always welcomed.