I’m always amazed when I embark on a new client project at just how overlooked accessibility can be in the UX space.
As practitioners, I think we often mistake accessibility as belonging to the realm of content strategy. However, having a good basic understanding of accessibility can serve you well in your UX work.
What do we mean by accessibility?
Accessibility refers to the practice of making websites (or web apps) usable by people of all abilities and disabilities.
One indication of whether a site succeeds in this goal is how well it conforms to the Web Content Accessibility Guidelines 2.0 (WCAG 2). The guidelines cover three levels of conformance: A, AA and AAA. The requirements for A are not as strict as they are for AA or AAA. In order to meet AAA requirements you must also meet A and AA. For the record, it is not recommended you try for AAA unless it’s been deemed a requirement for the organisation you are working for or with (most organisations I work with aim for AA or A).
Incidentally, the Australian Government is in the process of implementing a Web Accessibility National Transition Strategy, which means all federal government websites were assigned the task of achieving A compliance by the end of last year, and of achieving AA by the end of 2014.
So where does your UX work fit into all this? Let me illustrate with some of my examples from the field.
Accessibility won’t destroy your brand
I was once brought in quite late on a project to assist a membership-based organisation flesh out the functional requirements of their new website.
The project had arrived at the “high fidelity design” stage, so the team had already made decisions about their users. Since this project also involved a rebranding exercise, the entire project was being run by a digital agency at the helm that knew a lot about branding and print media. However, when it came to web, well, not as much.
In the opening minutes of the meeting, we were presented with a mockup of the home page. The design was fine, but there were many improvements that could have increased the accessibility of the site. I suggested that they should include a Skip to Main Content link in the top left of their design. After explaining why it would be in their interests to add this text, the designer ruled it out with the response that “No, it will destroy the brand.”
Not one to remain silent (I consider my role to be that of user advocate) I listed all the reasons why I thought this was an oversight. Unfortunately I didn’t win this one and the site went live without it. This was a tricky situation for the branding company who had worked many months to get to this point—they were unaware of the value of this small change, as they had never had to think about web sites being accessible.
Why was I so insistent? A Skip to Main Content link is something that you can add to your wireframes and argue the merit from the beginning. Adding this link in the top left of the page means it will be the first thing that a user using a large zoom level will encounter (this is also a good comeback for those clients who request that you include this link in the code, but not on the screen).
When we think about accessibility, we need to extend our considerations beyond people who are legally blind. We also have to consider people with cognitive disabilities, the elderly, people whose primary language is not English, people who are deaf or hard of hearing, people who may have dexterity issues and are navigating the page with assistive technology like screen readers, screen magnifiers, or specialised mice. In the latest WebAIM Screen Reader Survey (2012) 18.1% of the 1782 people surveyed said they used Skip links if available, which showed an increase from the 2010 survey results.
Consider creating inclusive personas
Who are your users? This is where we begin a lot of our projects—and isn’t this the essence of user centred design?
A couple of years ago I worked with a large federal government department who were undergoing a very extensive change to their website. They had already worked with an agency to develop user personas, and unlike most web teams who tuck their personas into a drawer and forget about them, they had their personas pinned up on a central wall and referred to them by name when discussing the website or changes to content. The consideration they gave to these fictitious users was, to me, at the time a wonderful way to work.
As time passed, however, I felt something wasn’t quite right about their users. Then it hit me: they were all able-bodied, gainfully employed men and women of differing age.
A user persona is supposed to represent a target user group all neatly wrapped up into an individual. We give them a name, talk about their interests, habits, home life and how they use the client’s product or service. If that’s the case, shouldn’t we be more inclusive in developing our personas?
Consider adding a persona that has a learning disability or a broken arm. Perhaps one of your personas is in a wheelchair, is elderly, has a slow Internet connection, or (not a disability per se, but still a common hurdle) has a poor grasp of English. How would catering to these users change your site discussions?
To give your argument some weight; 16% of Australians have some form of dyslexia and 44% of Australians have poor or very poor literacy skills. In 2009 2.2 million Australians aged between 15 and 64 had some form of disability and over 480,000 Australians are visually impaired in both eyes and 50,000 of these people are blind (PDF, 2MB).
Ask a user with a disability to join your user workshops
One project that I worked on in a small country town saw me conducting an information architecture workshop, where we discussed the users of the site and their information needs. Time and budget were limited, so I set the stakeholders the task before the workshop of coming up with some personas. I gave them some very focused questions to consider, told them how the workshop would run and asked if there was a possibility of having users from the community assist us with a bottom-up card sorting activity.
Wow—the stakeholders were so engaged and organised, and enlisted the help of several colleagues and two community members, one of whom who was legally blind. The participants knew I did not have the facility to create braille versions of the cards, but understood that a card sort was a group activity. Because I encourage a “think out loud” approach, neither the client nor the attendee saw this as an issue.
The vision-impaired attendee’s disability meant he approached the same information in a different manner. The ways that he grouped and labelled the cards were often more explanatory, and he was able to better describe what his user journey would look like when navigating to that content. It was an experience that gave me a valuable insight into how some users with disabilities approach websites.
Something for your toolbox
These are just a few examples of lessons that I’ve learned by placing accessibility at the heart of my approach with clients. I highly recommend you add accessibility to your UX toolbox, and use it to craft an inclusive design from the beginning. Doing so can help inform many decisions that you are going to be faced with, and can save time later in the project.
In my experience, considering and accounting for accessibility in a web project can result in enhanced usability for every user, not just users who happen to have a disability of some sort.
What accessibility stories do you have? Share them in the comments!