[7] accesskey 属性は、
要素にキー操作を割り当てるものです。
いまいち使い勝手が悪く、あまり活用されていないようです。
[59] accesskey 属性の値は、
利用者エージェントが当該要素の活性化や焦点を当てるためのキーボードショートカットを作成するための指針として使うものです >>8。
[36] accesskey 属性を使うと、
活性化したり焦点を当てたりできる要素に、
活性化のために打鍵するべき組み合わせ (キーボードショートカット) を設定できます >>9。
[60] 属性値は、 ordered set of unique space-separated tokens でなければなりません >>8。 属性値には、色々な入力装置でキーボードショートカットが利用可能となるよう、 いくつも候補を指定できます >>8。
[39] 各候補は、文字1つです >>8。属性値として指定された集合の各要素はUnicode符号位置1つでなければなりません >>8。
[11] 文字を入力するものでない鍵や複数の鍵の組合せを指定することはできません。
[13] この属性は必須ではありません。省略した場合、特にキーボードショートカットの指定はないものと解釈されます。
[67] 要素の assigned access key は、
要素の accesskey 内容属性から求めたキーの組み合わせです
>>8。
[68] 初期状態では要素は assigned access key を持ってはなりません >>8。
[69] 要素の accesskey 内容属性が設定、変更、
削除された時に次の処理を行わなければなりません >>8。accesskey 内容属性があれば、
[79] accesskey 内容属性が変更された時や要素が他の文書に移動された時を除き、
assigned access key を変更するべきではありません >>8。
accesskey
属性を持っていれば、他の要素がそのキーボードショートカットを使えない可能性があることになります。[91] 同じ accesskey の要素が複数あるとき、
どれが選ばれるべきか HTML Standard は規定していません。
利用者エージェントが場面に応じて適切に判断するべきなのだと思われます。
ただ一般に DOM への挿入順 (構文解析の場合は文書順)
で >>69 の処理が実行されるはずですから、自然な実装は DOM
への挿入順が早いものが優先されると思われます。
[42] 本処理は、 fingerprinting vector です >>8。
[80] 利用者が assigned access key に当たるキーの組み合わせを押下したら、
次のようにしなければなりません >>8。
[96] 通常は、活性の閲覧文脈についてこの処理が行われます。 活性でなければ実行されません。
sandbox
iframe が親閲覧文脈のキーボードショートカットを上書きできてしまうと不都合です。[40] 利用者エージェントはキーボードショートカットの一覧を利用者に提供できます >>8。
[26] この属性は、元々連結やフォームの制御子などへの鍵盤など (鼠以外) へのアクセス可能性や可用性を向上させることを目的に採り入れられました。 しかし、これまでに様々な問題があることが分かっており、 使い方によってはかえってアクセス可能性や可用性を低下させることになり兼ねません。
[27] 実装と鍵盤の種類による差異: HTML 利用者エージェントは様々な実装がありますし、 それを使用する環境も様々です。また、その環境で使用する鍵盤 (や同様の装置) も実に様々です。
この様々な環境の従来の慣習や実現上の制限のため、 HTML
の仕様上は accesskey
属性値を実際にどういう打鍵の組合せに対応させるかを定めていません。
accesskey が 1 であれば、
1 という鍵を押せば良いだけの実装もありますし、
Ctrl と一緒に押す実装もあります。あるいは
Alt と一緒に押させる実装もあります。
同じ 1 でも、鍵盤本体と数字鍵盤で2つ鍵があって、
どちらかしか使えないという実装も、両方使えるという実装もあり得ます。
利用者が特定の実装にだけ慣れていれば問題ありませんが、
複数の実装を使っていると混乱の元です。
著者としても、 accesskey
があることとその使い方を説明しようにも、
考えられる方法を列挙するか特定の利用者エージェントに限って解説するかしかありません。
鍵盤の鍵の種類は鍵盤の種類によって様々です。
ある鍵盤に存在している鍵が他の鍵盤に存在するとは限りません。
また、打鍵のしやすさも鍵盤の配置によって変わりますから、
なんとも言えません。可用性を追求すると HTML
の装置非依存性が犠牲になります。 accesskey
に限ったことではありませんが、 accesskey
属性では特に重大な問題といえます。
[28] 操作の統一:
accesskey によってなされる操作はできるだけ文書を超えて統一されていることが望ましいと考えられます。
例えば、連続する文書群の次の文書へのリンクがある文書では
N で、別の文書では X
では利用者は不便で仕方がありません。
(この例の場合は link 要素で文書の関係を記述し、
利用者エージェントの機能で、またはスタイル・シートで統一した
accesskey を与えるのが正しい解でしょう。)
統一するべきなのは文書間だけではなく、使用している利用者エージェントやオペレーティング・システムなどの環境自体ともです。 しかし、これを文書の側で実現するのは困難です。 環境の鍵盤操作の方法は多種多様であります。特定の環境に合わせると、 別の環境での可用性が低下することもあり得ます。
[29] 存在の明示:
accesskey 属性が指定されていても、
それだけでは利用者はそのことを知り得ません。
何らかの方法で利用者に accesskey
が設定されており、それがどの鍵であるのかを伝える必要があります。
>>27 な以上、これは利用者エージェントの役目のはずですが、
これを上手く実現している利用者エージェントはあまりありません。
(携帯電話の Webブラウザではリンクの前に
accesskey に応じた鍵の絵が表示されるものもあります。)
著者の側で文書の一部として記述していることもありますが、
文章に上手く溶け込ませるのが難しかったり、言語によっては不可能だったりもします。
[66] 00年代には、本属性はアクセス可能性のために重要な機能であると盛んに宣伝されました。 それに踊らされた人達の中には、とにかくページ内のリンクやフォーム制御子に accesskey 属性を設定してまわることが好ましいとして実践する人もいました。 しかし、無闇矢鱈に特定のページでしか使えないキーボードショートカットが沢山用意されても、 ほとんど意味が無いのは自明なことです。
HTMLElement インターフェイス accessKey 属性[95] HTMLElement インターフェイスの
accessKey IDL属性は、
accesskey 内容属性を DOMString
として反映しなければなりません >>8。
accessKeyLabel IDL 属性[94] HTMLElement インターフェイスの
accessKeyLabel IDL属性は、
文脈オブジェクトの assigned access key を表す DOMString
を返さなければなりません。無いときは、空文字列を返さなければなりません。
>>8
[41] 著者はキーボードショートカットの一覧を利用者に提供することを推奨されています >>8。
利用者エージェントが実際に割り当てたキーボードショートカットは
accessKeyLabel IDL属性により取得できます。 >>8
[31] accesskey は、
(accessibility key character
(アクセス可能性鍵文字
)
の意と思われます。
[47] accesskey 属性を定義していた HTML 仕様書:
[9] HTML4 + WF2 では、
a, area,
button, input, label,
legend, textarea,
selectaccesskey 内容属性が使えることになっていました。
[10] この属性の値は %Character です。
SGML 的には CDATA です。
アクセス鍵は文書文字集合から何か1文字です。
大文字・小文字の区別に対しては中立です。 HTML 4 17.11.2
[61] 大文字・小文字の区別に中立
というのも意味不明気味なのですが、
仕様書の記号の説明によれば、文書文字集合からの一文字
は
大文字・小文字変換の対象ではない
という意味なのだそうです。
多くのシステムはアクセス鍵の大文字・小文字を区別しませんが、
そのようなシステムと整合的な実装が適当なのか不適当なのか実装依存なのか、
もう少し説明が欲しいところです。
[12] 著者は、読者がアクセス鍵を指定する際の入力方法を考慮するべきです。 HTML 4 この注意は、 例えば多くの日本語環境で漢字をアクセス鍵としても実質的に意味を成さないようなことを指摘しているのでしょう。 また、歴史的に日本語用計算機・ソフトウェアでは仮名鍵盤によるアクセス鍵を使ったものもありましたが、 accesskey="イ" のように指定したところで相互運用上の問題が発生することでしょう。
なお、 accesskey 値は文書文字集合、すなわち UCS
の1文字と定義されていますが、必ずしも UCS の文字
と日常的、
あるいは1打鍵という意味での文字
とは一致しません。
具体的には、結合文字などで望む1文字
が1文字
で指定できない虞があります。
これも >>11 とあわせて仕様の限界でしょう。
(といっても、実際にアクセス鍵として使われた実績がある文字ではおそらく問題はないと思われます。)
[33]
accesskey 属性は、
Web Forms 2.0 で select
要素にも追加され、
利用者エージェントは対応して構いません、
最低でも相当する DOM属性は (DOM を実装していれば)
実装しなければなりません、と規定されました
WF2 2.5。
それ以前はなぜか select
要素には定義されていませんでした。
[34]
また、 Web Forms 2.0 は HTML 4
で明記されていなかった、 label
要素における動作についても規定しています (>>32)。
[18] アクセス鍵の呼出しはシステムに依存します。 例えば、 Windows では、通常アクセス鍵と一緒に Alt 鍵を押します。 Apple のシステムでは、通常アクセス鍵と一緒に Cmd 鍵を押します。 HTML 4 17.11.2
携帯電話のブラウザでは、アクセス鍵だけを押す実装が普通です。
[19] アクセス鍵のレンダリングは UA 依存です。 著者はアクセス鍵を名札文に含めることが推奨されています。 UA はアクセス鍵の値を、その役割を強調しつつ他の文字と区別するような方法 (例: 下線) でレンダリングするべきです。 HTML 4 17.11.2
Windows では例えば File でアクセス鍵が F なら File の F だけ下線を引くという界面が標準的です。 仕様書はそのようにレンダリングするのがよろしいと言っているのでしょう。
もっとも、この方法は名札にアクセス鍵文字が含まれていないときには問題が起こります。 特に、ラテン文字を使わない時には大問題で、日本語版 Windows ではファイル (F) のようなみっともない表記が採用されています。
このように、 HTML 文書のレンダリングに限った問題ではありませんが、 アクセス鍵を分かりやすく、見栄え良く伝える方法は整備されていません。
[20] アクセス鍵を打鍵した時の挙動は、 UA によって異なることがあります。詳しくは焦点の説明をご覧ください。
[32]
accesskey 属性が
label 要素に対して与えられた場合、
その label が関連付けられている要素に直接
accesskey を与えた場合と同じように動作しなければなりません。
WF2 2.5
[14] 要素に割当てられたアクセス鍵を押すと、焦点がその要素に与えられます。
要素に焦点が移った時の動作は要素に依存します。
例えば、利用者が a 要素によって定義されるリンクを活性化したら、
通常はリンクをたどります。利用者がラジオ・ボタンを活性化したら、
利用者エージェントはラジオ・ボタンの値を変更します。
利用者が文章入力欄を活性化したら、入力を認めます。 HTML 4 17.11.2
[49] XHTML2 の最初の作業原案で、ハイパーテキスト属性集成に属し、 実質すべての XHTML2 要素で利用できるものとして規定されるようになりました >>63。
[50] ハイパーテキスト属性集成に属しているのは、元々 HTML4 で a
要素に accesskey 属性が定義されており、その
href 属性がすべての要素に拡張されたためと思われます。
[51] 第6次案で accesskey 属性は削除され、代わりに QName
によって役割を指定する access 属性が追加されています。
[62] その後 access 属性は削除され、かわりに
access 要素が追加されました。更にこの要素は単独の仕様書として出版されました。
[64] しかしこのいずれも (そして XHTML2 も) 実装されることはありませんでした。 Webブラウザー開発者からも著者からも、ほとんど無視されていました。
[48] HTML5 への追加は実用上の問題 (環境によって利用可能な文字が異なること、
利用者が accesskey を発見する方法がないことなど) から先送りされ続けてきましたが、
2009年春の r3065 で追加されました。この時から accesskey
内容属性は大域属性となり、 accessKey DOM属性は
HTMLElement 界面の属性となりました。属性値は
HTML4 時代の「1文字」から「1文字」の「間隔分離唯一字句順序集合」に改められました。
更に、 accessKeyLabel DOM属性が追加されました。
[16] input 制御子にアクセス鍵を割当てる例
HTML 4 17.11.2
<FORM action="..." method="post"> <P> <LABEL for="fuser" accesskey="U"> User Name </LABEL> <INPUT type="text" name="user" id="fuser"> </P> </FORM>
アクセス鍵 U を打鍵すると、名札に関連付けられた入力欄に焦点が移ります。
HTML 4 17.11.2
[17] リンクにアクセス鍵を割当てる例 HTML 4 17.11.2
<P><A accesskey="C"
rel="contents"
href="http://someplace.com/specification/contents.html">
Table of Contents</A>打鍵すると目次に飛びます HTML 4 17.11.2。
accesskey の要素が複数あって、そのうちのどれかが form control のときで、かつ現在その含まれる form 内の control が活性なら、その form 内の accesskey 要素が反応してくれると嬉しいと思いません? たとえば、一頁内に複数の form があって、どれも「提出」ボタンが M-S で効いてくれると気持ちがいい。[15] どうして fieldset ではなくて
legend に accesskey 属性があるのでしょうね?
みんな、accesskeyってどうしてる? tabindexは? http://pc.2ch.net/hp/kako/1006/10062/1006224399.html (名無しさん)
[22] フォームとアクセシビリティ -- ごく簡単なHTMLの説明 http://www.kanzaki.com/docs/html/htminfo33.html#kbd_navi (名無しさん)
[23] accesskey=key - アクセスキー http://tohoho.wakusei.ne.jp/html/attr/accesskey.htm
ラベルを使う時はラベルに accesskey を指定するのが作法
だとしていますが、根拠が不明です。
(名無しさん)
[24]
ラベルを持つ入力コントロールの場合は、<label> で指定したラベルに accesskey を指定するのが作法のようです。
と書いてあります。
>>19 の規定を斜め読みして適当に解説しているとかいうことはまさかないとは思いますが。
(名無しさん)
[25]
HTML 4 DTD の注釈は accessibility key character
と説明しています。
(名無しさん [sage])
[30] フォーム制御子の場合近くの (現在焦点がある制御子と同じフォームの) ものを選んでくれるようになっていると一頁内に複数のフォームがある時に便利なのに、 と思ったりすることもあります。
(名無しさん)
[35]
HTML5 IRC logs: w3c / #html-wg / 20070417 (2007-04-22 17:06:56 +09:00 版) http://krijnhoetmer.nl/irc-logs/html-wg/20070417#l-177
(名無しさん 2007-04-22 09:24:44 +00:00)
[44]
accesskey is broken (わかば 著, 版) http://suika.fam.cx/~wakaba/d/d200707#d1-1
(名無しさん 2007-07-01 14:06:14 +00:00)
[45] The SMIL 3.0 Linking Modules ( 版) http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-extended-linking.html#adef-accesskey
[46] Webサービスにおけるショートカットキーの原則 - TRANS [hatena] ( 版) http://d.hatena.ne.jp/aratako0/20081223/p1
[52] IRC logs: freenode / #whatwg / 20090502 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20090502#l-489
[53] [whatwg] accesskey="" ( 版) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019579.html
[54] コラム|【第10回】「カート」へのアクセスキーは何番? ( ( 版)) http://mobileredesign.jp/column10.html
[55] 583533 – Implement AccessKeyLabel attribute ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=583533
[56] Global attributes - HTML | MDN ( ( 版)) https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes?redirectlocale=en-US&redirectslug=HTML%2FGlobal_attributes#accesskey
[57] Bug 72715 – Implement AccessKeyLabel attribute. ( ( 版)) https://bugs.webkit.org/show_bug.cgi?id=72715
[58] IRC logs: freenode / #whatwg / 20140713 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140713
[98] UIA: Remove the limitation on accesskey mapping (#125) (boggydigital著, ) https://github.com/w3c/html-aam/commit/76ae0290af58e40101825c4284ca0ac729f41973
[99] UIA: Remove the limitation on accesskey mapping by boggydigital · Pull Request #125 · w3c/html-aam () https://github.com/w3c/html-aam/pull/125
[100] Remove HTMLElement.prototype.accessKeyLabel? · Issue #838 · whatwg/html () https://github.com/whatwg/html/issues/838
[101] accessKeyLabel is only implemented in Firefox? · Issue #3770 · whatwg/html () https://github.com/whatwg/html/issues/3770
On Firefox Windows/Linux the key combination is ALT+SHIFT+X and on OS X it is CTRL+ALT+X. You can specify a different key combination using a different key in the access key attribute. Here is the vector:
<input type="hidden" accesskey="X" onclick="alert(1)">
[103] Tweak how accesskey on legend works (zcorpan著, ) https://github.com/whatwg/html/commit/aa374be03beebf25ed33022846c2d03d3ea03484
[104] focus() on a non-focusable legend delegates focus in WebKit/Chromium · Issue #3950 · whatwg/html () https://github.com/whatwg/html/issues/3950
[105] Tweak how accesskey on legend works by zcorpan · Pull Request #3987 · whatwg/html () https://github.com/whatwg/html/pull/3987
[106] XFA-Template, https://www.w3.org/1999/05/XFA/xfa-template-19990614