being blind online
Last night at the Auckland UPA meeting, Neil Jarvis from the Royal New Zealand Foundation of the Blind spoke. Neil provided very eloquent & useful demonstration of how three well-used websites differ in their levels of accessibility, using JAWS, a well-known screen reader.
The demonstration was similar to one I saw at Webstock last year by Darren Fittler which served a similar purpose. For those who have never seen JAWS or similar in operation (especially used by someone who is an expert user), it’s a very very worthwhile thing to see.
To summarise Neil’s points:
- Tools only show you how good or bad your code is. You can run as many tools over your code & hypothesise about your usability/accessibility as much as you like but the end user will tell you how good it is
- Assistive technologies differentiate between information - they can pull out the essential, the good and the “who cares” content - it does help users prioritise information
- Screen readers are not a new technology - they were being developed and in use back in the days of bulletin boards. They’re always trying to catch up and even though penetration of new versions can be slow if people are using standards it really helps.
JAWS
- JAWS is a $2000 extra cost above the outlay for a normal PC - upgrades are a couple of hundred dollars each time, so don’t always expect that users are going to have JAWS, and if they have JAWS, that it will be the most up-to-date version
- Users can get a “headings list” dialogue, which will list the headings in the page out, e.g. H2, H3, H4 etc - not that I would think that many people would have an issue understanding that this kind of hierarchy is important!
- JAWS also allows an “HTML features” list, so using the right element for the job is important - more users of assistive technologies understand these than the general population. Sometimes browsing this way can help Neil jump to where forms are, for example.
- JAWS can read to you in different voices for different elements like headings and links - you can change the speed, pitch & sex of the voice. You can also have sounds to represent different elements.
Examples
- Neil showcased the Radio NZ site as an excellent example of an accessible site,
- He pulled up a list of the links in a dialogue box there were several “find out more” links with no surrounding context. Which “find out more” would you choose?
- I know that a lot of content management systems do put in things like “find out more” automatically - how to do this kind of thing for a sighted person and not have it be useless for someone needing assistive technology? For example, on sites I’ve worked on we’ve linked the full name of an article but then after the abstract there is often a “read more” or similar. How to get around this?
- CDnow.com was Neil’s medium example - though it’s machine generated image names were completely useless on the homepage.
- If it’s important enough to showcase on your homepage, why would you let the identifier be something like PVB0000R12WW_01_PE32_0401_SCTZZZZZZZZZZ_V180697172_?
- This is also what comes up as a browse link in JAWS - how would you choose what to use?
- The Burger King site was an example of a bad experience - it comes back with the text “no links on the homepage! It’s a site for the sighted only as the Flash isn’t accessible either. Apparently there is a way you can export code for embedding Flash which is more accessible but developers do need to seek it out.
Accessible AJAX?
- Screen readers can’t deal with AJAX yet as tt’s a relatively new technology (and who knows if it will be lasting)
- Neil and a colleague have written pages which ARE accessible so there are ways forward with this
- Again, whether it can be accessible going forwards relies on developers as much as any assistive technology
Neil summed up by pointing out that creativity without responsibility is not necessary - you can be creative with your web work AND still be accessible.