ThePickards
standards, accessibility, and ranting and general stuff by the web chemist

Rosie Sherry has written an article called Showing Web Accessibility Statements The Door which I first came across on an article on Accessify.com and which I’m going to quote extensively from here. In it, she argues that accessibility statements found on websites aren’t really of much benefit, and we’d maybe be better off without them.

I disagree slightly. I would respectfully submit that it’s only the vast majority of accessibility statements that are of no benefit, and we’d be better off with a clearer understanding of what makes a good accessibility statement, and — I agree — calling it something else.

Rosie notes that she believes web accessibility statements have been brought about by fear of prosecution:

The use of web accessibility statements seems to be linked to the Code of Practice from the DDA. It appears that the fear of being sued over inaccessible websites led to the mass introduction of accessibility statements. This made it appear that people were making an effort to make accessible sites.Rosie Sherry

Whether or not this is true outside the UK, I don’t know — and I don’t have the time or inclination to carry out an in-depth study, I try to have a life as well as a website — but I do think she’s right in suggesting that a lot of sites have added accessibility statements in order to try and demonstrate a level of statutory compliance.

It is worth noting that local and national government sites in the UK are expected to expected to conform with WCAG 1.0 at the Double-A level, and so many include overly technical information relating to accessibility, in order to try and demonstrate that they have achieved this statutory level of compliance.

[we]

• Validated the website against the standards and recommendations of the Web Accessibility Initiative (WAI). This initiative is a programme lead by The World Wide Web Consortium (W3C)
• Ensure that all HTML documents conform to W3C HTML and XHTML Recommendations and other HTML standards.
• Ensure that the website is Bobby Compliant. Bobby is a comprehensive web accessibility software tool designed to help expose and repair barriers to accessibility and encourage compliance with existing accessibility guidelines.

UK Council

Just don’t get me started on exactly how useful are automated accessibility testing tools. Okay?

Rosie then lists some common problems she has with accessibility statements. She suggests that they have lost their focus on actually being of some benefit to the end user and instead are:

• Too long
• Technically orientated
• Focused on displaying of adherence to standards

Rosie Sherry

From a little snoop around a number of web sites, I have to say I’m inclined to agree with her:

This website makes full use of cascading style sheets to control the layout and appearance. However, it can still be viewed, navigated and used with the stylesheet turned off (the Firefox and Opera web browsers allow you to turn stylesheets off - why not give it a try?).UK Council

…there are also many councils which use accessibility logos, for example suggesting that their sites comply with WCAG at the highest level because they’ve been rated appropriately by the automated Bobby tool. Please see the link I provided earlier …

We also find sites which seem to insist that they’ve complied with everything that could possibly be expected…

All pages on this site are WCAG AAA approved, complying with all priority 1, 2, and 3 guidelines of the W3C Web Content Accessibility Guidelines. Again, this is a judgement call; many guidelines are intentionally vague and can not be tested automatically. We have reviewed all the guidelines and believe that all these pages are in compliance.UK Council

Hmm. Well, you’re wrong. In fact, that specific part of your accessibility statement fails a checkpoint — you’ve used the text “W3C”, which is an abbreviation of the “World Wide Web Consortium”, but you didn’t…

Specify the expansion of each abbreviation or acronym in a document where it first occurs.WCAG Checkpoint 4.2

That’s always a risk with specifying a compliance level. Some smart-arse like me can come along and pick holes in it immediately. The one I took this from is actually a pretty decent site — it validates, it doesn’t use tables for layout, lists are marked up appropriately and so on, but like on pretty much any site of any significant size, if you look hard enough you’ll be able to prove it doesn’t comply with every single guideline in every single case.

What I have noted however is that, on the whole, public sector websites tend to put much more thought and effort into ensuring accessibility than private sector sites. There may be a tendency to over-egg the accessibility omelette, as regards claiming a higher level of conformance, but generally public sector sites will have taken a number of steps down the road to accessibility and will be more accessible than some very large and well known private sector sites.

So should we drop the conformance claim from our websites?

On the one hand, public sector sites are specifically asked to conform with WCAG 1.0 at the Double-A level, and the W3C’s methods for including this specify that unless you want to indicate a separate conformance claim for each individual conforming page, you must provide the following information:

• The guidelines title: “Web Content Accessibility Guidelines 1.0″
• The guidelines URI: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
• The conformance level satisfied: “A”, “Double-A”, or “Triple-A”.
• The scope covered by the claim (e.g., page, site, or defined portion of a site.)

WCAG Conformance

On the other hand, this information is of no practical benefit to anyone, and other than someone with a particular interest in accessibility is likely to look like a meaningless pile of technical jargon (whereas to be fair, it is actually a semi-meaningful pile of technical jargon).

So what to do?

Well, a public sector organisation is expected to conform to WCAG 1.0 at the Double-A conformance level. It is not specifically mandated that it must claim this level of conformance however. Therefore the most logical thing to do seems to be to keep the accessibility benefits, but stop telling people all the technical guff that goes with them.

Do you even need to say “this site has been designed to be accessible”? After all, if people can use your site, they already know they can use your site, and if they find problems using your site, telling them your site is accessible is adding insult to injury.

Rosie then turns her attention on PAS78 and is just as direct with her criticism:

The PAS 78 states that accessibility statements should be used as contact place and for stating accessibility features such as access keys. I say there is no point.

• Most websites have a contact page anyways, why duplicate things?

There is trend for not implementing access keys as they are believed to not be much use in practice.

• What other features are there to most websites? Increase font size? Tab order? Are these features – or just common sense practice? Why state the obvious?

Afterall, if there are a stairs in a building, you wouldn’t provide a statement which tells someone how to climb them. (Right leg up, left leg up…!)

Rosie Sherry

I agree with the majority of this — if you’ve got a contact form, I don’t see the point of duplicating it, and I also think Accesskeys are more trouble than they are worth. However, I do disagree with the “stairs” analogy (although it did make me smile).

For me, the accessibility statement/building access analogy would be like having a note attached to the stairs, indicating that if you’re attempting to reach the higher level and you’re using a wheelchair, you may find it helps if you use the ramp situated over there instead. In other words, just because the majority of people who come to a site don’t need telling about something, that’s no reason not to offer additional advice to people who might benefit from it.

Rosie then asks:

Do we need to state that standards and tests have passed?Rosie Sherry

The question is “is it of any benefit to any users?” No it isn’t — they’ll either find the site accessible or they won’t, regardless of what we actually say about standards.

Do we need to educate a user on how to use a website?Rosie Sherry

The question “is it of any benefit to any users?” would get a different response here. It might be. Some visitors may not be aware of how to carry out common tasks such as adjusting their text size, and therefore some people will benefit. Exactly who is likely to benefit depends on your site.

If it’s a highly technical site on web design, maybe not. If it’s a public sector site telling people how to apply for benefits, you can’t expect all of the users — who may be in particularly vulnerable or disadvantaged groups — to begin with a high level of knowledge about using the internet.

Rosie expands on this point:

For example, if you use CTRL + to increase font size for one website, it will be the same for the next website you go to — unless you change software/browser purposely. Surely we cannot be responsible for educating each user?Rosie Sherry

Again, I disagree. We aren’t expected to be responsible for educating each user. We are expected to be responsible for providing enough information for someone to use our site. Our sites should be sufficiently accessible and usable that a moderately experienced internet user shouldn’t need specific instruction to use them, but there is nothing wrong with providing additional information for novice users.

While I don’t agree with every point Rosie has made, I do agree that the sort of accessibility statements that are commonplace are of very little benefit to the majority of users, and she’s got a good idea for a solution:

…there may be a requirement to offer assistance, but why not have it in a help area which addresses multiple issues. You could call it “help”, “using this site” or “about”, it would be a central area of help and still be easy to find and of use to everyone who is interested.Rosie Sherry

Good idea, Rosie. Let’s scrap accessibility statements — they’re boring and no-one wants to read them. I’d avoid calling it “about” though — that sounds to me more like something you’d use for terms and conditions, copyright information, privacy policies and so on.

Accessibility policies tend to be overly technical — for example mine is quite technical as I was looking to test my conformance against WCAG 2.0, but now I’ve proved that to my own satisfaction, maybe it’s time I rewrote it. Let’s instead have a “Help” section. It’s a nice, simple, one-word option that most people would be willing to click on if they were having troubles with someone’s site.

So what do we put in the help section? Bear in mind it needs to be simple, clear, understandable, and not overly long.

Well, here’s my initial thoughts:

Using This Site

If you must use Accesskeys, you may want to tell people how to use accesskeys on your site. If someone is likely to use accesskeys, they’ll probably already be aware of how to use accesskeys in their current browser. If not, you can tell them if you really must. But don’t provide a big list of browsers and accesskey combinations — this will just put people off and make them skip to the end of the section.

Instead, either sniff the user agent and tell them how to use accesskeys for their specific browser — or provide a link to another page or website that covers accesskeys in more detail. Don’t force people to read through a large list of key combinations — or do both. Use something like:

For example: To operate Accesskeys using Internet Explorer 7, you should press ALT and the accesskey together, release them and then press return.

Yes, it is possible to get your browser to present itself as a different user agent. However, people who have done this have done it from their own personal choice in order to pass off their browser as something else: they’re already likely to be well aware of how to operate accesskeys and change their preferences and so on, and the fact that you can’t recognise their browser is not your fault — they have deliberately disguised it.

I’m sorry, but AllYourBrowserAreBelongToUs 1.0 is not a browser known to us. Either consult your own reference materials to determine how to use Accesskeys, contact the browser developer, or try looking on the BBC’s My Site My Way website for more generic information.

Changing your preferences

If you offer customisations specific to your site, such as allowing the user to choose from alternative stylesheets, define their own accesskeys or alter the default text size, this is the place to provide those options (or at least a link to those options, if they would clutter up the screen). You may also wish to consider allowing the user to build a customised personal stylesheet, in the manner offered by the excellent English-language site the Government Offices of Sweden. Note that they specify that you require cookies to save customisations and you get progressive enhancement by means of a preview area if you have javascript supported. Excellent job.

Contacting Us or Reporting a problem

If you’ve already got a separate “contact us” page that’s visible from every page anyway, you might be happier just calling this “Reporting A Problem”. In any case, make it clear that if someone does have a problem when using your site, you want to know about it so that you can attempt to put it right. This could be as simple as saying:

If you experience any problems with this site that you are still unable to resolve, please contact me and I will do my best to try and help.

Technical details

If you really and honestly feel that you must specify all the technical details of your conformance claim, the fact that you’re satisfied your site is 100% accessible because it’s Bobby compliant (just don’t get me started, okay?), or even if you just want to list a whole pile of guidelines from WCAG, don’t do it here. Go create a page somewhere called “accessibility conformance claim”, and add a link to it with a short piece of accompanying text on your site information page. Remember, if it doesn’t actually help someone use your website, it doesn’t belong on your help page.

I’m sure there are improvements on this that could be offered, but that’s my starting ideas. What’s yours?

This entry was posted on Saturday, November 11th, 2006 at 5:03 pm and is filed under Public Sector, Articles, Standards, Accessibility, Life. You can follow responses via my RSS 2.0 feed. You can leave a response or trackback from your site.