@Media 2005: Web Accessibility and Disability by Robin ChristophersonTuesday, June 14, 2005
Robin Christopherson works for AbilityNet as an accessibility consultant. He is an experienced and expert screen reader user. He is blind, and has the most beautiful Labrador to guide him around. His presentation slides are available on the AbilityNet website.
AbilityNet is a leading pan-disability and IT charity in the UK. It has recently completed an e-benchmarking project with the government office and is currently busy in revamping the news section of the BBC.
When it comes to the definition of accessibility, Joe Clark's definition is better than mine. Compliance levels of the Web Content Accessibility Guidelines are at three levels. Level A is a must, Level AA is a should do, or good practice, Level AAA is a best practice.
Usability testing is normally done with some grandmother and her dog. A better test would be to use a grandmother with mild vision problems, and if you can find one, a dog who has problems using a mouse.
State of accessibility
There are 9.8 million people with a disability (as defined under the DDA), and many people have more than one disability.
Accessibility offers usability improvements for non-disabled people too. An interesting finding from the DRC Report into the accessibility of UK websites showed that a website meeting the basic level of accessibility when tested with a control group of non-disabled people, it demonstrated a 35% usability bonus. The control group were able to complete tasks on these websites in an average time of 36 seconds as compared to 52 seconds on average for other sites.
When most people think about a computer, they imaging a screen, a keyboard, a mouse and a box. I don't have either a screen or a mouse. I can't see a screen, and because a mouse is about moving a cursor to a visual point on a screen, I can't operate a mouse. Driving a screen reader is a keyboard intensive task.
For people with mild or moderate visual impairments they don't have to use screen readers, they can adjust their browser and increase the font-size. They prefer white text on a black background, so a site needs to make sure that it is still accessible under these conditions. Text resizing, in this particular instance, would be better as a priority 1 issue rather than the priority 2 it is at the moment in WCAG1.
Increasing the text size in Internet Explorer does nothing to increase the size of the text. This is because the site is styled using pixel based font-sizes. This limitation can be overcome by ignoring website-defined font sizes in the browser, but there are two major issues:
- Knowing that feature is there
- It overrides the hierarchy of the content, so the positioning of content may change, and what was originally a header may just be a short line of text.
Using a high-contrast Windows theme the Arsenal website displays the blue links on a black background. The design of the site, visually impaired visitors will struggle because of the lack of generous font-size rescaling. When doing flexible layouts, check for overlapping problems.
Many visually impaired people use the free magnifier that comes with Windows. A website needs to be functional under these circumstances. Typical problems with using a screen magnifier include big dialogue boxes falling of the bottom of the screen in full-screen magnifier mode. Third party screen magnifiers have the same problem.
On the Disney website when using a magnified, the pictures of anti-aliased text become pixilated to be unreadable. Picture of words are the biggest problem, visitors are unable to change the colour and size of these fonts. The Flash zoom facility is also far from adequate.
Some guidelines for dealing with mild or moderate visual impairment:
- Don't use colour alone to convey information - since there's no guarantee that the colours have not been changed for a visitor.
- Keep the layout consistent and uncluttered. This makes things easier to find on a website.
- Avoid using graphics for text
- Offer a high-contrast visual skin - see Joe Clark's session on Zoom layout
- Use clear non-serifed fonts, for example Arial, Tahoma or Verdana are recommended.
- Avoid using Flash for text
The e-learning sites are huge consumers of Flash, for example Learn Direct. 95% of the material can be done in HTML just as sexy and swish. The other 5% by all means do in Flash, and only that 5% needs accessible equivalents. We need careful thinking about using Flash.
Labelling of images is a critical step for making content accessible to screen reader users. Also actual text of the label is important. Take a site where every image used as a spacer image contains the text, "this is a spacer image", the screen reader would read out each one. Have to really tasted pain?
Skip to content links are more important for people suffering with motor impairment, and that would be very useful here to skip over the junk images. Skip to content links aren't that essential for screen reader users since screen readers have the option of skipping to the first available unique content in a page.
Amazon is strong on usability but poor on accessibility. The missing alternative text on their top navigation images creates a barrier of confusion. [screen reader reads out the amazon top navigation, all images no alt attributes, so it reads out the link name which is an obfuscated with a long serial number, with no idea what each link is for]. Think about this if you are using a screen reader and your job depends on being able to buy something on Amazon.
Simply labelling the link images, and its a completely different experience. [screen reader demo of the same page with alt-attributes on each of the top navigation images]. Its not rocket science.
The latest versions of IBM Homepage Reader can access Flash. How far do we go back in terms of screen reader versions? Older versions of screen readers just read out the word "object" for each piece of Flash embedded in a page.
Macromedia has done an awful lot with user agents in trying to make Flash accessible, but it still is a long way from perfect.
Key guidelines for blind visitors include:
- Make sure all images have equivalent alternative text
- Make sure the Flash works with modern screen reader, and provide an accessible alterative.
British Sign Language users are typically born without useful hearing. BSL uses different grammar, sentence structure and has a different vocabulary. For instance, working with the BBC we found out that the word "marinade" isn't in the BSL vocabulary. Use a glossary to define these words, that will benefit this particular group.
Caption video for them. [shows an example of a captioned video of Tony Blair, but unfortunately the caption was off-screen].
At this point Curt Holst, the AbilityNet webmaster, took over from Robin for the second half of the presentation.
There are many pieces of hardware created to help people with motor-difficulties in using computers. Alternative keyboards and mice, voice recognition is rapidly proving a useful technology. The standard mouse is moved using the thumb and little finger, tilting your hands in a strange way. Trying to click a mouse button in these circumstances often causes the mouse to move.
Alternative mice include a pistol-grip mouse, and a contour mouse (which allows the hands to be in a more natural position). A trackball is basically an upturned mouse, it keeps the mouse in a stationary position making it easier to click. It can even be used by foot.
Make link text a decent size, the bigger the clickable area the easier it is to point a cursor and click it. [Shows an example of a "text only" link which is tiny and well disguised].
Alternatives to keyboards include a key guard, which is placed over a keyboard. It is a piece of metal with holes on it (we never get complaints of a keyguard crashing!). It allows users to select a particular key without being able to press neighbouring keys. You can also rest your hands on it without accidentally pressing any keys.
Flash needs to be keyboard accessible if it is to be usable.
Navigation using drop-down menus (using the form select element), for example on the Arsenal website above, can't be used by keyboard users using Internet Explorer because of the onchange event-handler used. Quick links are not very quick.
A logical tab order should be obvious. The Disney website tab order isn't logical, it goes through the first two menu items, then jumps to the search form, then back to the next menu item. This is confusing.
People suffering from dyslexia often use voice recognition.
It is possible to click an area of the screen using just voice recognition. Using a mousegrid which sub divided the screen into 9 rectangles (in a 3x3 block). Picking one of these 9 boxes creates a smaller 9x9 box in the selected box, allowing the visitor to narrow down to a particular area of the screen, and then they can "click" using just their voice.
Keeping language clear and consistent, having a consistent navigation, a site map and a bread crumb trail makes a site easier to use. Also keep movement to a minimum.
Questions and Answers
About JAWS and supporting abbreviations: Using JAWS needs almost a tech-head level of knowledge. JAWS support of abbreviations and acronyms is not great. The main workaround is to add acronyms and abbreviations to an exceptions dictionary.
Voice recognitions has about a 98 or 99% accuracy. Its is fanatastic, but it does require the the user to read the manuals. The most common problems is not correcting mistakes that the software makes, so not allowing it to learn.
About accesskeys: They are useful for keyboard users. Its a difficult problem, the UK standards of using number keys 0 through 9 are not useful - they break when these keys are being used. Telling people about accesskeys is the hardest problem, one solution is to do like Windows does and underlines the accesskey in the linked word. Screen readers tend to hijack key presses, so they would see and interpret key presses before the accesskey functionality would be allowed to see them. So when there is a conflicy, JAWS configured keyboard use overrides the accesskey.
About the title attribute: JAWS default is just to read the screen text. The title can be read out by specifying that setting. Experienced screen reader users tend to request the title attribute when the link text is singularly uninformative. "Open in a new window" is a good use for the title attribute.
About the AbilityNet report slating Virgin: Virgin worked with AbilityNet to correct basic acccessibility mistakes, but the end result, still having accessibility problems, dilutes the message for web accessibility. AbilityNet and Virgin went with the pragmatic approach. The relaunch was a good public relations. There were lots of constraints on the Virgin websites. AbilityNet did not endorse the Virgin websites. The RNIB do great work in a number of places.
About Fangs: How close is Fangs to JAWS: It is advised that when testing in screen readers that a tooled and skilled inhouse resource be used. JAWS requires a lot of product knowledge. To use a screen reader effectively:
- Learn the core knowledge of the product
- turn off the screen
IBM Homepage reader is a fraction of the cost of JAWS, and is fairly representative of a vast majority of screen reader problems. Using IBM Homepage Reader with the graphic view turned off is about the same as having the screen off. The screen reader is good for testing, especially using tables reading mode.
AbilityNet does do adhoc consultancy. It is a charity, not a business. There's no charge to asking AbilityNet, but if its happening regularly, then things may have to change.
- Joe Clark: 'Web Accessibility and Disability: A Practical Introduction'
- KuraFire: @media 2005: Robin Christopherson