The local government Society of IT Management (Socitm) this week published a report on website accessibility which included a round-up of the five most common accessibility errors.
The society estimates that these five errors account for 76% of all website accessibility failures, and it asked Robin Christopherson, Head of Accessibility Services at the charity AbilityNet, to describe their impact. Robin is blind and uses the popular ‘JAWS’ screen reader software to access the web.
An edited version of Robin’s assessment follows.
“Common failure 1 is to have no alternative text for images.
“This is an extremely common occurrence. I visit a website and am confronted with numerous unlabelled images. For mouse users this ‘alternative text’ is what pops up when you hover over the image. The average web page has dozens of images, from photos and adverts to ‘eye-candy’ such as spacing graphics and design flourishes. Many of these images are also clickable links or buttons, and not knowing what these are makes navigation impossible. Imagine trying to drive from A to B where the signposts at every roundabout or junction are blank. A disaster!
“Every single image on a website should be properly labelled. You don’t need to begin captions by saying “Picture of.”, as I already know it’s a picture. You don’t need to label ‘spacer’ or ‘eye-candy’ images (but give these a default caption so that the page still passes the accessibility checkers) and, above all, make sure that all images that are also links or buttons describe what will happen when you click on them, eg alternative text as “Marilyn Monroe – click to read her life story”.
“As well as revolutionising the site for blind users, labelled images will also help those with dyslexia and literacy difficulties who use text to speech software (they hover their mouse over any text or image and the content is spoken out). It will also help those with images turned off (many hand-held users do not display images) and, last but by no means least, Google loves labelled images.
“Common failure Two is the inappropriate use of JavaScript.
“JavaScript is used to write mini-programs that are embedded in web pages and can enhance their functionality. They are very widely used and set to increase dramatically with ‘Web 2.0′ applications.
“My screen reader (JAWS) is one of the most sophisticated, but there are still many occasions when some uses of JavaScript leave meconfused or frustrated, roaming at length to discover what bit of the page (if any) has changed after clicking that link, or finding that I am totally unable to access that shopping cart as selecting that button using the keyboard does nothing at all.
“It isn’t enough to offer an alternative for those not using JavaScript, thinking that disabled users do not have JavaScript switched on as a matter of course. The vast majority of users of assistive technologies (such as screen readers, voice recognition, magnification, alternative keyboards and mice) can benefit from JavaScript functions as much as anyone, with the major caveat that there are certain uses of JavaScript that are not accessible to these technologies.
“The simple solution is to test your pages with these technologies to ensure that your particular application of JavaScript is not problematic.
“Common failures 3 and 4 are errors in simple and complex data tables.
“Thankfully, these days most websites use style sheets rather than tables to style and arrange the blocks of content on a web page. Where data tables are concerned, however, it is still the case that most are not coded in such a way that the relevant headings are spoken by a screen reader when moving from cell to cell. I hear ‘1327’ and ‘1727’ with no idea of whether these are sales of widgets or notable dates in history.
“The solution is to make sure that all headings of columns and rows are coded using the ‘th’ tag instead of the ‘td’ tag. A screen reader will then announce these along with the contents of the cell, putting the data in context (eg “Widgets sold in June, 1327″).
“And finally, common failure 5 is the use of features with a lack of accessible alternatives.
“Here you are confronted with an inaccessible bit of content or function and you search for a way around the obstacle, but to no avail. A classic example is ‘CAPTCHA’. A CAPTCHA is a type of security test used to determine whether the user is human (and so exclude automated spamming programmes). A common type of CAPTCHA requires that the user type the letters of a distorted image. Since the image is by definition unlabelled (as otherwise it can be read by malicious software) an alternative (such as an option to register by phone or email) is essential.
“When it becomes clear that you have content or function that cannot be made accessible, offer an accessible alternative. For example, the Google accounts sign-up process that uses CAPTCHA also has a link to an audio version of the code to be entered plus a link to contact customer services for those who cannot access either the visual or the auditory option.
“Always remember that an accessible site is a popular site – and not just for the disabled community. Research has shown that a site that is designed with accessibility in mind is also easier to use by all.”
NOTE: ‘A world denied: a supplement for Better connected 2008 on website accessibility’ is available from Socitm. It is free to subscribers to the society’s Insight programme; £50 for non-subscribers in the public and voluntary sectors and £99 for private sector non-subscribers.
Entries (RSS)
Comments
I object to the suggestion in item number 5 that an e-mail or telephone based alternative to the CAPTCHA is acceptable. It is patently unacceptable to be forced to wait anywhere from hours to days or weeks for something that is granted our sighted peers instantly if only one is able to physically see a CAPTCHA image. At a bare minimum, all sites should now feature an audio CAPTCHA playback. There’s really no excuse for omitting this feature now that services such as ReCAPTCHA.net exist as turn key solutions for web developers.
At this point, failure to provide at least an audio playback on any CAPTCHA represents nothing less than a “no blind people allowed” sign.
An excellent point Darrell. I’m in the process of removing CAPTCHA from my contact form (I was going to feed the form through Akismet for spam protection) but I will now look at ReCAPTCHA.net
The following is a link to a group of different CAPTCHA’s that I’ve created.
http://webbytedd.com/aa/assorted-captcha/
I realize that the first demo is not acceptable, but do any other the other examples work for those with disabilities? Granted some won’t because they require sight, but blindness is only one of many different disabilities.
Could a combination of different CAPTCHA’s provide a solution or is CAPTCHA just one of the things that can not be resolved?
Can I point out a small error in point number 5 where it says “make sure that all images that are also links or buttons describe what will happen when you click on them, e.g. alternative text as “Marilyn Monroe – click to read her life story”. ”
This isn’t really correct. The alternative description of an image should be the exact equivalent of its appearance. So if it’s a photo of Marilyn Monroe with no text in the image, it should just be ‘Marilyn Monroe’. However, if that image is also a hyperlink, the title attribute of the link itself can be used to describe where the link goes to.
Thanks for these new comments, I will publish them in the next issue of E-Access Bulletin to stimulate further debate and to recruit testers for the CAPTCHA ideas!
all the best,
dan
We had loads of problems with Spam on our contact form – some of it quite offensive, and, as some of it was going directly to frontline staff with considerably thinner skin than me, I had to do something about it.
Rather than going down the route of a traditional CAPTCHA, I used PHP to generate two numbers – one between 1 and 50, and another between 1 and 5, the second number of the first number never goes beyond 5, so the sum’s answer never goes beyond the next 10 digit range (to make the sum easier). This is all wrapped in a label, so screenreader users can see the link between the question and the form and I’ve never had another bit of Spam since!
The only thing that worries me is that this might lock out users with poor numeracy – am I being too cautious? Here’s the form for reference:
http://www.lichfielddc.gov.uk/site/custom_scripts/feedback2.php
I’m writing from Access Journal at RNIB, wondering if anyone has any ideas on the following points.
Should the whole idea of CAPTCHAs as a concept be abandoned? It seems that few web designers know about alternatives, especially for blind and partially sighted people. But even if we attempt to educate more designers about alternative CAPTCHAs, is spam software not going to soon improve to the point that it is too smart for CAPTCHAs anyway?
My understanding has always been (correct me if I’m wrong) that the standard CAPTCHA – obscure letters on a busy background – was introduced to beat software that could read standard text and ‘know’ how to fill in a form based on replicating a piece of text. This is why web designers do not use alt text tags – the same software could read that alt text and fill in a form.
But I thought that artificial intelligence was moving forward quickly, including in the abilities of programs to understand images and audio. I have a friend who could probably use a PhD project to this end if he was so inclined. Stuart above seems to have found a good idea – but I wonder whether programs will soon be able to ‘think’ around this solution, or failing that, bombard developers like him with every potential solution to a question CAPTCHA.
Am I being crazily futuristic? Or should we look forward to a future in which we are all – regardless of ability to interact with CAPTCHAs – left waiting for hours or days for a human to authenticate online forms?
…I could ask if there will be programs in the future which forge online forms and then interact with authenticators, over the phone for example. But that’s crazy talk.
We recently relaunched our site and used server-side validation on forms, rather than javascript. Content spam has dropped dramatically (almost disappeared, in fact) since. The validation scripting is quite time-consuming, but if you subtract the amount of time colleagues are not dealing with spam, it is probably worth the effort (though I haven’t done the sums yet).
We get about 100 enquiries a month through forms on our site. We completely rejected the option of CAPTCHA (although it had been requested by some colleagues) because of the accessibility issues; but also because it makes it harder for everyone to use, not just those with disabilities. I have 20/20 vision and I sometimes have difficulty deciphering CAPTCHAs.
Another possibility we considered was simply to classify any form submission with a URL in it as spam. Over 95% of the spam we used to receive contained a URL. So just add a note in the label of your form inputs to say ‘do not enter a URL’, and write a script so that any submission containing the string ‘http://’ is rejected.
Post a comment