WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Underlined text on button


From: Jukka Korpela
Date: Mar 27, 2002 12:57AM

Emma Jane Hogbin wrote:

> If users are "in the know" about access keys will they look
> for them on a site?

Good question. And how would they look for them? The original idea seems to
have been that a browser supporting access keys would automatically indicate
the access keys. For example, a user could give some command to get a list
of access keys, or a browser could show them in some special area in a

It has been proposed that access key 0 (zero) be assigned by authors to
correspond to a link to an explanation of access key assignments. This is
probably the closest we can get to the original idea with current browsers.

> The url posted here seems to suggest that screen
> readers/aural browsers ignore the access key attribute.
> Anyone know for sure?

I'm afraid I don't understand the question. Support to accesskey attributes
is basically a matter of recognizing certain HTML markup and providing some
method for using certain keyboard keys as shortcuts, corresponding to the
access key assignments. When screen readers or aural browsers are used, the
input method is usually a keyboard. So whether access keys are supported
depend on the browser, not on the methods it uses to present the document.
Presentation matters as regards to telling the user what the access key
assignments are.

For example, if a graphic browser that supports accesskey (e.g., IE 6) is
used together with screen reader software, then naturally the access keys
work the same way as in visual mode, i.e., not very well, but occasionally
in a useful way. But the user needs to have the assignments explained in
normal language. Underlining would not help a blind user, unless the screan
reader can actually explain say what letters are underlined. And putting
e.g. "(Alt-W)" after a form field, as often suggested and used, wouldn't
really help much either - if one hears that after getting into the field
somehow, filling it out, and proceeding. Besides, "(Alt-W)" could really
confuse an unexperienced user, especially if Alt-W does not work for him or
actually causes something completely different than focusing on a field.

Thus, the conclusion is that plain English explanations about access key
assignments are needed. ("English" is to be taken as a generic term for
natural language, of course.) This raises some practical questions. Suppose
first that you put the explanations onto a separate page. One would, in
practice, due to the way browsers support accesskey, need to put an explicit
link to a page with accesskey assignment explanations onto each and every
page that has some access key assignments. Naturally that link would then
have accesskey="0". But on IE, Alt-0 would take the user to that link only,
and then Enter is needed to follow the link. And the author would need a
separate explanation page for each page, if there is _anything_
page-specific in the assignments.

Alternatively, the explanations could appear on a page itself. Somewhere at
the bottom probably. The problem is how make access key 0 take the user
there. This might require trickery:

<div class="noprint">
<hr title="Access key assignments">
<div><a id="accesskeys" accesskey="0" href="#accesskeys">Access
<ul class="compact">
<li>0 = get this list
<li>1 = <a href="index.html" accesskey="1">main page of the site</a>
<li>4 = <a href="search.html" accesskey="1">search the site</a>

I'm not sure whether it's worth the trouble. We would use quite some special
methods as a workaround to compensate for deficiencies in browsers. When
browsers _really_ start supporting access keys, we would look a bit foolish,
with lots of pages with extra stuff like the above. But if access keys are
very important on some pages, due to their specific content and use, then
perhaps it _is_ worth the trouble.

Jukka Korpela
TIEKE Tietoyhteiskunnan kehitt