Spider Trax

Web Accessibility Statements And User Support

My attention was recently caught by a post from Rosie Sherry called Showing web accessibility statements the door. In this post, Rosie wondered if perhaps web accessibility statements were being taken too far? She felt that, in general, accessibility statements were:

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

She also felt that their target audience was being forgotten and asked how these statements would benefit a disabled user who “just wants to get on with things“?

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

Because the standard site contact page may not offer non-electronic contact information as well - such as minicom or textphones. Many sites don’t even offer something as simple as a mailto link as a alternative form of contact. They appear to assume that everyone can use a contact form effectively or wants to use an online form.

That is a very unwise assumption to make.

Secondly, contact pages are often specific to certain kinds of contact - sales enquiries, general messages etc. The person at the other end of the form may not be the best person to contact with regard to accessibility issues or enquiries. So it’s likely that you’ll need two sets of contact details and two forms anyway. Unless of course, you try to pile it all into one form using selects or radio buttons — at which point the form just gets too complex and no one wants to use it.

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

That’s really still open to debate and I can can point at user groups who find access keys very useful providing they’ve been implemented with due care. But whichever approach you chose to adopt, telling users would seem to be a Good Idea generally. Or are they just supposed to try various shortcuts out in the hopes that one of them will work eventually?

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?
Rosie Sherry

Listing how headings are used might be extremely useful to screen reader users who often navigate pages using headings. Telling them that you will be using H1 headings for the site name and H2 headings for page titles could significantly speed up their navigation around the site as they now know which heading to focus on (H2) and which to ignore as redundant (H1).

Obviously, if any site feature depends upon additional client-side technology, (e.g. JavaScript) or plugins (e.g. Flash) then users really need to be told about this and if there are any alternatives.

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

In theory, no. But given that so many sites aren’t built to any recognisable standard and have never been within a mile of a user test, it is arguable that, by knowing what standards a site has achieved, users may get a good idea of how easy (or not) it will be to use the site based upon their past experience. As it stands, I don’t really see how publishing such information can hurt.

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

We shouldn’t have to, in theory — especially if we just go ahead and assume that every user is as knowledgable as we are. However in practice,that is rarely the case.

Users may not know how to resize text within their browser or that they can use screen reading software to supplement their graphical browser if they have problems reading text. In fact there is no way to tell the difference between the highly experienced JAWS user and one who is trying screen reading software out for the very first time on the Web.

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

Sure, you wouldn’t tell someone who knows how to walk how to climb stairs. But you would teach someone who has just lost both of their legs in an accident how to use a wheelchair,wouldn’t you?

Users with newly aquired “special needs” will continue to appear on the Web all the time and I feel it is unreasonable to assume that they will already have learnt all that there is to know about their assistive technology or what they can do to make the web more accessible for themselves. As such, Rosie’s stair-climbing analogy is strained at best and could be perceived as downright insulting at worst. (And I say that as someone who did have to learn how to use Dragon quite suddenly last year — and, frankly, I needed all the help I could get!)

The trick, as I see it, is not to replicate existing information but just to point to a few good resources and leave it at that. This is the principle behind the whole web-hyperlink idea, after all. You know — links to useful information …

I do agree, for more complex and interactive sites, there may be a requirement to offer assistance. Rosie Sherry

Define “complex and interactive”. Where exactly should the line be drawn?

To some users, a site with links is an interactive site! And why should only users to “complex” sites get additional support? Could it be that there’s a tendancy to make assumptions here about what users should or shouldn’t know before they are allowed on the Web?

What next? A proficiency test before you get your browser’s licence?

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

I don’t think the information I’ve mentioned above has to be packaged in a page that is always called “Accessibility”. I agree that it could equally be placed in a Help section providing that a link to that section is available on every page. Perhaps in a page header or footer? And don’t forget:

<link rel="Help" href="http://www.foobar.com/help/" />

in the document head either.

As it currently stands, I know, from working with testers from the Shaw Trust, that disabled users do actively look for some sort of accessibility page shortly after entering a new site. Experience has taught them that this is the best place to find the kind of supporting information that may be essential if they are to navigate the site effectively. But, at the end of the day, does it really matter if the link is called “Accessibility” or “Help” as long as there is some real support there?

At the end of the day, this is precisely what PAS 78* is trying to achive with its focus on an accessibility statement. Real support — not lip service. And definitely not unfounded assumptions about users or different rules for different sites.

As for the disabled user who “just wants to get on with things” — no one is forced to read an accessibility page or statement and users are quite capable of deciding whether they want to read it or not.

So, where is the problem?

* Publically Available Specification 78: A guide to good practice in commissioning accessible websites

Top