LeeDumond.com

In case you haven't noticed, accessibility is a big deal on the 'net these days. More and more, designers and developers are realizing that facilitating access to the web by everyone regardless of disability is an effort worth undertaking, and that, as Martha would say, is a good thing.

Most of the time, those companies who feel they've stepped up to the plate in this regard will include a so-called "Accessibility Statement" somewhere in the deepest, darkest recesses of the site (where someone with a disability is least likely to find it, of course). All too often, this statement consists of nothing more than a short blurb about how "we're committed to making our site accessible to everyone blah blah blah", maybe a sentence or two about Section 508 compliance, and that's it.

What a total waste of time and bits.

You should realize that anyone who is taking the time and effort to seek out and read your accessibility statement is most likely a person with some kind of disability themselves, so the usual self-congratulatory fluff isn't of much help to them. A proper accessibility statement should go well beyond stating the obvious and explain, in detail, the specific accessibility features you've implemented, along with instructions on how to use them. After all, that's what anyone who's bothering to read your accessibility statement really needs to know.

What follows is a sort of guideline I've developed over time that I use in crafting an accessibility statement for sites I work on. Like anything web-related, it's a work in progress, as I always seek out ways to improve it. If you can think of anything I've missed or have ideas of your own, please feel free to leave a comment below.

1. Explain your commitment to accessibility. Briefly state your efforts to ensure accessibility, and why you consider it important. Just a sentence or two will suffice here. This is also a good place to solicit feedback, questions, or suggestions for improvement. Include a link to your contact page.

2. List the actual accessibility features you've implemented, and explain how to use them. Let users using text-only browsers, screen readers, or those who have difficulty with pointing devices, distinguishing colors, low vision, etc. know what to expect, how the application should behave, and how to access or adjust features or settings as applicable to improve their experience. What follows is by no means an exhaustive list, but it touches on the things such users might find most helpful.

•  Access Keys -- Many browsers support jumping to specific links by typing keys defined in the web page. In most Windows browsers, you can press Alt + an access key. In Internet Explorer, you may need to press Enter afterward. In later versions of Firefox, you may need to use Alt + Shift + an access key. In most Macintosh browsers, you can press Control + an access key.
  
  It's conventional practice to make Access Key 1 map to your home page link, and to make Access Key 0 map to your accessibility statement link. Beyond that, access keys should link to things that are helpful in getting around or obtaining help, like your site map link, search box, contact link, or general help link.
   
• Tab Indexes -- Many browsers support navigating through a web page by using the Tab key. As the Tab key is repeatedly pressed, links are highlighted in a specific order defined in the Web page. Pressing Shift + Tab will navigate through the indexed links in reverse order.
  
  By default, the Tab key will cycle through the links on a page in the order in which they're defined in the markup. However, you can (and should) override this behavior by using tab indexing to force a more logical tab order if necessary. Again, it's conventional to make the home page link first in the tab order. From there, you could cycle through the other "header" links, then through each link in your top-level main navigation, and so on. Let common sense be your guide here.
  
  It's a good idea to establish tab indexes for forms as well, so that pressing the Tab key allows users to navigate through all the fields in a logical order.
   
• Drop Down Menu Navigation -- As pointed out above, using tab indexing to allow cycling through your top level navigation is a great idea, but a carefully thought-out drop down menu will go one step further by implementing arrow key support for accessing lower-level navigation links. Include a brief explanation of how to open, close, and navigate submenus using the arrow keys.
   
• Other Navigation Aids -- If you provide "jump to content" or "skip navigation" links, a breadcrumb trail, site map, search, or anything else that might help a user find their way, be sure to point that out.
   
• Headings and Semantics -- If you're properly using headings to structure your document (as you always do, right?), be sure to mention that, as most modern screen readers can navigate headings using keystrokes, such as H to cycle forwards through the headings, Shift + H to cycle backwards through the headings, INSERT + F6 to provide a list of all headings, and so on. Other browsers or assistive technologies may provide different or additional functionality based on headings that appear in the page. For example, current versions of Opera have excellent keyboard navigation that is invaluable to visitors with motor difficulties.
   
• Text Size and Type Contrast -- Difficulty reading small text is by far the most common accessibility complaint among web users. This is closely followed by poor choices of colors, background images, or fonts that otherwise make text difficult to read. All modern browsers allow the user to quickly adjust text size; but there are other things you can do as well, such as supplying alternate style sheets, or using themes in ASP.NET, to provide user-selectable "large font" or "high-contrast" layouts. Just be sure to mention whatever remedies you've made available for those may find your site a bit hard on the ol' eyes.
   
• Links -- Many assistive devices won't be able to distinguish the difference between a "true" hyperlink and a link used as a script trigger. If the core functionality of your site includes the use of JavaScript-dependent "pseudo-links", such that the link is inoperable with JavaScript turned off, you should point this out. To mitigate this issue, consider using regular buttons instead of "fake links" to initiate postbacks where possible. And while we're on the subject...
   
• JavaScript and CSS -- Of course, almost every modern site uses JavaScript and CSS, but certain assistive devices will either ignore these features altogether, or interpret them in a way you might not expect. If any part of your site's core functionality absolutely depends on JavaScript or CSS being enabled, you should mention this here, so affected users will be aware of it and can adjust accordingly. If you've "gone the extra mile" and provided non-script dependent alternatives, definitely mention that too, as well as how to access those alternatives.
   
• Browser/Device Compatibility -- List here the browsers and other devices on which you've tested your accessibility features, and mention any known browser-related limitations that may hamper accessibility.
  

3. Explain your commitment to standards. An important part of maintaining accessibility on the Web is an adherence to standards -- accessibility-specific standards, as well as general Web standards. Here, you should mention specifically describe your efforts to comply with the following standards at a minimum:

• Web Content Accessibility Guidelines -- Mention which Priority level (1, 2, or 3) the site complies with. List any site sections or pages which aren't WCAG compliant, and exactly how and why they deviate from the standard.
   
• Section 508 -- Describe your efforts to achieve 508 compliance. If your site, or certain sections or pages of your site, aren't 508 compliant, list them and explain how and why.
   
• W3C Doctype -- Mention the DTD you've targeted in your pages, and list which sections or pages don't properly validate under that standard and why.

For an example of a completed accessibility statement which generally follows the above guideline, check out this one at the Key Laboratory Services site.

Subscribe to this blog for more cool content like this!

Bookmark / Share