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
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
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