Summary

Accessibility statements are an ideal place to empower visitors to your website. Most accessibility statements are too technical, and don't necessarily address the needs of the visitor. Those that do address the needs of visitors often have the information lost in a myriad of other information that is unlikely to be understood by the average visitor to the website. What should and shouldn't be included in an accessibility statement?

Author: Gez Lemon

This article has been kindly translated into French by Monique Brunel.

Contents

Accessibility Statements

An accessibility statement typically shows an overview of the accessibility features implemented on a website. Unfortunately, most accessibility statements concentrate on the technical aspects, which will mean very little to most visitors of the website. The technical aspects will make sense if your website is aimed at web developers and designers, but if your website is aimed at the general public, the accessibility statement should highlight how to get the most from your website in a way that is understandable to your target audience.

The first and most important part of an accessibility statement should demonstrate your commitment to accessibility, and provide a means of contacting the website for people that may be experiencing problems. For example:

Juicy Studio is committed to ensuring that this website is accessible to everyone. If you have any questions or suggestions regarding the accessibility of this site, please contact me, as I am continually striving to improve the experience for all visitors.

The focus of the rest of the accessibility statement should be about empowering your visitors, illustrating how to get the most from your website and how to overcome any accessibility barriers that might be present in your content.

[Back to the contents]

Accessibility features

A lot of accessibility statements start with a section about conformance. Conformance is an important aspect of accessibility, but the chances are that conformance will be of little interest to your visitors; they can either use the website efficiently, or they can't, and that's likely to be all your visitors care about. If you feel compelled to mention all guidelines and recommendations that you follow, consider putting them in a glossary at the end of the accessibility statement to save those who are not that interested having to wade through a bulky section on conformance.

You may have gone to considerable lengths ensuring that your content is accessible, and it's quite likely that you would like to tell your visitors about the steps you've taken. It's not unusual to find the following in accessibility statements:

These may well be commendable features, but what do they mean to your visitors? Surely a visitor that gathers a list of links from a page would realise whether or not they made sense out of context without a statement to that effect? Similarly, a visitor is likely to realise whether or not tabular data is marked up correctly, and whether form controls are explicitly associated with their prompt without you stating it; particularly as they primarily benefit a particular section of your audience that may not necessarily understand the implications of the statements, but would definitely notice if those features hadn't been implemented. Whilst these steps might improve the accessibility of your content, they may not mean that much to your visitors, and will likely discourage them from reading the rest of your accessibility statement.

When you write about the accessibility features you have implemented, also provide instructions that illustrate how visitors to your website can make use of them. Rather than write a statement that the document is semantically correct, explain how your visitors can use these rich semantics to improve their experience on your website. For example, if you have used headings correctly, explain how visitors to your website can navigate using headings alone. Visitors using recent versions of screen readers can navigate using the following keystrokes:

Also, keep in mind that people with disabilities are not always using an assistive technology due to the cost. Opera has excellent keyboard navigation that is invaluable to visitors with motor difficulties. In Opera, the following keys can be used to navigate headings:

To truly empower your visitors, and to ensure they get the most out of the Web in general, it's essential that you explain how they can make use of the accessibility features that you have implemented. If you have included relative links to enhance navigation, explain how they can be used by visitors to your website. As well as being beneficial to visitors using text-only browsers, these features are also exposed to graphical browsers such as Mozilla and Opera. Explaining how visitors can adjust the font-size is far more beneficial than stating that font-sizes are specified using relative units of measurement. If you have provided a style sheet switcher, explain how to use alternate style sheets with user agents that support style sheet switching, along with your implementation of style sheet switching for user agents that support style sheets, but not style sheet switching. If you have included a longdesc attribute for complex images, explain how visitors using assistive technology can access these descriptions. If you have marked up abbreviations and acronyms correctly, explain how they might be beneficial to your visitors, along with tools that can be used to expose abbreviations and acronyms. Similarly, explain how visitors can make use of definitions if you've used them, along with all other accessibility features that you've implemented.

[Back to the contents]

Accessibility Barriers

This is the one section that is very rarely included in an accessibility statement. The primary reason is that authors are unlikely to want to admit that, despite their best efforts, some sections of the website are inaccessible. The point of this section isn't so much about admitting to your failures, but providing advice on how people can gain access to parts of the website that may otherwise be inaccessible to them. For example, if a section of the website relies on some technology that may not be accessible to all visitors, this is where you can point users to the accessible version of that content.

The most important thing is that visitors to your website can report problems they might encounter, and learn how to get the most from your website.

[Back to the contents]

Category: Accessibility.

Comments

  2. [writing-a-good-accessibility-statement.php#comment2]

    Useful article, Gez. I think this topic was in need of a bit of refreshment...

    I've seen some sites beginning to separate help with using accessibility features on the one hand, and an accessibility statement on the other, into two different pages. I think this is a fair approach, as users shouldn't be expected to wade through a load of 'We are committed to providing the best experience blah blah blah' waffle if they are just searching for a list of access keys.

    I couldn't agree more about the Accessibility Barriers section. I've only seen this on a few sites, but it has the benefit of demonstrating that you really are committed to accessibility if you admit to the problems. It's also a good place to explain any plans to improve access to problem areas in the future.

    Posted by James Newbery on

  3. [writing-a-good-accessibility-statement.php#comment3]

    I couldn't agree more about the Accessibility Barriers section. I've only seen this on a few sites, but it has the benefit of demonstrating that you really are committed to accessibility if you admit to the problems.

    I've only ever seen accessibility barriers mentioned on one website, and I agree that it gives an impression of being committed to accessibility. I can't remember where I saw it now, but it provided links to alternative content, and an explanation of why it was done this way. I remember thinking that I trusted that website far more than I would one that was plastered with badges with little thought to true accessibility.

    Posted by Gez on

  6. [writing-a-good-accessibility-statement.php#comment6]

    Hi Liddy,

    Unless I'm missing the point, which is highly likely, I don't follow how the proposed IMS/ISO/DC standard would help standardise accessibility statements. Are you suggesting creating a new DC term for accessibility statements that could be used with the AccessForAll Application Profile? I do think that adaptability statements to provide a mechanism for delivering equivalent content where required is a brilliant idea, and would negate the requirement for so much detail in accessibility statements if users were educated to create and maintain an ACCLIP. It's an area where I need to learn more, so I've joined the mailing list to get a better idea of the work you're doing.

    Posted by Gez on

  8. [writing-a-good-accessibility-statement.php#comment8]

    I'm not sure telling users how to use their own software is the best idea. If we go ahead writing guides on how to make use of accessibility features in various user agents (Opera, Firefox, IBM HPR, Window Eyes, Jaws, Interner Explorer), then we're creating an accuracy and maintenance problem for ourselves.

    Posted by Small Paul on

  10. [writing-a-good-accessibility-statement.php#comment10]

    I'm not sure telling users how to use their own software is the best idea. If we go ahead writing guides on how to make use of accessibility features in various user agents (Opera, Firefox, IBM HPR, Window Eyes, Jaws, Interner Explorer), then we're creating an accuracy and maintenance problem for ourselves.

    User-education is very important for accessibility. Not many people are aware of how they can use navigation and other features that aid accessibility. In terms of being a useful document, helping people make the most from a website is a lot more beneficial than stating the blatantly obvious. In terms of maintenance, it's a single page that wouldn't be that difficult to maintain, particularly as user-agents are starting to adhere to UAAG, and the functionality should be similar across user agents (as it is with heading navigation with screen readers).

    Posted by Gez on

  11. [writing-a-good-accessibility-statement.php#comment11]

    How would one find the Accessibility Statement on this page? (i've probably overlooked it)

    I don't have an accessibility statement. I'm not suggesting that an accessibility statement is mandatory; just that if authors provide an accessibility statement, it should be useful to their visitors.

    Posted by Gez on

  12. [writing-a-good-accessibility-statement.php#comment12]

    Do you have any examples sites with accessibility statements that follow your best practices? I am working on developing an accessibility statement and it would be helpful to see someone who does this really well.

    Posted by Justin Thorp on

  13. [writing-a-good-accessibility-statement.php#comment13]

    Hi Justin,

    I don't have an example of a good accessibility statement. If anyone knows of any that follow the format outlined here, I would gladly add them to the end of the post as examples of helpful accessibility statements.

    Posted by Gez on

  14. [writing-a-good-accessibility-statement.php#comment14]

    We're in the latter stages of a research project looking at the effectiveness of accessibility advice provided on web sites, and expect to publish our findings later this month. This has been a two stage project - an expert review of 24 online accessibility statements and user evaluations of 12 of those statements, with guidelines for best practice drawn from our findings.

    We're particularly keen to find out:

    1) how easily found is the accessibility information? (given that it's likely to be of particular use to people who hitherto would not have considered it necessary to read it until they realised they had an accessibility problem), and

    2) once there, how useful is the information provided?

    I'll post back once our report is complete; but an interesting phenomenon exhibited by many sites is the way the link to the accessibility page is presented - often in small, pale text, at the bottom of the page. This attitude to accessibility is (I suspect unwittingly) encapsulated by the Derbyshire Building Society site (GAWDS site of the month nominee recently): accessibility information appears in the 'Small Print' section of the site! - http://www.thederbyshire.co.uk/about_us/small_print/accessibility.html

    Posted by David Sloan on

  15. [writing-a-good-accessibility-statement.php#comment15]

    Hi David,

    I'll post back once our report is complete

    Yes, please do as I would be very interested in the results.

    an interesting phenomenon exhibited by many sites is the way the link to the accessibility page is presented - often in small, pale text, at the bottom of the page.

    It's certainly ironic that potentially the most important information on the website for some visitors is presented this way. I think things have improved slightly, as a couple of years ago I noticed that some companies only provided a link to the accessibility statement on the home page, or on a site map.

    This attitude to accessibility is (I suspect unwittingly) encapsulated by the Derbyshire Building Society site (GAWDS site of the month nominee recently)

    Wow, I'm shocked that someone nominated that for site of the month to an accessibility group.

    Posted by Gez on

Comments are closed for this entry.