[2] access 要素の key 属性は、 当該 access 要素に割り当てるキーを指定するものです。

[3] この属性は XHTML2 WG によって提案されていましたが、支持を集められず廃案となっています。

仕様書

意味

[5] この属性は1つ以上のキーkeyの写像mappingをアクセス・ショートカットに割り当てます。 ここで「キー」と呼ぶのは歴史的な理由であって、実際にはより抽象的なものであり、 鍵盤上のキーに限りません。鍵盤上のキーを Alt などと同時に押すことを表しても構いませんし、マウスによるジェスチャーでも音声による命令でも何でも構わないとあれています。 いずれにせよ、 access 要素の処理においてはキー入力が行われたものとして扱うことになっています。 >>1

属性型

[4] この属性の値は Characters とされています >>1。 つまり、属性値は、文書文字集合における単一の文字を1つ以上指定するものです >>1。

[14] この属性は省略可能です。省略した場合は利用者エージェントがキーを割り当てるべきであるとされています (>>13)。

[17] 複数の活性activeの要素に同じキーの値を割り当ててはなりません。 media 属性を使うと不活性inactiveにすることができます。 >>1

[18] すべての文字がアクセス・キーとして適切ではないことに注意する必要があります。 例えば声調符号付きの文字のように、鍵盤から直接入力できない文字もあります。 単体で表示されるときと他の文字と合わせて表示されるときでレンダリングが違う文字は利用者にどの文字を入力するべきか伝えるのが難しいので、注意が必要です。 鍵盤配置によっては利用できないキーもあり、やはり注意が必要です。 >>1

[23] XML Schema実装と DTD実装は Character となっていて >>1、本文と矛盾していました。

[24] XHTML2 WG ではよくあること。

処理モデル

[6] 利用者が指定されたキーを入力した時には、当該 access 要素が参照する role や id を持つ要素であって、 現在位置から見てナビゲーション順navigation orderにおいて次の要素へと焦点を移動します。 >>1 ただしナビゲーション順はホスト言語により決まる >>1 とされています。

[22] 実際にはナビゲーション順は >>1 と order 属性によって決定され、 ホスト言語に委ねられているのは移動対象として適切な要素であるかどうかの基準だけです。

[7] XML Events により代わりの事象を配送deliveryすることも可能です >>1。

[8] 意味がよくわかりませんが、キー入力をXML事象によりエミュレートできるとかそんなようなことでしょうか...

[12] ... ということが UAAG 1.0 を引用しつつ規定されています。

レンダリング

[15] キーの割当は、メニューの項目の横に表示する、ラベル中の文字に下線を引くなどの方法で視覚的なヒントとして示すことが普通です。 これは利用者エージェントに依存します。 著者はアクセス・キーの文字を適用対象のラベルに含めておくべきです。 >>1

歴史

[20] この要素ははじめ XHTML2 に追加され、後に単独の XHTMLモジュールとして出版されています。

関連

[19] この属性は accesskey 属性を拡張したものとなっています。 HTML4 の accesskey 属性はキーを1つしか指定できませんでしたが、 こちらでは複数指定できます。 (HTML5 の accesskey 属性でも複数指定できるように拡張されています。)

メモ

[21] DI 至上主義なのか鍵盤に依存しないなどと言ってはいるものの、 現実にはマウス・ジェスチャーや音声の命令なんかを1文字に写像する慣習など存在していないので、 その辺をなにも規定しないで使えますと言ったところで誰も使わなかったでしょうな。