WebAIM - Web Accessibility In Mind

E-mail List Archives

The state of Acceskeys (was RE: Flash interaction and screenreaders)

for

From: John Foliot - WATS.ca
Date: Jul 30, 2005 8:29AM


Sinead Hogan wrote:
> Hi again,
> Yes, I was referring to access keys (sorry, i'm a newbie!)
> This brings me to wondering if its possible to make some interactions
> accessible at all to users of screen readers who can only use a
> keyboard. For example I could (hopefully!) make my menu system and
> other interactions accessible to keyboard-only users, and I could
> make them readable to screen readers. But does this issue of access
> key use by screen readers mean that it isn't possible to make some
> interactions accessible to both at once?
<snip>
> From what I understand so far though, I would have this same issue if
> I was using technologies other than Flash. Right?
> Sinead.

Oh Dear...

Well Sinead, first off, welcome to the wonderful world of web
accessibility.

Accesskeys - yep, I'm the guy who's gonna beat ya up on them <grin>. In
all seriousness, unfortunately (IMHO) accesskeys are completely broken
and should be abondonned for now. We've done a fair bit of research on
the topic, which can all be found here:

Using Accesskeys - Is it worth it?:
http://www.wats.ca/articles/accesskeys/19

More reasons why we don't use accesskeys:
http://www.wats.ca/articles/accesskeyconflicts/37

Accesskeys and Reserved Keystroke Combinations:
http://www.wats.ca/resources/accesskeysandkeystrokes/38

Link Relationships as an Alternative to Accesskeys:
http://www.wats.ca/articles/accesskeyalternatives/52

The Future of Accesskeys:
http://www.wats.ca/articles/thefutureofaccesskeys/66

... It should be noted that the last article is now somewhat dated: the
W3C has again re-thought how they want to implement this type of
fucntionality.

For those who are interested, the latest draft of XHTML 2 sees the
following
(http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule
):

@access becomes an element, as opposed to an attribute
introduction of @targetrole as an attribute

The way it appears to be going is that the <access> element is a meta
element (listed in the <head> block) which declares key access points
via the targetrole attribute:

<access key="c"
title="Table of Contents"
targetrole="toc" />

These target roles are defined either a) as part of the common
collections[1] (which is provided in the Spec), or b) defined using the
@role attribute (which references new or unique target roles via an RDF
declaration).

On the upside, we will now have a list of common targetroles - which I
see as positive as at least now there is *some* standardization [Note: I
think this "common" list is still under review as well]. Further, the
spec makes the 'key' attribute an optional attribute - it is envisioned
that given the common roles, user agents will now be able to internally
map their own keybindings. In otherwords, now each web document that
has the targetrole of "toc" (your navigational block) can have the same
"accesskey" functionality with the same key-binding every time. These
keybinding may be "hard-wired" (ie using JAWS would automatically map
ALT+X to "toc"), or user agents could allow end users to set their own
keymappings as they desired (similar to the functionality already
witnessed in Opera)

However, the drafters have still left the actual ability to key-bind to
the author, which I fealt left the door open for conflict once again. I
complained (oh boy did I complain!), and it appears (I hope!) that the
spec will re-emerge with a "cascade" mechanism which *should* offset
this problem:

1) User-defined bindings take precedence over all other
declarations.
2) User agent bindings take precedence over author declared
bindings.
3.1) Author declared bindings are exposed when no mapping is
previously declared.
3.2) User agents announce the availability of a keybinding and
allow for user mapping if desired.
(At least, this is my understanding - I have bcc'd a member of the
authoring committee who hopefully will correct me if I am mis-informed)

It was further suggested to me that the web-accessibility community
should then support a "best practices" to a) implement the common roles,
b) avoid specific keybindings. It also now puts an emphasis on the user
agents to deliver the functionality we seek using this new method.
Hopefully the browser developers will implement this faster than they
have implemented other W3C proposals (audio style sheets comes to
mind...)

So that is where it appears to lay for now. As "accesskeys" *is* my
cause celebre, I will be watching closely, and will share further news
when I get it.

Cheers!

JF
--
John Foliot <EMAIL REMOVED>
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053

[1] The current list of proposed targetroles:

main
This defines the main content of a document.
secondary
This is any unique section of the document. In the case of a portal,
this may include but not be limited to: show times; current weather; or
stocks to watch.
navigation
This is the navigation bar on a web document. This is typically a
list of links to other pages on the site or other areas of the same
document.
banner
A banner is usually defined as the advertisement at the top of a web
page. The banner content typically contains the site or company logo and
other key advertisements for the site.
contentinfo
This is information about the content on the page. For example,
footnotes, copyrights, links to privacy statements, etc. would belong
here.
note
The content is parenthetic or ancillary to the main content of the
resource.
seealso
Indicates that the element contains content that is related to the
main content of the page.
search
This is the search section of a web document. This is typically a
form used to submit search requests about the site or is a more general
Internet wide search service.