May 10, 2015 · Weekend Testing

WTA-61: Accessibility in action

This weekend I had the pleasure of participating in the latest Weekend Testing Americas session, themed around accessibility, specifically understanding how screen readers can help users with visual impairments. The session was chaired by Michael Larsen with practical exercises led by Albert Gareev, two people who have an outspoken passion for raising accessibility awareness, which shone through in the session.

It's an area where I've spent a fair amount of my career; during my years spent working for Oracle, and elsewhere when producing software which integrates with IBM products (and has to meet their own stringent internal accessibility standards). I've been fortunate in that I've worked with organisations which are large enough (and, potentially, liable enough) that they can't afford to ignore accessibility. However, not everybody is so lucky; several attendees in our Weekend Testing session (including one from the public healthcare profession) expressed concern that such issues weren't even registering on their company's radar.

It's a complex subject, and there's certainly no one-size-fits-all solution. However, I want to share a few key pieces of advice that I've picked up during my time working with helping companies to achieve compliance.

You probably don't appreciate accessibility as an issue

While the subject of "best practices" is rather touchy in the testing world (see: James Bach - No Best Practices), it's my belief that when considering application accessibility, checklists and guidelines can provide real benefit.

For starters, most of us are lucky enough that we don't have to face accessibility issues on a daily basis. This means that we're predisposed to assume that accessibility isn't an important concern, when what we mean is that it isn't our concern. This also tends to be a self-fulfilling prophecy; if your attitude is "Users with visual impairments don't use our software", don't be surprised if they use your competitors when they discover that your product is not catering for them.

Even if we agree that we need to make our applications accessible to all, where do we start - how do we understand what hurdles an impaired user might face?

Although they shouldn't be used in isolation, accessibility guidelines can be a big help here. There. I said it.

You won't achieve compliance overnight

Take a quick look at the most popular accessibility best-practice list, the Web Content Accessibility Guidelines (WCAG). That's a scarily long list, isn't it? Bear in mind that's just a summary page - each sub-point has a further two hyperlinks, taking you to pages which help you to understand the issue, and give you tips on how to resolve it.

There's a lot to do - and this is just one such set of suggestions. There are other resources such as Web Accessibility In Mind (WebAIM) and the framework provided by the Web Accessibility Initiative (WAI-ARIA) each of which has its own set of well-considered (and often overlapping) ways to improve application accessibility.

There's no quick-fix for accessibility per se, but the good news is:

There may be individual quick fixes which deliver real benefit

Although designing for accessibility is a complex challenge, chances are that you have some low-hanging fruit in high-traffic areas of your application. The classics are link text (does the hyperlink text make sense in isolation, or does it just say "Read more"?) and image alt tags (are you communicating important information through images which won't be picked-up by a screen reader?)

Most checks for accessibility can't be automated - a machine can't tell whether a link's text gives enough context for any given user, or whether "dog" is an acceptable caption for a picture of a cat! But you can utilise automated tools to help: the Web Accessibility Toolbar, for example, will parse a page and extract all of the links / image captions for you, so that you can manually verify whether they're appropriate.

By taking such small, relatively easy steps, you can deliver appreciable benefit to impaired users, with the added benefit of making things better for your sighted users too!

Gain traction by tackling accessibility head-on

I remember the first time that I saw the WCAG checklist. I was overjoyed: it seemed to be a cheat-sheet for finding lovely new bugs to log! ("Oh look, that page is failing according to point 32B, time to raise another issue!")

But as I found (and as fellow Weekend Testing attendees also attested), each individual issue was deemed to be low priority, and were never deemed important enough to address. If anything, you might find that you're getting resistance from the development team: "Why are you logging all of these unimportant issues?"

Rather than facing the ignominy of a hundred rejected issues, it might be easier to gain traction by trying to get accessibility itself on the agenda. Get your team and managers to buy-in on the idea of accessibility (which, as a concept, should have a higher priority than any individual accessibility issues) - once there's a shared understanding of its importance, you can work out how to make your products compatible.

Here are some ideas on how to broach the subject to your team:

  • Replicate our Weekend Testing session with your own team and product! Install a compatible screen reader alongside your product/website, and show the team how it works with well-designed content (e.g. Wikipedia). Then move over to your application and see how it compares.
  • Explore your software, using helper tools such as the Web Accessibility Toolbar, to pre-emptively determine where your low-hanging fruit might lie. It's much easier to gain support if you can say "there's some things we could address relatively quickly" rather than just waving a scary checklist of standards.
  • Run user studies on your software, using people who have need to use screen readers on a daily basis. At Oracle, I was fortunate enough that we had access to a large accessibility testing team which included visually-impaired users, but you can always look externally, through organisations such as Shaw Trust.
  • Finally, draw their attention to the next section below...

There'll eventually be a legal imperative to do this

Although compliance requirements vary greatly across different countries and industries, there's only one way this is headed. In America, Section 508 already provides sanctioned imperative for companies to make their products accessible; even if you're not in the United States, if you intend to sell your software into an American organisation then they're required to ensure that your components meet the same accessibility requirements.

Some people struggle to get accessibility taken seriously because (to quote Dan Billing from the WTA session) "accessibility doesn't drive revenue". Well, it does drive revenue if you can't sell a major contract because your product doesn't meet government legislation. If your product teams remain unconcerned by your accessibility status, and you feel comfortable doing so, try talking to your company's financiers - a blocked pipeline is a sure-fire way of getting issues onto the radar!

What if you're a small startup organisation? Well, presumably you don't intend to be small forever; at the very least, someone high-up in the company probably has dreams of being acquired by a large company which needs to take this sort of thing very seriously. The sooner you start to consider accessibility, the less headache you'll have - though, to bring things back to where we started, don't expect to make things better overnight.

Talk to an expert!

If you're trying to get accessibility issues taken seriously within your organisation, or are looking for practical ways to work accessibility testing into your everyday testing activities, please drop me a line. You might also be interested to know that Albert is running a tutorial at CAST 2015 - "Black Box Accessibility Testing: A Heuristic Approach".

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket
Comments powered by Disqus