[2] access 要素の key 属性は、
当該 access 要素に割り当てるキーを指定するものです。
[3] この属性は XHTML2 WG によって提案されていましたが、支持を集められず廃案となっています。
[5] この属性は1つ以上のキーの写像をアクセス・ショートカットに割り当てます。
ここで「キー」と呼ぶのは歴史的な理由であって、実際にはより抽象的なものであり、
鍵盤上のキーに限りません。鍵盤上のキーを Alt
などと同時に押すことを表しても構いませんし、マウスによるジェスチャーでも音声による命令でも何でも構わないとあれています。
いずれにせよ、 access 要素の処理においてはキー入力が行われたものとして扱うことになっています。
>>1
[4] この属性の値は Characters とされています >>1。 つまり、属性値は、文書文字集合における単一の文字を1つ以上指定するものです >>1。
[14] この属性は省略可能です。省略した場合は利用者エージェントがキーを割り当てるべきであるとされています (>>13)。
[17] 複数の活性の要素に同じキーの値を割り当ててはなりません。
media 属性を使うと不活性にすることができます。
>>1
[18] すべての文字がアクセス・キーとして適切ではないことに注意する必要があります。 例えば声調符号付きの文字のように、鍵盤から直接入力できない文字もあります。 単体で表示されるときと他の文字と合わせて表示されるときでレンダリングが違う文字は利用者にどの文字を入力するべきか伝えるのが難しいので、注意が必要です。 鍵盤配置によっては利用できないキーもあり、やはり注意が必要です。 >>1
[23] XML Schema実装と DTD実装は Character となっていて >>1、本文と矛盾していました。
[6] 利用者が指定されたキーを入力した時には、当該 access
要素が参照する role や id を持つ要素であって、
現在位置から見てナビゲーション順において次の要素へと焦点を移動します。
>>1
ただしナビゲーション順はホスト言語により決まる >>1 とされています。
[7] XML Events により代わりの事象を配送することも可能です >>1。
role や id との関係は、著者による提案として扱うべきです。利用者エージェントは (OS や UA の UI と干渉する、キーが利用できないなどの理由で) 割当を上書きしても構いません。 >>1key 属性が指定されていない場合は、利用者エージェントがキーを割当、利用者に提示するべきです。この利用者エージェントによる割当はセッションを超えて保持するべきです。 >>1[15] キーの割当は、メニューの項目の横に表示する、ラベル中の文字に下線を引くなどの方法で視覚的なヒントとして示すことが普通です。 これは利用者エージェントに依存します。 著者はアクセス・キーの文字を適用対象のラベルに含めておくべきです。 >>1
[20] この要素ははじめ XHTML2 に追加され、後に単独の XHTMLモジュールとして出版されています。
[19] この属性は accesskey 属性を拡張したものとなっています。
HTML4 の accesskey 属性はキーを1つしか指定できませんでしたが、
こちらでは複数指定できます。 (HTML5 の accesskey
属性でも複数指定できるように拡張されています。)
[21] DI 至上主義なのか鍵盤に依存しないなどと言ってはいるものの、 現実にはマウス・ジェスチャーや音声の命令なんかを1文字に写像する慣習など存在していないので、 その辺をなにも規定しないで使えますと言ったところで誰も使わなかったでしょうな。