Saturday 20 July 2002

Accessibility tip 25: Create an accessibility statement

It’s Day 30 of 30 days to a more accessible weblog and time to explain to others what we’ve done. Mark Pilgrim suggests that:

If you’ve implemented any of the tips in this series, create an accessibility statement that lists the accessibility features of your site.

I’ve implemented all the tips in the series so I was relieved that he also said:

Feel free to use the accessibility statement for as a template, including structure, wording, and links to further reading.

And that’s exactly what I’ve done. Interestingly, having comments enabled prevents my pages from being Bobby-approved. A new window opens without warning when a visitor clicks on a Comments link on either the index and monthly archive pages (although the comments are inline with the rest of the page content on the individual archive pages). Bobby also reports the following errors (caused by the onClick event handler associated with the Comments link and the fact that there are multiple Comments links on the index and monthly archive pages):

This page does not meet the requirements for Bobby AA Approved status. Below is a list of 2 Priority 2 accessibility error(s) found:

Make sure event handlers do not require use of a mouse. (12 instances)
Lines 48, 70, 88, 98, 173, 192, 210, 256, 268, 277, 289, 310

Do not use the same link phrase more than once when the links point to different URLs. (8 instances)
Lines 88, 173, 192, 268, 277, 310, 448, 450

I could probably do something tricky to change the Comments link to Comments on <$MTEntryTitle$> but that would still leave the onClick event handler problem so I guess I’ll live with my Bobby-unapproved status.

Finally, thanks to Mark Pilgrim for providing a wonderful 30-day learning experience. I’ve learned an enormous amount.

Permalink | Technorati


1. Comments link: incorporating the title is your best bet.

2. onclick problem: provide redundant attributes for different input types. See . "if you must use device-dependent attributes, provide redundant input mechanisms. In other words, specify two handlers for the same element. Use "onmousedown" with "onkeydown". Use "onmouseup" with "onkeyup". Use "onclick" with "onkeypress"."

3. Nice accessibility statement.

Posted by Mark Pilgrim on 20 July 2002 (Comment Permalink)

Someone at the public evangelist forum posted a link top a page that may be interesting to read,

"Access Key Visualization With CSS"

What bothers me however, is that these methods as described heavily rely on CSS-2 compliance (which is, as we all know, not widely supported). Forms of accessibility should be a key feature of a site and not be strung up on a specific (optionally supported) technology. It is like making this Comments popup possible only if you have JS enabled.

Just some server side code:

My Page(Keyboard Shortcut: 2)"; ?>

A nice side-effect of using numbers for you accesskey values: MIE5.1/Mac focusses on links as you type them. Since it is unlikely that there are links in the page that start with a number, MIE5.1 users will have instant focus on key links by use of their keyboard. Ofcourse, the CTRL- combi works too (MIE5/Mac that is).

Oh, and the forum is at

For the onClick JS event.. An onActivate event would be the thing here, wouldn't it? Heh, I think we cannot count on ever seeing that one.

Have you tested your page by using keyboard navigation on the Comment links? My MIE5.1 follows the link as if JS does not exist (and yeah, I switched it on for this purpose). So here you have another argument for using the 'return false;' construct. Too bad Bobby doesn't understand it.

However, I think you should drop the entire popup thing altogether anyway. What annoyes me most about it, is that after having Comments popped up, any new windows I open will have the dimensions of the popup.

I think, if following the Comments link inside the same window as the site creates confusion, you should fix it by creating a clearer navigation.

Like, having the post repeated in the Comments page to start with, then at the bottom of the page, a list of links to the front page (grants overview of all recent posts and their amount of comments) and older posts (grants direct access to the posts themselves). Or, you could make use of a "Previous/Next" kinda setup, showing the title and date of the post ofcourse.

I think Mark's 30-days series should be included in a calendar for web designers, or something.

Posted by Kris on 20 July 2002 (Comment Permalink)


Don't remove my code examples :-P

if(strpos($ua,"Mozilla") $acflag = false
else $acflag = true;
<a href="page.html" accesskey="2" title="description">My Page</a><?php if($acflag) echo " <span style="background: transparent; color: #090;">(Keyboard Shortcut: <kbd>2</kbd>)</span>"; ?>

Posted by Kris on 20 July 2002 (Comment Permalink)

Oh, and please don't mind the Parse Errors.


<?php if($acflag) echo " <span style=\"background: transparent; color: #090;\">(Keyboard Shortcut: <kbd>2</kbd>)</span>"; ?>

Posted by Kris on 20 July 2002 (Comment Permalink)

Hmm, maybe posting that code snippet somewhere else and pointing to it would be a better solution. I'm interested in various ways to accomplish this server-side. I'm considering secretly routing everything through some Python-based post-processing (to clean up Q markup to be IE-compatible, among other things); I could add this as well, or at least have it as an option.

I think that linked example is unnecessarily complicated to do it client-side. At least for links:

a[accesskey]:after {
content: " [" attr(accesskey) "]";

The actually simulates the default behavior of iCab, the only visual browser I know to visualize accesskeys.

The solution for INPUT boxes really needs to come at the browser level, so you can define the accesskey on the LABEL but see the visual representation next to the INPUT box. Can't possibly do that with CSS, and it's non-trivial to do server-side. Ideally it would simply be a checkbox in the browser preferences: "Show keyboard shortcuts" or something.

It's a difficult issue.

I was discussing this in email with someone, about ways that individual users can use their own tools better. User-defined stylesheets are going to end up being a big part of that, I think. Even if the users don't do it themselves, a checkbox in the preferences can activate a particular built-in CSS change. Internalize the CSS, in other words. Enterprising young minds can come up with examples, and then later, browser makers can internalize them.

Posted by Mark Pilgrim on 21 July 2002 (Comment Permalink)

I've searched the net far and wide, and the W3 site as well, and can't seem to find a complete reference for the available accesskey attribute values.

Now that web developers have AOL, IE4, IE5, IE5.5, NS4x, NS6x, NS7x, Opera, Safari, Mozilla, and even more browsers, it seems there needs to be a list of the available accesskey values that remain, after subtracting all of the built-in keyboard commands already taken by the various browsers.

The problem is best stated in this way:

The total maximum number of possible accesskey attribute values (47?) is, in practice, a smaller subset of {abcdefghijklmnopqrstuvwxyz0123456789-=`[]\;',./} based on the following:

- Internet Explorer has reserved:
---- Alt-f : File Menu
---- Alt-e : Edit Menu
---- Alt-v : View Menu
---- Alt-a : Favorites Menu
---- Alt-t : Tools Menu
---- Alt-h : Help Menu
---- Alt-d : Address Field

- Netscape Communicator 7 has reserved:
---- Alt-f : File Menu
---- Alt-e : Edit Menu
---- Alt-v : View Menu
---- Alt-g : Go
---- Alt-b : Bookmarks
---- Alt-t : Tools
---- Alt-h : Help
---- Alt-w : Window

- Opera 7 has reserved:
---- Alt-f : File Menu
---- Alt-e : Edit Menu
---- Alt-v : View menu
---- Alt-n : Navigate menu
---- Alt-b : Bookmark
---- Alt-m : mail
---- Alt-w : Window
---- Alt-H : Help

Thus, the remaining keys left for use as a value to the accesskey attribute for links on accessible web pages are:


35 available access key attribute values.

This does not include AOL browser (IE variant?) or Safari on Macintosh OSX, which may reduce this set even further.

This also brings up the question, how do you encode a page properly to support WAI standard(s), which has more than 35 links on a page? In otherwords, are accessible pages limited to 35 links per page? It can't be.

Posted by Geoff on 15 April 2003 (Comment Permalink)

This discussion is now closed. My thanks to everyone who contributed.

© Copyright 2007 Jonathon Delacour