一考・accesskey&tabindex

HTML4およびXHTMLで定義されているaccesskey属性とtabindex属性は、キーボード操作をするには大いに役立つ属性ですが、これらの属性について考えてみましょう。

実際の動作については、accesskey&tabindex実験のページで確認してください。

リンクやフォームの入力部品にショートカットキーを割り当てることで、直接項目へ移動したり、リンク先へ移動させることが出来る機能です。
対応している要素は、a,area,input,textarea,button,label,legendです。

Tabキーを押して、リンクやフォームの項目間を移動させる順序を指定します。指定できる値は、0〜32767までの数字で、小さいほうから順に移動します。tabindexが指定されていなかったり、0が指定されている場合は、1以上の値が指定されているものより後に移動します。同じ値が指定されている場合は、より前に指定された方に先に移動します。
対応している要素は、a,area,input,textarea,button,select,objectです。

Windowsでaccesskey属性を使う場合、Alt + 指定したキー です（例外は、Opera7.x。Esc + Shift のあとで 指定したキー）。リンクの場合は、ブラウザによってフォーカスがあたるだけか、リンク先に移動するかが変わります。フォームの部品の場合は、フォーカスがあたります。
tabindexについては、Tabキーでリンクとフォームの入力部品いずれにもフォーカスがあたります（input要素のtype属性がsubmitやresetの場合は即実行。例外はOpera7.xのフォーカスがあたるだけ）。

Window用ブラウザのaccesskeyとtabindex対応状況

ブラウザ名	accesskey	accesskeyがある リンクの動作	accesskeyがある 送信ボタンの動作	tabindex
Internet Explorer3	非対応	動作しない	動作しない	非対応
Internet Explorer4	対応	リンク先へ移動	即送信	対応
Internet Explorer5	対応	フォーカスがあたるのみ	即送信	対応
Internet Explorer5.5	対応	フォーカスがあたるのみ	即送信	対応
Internet Explorer6	対応	フォーカスがあたるのみ	即送信	対応
Netscape4.x	非対応	動作しない	動作しない	非対応
Netscape6.x	対応	リンク先へ移動	即送信	対応
Netscape7.x	対応	リンク先へ移動	即送信	対応
Mozilla	対応	リンク先へ移動	即送信	対応
Opera6.x	非対応	動作しない	動作しない	非対応
Opera7.x	対応	リンク先へ移動	フォーカスがあたるのみ	対応
Lynx2.8.5	非対応	動作しない	動作しない	非対応
ホームページリーダー3.01	非対応	動作しない	動作しない	非対応

Macでaccesskeyを使う場合、control＋で指定したキー です。（除くiCab。iCabは指定したキーのみで動作）。リンクの場合は、いずれもリンク先へ移動します。
tabindexは、デフォルト状態でTabキーでリンクにフォーカスしないブラウザが多いので要注意。デフォルト状態ではInternet ExplorerのみTabキーでリンクにフォーカスします。

Mac用ブラウザのaccesskeyとtabindex対応状況

ブラウザ名	accesskey	accesskeyがある リンクの動作	accesskeyがある 送信ボタンの動作	tabindex
Internet Explorer4.5	非対応	動作しない	動作しない	非対応
Internet Explorer5.1x	対応	リンク先へ移動	即送信	対応
Internet Explorer5.2x	対応	リンク先へ移動	即送信	対応
Safari v1.2	対応	リンク先へ移動	即送信	フォームのみ対応（注1）
Netscape4.x	非対応	動作しない	動作しない	非対応
Mozilla	対応	リンク先へ移動	即送信	フォームのみ対応（注2）
Opera6.x	非対応	動作しない	動作しない	対応
iCab	対応	リンク先へ移動	即送信	非対応
OmniWeb4.5	非対応	動作しない	動作しない	フォームのみ対応

（注1）環境設定−詳細−ユニバーサルアクセスで「tabキーでリンクを強調表示」をONにすればリンクにも対応。
（注2）環境設定−Advanced−keyborad NavigationでTab Key Navigationに関する２つのチェックをONにすればリンクにも対応。

Linuxの場合、Windowsと同じ動作です。

Linux用ブラウザのaccesskeyとtabindex対応状況

ブラウザ名	accesskey	accesskeyがある リンクの動作	accesskeyがある 送信ボタンの動作	tabindex
Mozilla	対応	リンク先へ移動	即送信	対応
Opera7.x	対応	リンク先へ移動	フォーカスがあたるのみ	対応
Konqurer	非対応	動作しない	動作しない	対応
w3m	非対応	動作しない	動作しない	非対応
lynx	非対応	動作しない	動作しない	非対応

WindowsやLinuxの場合、accesskey属性対応ブラウザで、ブラウザが元々持つキーボードショートカットキーとバッティングするようなaccesskey属性値の指定をしてしまうと、accesskey属性値が優先されてしまいます。

ブラウザが元々持つキーボードショートカットキー一覧

ブラウザ名	ブラウザ側のキーボードショートカットキー
Windows版Internet Explorer4	F,E,V,G,A,H
Windows版Internet Explorer5以降	F,E,V,A,T,H,D
Netscape6.x	F,E,V,S,G,B,T,H
Netscape7.x,Mozilla	F,E,V,G,B,T,W,H,D

ちなみに、Google Toolbar2.0はGで検索フォームにフォーカスがあたります。

1. ブラウザ側のキーボードショートカットキーとのバッティング
2. ブラウザごとの操作の違い
3. 個々の制作者によるばらつき
4. 即実行されることによる問題
5. 複数キーの同時押しが要求される

最初の問題は先ほども触れていますが、ブラウザ側のキーボードショートカットキーとのバッティングで、ブラウザが元々持っているキーボードショートカットキーが使えなくなるおそれがあります。制作者側の都合で、ブラウザが元々持っている機能を使えなくするのは良くないと思います。

２つ目の問題は操作についての問題です。最近のブラウザではaccesskey属性が使えるのがほとんどですが、OSの違いによる操作の違いとブラウザによる操作の違いという問題があります。特に後者が深刻です。iCabでは、割り当てキーだけを押下すれば動作してしまいますし、Windows版とLinux版のOpera7.xでは、Shift + Esc の後に割り当てキーで動作します。同じOS上で動作するブラウザで動作手順が異なるというのは良くないでしょう。

３つ目の問題は、accesskeyを採用しているサイトであっても、採用しているキーバインドがバラバラで、統一感がないことです。キーバインドにアルファベットを使うにしても、最初の問題をクリアしようとすれば、リンク先とアクセスキーのつながりが薄くなりがちでしょう。また、個々のサイトで異なる操作を訪問者が覚えるかと言えばNoでしょう。

４つ目は、ブラウザによってはリンク先へ即移動したり、フォーム送信・リセットをしてしまうブラウザが多々存在することです。
もし、以下のようなことになっていたら、どうしますか？

• リンク先がブラウザクラッシャーだった
• いきなり怪しいサイトへ移動してしまった
• リンク先にウィルスが埋め込まれていた
• フォームが送信されて不利益を被る結果になった
• フォーカスがあたったのがリセットボタンでせっかく入力したフォームの内容が消された

どれもこれも考えただけでぞっとします。
まあ、accesskeyが指定されているリンクやフォームの動作については、HTML4.01の仕様書によると、以下のようになっています。

Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link. When a user activates a radio button, the user agent changes the value of the radio button. When the user activates a text field, it allows input, etc.

最初の英文を読む限りはフォーカスを受け取るだけのように読めるのですが、後の例を読むとA要素ではユーザエージェントがリンク先をたどるともなっているし、訳わかりません。それ故実装も異なってしまっているのでしょう。

最後に、accesskeyを活用するためには、ほとんどのブラウザで複数キーの同時押しが要求されるという点です。これはOS側の設定で軽減されるとはいえ、キーボードアクセスが使いたい層のニーズに合っているかといえば疑問です。

これらのことを考えると、パソコン上で閲覧してもらうのを前提とするページにaccesskey属性を設定するメリットは薄いでしょう。accesskeyが活きる状況というのは、携帯電話デバイスからのアクセスを想定したページになると思います。これは、操作方法が限られている故に、accesskey属性を設定することでスムーズなアクセスが出来るからです。

• リンクにフォーカスがあたらないブラウザの存在
• 必要性の問題

最初の問題は、Macの場合、デフォルト状態ではTabキーでリンクにフォーカスがあたらないブラウザが多いという問題があります。これは意外な落とし穴ですので気をつけてください。そもそも、Macの操作はマウスを使うのを前提にしている部分が多いので、キーボードアクセスがしたいのであれば、Macを選択しない方がいいと思います。

そもそもtabindexを用意するべきかどうかという問題があります。Tabキーをつかって、リンクやフォームの入力部品にフォーカスをあてることが出来るブラウザの場合、適切な並べ方をしていればわざわざtabindex属性を設定する必要はないと言えます。入力部品やリンクの不適切な並びがあることを想定した属性を使う以前に、フォームやページの設計を見直すべきだと思います。

パソコン上で閲覧することを考えると、accesskey、tabindexともに設定するメリットは薄いでしょう。

これらの属性をつけたがる人たちのよりどころであるW3CのWebコンテンツアクセシビリティガイドライン1.0 では、チェックポイント9.4とチェックポイント9.5でtabindexやaccesskeyを設定することを促してはいるのですが、いずれも優先度が最も低い優先度3として設定されています。また、Another HTML-Lintで100点を取るためにつけるのは非常に虚しい話です。

accesskeyやtabindexを設定しなくても、Tabキーを使ったキーボード操作ができるブラウザが各OSには用意されています。したがって、キー操作をすることでユーザの予期せぬ動作を引き起こす可能性のあるaccesskey属性やtabindex属性を設定しないというのがベターかもしれません。