The Art of Accessibility

Some designers and developers object to having to cater for accessibility. The argument I’ve heard most often is that the demands of accessibility are too restrictive, limit creativity, or undermine design aesthetics. In other words, accessibility limits artistic freedom, and that’s unacceptable.

I could try to refute that on the grounds of practical ethics — the aesthetic preferences of one are simply not important, when stacked up against the functional needs of another.

But there’s another way of looking at it, less likely to be seen as an accusation, and perhaps more strongly resonant with the nature of the creative mind; and it’s this — a restriction is also an inspiration; an issue is an idea.

Playing psychological tricks on ourselves

It’s said that necessity is the mother of invention — you never really look for something until you need it. If we think of accessibility requirements in terms of the need for invention, then each of us as developers have the chance to be the mother! The requirement of accessible web-development is to build the sites and apps we want, without creating [needless] barriers to particular groups of users. And this doesn’t have to be a problem to frustrate us, when it can be an opportunity to elevate us.

Child psychologists are often great proponents of reverse-psychology. If the child is bored because they can’t think of anything they want to do, then give them something they don’t want to do, that’s tedious and un-enjoyable. You can bet it won’t be long before they think of something more fun!

We’re all children at heart, and we can use psychological tricks on ourselves to deal with creative barriers. If a requirement of accessibility says you can’t implement feature x because of conflict y, let your child-mind complain, oh, but I really wanted feature x!. Then your rational-mind can jump-in and say, okay. so how can we do that without causing conflict y?.

An easier way to deal with that would just be to shrug and forget it, like oh well, we just can’t have feature x, or maybe, conflict y will just have to hang (after all it only affects a minority, and everyone knows, minorities don’t matter!). Bad developers are always telling their clients what they can’t have. Good developers are looking for ways to make things happen anyway. View accessibility the way an artist views the nature of their medium; after all, what is art, but the resolution of a challenge?

Would Michelangelo’s David be regarded as such a masterpiece, were it not so rare and difficult to produce a work like that? Would Isambard Kingdom Brunel still be held in such historical esteem, had he not produced so many innovative solutions to the engineering challenges of his day?

Nothing worth doing is easy.

A parable of headings

Many years ago, when I was developing a commercial drop-down menu script, I wanted to make it easier and less confusing for screenreader users to navigate internally within the menu-content list. A large, complex and multi-nested list of links can be quite slow and disorientating to use in such devices, when there are so many links, and the device gives little or nothing in the way of inner structural cues (eg. most give no information about the nesting of lists, when they start or end).

The solution I eventually came up was to use internal sub-headings, for example an <h3> wrapped around each of the top-level links. Most serial-devices have a “headings list” or “headings-reading mode”, which allows the user to jump around the page using the headings as targets. So lacing the list with headings provided a degree of random-access, to each of the main branches in the menu tree, via this mode of navigation. And it did so in a way that was appropriate and semantically correct.

Later, I developed this technique into the more general use of headings as an aid to navigation for screenreaders, text-browsers and other serial devices. By lacing a page with headings that describe and preface sections of content, users are able to find their way quickly to sub-sections of any page. I referred to them as meta-headings, but they’re now more commonly known as structural labels.

You can see them being used right here on this page. If you disable CSS, you’ll see how primary sections of content — such as the site navigation, search box and footer-links — are preceded by structural headings that describe their function or content; together they describe the overall content-hierarchy of the page (which you can see in Opera using View->Style->Table of Contents). They allow the user to jump instantly from one section to another; it’s easy to see how useful that would be in a linear-access device (like looking for clips on a DVD rather than a video-tape). But the random-access mechanism itself already exists in the technology, we’re just playing to that, by providing it with data.

The point is…

As useful a technique as this is, it’s not the real point I wanted to make. The point is, it stemmed from a mind-state which viewed accessibility as a challenge, not a burden. If I’d simply shrugged at the original issue, and just said well that’s as good as it gets, then I’d have never found that solution, and never have developed it into such a simple and invaluable way to improve accessible in-page navigation. (Not that I’m the only person to have thought of it; but the point is there nonetheless!)

History is replete with examples of problems giving rise to inspired solutions, some so useful that they far transcend their address of the original problem. Technologies and materials designed for the space-program are now found in countless domestic products (like smoke-alarms, drinks-containers and toothpaste). What was once intended to provide post-apocalyptic military intelligence went on to revolutionise how the whole world does business (you know that one!). And perhaps most poignantly, a system originally designed for soldiers to communicate covertly at night, was developed into a writing system that millions of people who are blind rely on (braille).

If life has taught me anything, it’s that problems are always easier to solve when approached with a positive attitude.

And if all I can do by writing like this is to help spread an attitude of enthusiasm and pride, then I consider that a job well done. It seems like people don’t talk about web accessibility as much as they did a few years ago. Certainly, I’ve stopped thinking of it as such a major deal, but that doesn’t mean it’s solved, or gone away. It’s just become another ‘thing we do’ — just another part of what it means to be a professional web developer.