Real programmers don't document. If it was hard to write, it should be hard to understand.
Lists and Screen Readers
Over the past few years, and especially following Mark Newhouse’s article, Taming Lists, on A List Apart, usage of the styled lists within markup seems to have increased dramatically – particularly within the creation of site navigation menus. But do all styled lists offer the same level of accessibility?
Lists also seem to be more popular within page content as a way of breaking down information into logical “chunks”. After all, CSS offers a number of different ways styling lists, so why not make best use of them? If you need to use an ordered list (ol) you can chose from the following ‘numbering schemes’ via CSS’ list-style-type attribute:
- decimal
- lower-roman
- upper-roman
- lower-alpha
- upper-alpha
- none
But are all of these CSS options equally accessible? How does a speech reader handle a list numbered using “I, II, III , IV” etc? Given JAWS’ somewhat patchy CSS implementation, is it reasonable to automatically assume that this screen reader will render different list item markers in the logical manner?
In a situation like this, the obvious answer is to create a test page and as JAWS users to comment on it.
http://www.blackwidows.co.uk/test-suite/JAWSListTest1.php is just such page. Andrea Kennedy, from the Shaw Trust’s Web Accreditation Team, kindly agreed to ask some of the Team’s JAWS users to test page and send me their feedback.
Interestingly enough, they reported that all of the lists were read phonetically.
The Lower Roman list was not very user friendly and made no sense. The Upper Roman list was initially semi-usable but read as I, 2, 3, IV followed by a list of letters and numerals.
As expected, the Unstyled and the Decimal Lists did not present any accessibility problems. However, the most popular of all was the list in which the list item marker had been suppressed. This list rendered very well and was extremely popular with at least two of testing team who found repetitive list markers particularly annoying.
So, the moral at this point is:
Use ordered lists by all means but please stay away from roman numerals. No matter how attractive they may appear within a graphical browser, they will almost certainly reduce your carefully marked up text to audio garbage within a screen reader.
Next – what is the best list to use for a site navigation menu?
An unordered list (the current favourite), an ordered list (favoured by some semantic advocates) or a definition list (again, there are semantic arguments for using this approach)?
Which, if any, offers the highest level of accessibility/usability for screen reader users?
No, in fact the thing we should do is merely add this to the catalogue of things Jaws gets wrong. It’s their problem, not ours. The HTML spec for ordered lists is years old.
Also, you didn’t test other screen readers or the type=”" attribute. At best your results are suggestive.
I’m not going to stop and defend JAWS. I often find it’s implementations to be bizarre and illogical. I’m assuming that this is a speech parsing issue where the engine needs additional dictionary entries for ‘words’ such as “IV.” depending upon context, punctuation and spacing but, I freely admit that my knowledge of speech parsing could be written on the back of a postage stamp!
However, whilst JAWS does get this wrong, I think we should at least be aware of it and try to avoid this particular bug were at all possible. What’s wrong with factoring this into your decision as to which numbering style to use?
I agree – the test sample is very small and, as such, the results can’t currently be described as much more than ‘worth bearing in mind’. I’d dearly like to gather more data. I’ll try adding a feedback form to the test page asap and see if I can gather some data on WindowEyes, IBM’s HomePage Reader and Opera 8 from colleagues.
With regard to the type=”"attribute, I think that should be tested separately. Perhaps a second test page replicating the current one but with each list duplicated – once with the type attribute set and once without? That way, we should be able to get some data as to whether setting the type attribute affects overall readability.
I agree that even if JAWS gets it wrong, there’s little point in punishing the end user if it can easily be avoided.