Blog

A couple of weeks ago I attended the Accessibility 2.0 Conference, held at Microsoft’s extremely plush offices in Victoria. This was the first time I’d been to a conference on this topic, and the first thing that struck me was how human it was compared to the average conference. It may have been the wider-than-usual age range of the attendees, the obvious passion they felt for the subject, or simply the presence of several guide dogs lazily stretching during the talks. Whatever it was, it made for a conference with unusual warmth.

I admit I wasn’t sure what to expect, as my experience of AX (accessibility) to date has been a world of code, rules and grey areas. The fundamental problem as I always saw it was not in the application of rules but in a general mindset. Accessibility often means making a few code tweaks at the end of the design and build process, and many people’s experience of AX will be of getting a specialist agency to run an accessibility check on an existing site. The process of implementing AX from the start has always seemed very vague – who takes responsibility? Who should be involved?

Mark Boulton summed this up well in his excellent talk on Inclusive Design when he reminded us that a building that hadn’t been designed with accessibility in mind just wouldn’t make it past the blueprint. Can you imagine a multi-storey car park with no lifts? No ventilation? In the same way that it would be unfair (not to mention unrealistic) to expect the builders or engineers to deal with all this once the building was up, it’s unfair of us in the digital realm to expect the coders to “fix” the accessibility issues once a site has been designed. Christian Heilmann of Yahoo, who was part of a panel on “To comply or not to comply” made this point when he said that it shouldn’t be up to the developers to “tick the accessibility boxes”.

So how do we do this? Mark said the AX community needs to move beyond specs and acronyms, and become accessible itself by reducing barriers to understanding. But responsibility lies with the design community as well. “Design without constraints isn’t design, it’s art” – and AX must be treated as any other constraint, from the start of the project.

Another interesting point Mark made is that designers must expose themselves to the users they are designing for. This area is where I was hoping to find some answers to a problem that has bothered me for a long time. In usability testing, 5 or 6 participants per user-type are recruited to uncover most usability issues. Surely the same applies to accessibility testing? In which case, do we need 5 or 6 per disability-type? Across all the user-types? The cost and logistics of this type of exercise are plainly not feasible for most projects.

The panel accepted that this is an issue, and suggested that users should be recruited across all user types, and that a disabled user should be representative of that user type, rather than of that disability. I think this is a useful first step, and hopefully we will start to see more of this type of recruiting in the usability field. But usability/accessibility testing is again generally something that is done at the end of the project, or at least after the initial structure has been laid down.

The conclusion I’ve drawn from this conference is that the responsibility of ensuring our sites can be used by everybody needs to be taken away from the developers and laid down at the door of the information architects and designers. If we can build it into the very structure, navigation and design, then surely the developers’ task of building the accessible code will be made that much easier. And the first challenge is to educate our clients that AX is as important when designing a website as it is when designing anything else.