Webアクセシビリティのマシンリーダブルとは？支援技術に伝わるHTMLの基本

マシンリーダブルとは、ページ内の情報や操作の意味を、ブラウザーや支援技術などのソフトウェアがプログラムから判別できる状態です。

文字が画面に表示されているだけでは、見出し、ボタン、入力欄といった役割まで伝わるとは限りません。

HTMLで構造、名前、関係を適切に示すと、スクリーンリーダーをはじめとする支援技術が、利用者にページの内容と操作方法を伝えやすくなります。

マシンリーダブルが意味すること

Webアクセシビリティでいう「マシンリーダブル」は、単にデータをコンピューターで読み込めることではありません。

見出しを見出し要素として、操作ボタンをボタン要素として実装し、入力欄には名称を関連付けるなど、見た目の意味をコードにも反映することを指します。

例えば、文字を大きく太くしただけの <div> は、人には見出しに見えても、支援技術には通常の文章として伝わる場合があります。

<h2> を使えば、その文字列が見出しであり、文書構造の一部であることを示せます。

支援技術がページをどう案内するかは、関連記事「スクリーンリーダーの仕組みと実装ポイント」でも解説しています。

支援技術に伝わるHTMLの作り方

見出しとリストで文書構造を示す

見出しは、文章を大きく表示するための装飾ではなく、その後に続く内容の名前です。

WordPressの投稿タイトルをページの主見出しとし、本文では <h2> と <h3> を内容の階層に合わせて使います。

順序に意味がある手順には <ol>、順序を問わない項目には <ul> を使うと、項目のまとまりもコードから判別できます。

<h2>申請の流れ</h2>
<ol>
  <li>必要事項を入力する</li>
  <li>内容を確認する</li>
  <li>申請を送信する</li>
</ol>

画像の役割に合わせて代替テキストを書く

画像の alt 属性は、見た目を一律に説明する欄ではありません。

本文の理解に必要な画像には、同じ目的を果たす短い説明を付けます。

リンクやボタンとして使う画像では操作先や機能を伝え、意味を持たない装飾画像では alt="" として読み上げの対象から外します。

画像の目的別の判断例は「画像の代替テキスト（alt）の使い方」で確認できます。

<img src="team.jpg" alt="会議室で設計案を確認するプロジェクトチーム">
<img src="border.png" alt="">

フォームの名称と説明を入力欄に関連付ける

入力欄の近くに「メールアドレス」と表示するだけでは、その文字と入力欄の関係をソフトウェアが判別できない場合があります。

<label> の for と入力欄の id を一致させると、表示上の名称と入力欄を関連付けられます。

<label for="email">メールアドレス</label>
<input type="email" id="email" name="email" required>

入力条件やエラー内容も、色や配置だけに頼らず、該当する入力欄との関係が分かるテキストで示します。

リンクとボタンを目的で使い分ける

別のページや位置へ移動する操作にはリンク、送信や表示切り替えなどページ上の処理にはボタンを使います。

標準のHTML要素を目的どおりに使うと、要素の役割やキーボード操作を支援技術へ伝えるための基礎が整います。

音声と動画に代替手段を用意する

音声で伝える情報には文字起こしを、動画内の音声情報には字幕を用意します。

自動字幕を使う場合も、固有名詞や専門用語を含めて内容が正しく伝わるかを公開前に確認します。

構造化データとセマンティックHTMLの違い

セマンティックHTMLは、見出し、リンク、ボタン、入力欄など、ページを構成する要素の意味をHTMLで示す方法です。

一方、Schema.orgなどの構造化データは、記事、商品、イベントといったページ情報を、検索サービスなどが分類しやすい形式で記述するものです。

構造化データを追加しても、見出しやフォームの実装が自動的にアクセシブルになるわけではありません。

アクセシビリティの基礎は利用者が操作するHTMLにあり、構造化データは別の目的で補完する情報です。

Googleの構造化データに関する公式ガイドラインも、正しく実装したページであってもリッチリザルトの表示を保証しないと説明しています。

検索順位やクリック率の向上を約束する仕組みではないため、アクセシビリティ改善の効果とSEO上の効果を同一視せず、それぞれを検証します。

WCAGと日本の法制度をどう捉えるか

WCAG 2.2は、Webコンテンツを障害のある人にとって利用しやすくするためのW3C勧告です。

代替テキスト、情報と関係性、見出しとラベルなど、この記事で扱う実装を点検する共通の基準として利用できます。

実務での読み方は、関連記事「WCAG 2.2とは何か」でも整理しています。

日本では、内閣府の障害者差別解消法に関する案内が、事業者による合理的配慮の提供について説明しています。

ただし、「マシンリーダブルなHTMLにしただけで、あらゆる法的要件を満たす」という意味ではありません。

Webサイトの事前的な改善と、利用者から申し出があった場面での個別の配慮は区別して検討する必要があります。

具体的な改善項目を確認するときは、デジタル庁のウェブアクセシビリティ導入ガイドブックも参考になります。

結果を誇張しない実装例

災害情報を掲載する場合

避難情報を画像だけで掲載すると、代替テキストや本文がない限り、画像内の情報を支援技術で取得できません。

地域名、対象者、行動、更新時刻を見出しと本文で示し、図を補助として使えば、情報の構造をソフトウェアから判別しやすくなります。

商品を購入する画面の場合

商品画像には購入判断に必要な内容を伝える代替テキストを付け、価格や仕様は画像内だけでなくテキストでも示します。

入力欄のラベルと購入ボタンの役割をHTMLで示せば、利用者は支援技術からもフォームの目的と操作を確認しやすくなります。

これらは実装の比較例であり、問い合わせ件数、購入率、検索順位の改善を保証する事例ではありません。

公開前に確認する項目

• 投稿タイトル以外に <h1> を重ねず、本文の見出し階層を <h2> と <h3> で整理しているか
• リンクとボタンを目的に応じて使い分け、操作の意味が要素名から分かるか
• 情報を持つ画像には目的に合う代替テキストがあり、装飾画像の alt は空になっているか
• 入力欄にラベルが関連付けられ、入力条件とエラーがテキストで伝わるか
• 音声や動画に、内容に応じた字幕や文字起こしがあるか
• キーボード操作とスクリーンリーダーで、読む順序と操作結果を確認したか
• 構造化データをアクセシビリティ対応の代用にしていないか

支援技術に伝わる実装から始める

マシンリーダブルなWebページは、見た目で示した構造や操作の意味をHTMLにも反映しています。

見出し、代替テキスト、フォームラベル、リンク、ボタンを目的どおりに実装し、実際の操作環境で確認することが改善の出発点です。

構造化データや検索上の施策は、その基礎を整えたうえで別に評価すると、アクセシビリティとSEOの目的を混同せずに運用できます。