Accessibility statements or Site help pages?

It’s been on my to-do list for ages to rework the accessibility statement on this site into something closer to what we use for most sites at my dayjob: a “Site help” or “About this site” page. I was recently reminded of this when reading Peter Krantz’ Don’t Provide an Accessibility Statement at Standards Schmandards.

The title may sound a bit over the top. After all the talk about accessibility statements over the last few years, are we supposed to stop providing them now? No, not really, but perhaps we should replace them with something better. In the article Peter refers to Evaluating the Usability of Online Accessibility Information, a study showing that users in general have a hard time finding and understanding accessibility statements. The study also indicates that users may be more inclined to use a page that does not specifically mention accessibility, since they may not understand the term “accessibility”.

Furthermore, accessibility statements are often very technical and seem aimed more at other developers than at the people who would actually benefit from the information. Yep, I’m guilty.

The report suggests that developers consider adding widgets that replicate browser functionality, such as text resizing. I’ve never been a fan of widgets like that, probably because they are often found on sites that break just about every guideline there is, but claim to be accessible because users can click on a teeny-tiny “A” or “T” to make the text bigger (provided they have JavaScript enabled, of course).

I think a better idea is using the “Site help” page to explain to users how their browsers work. Not an easy thing, but you have to start somewhere.

Posted on October 31, 2006 in Accessibility, Quicklinks

Comments

  1. The “Site help” page is IMHO useful for people, than Accessibility statements.

    But what about usability? Is for people reasonably to read “Site help” and learn tips for easier use? And have they time for it?

  2. Surely context sensitive help activated on hover, or by some other means, would be much more useful than a separate page?

    In my opinion, making that help intuitive and accessible would be the real challenge.

  3. On my latest site I’m building for a client, I’ve actually got a “Technical Information” page where I’m putting all the developer-oriented stuff about accessibility and microformats implementation etc; freeing up the site help for just the summary accessibility information - so catering for both audiences.

  4. November 1, 2006 by Jamie Dixon

    A very interesting topic you’ve raised here Roger.

    I often find with this type and level of communication, that chunking down, and realising exactly what is being aimed for, can be not only an advantage, but also a key to the communication being valid and useful in the given context.

    When we consider what the purpose is our communication, often it opens up a meta-level of access thinking, in that we can begin asking, not only what type of accessibility does our site provide, but also realise the level of accessibility (or lack thereof) our accessibility statement is presenting.

    As someone who works in the communication industry (language and behaviour) as well as being a full time developer, I often come across writings and explanations, that on the surface seem to meet the required criteria for access, yet when compared to the context in which the communication was commissioned, there can often be a total lack of correlation.

    The point is, if you’re writing something for a specific set of people, or you want something to be understood by a wide variety of different human beings, from different backgrounds and with different abilities and knowledge, its often of great benefit to write in a way that is clear, understandable, and contains as few ambiguities and presuppositions as possible.

    Having been a reader of your articles for quite a long time Roger, I can confidently say that the majority of your posts fit in with this level of clarity.

    I’m looking forward to reading what others have to say on this topic.

    That’s my 2c, you’re mileage may very well vary.

    Jamie Dixon

  5. Regarding what’s most important I’d have to say a Site Map. Offering one, after all, a required accessibility checkpoint. An accessibility statement is not.

    For my own uses, though, almost exclusively I create a “Site Info” page on which I put accessibility information, site map, privacy policy, copyright info, disclaimer, etc. I then provide fragment identifiers or bookmarks on the page so from anywhere on the site I can flag any content body of interest. To me this is an ideal solution. A catch-all. In my eyes this method makes a lot of sense.

    Example:

    For the “site map” part of it I go one step further and use an “include” so I can also include the same file on my error pages:

    Example:

    http://green-beast.com/foo

    Mike

  6. Or “Site Help”… that works ;-)

  7. I have a rather detailed help page that includes accessibility information and an informal “statement.” If you want to take a look and see what you take away from it, or give me your opinion, visit loadaverageZero Help.

  8. Wow, Douglas… that’s really comprehensive. Nice.

  9. @Douglas: While I applaud the level of detail you’ve gone into with your help page, I think it goes far beyond what most users would find useful and stretches into the “very technical” realm that Roger was referring to. It’s really quite long and looks overwhelming - I’d be interested to know how many users are scared away by that page.

    @Roger: I think that a site help page explaining to users how to use the functions already provided to them by their browsers is probably a great way to go about it. I think you’ll remember the bold article that Jeff Croft posted a couple months back that touched on that same idea.

  10. That is good idea to provide some kind of “browser funcionality” info. But don’t you think it maybe almost impossible to deliver info about every browser on the market? That is why I think that browser independent widgets working together with “site help” page may be the best usability solution.

  11. Douglas: That is intense! I think if I were an average user I would have stopped reading at “PHP data objects”, though obviously your site’s readership is technically inclined ;)

    Generally speaking I like the idea of a ‘Site Help’ page that groups together information that might help users to get the most out of the website - including accessibility.

    I’m not in favour of using accessibility statements, (x)html compliance badges etc as bragging tools - although on websites aimed at other web designers I understand the political relevance of drawing attention to the value of accessibility and web standards.

  12. As people are generally not surfing but are actually fulfilling tasks on the web - ie order stuff, read email, look for price of external hard drive, etc - I would point out timidly that site help itself could make me wonder what in the design is wrong to make someone on a site feel the need to fulfil that function? As Jeff Croft mentioned more people click site help than accessibility statement how much of that equates to “I need help!”??? Which may be another issue entirely.

    I don’t know if that is an entirely fair question but truely if accessibility statements are never visited that’s one issue (making them dejargonized will not affect people not going there in the first place), but if people are hitting site help it should be an indicator something in the information architecture, general design or otherwise might be askew. That’s based on the time poor user theory that nobody just goes and clicks random links on a site unless they fulfil an expected need.

    Does that make sense? I’ve had a blocked ear all week and it may be drivel but as far as I can see just changing Statements to Help isn’t necessarily IMO the same thing. A Statement in my view is similar to about, policy, privacy statements etc - a site help is like FAQ or may denote the need for better search, and maybe site map is similar in some ways.

    Anyway I just thought I’d put that in rather to perhaps deepen the conversation Roger. There seems an expectation in the change to site help that its an obvious replacement and I’m not entirely sold. Perhaps its just a different page entirely?

  13. I’ve advocated “Using this site” for the past year or so.

  14. As an aside, I’ve often wondered about the whole concept of bragging about how great one’s site is by way of linking to automated validation and accessibility testing tools. I think there are better ways of raising awareness of accessibility and well-formedness among clients (and developers should already know better). To look at it from another perspective, your visitors don’t care. Period.

    Regarding “Accessibility Statement” vs. “Site Help,” what I did for our site was to link it both ways — once as “Accessibility Info.” (in our sidebar, near the bottom) and once as “Help” (in our header). I think the non-technical approach is spot-on though. Explain, in non-technical terms, only the accessibility features that require explanation (e.g., what your access keys are, how to resize text within the browser, etc.). Leave out the fact that you’ve used “tabindex” and “totally valid CSS 2.1 and XHTML 1.1”. Again, your users don’t care.

    Anyone care to comment on how well they think we’ve accomplished this?

  15. I’m discontinuing, and will in time delete, all ‘accessibility statements’ and ‘how to use your browser’ help pages on sites I’m involved in.

    A site is more or less accessible because of the way it’s built and maintained, and no statement adds anything of value to the average user, IMO.

    Users should know how their own browser and assisting software works. We web designers should too, so we can accommodate visitors as best we can. However, we can hardly cover all solutions and ways they are used, so I don’t think we can add much by writing in detail on the subject for the end-user.

    At best we can help users by providing links to the relevant info-pages on software-vendors’ sites, as there is a chance that updated information is provided on how to use each specific software-solution.

    @Blair: that help page looks reasonably good, IMO. However, it seems like Firefox 2.0 is messing up your accesskey list.

  16. @Georg: Ugh. Somehow, until now, I had missed any mention of the change in Firefox 2.0 with regards to firing access keys. Thanks for the heads up — Gez hasn’t updated his feed with that article as of yet…

  17. November 3, 2006 by Roger Johansson (Author comment)

    Steve:

    Surely context sensitive help activated on hover, or by some other means, would be much more useful than a separate page?

    For certain things yes, but collecting and displaying general help on a single page is still useful I believe.

    Jamie:

    Having been a reader of your articles for quite a long time Roger, I can confidently say that the majority of your posts fit in with this level of clarity.

    Thank you! I work hard on that. Sometimes I’m not too happy with the results, especially considering how often people seem to misunderstand or misinterpret what I write. In some cases that seems to be a problem on the reader’s end though ;-).

    ‘Mike:* Explaining how to resize text in the browser is a good idea. Not so sure about specifying which automated tools were used for testing though.

    Douglas: Wow, that is a massive help page! I agree with Jonathan though that it is both good (everything you could possibly need to know about the site is there) and not so good (it is a bit overwhelming).

    Jonathan: Yes, I remember Jeff’s article ;-).

    Kuba: Of course it isn’t feasible to provide detailed instructions for every existing browser. What we can do is provide one or two solid examples and then write something like “If you use another browser, these settings should be available in the View menu”. You get the idea.

    nortypig: I see what you mean, and you do have a point. A “statement” could be there for political or compliance reasons, much like a “privacy policy”. To me the idea of a “Site help” page is to provide information that ideally should be applicable to every site the user visits, not just your site. Letting people know about text resizing and print preview, for instance, would be helpful to them no matter what site they visit.

    Blair: The sections on text resizing and printing are almost exactly what I had in mind. I am an accesskey skeptic for several reasons, one of which Georg points out: they are far too inconsistently implemented in browsers to be of any real use.

    Georg: I agree fully that users should know how to use their software. But since apparently most Web users don’t, I like the idea of doing what I can to educate people.

  18. Accessibility statements have always bugged me, they just don’t seem quite right.

    It wasn’t until recently that I looked into things, where I have now published my thoughts on my software testing blog.

    Feedback from the community is appreciated.

  19. Rosie Sherry would like to see the back of them:

    Showing web accessibility statements the door.

  20. I and some colleagues carried out the study of the usability of accessibility statements referred to in this and other blogs, so I’m glad to see it’s helping to spark some debate!

    The real problem here is that many (most?) people with impairments don’t know what they can and can’t do to improve the way they view or interact with web content. Whereas we pretty much all know that if we’re struggling to hear the audio output of a TV or radio, we can adjust that easily using a control on the device, or a remote. It would be ridiculous for a TV news presenter to say “don’t forget, if you can’t hear me very well, turn up the volume or turn on captions using your remote control.” Until user agents make it as equally obvious that we can make similar changes to web content, there is a problem whereby some people will struggle to access web content - even if it’s designed with accessibility in mind.

    You might say “well, that’s where RNIB, or AbilityNet - or insert the name of any other charity doing sterling work at helping to improve the accessibility of the web - take responsibility”. That may be so for someone who knows they’re disabled, but what about the millions of people who acquire impairments over time - people with age related decline in visual or manual dexterity for example? They are not necessarily going to wake up saying “oh dear, I’ve just become visually impaired today, so I’d better call the RNIB”. But suddenly, at some point, they will need some help - and if they don’t get it, they may ultimately give up using the Web. At the moment browsers don’t offer that help in a particularly accessible way.

    In the study, our subjects were by and large very reluctant to poke about in browser menus for fear of ‘breaking’ things - in fact I’d say most had no concept that the web page they were viewing could be changed (one person would copy and paste the text of a page into Word then change the font size so he could read the text).

    So my view, reinforced by our study, is that as web content providers, we can do something, by providing a page that tells people what sort of adjustments they can make, and - if you want - how they can make them. Best of all is to point to a resource like like the BBC My Web My Way site, which is expansive in terms of impairments and browsing setups covered - and saves you the work of maintaining and updating this information. The challenge, as we identified, is what to call the link to this page - and how to make it as easy to find as possible.

    Re accessibility widgets - our subjects liked them when they found them - but I’d stop short of mandating their use. I don’t think polluting pages with user-interface controls is a long term solution. It leaves us with a choice though - go the extra distance to retain site visitors by helping them with accessibility advice, or doing nothing, which may leave a nominally accessible site but without the support that people need to use it. It is tough on authors, but a short term (I hope!) fix until browser manufacturers get their act together.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.