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.

You won’t believe how much myth and misinformation is out there. Some say it’s deprecated. In fact it never was. It is part of XHTML 2 and XHTML Basic, and there is a target module in XHTML 1.1, the modularized version of XHTML. The attribute is not included in HTML 4.01 Strict and XHTML 1.0 Strict because it was then considered to be related to frames and iframes, but it’s not marked “deprecated.” It was simply not in the core set of modules for the XHTML 1.1 driver.

Some people argued it’s a behavior and thus belongs into unobtrusive JavaScript. But then clicking on a link to get to another page is also some functionality, and nobody would think of replacing anchors with loads of bloated script to simulate such a basic behavior.

So I ended up extending the extensible with a customized DTD:

1. <?xml version="1.0" encoding="iso-8859-1"?>
2. <!-- Bring in the XHTML 1.1 driver -->
3. <!ENTITY % xhtml11.dtd
4. PUBLIC "-//W3C//DTD XHTML 1.1//EN"
5. "http://www.w3.org/TR/xhtml11/ DTD/xhtml11.dtd">
6. %xhtml11.dtd;
7.  
8. <!-- Bring in the Target Module -->
9. <!ENTITY % xhtml-target.mod
10. PUBLIC "-//W3C//ELEMENTS XHTML Target 1.0//EN"
11. "http://www.w3.org/TR/ xhtml-modularization/DTD/ xhtml-target-1.mod">
12. %xhtml-target.mod;

However, now I have to bid farewell to that bizarre old friend: the working draft of XHTML 1.1 Second Edition includes the target module in the core set, finally. I’m relieved because tinkering with DTDs is a pain, but it had style …

Note that in the current version target is not yet included in XHTML 1.1 Schema, but I have been assured it will definitely be in the final version.