Joe Clark recently published the results from a limited study of screen-reader usability at a redesigned, standards-compliant e-commerce site.
The revised site used semantic HTML markup that usually passes validation tests and also incorporated many common accessibility features. A study was carried out with screen-reader users to determine how well compliance with Web standards and accessibility guidelines translated into actual usability and accessibility.
Even though the study employed only two participants (both of whom were expert screen-reader users) there is still plenty of insight to be gained from the study. In particular, the participants used different versions of JAWS. The participant using version 5 could achieve almost all tasks, whereas the participant using version 4.51 could not achieve any tasks – this was put down to inadequate HTML and CSS support in his version of JAWS. The study concluded:
It appears that mere standards compliance does not always translate into full accessibility for screen-reader users. First of all, the screen readers themselves fall down on the job of interpreting compliant HTML and CSS. Moreover, some site designs whose interfaces are understandable when viewed in a gestalt do not translate well into sequential viewing.
The latter point highlighted another interesting result, and one which shouldn’t surprise those who try to implement accessible sites in the real world. Design decisions affected the experience of the study participants to such a degree that some tasks were still not achievable. Ticking all the WCAG boxes does not guarantee accessibility.
On a similar note, Russ Weakley and Roger Hudson recently published a study of real world interpretation of HTML table mark-up by assistive devices.
In particular the study tested the difference between id and headers versus scope to see which of these options was more widely supported in assistive devices. If you’re unsure how this mark-up is applied to tables, I recommend a read through Roger Johansson’s tutorial, Bring on the tables. The report came to a surprising conclusion:
At this stage, it appears that id and headers are the most effective way to make complex data tables accessible. Although id and headers are slightly more difficult to code than scope, the apparent poor screen reader support for scope means that this is probably not an effective accessibility option.
This is a shame as scope is generally much simpler to use than id and headers, and in almost all cases requires much less mark-up. This might be why the WCAG HTML Techniques note spends much more time explaining headers than it does explaining the more commonly used scope.
Accessibility · Mark-up techniques
Alistair wrote:
I have to say, its an interesting outcome. I haven’t personally looked into the screen reader technology before, so I’ve taken the word of others on how it performs. If what Joe has highlighted is a reasonable outcome for ‘most’ scenarios, it would appear I and a lot of others, have placed faith in the wrong places.
I suppose the good thing is that at least the headers technique does work. Imagine trying to access a table heavy site without it? That said, chances have it that most sites don’t implement it anyway so it is up to the screen readers to interpret simple table markup. Hell, a vast portion of sites still use <strong> inside a <td> to signify a heading.
Al.
Small Paul wrote:
Eesh. A headers attribute on every damn cell.
Gah.
karim wrote:
Sorry for being out of topic, but…
actually, well… Isn’t it a bad usability practice to give links on single words without a clear destination of a link?
example:
Joe Clark recently published the results from a limited…
I used to see such links more and more on blogs, and I humbly think that links in a “content usability” matter should be fully described.
“I always want to know where I’m going :) ”
Indeed, IMHO, that would be beter to give at least a “title” attribute to links containing a brief description of the target.
Well sorry for being so direct, but we speak usability and I’m just wondering if I was wrong to think this way.
Rich wrote:
karim – I’m a firm believer in context. The links in your example, when taken in the context of the sentence, make sense despite the link itself being but a single word.
I usually add title attributes to links when I don’t think the destination is particularly obvious.
But if you really want to know there the link is going to then look in the status bar; it’s quicker that waiting for a title tool tip.
I’d be interested to know how you would have written my opening paragraph, in particular what treatment you would have given the links.
karim wrote:
Rich, You’re right.
But I wonder if footnotes (or sidenotes with dhtml) aren’t better.
Thinking about nicetitles too…
Maybe, notes like those on Fernandos’ post (see below) are useful too, don’t you think?
Fernando’s LinkNotes post
karim wrote:
Here I’m again :)
What’s about the idea of footnotes in your previous post?
Have a nice day :)