We don’t talk about accessibility much here (because there are people who are much better at talking about it than I am), but I have come across two really interesting posts lately that I think you should take a look at if you haven’t already, and if you’re in any doubt as to whether – as a UX person – accessibility is part of your responsibility.
Over at SitePoint [Why Accessibility – Because it’s our job!] James makes it clear that he thinks that accessibility and usability are intricately entwined. More importantly, I think, he re-iterates that in most cases, it takes not that much more effort to make a site accessible in the first place.
Jeremy Keith also takes up the cause on his blog [Ignorance and Inspiration] quoting some truly ignorant responses to the recent Target lawsuit, but also pointing us to these great videos of people using assistive technologies to interact with the internet and other software. [via Richard Johansson ].
They are really quite inspirational and make it clear that even in the face of significant physical restrictions, peole are able to do pretty amazing things with their computers… if we design and code in such a way that allows them. In fact – they manage to do some pretty amazing stuff in the face of some pretty crazy design and coding as well.
Yes, it is true that many clients that you work with will not have a very active interest in accessibility. I have lost count of the number of times that I’ve been told that ‘blind people are not in our target audience’. Not to start in on the fact that making your site accessible is about much more than just people with visual impairment….
There once was the perception that making your website accessible was a time consuming and expensive exercise. That is far from the case. The fact is, a standards compliant site is most of the way to being accessible – this is the way we should be coding our sites anyways!
There are still lots of ways for designers to screw up accessibility, and I think that a lack of exposure to how our work behaves for people using assistive technologies means that we don’t understand the impact of the decisions we make sometimes.
Developing an understanding and awareness of simple ways to avoid common accessibility problems, and ensuring that, as we design, we spend just a little time checking our work to make sure that we’re making life easier and not unnecessarily difficult will provide lots of benefits for very little investment.
As the advocates for user experience I think it’s important that we’re advocating for *everyone’s* experience and perhaps doing a little bit more than just whispering the word ‘accessibility’ in a meeting early on and allowing it to be just as easily dismissed. And not just because of the potential legal implications, but because it’s our job.
What say you?
Just to clarify the chronology, James posted after I did. As he said in an email to the BritPack list, “Thanks for dragging that up again ;P I’ve now had to spend a morning writing a blog post for SitePoint to “clarify our position.”
My argument is usually similar to what you quoted on it not being that much more effort to make something accessible. Not making a design solution or code output accessible is sloppy work in my mind. If you follow bare minimum standards you are gold in this area.
On a related note, I’m curious at what impact making a persona blind or having mobility constraints would have on the design process. Not forced so that the disability becomes central to the persona, but just as an attribute, like this persona happens to be blind the same way they happen to be black or happen to be gay or happen to be divorced.
That’s nothing. I went to a drive thougrh ATM and it had braille on it for all the blind drivers that wanted to withdraw money from the bank in their car.With the sentence: These instructions are provided in braille for our seeing impaired customers. The only possible reason for that message is to make me think my bank cares about the disabled.
Leisa, it’s *Roger* Johansson, not Richard :-). Otherwise, I says Right On!
thanks Jeremy… I’ve taken out some of the chronology-suggestive terms. I didn’t check whether the forum posts or James’ post happened first on SitePoint.
Liv – I’ve had personas with accessibility issues in the past and found them to be quite useful… however a lot of getting accessibility right comes down to the detail work – what a button says and where a form sits compared to links that are related to it, for example. I’m not sure personas help at that level.
Lisa Herrod talked a bit about this at the recent Web Directions South by the looks of things… here slides are here: http://www.webdirections.org/resources/lisa-herrod/ I think there’s an audio track coming soon.
Marrije – oops! of course it’s Rodger. Where’s my brain. I’ve gone back and fixed that now. Sorry Roger! (Hopefully he didn’t even notice)
As an IA (or EA at my current gig) who has come to my current role through a large amount of actually building interfaces as well as designing them I am often disappointed by the lack of knowledge around this topic in the ranks of IAs. There is a lot about accessibility which is the domain of how a site is built and a lot that relies upon the relationship between the designer (informational and visual) and the developer but I really like your musing about simple ways to increase accessibility. Like usability there are a whole bunch of things we can do to just avoid making the interface worse.
This is one reason why I think watching the videos like those linked to above is so useful, as you can begin to have an understanding of the user’s needs. Sort of like watching a usability testing session for the first time.
What I think is often missing is that improved accessibility means more accessible to ANYONE not just those with specific/profound disabilities (e.g. blind, deaf, mobility, etc). I like the use of the term ‘universal access’ over ‘accessibility’ for this reason.
Adding closed captioning to a television broadcast doesn’t take away from my ability to hear it – but it adds to my ability to read it (in the gym on the treadmill, or while my mom takes a nap so I don’t disturb her). Accessibility/Universal Access isn’t about reducing one person’s experience for the sake of another – it’s about adding to the experience in an elegant way to heighten the experience for everyone.
There is a very good chance that at some point in our lives we will all experience a reduction in our abilities (this is usually called getting older). The next time someone says “blind people aren’t are target audience” ask if they want to reach the graying baby-boomers.
A designer that doesn’t understand the varied abilities and backgrounds of their users is ignorant. A designer that is aware but doesn’t care about their users (or worse, blames the user for their ability) is a bigot.
Totally. There’s a tendency for people to say “but how many blind scientists/lawyers/truck drivers” do you know when building sites for target markets, and it becomes tiring giving the same response. Things I’ve discovered, though:
– people tend to shut up when you tell them that their number-one blind user is Google. You don’t even need to mention SEO; the fear of poor search traffic is surprisingly effective at encouraging clients to demand better.
– copy, layout, and traditional design elements contribute as much to accessibility as nifty semantic HTML and trickery. Often, fixing copy fixes a lot.
– most accessibility issues with interface design I’ve seen emerge from people trying to build un-weblike interfaces: usually beginning with desktop idioms like drag/drop, for instance. It’s harder to reverse-engineer straightforward GET/POST interfaces onto this, than to progressively add rich interfaces to traditional websites. Trying to convey this to the people wireframing and specifiying (who, it seems, so rarely are designers or developers) is hard, but worth it.
Actually the main premise of my presentation at Web Directions was that User Experience Design is incomplete and unbalanced unless accessible design practices are implemented at every stage of website design, from initial research through to site launch. Key characteristics of users with disabilities need to be included within our primary personas. If we fail to incorporate accessible design practices throughout a project isn’t it really just ‘selective user experience design’?
While it’s important to consult with UX practitioners who have expertise in accessible design, we also need to recognise that every member of the team has specific responsibilities that impact on site accessibility. For example, some WCAG checkpoints are specific to the IA and others to the content developer. There are some that really have nothing to do with the FE dev at all. So when accessibility is integrated within UXD, focus on the cost of accessible design is significantly diminished.
An article based on my presentation and the Slidecast will be published soon.
I saw Lisa’s presentation at World Usability Day in Sydney (same one as at Web Directions – right Lisa?). What really struck me was the fact that accessibility really is the responsibility of more than just the developers and that checkpoint compliance and associated tasks should be allocated across the project team.
On another note, I have recently been involved in some ‘joint’ workshops with all aspects of the development team (IT, Business, Design, UX) and the outcomes were dramatically improved that had things been ‘thrown over the fence’! After all, I see a UX practitioners job primarily communication (in a language that everybody understands) across all facets of a project, is it not?