3つのセクションを持つWebアプリがあるとします。左ナビゲーションメニュー、ツールバー/設定セクション、およびメインアプリケーション領域。ほとんどの場合、ユーザーはアプリケーションを直接操作し、ドキュメントのフォーカスはアプリケーションの「階層」のどこかにある可能性があります。つまり、アプリケーションに出入りしてタブを移動して、左側のナビゲーションまたはツールバーにフォーカスを置きます。痛みになります。
フォーカスを左側のナビゲーションメニューまたはツールバーに変更するためにショートカットを追加する(およびショートカットのキーストロークをそのセクションの横に表示することをお勧めしますか?)それ以外の場合は、多くのタブ操作を行うか、サイトのその部分とやり取りする他の方法を使用する必要がある可能性があります。これがWCAG a11yの要件とどのように一致するかを知っている人がいるなら、ボーナスポイントです。
編集、ワイヤーフレームで更新:
左ナビゲーション、ツールバー、およびアプリケーション(アプリケーションの「重要な」部分)を備えたアプリケーションがあるとします。アプリケーションは、最初にワイヤーフレームで「SOME APPLICATION」というラベルが付いたアプリケーションセクションに焦点を当てており、フォーカスの使用から抜け出すのを難しくする可能性のあるネストされたセクションが多数あります。ユーザーがショートカットを使用して各セクションの最初の関連リンクまたはボタンにフォーカスを移動できるようにすることは適切ですか? (私は画像のショートカットのいくつかの工夫された例を使用しましたが、おそらくより適切であるかもしれないいくつかを想像できます)
キーボードナビゲーションは適切な状況では素晴らしいことであり、多くの場合、キーボードナビゲーションを使用したくない人には「見えない」ため、追加することの欠点はほとんどありません。
「正しい状況」には、次のいずれかまたはすべてが含まれます。
アクセシビリティのガイドラインについては、 成功基準2.1.4:文字キーのショートカット を参照してください。具体的には、これは1文字のキープレスであるショートカットに関連するため、[ctrl]+
または[cmd+]
ショートカットを使用している場合は問題ありません。フォーカスを設定したい要素を指すトリガーリンク要素としてショートカットを実装します(直接フォーカスを設定するキーではなく)-これはほとんどの支援技術と互換性があり、それらはすべてプレーンリンクを処理できるためです。とアンカー。これは、ショートカットをプロンプトとしてユーザーに表示するという考えにうまく対応しています。