Accessibility: Pairing with a blind consultant.

The following post is a joint collaboration between Darren McMillan and Jamie Cuthbertson.

Darren

Some time ago our company won a major contract with a large overseas firm.  Part of the contractual agreement was that we would provide a screen reader compliant platform. The company employed some blind and partially sighted staff working as call center agents and they would all eventually be using our software.

It was a major deal for us and we quickly set about building a small team of two developers and myself as a tester whose job was to investigate the effort required to make our platform screen reader compliant.

That was a couple of years back now, and it was a good experience attempting to simulate how a blind user would use our application.  Certainly for me, I became more aware of accessibility issues which previously I wouldn’t have considered.  Eventually it led me to having a major input on designs for customized accessible implementations of UI screens.

Trying to simulate the experiences of a blind user and designing UI’s for them is really difficult when you don’t know for certain how a real blind user will navigate and interact with the system.

To overcome this risk we hired the services of Jamie Cuthbertson.  Jamie was seriously injured back in 1986 during a military training exercise whilst working for the British Army, this left Jamie completely blind.  Among the many incredible things Jamie has done since his accident is the work he does as a consult.  We’ve hired him on several occasions to help test our software and point out issues which will affect blind or partially sighted users.  He’s also provided training services to a group of fourteen developers and testers, somehow managing to keep them entertained, focused and motivated whilst teaching us the difficulties facing users like him, and how to overcome them.

On two occasions I’ve been lucky enough to spend the day pair testing newly developed functionality with Jamie.  It never ceases to amaze me how much I learn from him!  Thankfully it’s also highlighted that we are actually doing a pretty decent job making our product accessible.

Jamie

It was very pleasing to be asked to return to Sword Ciboodle to test another of their software modules from an accessibility perspective.  Not only did it mean they hadn’t lost my phone number (Smile) but it also suggested that my previous testing work had proved worthwhile from the company’s perspective!  It was great to link up again with Darren as he has a relaxed approach which made the testing sessions both productive and enjoyable.

In terms of my background, I have been using the Jaws for Windows screen reading software for more than 15 years and would now consider myself to be a very competent user.  I work with the internet a fair bit and have developed my own methods of navigating round both simple and more complex sites.  I have a basic knowledge of HTML and CSS and I did do some Pascal programming during my MSc IT course at the University of Glasgow in the early 1990′s.  The important thing here, however, is that I am certainly not an expert in the use of modern website creation tools and techniques.  Essentially what I’m saying is that I can advise a website designer about issues that a website creates for me as a blind user but I am unlikely to know how to fix the problem from a technical perspective – this is where working alongside a representative from the company has proved so useful.

When talking about accessibility testing, I think that it is also important to highlight 2 issues that are often either misunderstood or not considered.

Firstly is the difference between ‘accessibility’ and ‘usability’.  It is perfectly possible to design a website which is technically accessible but functionally unusable.  If you follow all the accessibility guidelines, the page will be accessible.  If, however, the page layout is overly complex or there is too much information crammed onto the page, it may well become more and more unusable.  An analogy of this might be an adapted loo in the middle of a busy shopping precinct – ramps up to the door, widened doorway, modified taps and loo etc.  This would be entirely accessible.  Imagine now that the walls were made of glass – the loo is still accessible but not very usable!!

In my opinion, issues about accessibility tend to affect minorty groups whereas issues of usability affect everyone.  Both these issues need to be considered when testing a website and not just the technical issues surrounding accessibility.

The second thing to bear in mind relates to the varying levels of end user ability in terms of using their access software on the internet.  I have often worked with blind or partially sighted individuals who believe that a website is not usable, only to subsequently find out that they are not fully aware of the capabilities of their own software.  The website might indeed need some further work but it may be more a case of the end user requiring additional training in the use of their speech system.

Darren

The first chance I got to pair with Jamie was when we’d reached the last stage of our development effort on a web text chat feature our team had been building.  The cool thing about this project was that we’d built a customised accessible chat client aimed at blind and partially sighted users.

I spent some time brain storming ideas around this accessible chat client with the teams Technical Architect, before getting input from some other people on the team.  I was pretty pleased with what we’d come up with and when I heard we’d be getting Jamie in to try it out I was really excited to hear his thoughts on it.

Jamie and I spent the day trying out different scenarios with the new feature, looking for issues which might cause problems for other blind users.  We noted down a lot of issues, thankfully we had no blockers!  We did highlight some very important problems though that would need to be fixed; some of these being product wide and not constrained to the functionality we were testing.

It proved to be a really good move getting Jamie in to help us test the feature, one which was evident when I paired with him again only a month or two later.  This time around I was testing a feature I knew nothing about, so I spent a couple of days getting used to it prior to Jamie’s arrival.

Again we found issues which needed to be fixed.  One blocker this time in a CAPTCHA which produced an audio repetition of the CAPTCHA word in a manner such that even the most focused listener wouldn’t have been able to understand it.  Having been produced by an outsourced team, with minimal accessibility experience we’d expected a load of issues, but thankfully it’s wasn’t too bad.

Watching Jamie work and how he interacts with the product was a real learning experience for me.  When I’d been thinking that tab order navigation would be really important I quickly found that a blind user can use many, many ways to navigate a web page!

Simple things like ensuring you assign a proper hierarchy to headers on a page, and considering how the use of 3^rd party components might affect your UI’s navigation paradigm, confusing a user become really important.  Most importantly you learn that just like you would experience with a usability evaluation, everyone is different, and no two users will interact with a product in the same way.  Therefore we can’t assume that our well thought out changes to make our product accessible will work!  Until we actually test it with some real users who have accessibility needs.  That’s one of the key benefits Jamie brings, the experience of how people interact, or can interact with your product.

Jamie

The work that I’ve done with Darren has been a real eye-opener (pardon the pun) for various reasons.  In particular, following our most recent testing session, I realised that we had to approach the testing differently for each of the application.  One module was to be an in-house software package where staff training would be available before going live.  Another modules was an externally facing application where the end user would have no prior training.  In this case, because the end user skill levels would vary greatly, the site needed to be more intuitive to use and, therefore, the way we tested had also to be different.  Retrospectively this is very obvious but I hadn’t previously appreciated how much this issue alone might impact on, not just the testing process, but the whole way in which the application is designed from the outset.

I suppose if I was asked to give some tips on how developers should go about creating excellent websites for a wide audience, I would probably list the following:

• Design your products with the widest possible audience in mind from the outset – the good old ‘universal design’ principle.
• Think about all the issues affecting the technical aspects, accessibility usability and testing, before starting development of your product, and not retrospectively.  Time spent planning is rarely wasted!
• Always seek assistance, in the testing phase, from end users who have the skills and experience to give constructive feedback.  In the long run this will save time and money.
• Remember to consider both usability and accessibility together and not as separate entities.
• Remember that, if your site is supposed to be communicating a message to the end user, it fails if the end user can’t get that information.  With around 10 million people in UK who have a disability, this is a lot of people to be ignoring and a very sizeable potential market!!  If you are developing for a commercial organisation, this is an enormously important fact to bear in mind- good for the client, good for the developer.
• Try to keep the fundamental structure of your sites simple and easy to understand.  Cluttered layouts, repeated links, poorly labelled graphics and so on certainly make life difficult.  Good use of plain English and a consistent structure throughout the site can make a huge difference.

Darren

Having received training from Jamie and worked with him on two vastly different projects, I’ve found his input to be invaluable.  I’m also in a much better position myself having gained skills and experience from working alongside him, most importantly I’ve gained more of an understanding of the issues affecting blind and partially sighted users.

If you would like get to touch get in touch with Jamie, either for advice or to have him come and assist you and your team simply drop him an email at jamie@mytic.co.uk or visit his website for more details about him and how to contact him.

Jamie passed on some fantastic and insightful survey’s from web aim, analysing how people used screen readers.  I’d highly recommend you give these a read:

• WebAIM screen reader survey 2008/2009
• WebAIM screen reader survey 2009
• WebAIM screen reader survery 2010

In an era of expensive lawsuits over inaccessible websites and software, it pays to invest in getting it right.

No related posts.