a11y/no-accesskey · accesskey 属性
accesskey 属性はページレベルのショートカットキーを割り当てますが、実際のキーの組み合わせはブラウザと OS によって異なり、ユーザーには発見できず、支援技術のキーバインドと衝突します。
重大度: warning · カテゴリ: a11y
チェック内容
accesskey 属性を持つあらゆる要素を検出します。
<button accesskey="s">Save draft</button>
多くの属性ルールと異なり、式による accesskey={key} も検出します: 問題なのは属性の存在そのものであり、値は一切関係しないため、静的に判定できない部分がありません。
検出しないもの:
- スプレッド属性経由で供給される
accesskey。静的解析の範囲外です。
なぜ重要か
accesskey はページレベルのキーボードショートカットを割り当てますが、実際のキーの組み合わせを選ぶのはあなたではなくブラウザと OS です。同じマークアップがあるブラウザでは Alt+キー、別のブラウザでは Alt+Shift+キー、macOS では Ctrl+Opt+キーを意味します。ユーザーにはショートカットの存在を発見する手段がなく、その組み合わせはスクリーンリーダーやブラウザのキーバインドと日常的に衝突して、それらに最も依存するユーザーからコマンドを黙って奪います。この属性を一切使わないというのが、長年のアクセシビリティガイダンスです。
修正方法
属性を削除し、可視でフォーカス可能なコントロールに任せます。
<button>Save draft</button>
本当にキーボードショートカットが必要なら、キーハンドラで実装してページ内に見える形でドキュメント化してください。そうすれば正確な組み合わせを自分で選べて、予約済みのものを避けられます。
制限事項
対象になるのは静的に名前が決まる要素の属性だけで、カスタム要素も含まれます。accesskey を供給しうるスプレッド属性と、<svelte:element> による動的タグは静的解析の範囲外のため検出されません。
Svelte コンパイラとの重複
コンパイラは同じマークアップに a11y_accesskey を警告します。この重複は意図的です: コンパイラの警告はビルドログに流れるだけで、スコアもゲートも抑制もしません。一方このルールはヘルススコアに反映され、svelte-vitals-disable-next-line を尊重し、--fail-on で CI を失敗させられます。どちらのチェックも値に関係なく属性の存在を判定するため、既知の相違点はありません。
モードによる違い
ありません。このルールが読むのは同じ .svelte / .ts のソースファイルなので、CLI、Vite プラグインのビルド、ライブダッシュボードの静的ベースラインのいずれでも結果は同一で、レンダリング済み HTML の解析で再評価されることもありません。--route で実行範囲を絞ると、このルールは動きません。コンポーネントスコープのルールには、検出を紐づけるルートが無いためです。
無効化
accesskey が本当に意図したものなら、<!-- svelte-vitals-disable-next-line a11y/no-accesskey --> で個別の要素を黙らせるか、ルールを無効化します。
export default {
rules: {
'a11y/no-accesskey': 'off'
}
};