Amazon11/12まで!スマイルSale開催中! セール会場へ

SWELLのキーボード操作を調べる|Tabキーで本文に着くまでを実測する

Tabキーの実際の移動先は、リンクやボタンのDOM順に加え、tabindex、非表示状態、無効化、ブラウザーの設定などで変わります。

querySelectorAllで集めた要素数を、そのままTab回数として扱うことはできません。

以前掲載していた112個・本文まで50回という値は、候補要素の集計と実際のキー操作を混同していたため撤回しました。

このページでは、実操作と候補一覧を分けて確認します。

目次

著者

WEB制作をしているデジタルノマド
WordPressのカスタマイズが好きで、色々と自作しています。

WordPressのカスタマイズに困ったらご相談ください!

最初に実際のTab操作を記録する

ログアウトした公開ページを開き、URL・WordPressとSWELLの版・ブラウザー・画面幅・メニューの開閉状態を控えます。

PC幅とスマホ相当の幅では別々に記録してください。

開発者ツールからTabを押し始めるとページ以外へ移動するため、ページへフォーカスを戻してから始めます。

Tabで次へ、Shift+Tabで前へ移動し、フォーカスが見える要素の名前を順に記録します。

リンクはEnter、ボタンはEnterとSpaceで操作します。

本文へ進むスキップリンクがあれば、見た目のスクロールだけでなく次のTabが本文側へ移るかも確認してください。

メニューを閉じた状態、開いた状態、Escapeで閉じた状態を分けて確認します。

閉じたメニューへフォーカスが入る、閉じたあと元のボタンへ戻れないなど、再現できた操作を記録します。

サイト全体で一律に発生すると決めつけないでください。

スポンサーリンク

記録は「押したキー・移動先・結果」を1操作ずつ残す

確認する部品をメニュー、検索、本文リンク、目次、フォームなどに分けます。

各部品で「開始位置」「押したキー」「移動先」「枠線が見えるか」「操作できたか」「閉じた後の戻り先」を記録すると、修正前後を比較できます。

確認していない部品は未確認のまま残します。

例えば「閉じたメニューのボタンにフォーカス → Enter → メニューが開く → Tabで項目へ移動 → 閉じる操作 → 元のボタンへ戻る」という流れを記録します。

これは記録形式の例で、このページでSWELLの実動作を測った結果ではありません。

フォームは検証用の送信先で確認し、本番への意図しない送信を避けます。

モーダルの内部でTabが循環すること自体は、不具合とは限りません。

キーボードで閉じて外へ戻れるかを確認します。

抜け出す手段が分からない、または操作できない状態を優先して調べます。

W3Cのキーボードトラップ解説も参照してください。

開発者ツールで候補の属性を確認する

次のJavaScriptは、調べたい公開ページの開発者ツールのコンソールに一度実行します。

投稿本文やfunctions.phpへ貼るコードではありません。

DOMを書き換えず、候補の属性を表に出力します。

解除用コードは不要です。

(() => {
  const selector = 'a[href],button,input,select,textarea,summary,[tabindex]';
  const candidates = [...document.querySelectorAll(selector)];
  console.table(candidates.map((el, index) => ({
    DOM位置: index + 1,
    要素: el.tagName.toLowerCase(),
    名前: (el.getAttribute('aria-label') || el.textContent || '').trim().slice(0, 60),
    tabindex: el.tabIndex,
    disabled: el.matches(':disabled'),
    inert内: Boolean(el.closest('[inert]')),
    描画領域あり: el.getClientRects().length > 0,
    visibility: getComputedStyle(el).visibility
  })));
})();

表の「名前」はaria-labelまたはテキストから取った調査用の目印です。

label要素やaria-labelledbyなどを含むアクセシブルな名前の計算ではなく、空欄でも直ちに名前がないとは判断できません。

ブラウザーのアクセシビリティ情報も確認してください。

これは候補一覧であり、Tab順や回数を算出しません。

ラジオボタンのグループ、閉じたdetails、iframeやShadow DOM、祖先のスタイルなどは別途確認が必要です。

tabindexが正の要素はDOM順より前に移動する場合があり、負の値は通常のTab移動から外れます。

見えないメニューを診断する

opacity:0だけでは通常Tab移動から外れません。

ただし、opacityが0で子リンクが存在するだけでは不具合の証明になりません。

祖先のdisplay・visibility・inert、要素のtabindexやdisabledを調べ、実際にTabで入れるかを確かめます。

SWELLの版、追加CSS、メニュー拡張によって状態は異なります。

閉じたメニューを修正する場合は、開くと操作できること、Escapeや閉じるボタンで閉じられること、フォーカスが戻ることまでテスト環境で確認します。

常時inertを付けると開いたメニューも操作できなくなります。

テーマ本体を直接編集せず、追加した処理だけを外せる形にします。

修正の優先順位を決める

まず、メニューから抜けられない、検索や送信などの主要操作ができない、といった利用を止める問題を直します。

次に、フォーカスが見えない・移動先が隠れる問題を確認し、その後で不自然な移動順や同じリンクの過度な繰り返しを見直します。

これは作業順の目安で、WCAG適合性の採点基準ではありません。

フォーカス位置が見えることは、キーボード操作で現在地を判断するために必要です。

W3Cのフォーカス可視化の解説を確認し、このページの点検だけでサイト全体のアクセシビリティ適合を判定しないでください。

スポンサーリンク

フォーカスの見た目と修正後の確認

枠線を一律に消すCSSは避けます。

:focus-visibleはブラウザーがフォーカス表示の必要性を判断する仕組みで、キーボード操作だけに限定されるとは限りません。

背景に埋もれない線の色と太さを選び、メニュー・検索・本文リンクで確認します。

修正前と同じURL・幅・メニュー状態で再確認し、操作の順番と不具合が解消した箇所を記録します。

要素数が減っただけでは改善と判断しません。

追加CSSやスクリプトの場所と変更前の内容を保存し、不具合が出たら追加部分を外して戻します。

本文末の図版で確認した範囲は、2026年10月1日の幅390pxの検証用ページにおけるフォーカス移動です。

その図版のWordPress・SWELL・ブラウザーの版は本文に記録していません。

SWELLサイト全体のTab回数や、各メニュー・検索・目次の組み合わせごとの操作結果は、この図版では確認していません。

仕様はMDNのtabindexとinertを参照してください。

動く部品の見本はSWELLブロック見本集にあります。

候補に含まれる操作不能要素を飛ばし、次のボタンにフォーカスが移った検証画面
2026年10月1日、幅390pxの検証用ページで撮影。候補には7要素ありますが、開始リンクの次のTabは「次のボタン」へ移動しました。SWELL全体の操作回数を測った画像ではありません。
  • URLをコピーしました!

実装を任せたい方へ

SWELLのカスタマイズ代行

記事のコードをそのまま使うのが不安な場合や、サイトに合わせた調整が必要な場合は当社が実装します。1時間 ¥8,000〜(税込)。テーマ更新に強い書き方で納品します。

WAZAの有料記事のサブスクリプションも開始しました。

サービス

Service

WordPressサイトのカスタマイズのサービスに関心がありましたら、ぜひ詳細をご覧ください。

目次