Otherwise the draft’s abstract and introduction are vague and leave room for interpretation what this is exactly about. What I have understood is:

1. This module defines a new element with the name access.
2. The element can be used to define an access key for any other element.
3. Another usage could be as a skip link as there is a targetid and targetrole attribute.

For me it remained unclear whether this element belongs in the head like link elements, or in the body like anchors or label elements. Anyway, among other Common attributes it can have a title plus a few new attributes: key, targetid, targetrole, and activate.

• The key attribute is optional and defines an access key in a generic way. So far there was only the accesskey attribute for anchors and form elements, now any fancy Web 2.0 div element impersonating something else can receive focus by striking a key. Browser vendors are encouraged to emphasize the responsive character in a word, like underlining it. Also the working draft provides a description what user agents should do if there are conflicts with existing shortcut keys. So the team paid attention to the discussions about the reasonableness of the accesskey attribute.
• The targetid and targetrole attributes assign targets by id or role. There can be more than one of each, comma separated. I imagine that’s like tabbing through elements, but with a shortcut key.
• The last new access attribute is activate. I must admit I have no clear idea what “activate” could mean or what this attribute is good for. An element receives focus, so there should be a perceivable effect, some sort of feedback to the user. If an author does not want this, there are ways to suppress default renderings by CSS. If she doesn’t want the focus event to trigger something, there’s JavaScript to cancel it.

I thought of playing with the new element, but it’s too early for a test implementation. The working draft still lacks a XML Schema that could be used in namespaces. It would be possible to extend a DTD without much conflicts, alas the module doesn’t come in one box, but in two (again). So you would need to append both the qname module and the access module instead of simply adding the access module. I don’t understand the rationale for this separation, but I see it’s more painful for an author to implement it that way.

However, the access element provides a better and more generic functionality than existing alternatives, it fills the gap of missing access keys, and if I got it right it defines a standardized method for skip links, although this could be expressed clearer. Apart from the usual suspects there is Google’s accessibility specialist T. V. Raman on the team, and Richard Schwerdtfeger from the team that built more accessibility into Firefox, the Open Document Format, and IAccessible2 as an accessibility interface for screen readers. So my bet is we will see support for this element in our favorite browser as soon as this draft is more mature. Your turn, Microsoft.