29:
The UK Government are sponsoring a website to encourage Startup Britain.
As with 90% of UK Government websites, there are basic accessibility issues that would take somebody 5 minutes to put right. Here’s the email I sent explaining a couple of quick and easy fixes.
Hi there,
Your website looks like it could be a useful tool, but I spotted a couple of problems that could make it difficult for those with disabilities to use.
Firstly, there is no way to know where you are on the page if you’re using a keyboard and not a mouse. You have the following line in your CSS.
/resource/css/site/base/site.css line 91
a {
text-decoration: none;
outline: none;
} |
If you remove it, then links that people have focused on by using the tab key will have an outline and they will know where they are on the page.
The next big issue is to do with the email signup form.
<fieldset>
<input class="clear-input textbox" id="register-email" name="entry.0.single" value="Your email address">
<a class="submit button" href="/"><span>GO</span></a>
</fieldset> |
There are a number of problems here that make the form difficult for people using a screenreader to use.
1) No <form/> element. This makes it hard for people to know where on the page the form is.
2) No <label/> associated with the <input/> element.
3) An <a/> element with ambiguous text instead of a <input type="submit"/> element.
4) Form won’t work without JavaScript.
Much better would be to use something like this:
<form action="/register" method="post">
<fieldset>
<label for="register-email">Your email address</label>
<input class="clear-input textbox" id="register-email" name="entry.0.single" value="Your email address">
<span class="button"><input type="submit" value="Go" class="submit" /></span>
</fieldset>
</form> |
With this code the JavaScript enhanced form would still work, but it would fall back to a regular form if JavaScript is not available for any reason.
Hopefully your web design team can implement these changes quickly and make the site easier to use for people with disabilities. It may be worth asking them to check the rest of the site as there may well be other problems that I didn’t immediately notice.
If you have any questions then drop me a line.
Best regards
David
20:
I’ve just found a strange bug in Google Chrome.
I’ve been working on a set of templates for fineartdavid.com, and was testing them for keyboard accessibility. I hadn’t expected anything unusual because there is nothing very complicated in the the HTML. When I tabbed through the page however, the large images were being skipped.
At first I thought the problem was caused by block-level links. These are allowed in HTML5 and are a good solution to the design pattern where you have an image and a header both pointing to the same link.
<a href="#">
<img src="/path/to/image.png" alt="descriptive alt text" title="" />
<h2>Blog entry title</h2>
</a> |
A few experiments showed that this was fine though, and that the problem only happened when the image was floated. Further investigations showed that any links that contain only floated elements are removed from the tab order.
Check out the test suite. Obviously has implications for accessibility, so lets hot it is fixed soon.
Update: I’ve updated the title because this happens in Safari too, meaning it is a Webkit, and not Chrome bug.
Update 2: I’ve filed a Webkit bug report.
23:
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.
rss feed