accesskey属性は主要な操作の代わりにせず補助する操作へ限定する

accesskey属性は、keyを使って要素を操作するための指定です。しかし、どのkeyをどの修飾keyと組み合わせるかは、browserや環境によって異なります。すべての利用者へ同じshortcutを約束できないため、主要なlink、送信button、navigationをaccesskeyだけで使える設計にしてはいけません。

shortcutは、操作の回数を減らすための補助です。画面上の意味が分かるbuttonやlinkを、shortcutの代わりに消すものではありません。日常的に使う管理画面では役立つ場合がありますが、初めて来る利用者がkeyの組み合わせを知らなければ、何もできません。通常の操作を残したうえで、対象の作業だけを補助します。

HTML 5.1では、accesskey属性の値は一つ以上の文字で、要素をactivateまたはfocusするためのshortcutとして扱われます。同じaccess keyが複数の要素へ割り当てられた場合、user agentは候補から一つを選ぶことがあります。指定そのものより、重なったときに利用者が迷わない構成を先に考えます。

通常の操作を残したまま補助する

accesskeyを使う場合も、画面上で読めるlinkやbuttonを省きません。利用者がkeyを知らない、使えない、別のshortcutと重なる場合でも、同じ作業へ進める必要があります。shortcutがなくても完了できる操作を、先に整えます。

たとえば、社内で毎日使う受注確認画面に、一覧へ戻るlinkがあります。linkを画面上へ残したうえで、対象browserで使えるshortcutを補助として用意することはあります。一方、一般向けの問い合わせformで「AltとQを押せば送信できる」とだけ案内しても、利用者の環境によっては使えず、送信buttonが見つからなければ作業を終えられません。

一般向けpageでは、shortcutを覚えるより、見出し、link文言、buttonの位置を分かりやすくする方が先です。問い合わせpageなら、連絡方法と送信buttonが読めることが必要です。記事pageなら、本文と関連linkへ進めることが必要です。accesskeyを付けたことで、通常のnavigationやfocusの順序を分かりにくくしてはいけません。

反復作業の多い社内画面でも、すべての操作へkeyを割り当てる必要はありません。保存、一覧へ戻る、次の確認へ進むなど、時間を使う操作がどれかを観察します。利用者ごとに作業順が違うなら、共通のshortcutを増やす前に画面の流れを見直します。keyを覚える負担が、クリックする負担より大きくなることもあります。

keyを決める前に重なりを調べる

accesskeyを指定する前に、次の順で確認します。

1. その操作がshortcutを必要とする反復作業かを確認する。
2. 画面上のlinkやbuttonだけで完了できるかを確認する。
3. 同じpage内で同じaccess keyを使っていないかを確認する。
4. 対象browserと入力環境で、実際にfocusまたはactivateできるかを試す。
5. shortcutが使えない場合の操作を残す。

説明用の仮例として、記事編集画面に「保存」「preview」「一覧へ戻る」があるとします。三つへ安易に一文字ずつ割り当てるより、繰り返し使う操作がどれかを確認します。keyがbrowserの機能や入力中の操作と重なれば、覚えたshortcutほど邪魔になります。頻度が低い操作は、読みやすいbuttonやlinkを整えるほうが先です。

同じpage内で同じkeyを重ねると、利用者はどこが操作されるか予測できません。sectionごとに似たbuttonがある場合も、shortcutを増やすより、buttonの文言と配置を分けます。keyが一つに決められない操作は、accesskeyに向きません。使う対象を絞ることで、重なりを調べる範囲も小さくなります。

対象browserで試すときは、文字を入力している途中、buttonへfocusがある状態、pageを読み始めた状態を分けます。画面のどこにfocusが移るか、意図せず別の操作が起きないか、shortcutが使えないときにマウスやkeyboardで同じ操作ができるかを確認します。accesskeyの値だけをsourceで確認しても、作業上の問題は見つかりません。

shortcutの実装と業務の手順を分ける

制作側はaccesskey属性をmarkupへ付けられます。しかし、どの作業を早くしたいか、誰がどの環境で使うか、重なった場合にどう戻るかは、実際の業務を知る側が決めます。shortcutを付けることと、作業手順を改善したことは同じではありません。

外部の制作者へ頼むときは、keyだけを指定しません。対象page、対象操作、利用者、対象browser、通常の操作方法、確認する場面を伝えます。制作側はmarkupと動作を確認し、業務側はその操作が本当に繰り返されるか、作業を妨げないかを確認します。操作の権限が必要な画面なら、誰がその画面を使えるかも別に決めます。

shortcutを付けた後は、操作回数が減ったかだけで判断しません。誤操作が増えていないか、shortcutを知らない人が通常のbuttonを見つけられるか、引継ぎの人が対象とkeyの対応を分かるかを確認します。短縮する対象は小さくても、通常の操作を壊すと作業全体は遅くなります。

最初の一手は、一日のうちに何度も繰り返す操作を三つまで書き出すことです。画面上の操作だけで困らないものは残し、繰り返しが多く対象環境も決まるものだけをtestします。accesskeyは主要な操作を置き換えるものではなく、通常の操作が整ったあとに検討する補助です。