Accessibility findings vs recommendations

This article on newspaper site accessibility dropped into my inbox, from the author hoping to get some coverage from accessibility related sites. Whilst the aim is good (testing sites to increase the awareness of accessibility), I wouldn’t be happy with the recommendations.

The meat of the article is the findings from John (a retired research worker from Sussex) and his use of the Independent Newspaper site. For example:

The text-heavy appearance of and its lack of a left-hand navigation bar aided John’s ability to tab through the content, as he said he would rather be tabbing through individual links to articles than an excess of section headings.

This is a little confusing to a web developer, as in the tabbing order, there are 10 section heading before the content. In the source code, there are almost 200 links in the top navigation, one of which is the ‘Front pages’ link referred to later in the article. That doesn’t really match the conclusion drawn about accessibility, and it’s just a red herring to infer from this that the text nature of the site is a good thing.

What would be really useful for that situation is a skip link, or a better method of drop-down navigation.

There are some valid points on pop-ups and consistent navigation. The search issue (there being two) was especially good because visually, the two searches are very separate. However, in the source they are next to each other, with no means of distinguishing them. However, you might take from the article that one should be removed, whereas a hidden heading or two would be more appropriate here.

I think one of the bigger concerns for me is that John apparently uses JAWs 3.7, which has been out of date for at least 5 years! The impact of this is that many functions standard since version 6 (and improved in 7 & 8 ) aren’t available, so John didn’t know to complain that many of the headings are not marked up as such, or ask why the navigation items are wrapped in <pre> elements.

As well using an old screen reader, it’s problematic to just use one screen reader. I wouldn’t expect many organisations to test with more than one screen reader, but you can’t then generalise the results without reference to the accessibility standards. It is notable that the expert opinion has to try and put John’s finding in perspective, bringing in comments about non-screen reader issues.

Don’t get me wrong, getting a real user to test a site is a good thing, and helps to hammer home why it’s important.

However, to work out how to improve, I would want a much broader view. Usability testing of any kind is essentially a case study approach, and the findings have to be taken in a wider context that encompasses of the all the site’s users and goals.

(For a much more in-depth look at this type of issue, try reporting accessibility issues. You can also find all the accessibility articles on

4 contributions to “Accessibility findings vs recommendations

  1. Hi Alastair,

    As the author of the article in this post, I just wanted to say thanks for your thoughts about the scope of our study.

    You’ve pinpointed some of my concerns as the study was being conducted – namely that this it was extremely subjective.

    We’ve tried to flag this up in the articles as much as possible, and given the time and resources I would like to have extended the study along the lines suggested.

    While it is subjective, our experts told us that many of the problems John encountered were a common experience for screen reader users, so hopefully some wider conclusions can be drawn in this respect.

    Regarding John’s equipment – it is an old version, but again many usability and accessibility specialists said this was an issue in accessibility itself: JAWS is expensive, blocking many users from having the latest version.

    I agree that to address accessibility issues on a website based on the findings of one user would be damaging – The Guardian’s chief technical strategist makes some interesting points in his response to our article on to this effect.

    I think your distinction between the why and the how is a very accurate one, and I don’t think we, as journalists, are necessarily qualified to provide the how. I do hope, however, that the sites we reviewed and contacted might start looking into the how themselves, if they’re not already doing so.

    Thanks again.

  2. Hi Laura,

    Thanks for the response, I wasn’t trying to be critical of your effort, just cautionary about what people take from this.

    The issues are probably fairly common amongst screen readers users, but the cautionary aspect is what you actually do about them. In many cases people (site owners) jump to fix those issues one person brought up, not realising they may be hampering others using different technologies.

    I hope that in your upcoming or concluding articles, you can make reference to the official guidelines, which make it easier to cater for all people (except perhaps people with cognitive issues).

    Accessibility requirements can often seem conflicting between different user groups, but there is usually a way to satisfy all groups without resorting to different site versions.

    When you say things like well-designed for use by JAWS., it implies that people should be designing for JAWs. That is fundamentally wrong.

    Pages should be designed to be as universally accessible as possible, not targeted at the moving target of different technologies.

    Regarding the age of access technologies, it is true that people do not tend to upgrade quickly, partly due to cost, but also due to the considerable amount of learning needed for each new version.

    However, you would get significantly different results on even a 3/4 year old version, as after 3.7 Freedom Scientific made much more effort with regards to web accessibility in JAWs. Several of the issues brought up in the articles would not have been issues in even version 6, let alone 8 or 9.

    When someone says something like “JAWS will only read text, so I imagine there are quite a lot of pictures on this site, which is less helpful to me as a screen reader user.” This shows a lack of knowledge about their own technology, as JAWs will quite happily read alternative texts provided on images, assuming the site has included them. There is little a site owner or developer can do in this case.

  3. I hope to write a concluding/reflective blog at the end of the week and I’ll make sure I flag up the official guidelines and raise the points we’re discussing here.

    I see what you mean about certain findings implying that pages should be designed for JAWS, but I hope that our introductory piece to the series makes it clear that the reviews relate to the (very individual) views of a JAWS user. I agree – what works for him, will not be applicable to all.

    I also strongly agree with your sentiment that “Pages should be designed to be as universally accessible as possible, not targeted at the moving target of different technologies.” – this was something that came across in a lot of interviews with accessibility designers and experts I spoke to beforehand, and something I’ve emphasised on the site’s blog.

    I’m really grateful for your thoughts – you’ve managed to articulate a jumble of issues in my mind better than I could!

Comments are closed.