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.

South by Southwest (SXSW) is a huge conference for interactive media as well as a film and music festival in Austin, Texas, March 7-11, 2008. Every year it attracts the best designers and developers, and there is an immense number of panels to choose from. Exactly 128, out of which 80 are chosen from an open submission process.

Gez Lemon and I plan to run a panel called “Get Rich, Remain Accessible,” naturally about WAI ARIA (Accessible Rich Internet Applications). Gez wrote a great article about ARIA liveregions, and I wrote that article at A List Apart, so it’s the perfect team. Together we would like to present:

1. The accessibility problems introduced by the current trend of web applications,
2. new ways to add semantic meaning, communicate importance, define relationships, and give focus to elements using WAI-ARIA,
3. how to limit the impact of these problems whilst WAI-ARIA is gaining support by user-agents, and techniques that work right now.

It would be nice if you took the time to vote for us at the SXSW panel picker application. The voting process is open until 11:59 pm, September 21. If you push our presentation to the top 80 you will ensure Gez and I actually make every effort to attend the conference as we will get free tickets for ourselves. Spread the word …

The W3C’s standards draft for Accessible Rich Internet Applications (ARIA) addresses those limitations. It provides new ways of communicating meaning, importance, and relationships, and it fills gaps in the (X)HTML specifications and increases usability for all users by enabling navigation models familiar from desktop applications. Best of all, you can start using ARIA right away to enhance the accessibility of your websites.

I held talks about the upcoming standards in Cologne and Frankfurt, which resulted in writing a blog entry about the topic that eventually became an article for A List Apart.

Update: there’s also a German translation of the article at Barrierekompass.

If you’d like to learn more I’ll be speaking at the BarCamp in Frankfurt on April 21-22, and the Infopark Internet Congress in Berlin on May 11th.