rss feedCognitive accessibility testing
This post was originally hosted at http://fineartdavid.com
Notes from my Standards.Next presentation on September 19th, 2009, prettied up and made more readable.
My name is David Owens and I’m a front-end developer with an agency called tmg. We’re based in London Bridge, although I’m living and working from Berlin. (Actually, I’m a technical consultant according to my business cards, but I’ve left them all at home, so I’m going to have a proper job title for the day)
It’s great to be speaking here this weekend with people who have a lot more experience and knowledge of the subject than I do. I’m looking forward to learning a lot, both here and at the Accessibility 2.0 conference on Tuesday.
Today I’m hoping to share with you some of the insights which I gained, from a developer’s point of view, after doing some usability testing last year.
As I said (I’m not going to say “tweeted”) when Bruce first mentioned today’s event, “I’d definitely be interested in a cognitive accessibility event. I was stunned by how much I learned during a testing session.”
What I wasn’t expecting was Bruce’s reply, “Seriously, that qualifies you to do a 15 minute talk.”
So I thought, “why not?”, and here I am to shout about how much my eyes were opened by spending some time watching real people using a website I’d built.
Disabilities aren’t discrete things.
A lot of the things which I saw relate to accessibility and usability as a whole.
I guess one of the reasons for this is also one of the first things which I realised. That is that disabilities, including cognitive impairments, aren’t discrete things. We had arranged our testing with Shaw Trust so we could look out for any difficulties which might be highlighted by a range of disabilities. It just happened that many of the people doing the testing had more than one condition which made using websites more difficult than it should be.
It highlights the rule that if you build accessible websites, you will invariably end up helping more people than you expected.
That said, these are the things which came up were the result of, or were at least emphasised by, some kind of cognitive impairment.
So almost immediately we had to change how we’d been doing things.
Simple testing scripts
Kirsty, one of the testers at Shaw Trust, was primarily there to help us out with testing the website using a screen reader, but she also has difficulties with processing complex instructions or abstract concepts. Both major obstacles when you are testing a website you’ve never used before.
So we quickly realised we needed to change the way we were doing the testing. We sat down and rewrote the testing script to use real scenarios and tasks. Instead of presenting a page of search results and asking Kirsty to assess it, we went through the first step of filling out the search form together, and then asked Kirsty to use the next page to find out more about a specific result. In this case a hospital near to the testing centre. Once we provided that context we were able to see where the real issues lay, rather than go though a check list of things you need in a table or list of results to make it accessible.
So, the that was the first thing I learnt. Make sure your testing script doesn’t create even more confusion or ambiguity. Use simple language and provide context for what you are asking people to test.
Source order and abstract desicions
The next thing I realised was something which I think a lot of web developers suffer from. Thinking about the best way to do something to the point of abstraction, and aiming for some kind of design purity which loses track of the real world.
When we were planning the source order of the HTML (Hypertext Markup Language) we had a long chat about whether to put the content or the navigation first. We went through the various arguments for each, and eventually decided that the best option would be to put the content first. Because that’s the most important part. That’s why people have gone to the page isn’t it? We had this idealised version of how somebody would use the website. They always navigated to the page they needed, and then wanted to start reading through the content of that page. As an added bonus, this approach meant that all the important stuff was at the top, underneath our level 1 header. Accessibility and SEO (Search Engine Optomisation) win.
In real life, it didn’t work like that. Tom, who was helping us to test keyboard navigation, but who also has mild dyslexia and trouble with low-contrast designs, was flummoxed. He started using the keyboard to move through the page, but didn’t go where he was expecting. “Ah”, he said “why has it gone over there?. I thought it would start here, at the top. I mean, that’s how I normally read things. Top to bottom. Left to right.” He was distracted to the point that this stopped him from completing the task. So rather than Accessibility and SEO win, we had Real Life fail.
When we got back to the office and though about it, his logic made a lot more sense than the discussions we’d had before. So, yeah. That’s the next practical tip, Make the source order, and the tabbing order, run in the direction people read the page.
Most people haven’t read SEO articles about the importance of putting the content first, nor have they considered some kind of theoretical hierarchy of elements of the interface.
But I think that’s something that can be applied more generally too. When you’re asking somebody to do something complicated, don’t throw something unexpected into the mix, in this instance jumping around all over the page, even if it makes perfect sense to you.
Text resizing and other widgets
The next thing which I want to talk about is related, in that it is also an example of idealism, or dogma, versus pragmatism. For a long time I had taken the view that educating people about how to use their browser was the best way to make the web more accessible. A key example of this is text-resize widgets.
I was sat down with Richard, who has a mild learning difficulty, and I asked him if there was anything he could think of that would make it easier to use the website.
The first thing he said was “I wish there was a way to make the text bigger”.
I replied, “Well you can do that the same way you do it for any website”, knowing that all our fonts were set up nicely, and that we had zoomed in on every page we built at the design stage.
Richard explained that he had been told how to do that lots of times before, but that it was difficult to remember. There were so many menus and short cuts to learn that he had simply given up trying.
When put that simply, the case for presenting that option up-front seems pretty solid. Of course there are all kinds of browser settings that could, or should, be easier to get at, but for something as simple as a text-resizer it seems a no-brainer.
Putting help where people can find it
The last thing I wanted to mention follows on from that and takes us back to Kirsty again. The website included a set of videos about an audit which had taken place, specifically about healthcare for people with cognitive impairments. We had spent quite a lot of time developing a HTML/CSS (Cascading Style Sheets) interface to control our Flash video player and were very pleased with it. The problem was that when using the screen reader Kirsty hit the Flash movie before the controls and stopped. She had previous experience with Flash and was so put off that she didn’t even try to get past it.
Our solution was to put the HTML controls first in the source order. That way people using a screen-reader hit a button called “Play” before they hit a potentially off-putting Flash movie.
So for that one, I think the lesson would be, if you have things to help people, put them up front. Don’t make people come up against a problem and then look for a solution. They might not get that far.
We’re yet to test this particular solution out with real people, but that’s another important lesson. We need to keep coming back to these things and retesting them with as many people as we can. People with cognitive impairment are still one of the less well understood groups in terms of how we can make things easier for them.
Share the testing results
Something which I think we could all do better is share our results from testing. At the end of the day it can be expensive, and not all clients are willing to pick up the bill, but maybe we could come up with a way to pool and share what we are learning about users who have these kinds of disabilities in the same way that we have started to do with the more well documented impairments.
Thanks all for listening.
