コラム / 制作会社・広告会社向け

リンクとボタンの使い分け|HTMLの役割とキーボード操作を検証

移動するリンクと、その場で実行するボタンは、見た目ではなく目的で選びます。クリックだけのdivと標準要素を比べ、Tab・Enter・Spaceの操作、開閉状態、PCとスマホ幅をローカルで検証しました。

公開 最終確認 2026-11-09著者 GreenCoding
別ページへ進むリンクと同じ画面のパネルを開くボタンを、端末とキーボードで描いた生成イラスト

サービス詳細へ移動するならリンク、いまの画面で条件を開くならボタンを使います。同じ緑色の四角に見えても、HTMLの要素は操作の目的で選びます。マウスで押せるだけでは、キーボードでも使えることの確認にはなりません。

制作会社様の実装・確認担当に向けて、サービス紹介ページの二つの操作を例に説明します。架空の画面をローカルで作り、クリックだけを付けたdivと、標準のリンク・ボタンを比較しました。サンプルは外部送信や保存を行いません。

移動する操作と、画面内で実行する操作を分ける

W3Cのリンクパターンは、別ページや同じページ内の場所を参照する操作を扱います。行き先がある場合は、hrefを持つa要素を基本にします。ボタンは、表示の切り替えや送信などの操作に使います。

  • サービス詳細へ移動:a要素に実在するURLやページ内の移動先を指定する。
  • 対応条件を表示:button要素で、その画面の説明領域を開閉する。
  • フォームを送信:送信の意味を持つボタンとして設計し、入力確認や送信後の状態も別に検証する。

リンクをボタンのように装飾すること自体は可能です。ただし、画面設計の段階で「ボタン」と呼んでいる部品でも、遷移するのか、その場で実行するのかを実装担当へ伝えます。名称だけで要素を決めないようにします。

クリックだけを登録したdivでは操作が不足する

<!-- 問題例:見た目とクリックだけの部品 -->
<div id="bad">対応条件を開く</div>

// クリックでは動くが、標準のボタン操作は備わらない
bad.addEventListener("click", openConditions);

この形では通常のTab移動で選択できず、標準ボタンのEnter・Spaceによる実行も自動では付きません。roleやtabindexを足すだけで、必要なキー操作まで完成するわけではありません。独自の操作部品が必要でなければ、最初からbuttonを使うほうが確認する範囲を絞れます。

標準要素で移動先と開閉状態を表す

<a href="#destination">サービス詳細へ移動</a>

<button id="good-button" type="button"
  aria-expanded="false" aria-controls="conditions">
  対応条件を表示
</button>
<div id="conditions" hidden>
  <p>対応範囲は案件ごとに相談します。</p>
</div>

<section id="destination">
  <h2>サービス詳細</h2>
</section>

この例のボタンは送信を行わないため、type=”button”を明示します。MDNは、フォーム内のボタンが意図せず送信動作をしないよう、用途に応じてtypeを指定することを案内しています。開閉状態はaria-expandedと実際の表示を一緒に更新します。

const btn = document.querySelector("#good-button");
const panel = document.querySelector("#conditions");
btn.addEventListener("click", () => {
  const expanded = btn.getAttribute("aria-expanded") === "true";
  btn.setAttribute("aria-expanded", String(!expanded));
  panel.hidden = expanded;
});

標準ボタンはキーボードからの実行もclickへつながるため、この例ではEnter用・Space用の処理を重ねて追加しません。二重に登録すると、一度の操作で開いてすぐ閉じるなどの不具合を招くことがあります。ダイアログや複雑なメニューは別の設計が必要で、この短い例だけで代用はできません。

ローカルで確認できた結果と、残る検証

  1. クリックの差:問題例のdivはクリックで説明を表示しました。見た目だけでは不足を見分けにくい状態でした。
  2. キー操作:リンクからTabでボタンへ移動し、Spaceで開き、Enterで閉じることを確認しました。開閉後もフォーカスはボタンに残りました。
  3. 移動と幅:リンクをEnterで実行すると、URL末尾が指定した移動先になりました。PC幅1280pxとスマートフォン相当の390pxで、ページ全体の横はみ出しがないことを確認しました。

確認日は2026年11月9日、環境はローカルHTMLとIABのChromium系ブラウザーです。ブラウザーの厳密なバージョンは取得できていません。390pxは表示幅の試験であり、スマートフォン実機のタッチ操作やスクリーンリーダーの読み上げは未確認です。対応対象の端末・ブラウザーで追加確認してから検収します。

フォーカスの枠を消さず、文言が長くなっても切れない余白を設けます。遷移先、開閉、入力送信を別々の項目として検収表へ記録すると、押せたという一つの結果で全操作を合格にせずに済みます。ページ内移動の位置調整は、固定ヘッダーとページ内リンクの実装例も参照できます。

依頼時は、押した後の結果まで共有する

画面デザインと一緒に、移動先、開いたときの内容、閉じ方、フォーカスの行き先を渡してください。GreenCodingのコーディング・WordPressの実装支援では、案件の対応環境に合わせたマークアップや操作確認を相談できます。既存部品を直す場合も、見た目と動作の両方を確認して作業範囲を決めます。

公式参照情報

Web案件の進め方が未確定でも、
ご相談いただけます。

支給資料と現在決まっている範囲を確認し、必要な工程、役割分担、実装・検証範囲を整理します。

制作パートナー向けサービスを見る