6. Webアクセシビリティでまず確認したい基本項目

Webアクセシビリティには多くの確認項目がありますが、最初からすべてを完璧に理解しようとすると、少し難しく感じるかもしれません。

そこでまずは、Webサイトを運営するうえで特に確認しやすく、改善効果も大きい基本項目から見ていくことをおすすめします。

ここで紹介する項目は、専門的な検査を行う前にも確認できる内容です。制作会社やシステム担当者だけでなく、広報担当者、採用担当者、CMSで記事を更新する担当者にも関係します。

6-1. 見出し構造は正しいか

Webページでは、見出しの構造がとても重要です。

見出しは、ページの内容を整理し、利用者が情報を探しやすくするための目印です。見た目として文字を大きくするだけではなく、HTML上でも適切な見出しタグを使う必要があります。

一般的には、ページの主題を表す見出しに<h1>を使い、その下の大きな区切りに<h2>、さらに細かい内容に<h3>を使います。

見出し構造が正しく整理されていると、スクリーンリーダーを使っている人がページ全体の構成を把握しやすくなります。また、検索エンジンやAIにとっても、ページの内容を理解しやすくなります。

確認するときは、次の点を見てみましょう。

• <h1>がページの主題を表しているか
• 見出しの順番が不自然に飛んでいないか
• 見た目だけを大きくして、見出しタグを使っていない箇所がないか
• デザイン目的だけで見出しタグを使っていないか
• 見出しだけを読んでも、ページの流れが分かるか

たとえば、<h2>の次に突然<h5>が出てくるような構造は、ページの階層が分かりにくくなります。

また、文字を大きくしたいだけの理由で見出しタグを使うことも避けましょう。見出しタグは、文字サイズを変えるためのものではなく、文書構造を示すためのものです。

6-2. 画像に適切な代替テキストがあるか

画像には、必要に応じて代替テキストを設定します。

代替テキストとは、画像の内容や意味を文字で説明する情報です。HTMLでは、画像のalt属性として設定します。

代替テキストがあることで、画像を見ることができない人にも内容を伝えられます。また、画像が読み込まれない場合や、検索エンジン・AIが画像の意味を理解する場面でも役立ちます。

ただし、すべての画像に長い説明を入れればよいというわけではありません。

画像の役割によって、適切な代替テキストは変わります。

• 意味のある画像には、内容や目的が伝わる代替テキストを入れる
• リンクになっている画像には、リンク先や操作内容が分かる代替テキストを入れる
• 装飾目的だけの画像は、空のalt=""にする
• 画像内の文字が重要な場合は、その内容を本文にも記載する
• グラフや図表などは、本文で内容を説明する

たとえば、会社の代表者の写真であれば「代表取締役 〇〇の写真」のように説明できます。資料請求ボタンの画像であれば、「資料請求はこちら」のように、クリックしたときの目的が分かる表現が必要です。

一方で、背景の飾りや罫線のような画像に「装飾画像」と読み上げられてしまうと、利用者にとっては余計な情報になります。その場合は、空のalt属性を設定します。

代替テキストは、画像を見た人と見られない人の情報差を減らすためのものです。画像の見た目を細かく説明するのではなく、その画像がページ内でどのような意味を持っているのかを考えて設定しましょう。

6-3. 文字色と背景色のコントラストは十分か

文字色と背景色のコントラストも、Webアクセシビリティでは重要な確認項目です。

コントラストが低いと、視力が弱い人、色の見え方に特性がある人、高齢者、屋外でスマートフォンを見ている人などにとって、文字が読みづらくなります。

特に注意したいのは、薄いグレーの文字、淡い色の背景に白文字、画像の上に重ねた文字、ボタン内の文字などです。デザイン上はおしゃれに見えても、読みづらい場合があります。

確認するときは、次の点を見てみましょう。

• 本文の文字が背景に対して十分に読みやすいか
• ボタンやリンクの文字が読みやすいか
• 画像の上に重ねた文字が背景に埋もれていないか
• エラー表示や注意書きが色だけに頼っていないか
• スマートフォンの画面でも読みやすいか

WCAGでは、通常の文字について一定以上のコントラスト比が求められます。厳密な数値確認には、コントラストチェックツールを使うと便利です。

また、色だけで情報を伝えることも避ける必要があります。

たとえば、フォームのエラーを赤色だけで示している場合、色の違いが分かりにくい人には伝わらない可能性があります。その場合は、「必須項目です」「メールアドレスの形式が正しくありません」など、文字でも内容を伝えることが大切です。

コントラストの改善は、アクセシビリティだけでなく、Webサイト全体の読みやすさにも直結します。

6-4. キーボードだけで操作できるか

Webサイトは、マウスやタッチ操作だけでなく、キーボードだけでも操作できる必要があります。

キーボード操作は、視覚障害のある人や、マウスを使うことが難しい人だけでなく、けがをしている人、ノートパソコンで作業している人、効率よく操作したい人にも関係します。

まずは、実際にマウスを使わず、キーボードだけでページを操作してみましょう。

主に使うキーは、Tabキー、Shift + Tabキー、Enterキー、Spaceキー、矢印キーです。

確認するときは、次の点を見てみましょう。

• Tabキーでリンクやボタンに順番に移動できるか
• 現在どこを選択しているか、フォーカス表示で分かるか
• メニューをキーボードで開閉できるか
• モーダルウィンドウをキーボードで閉じられるか
• フォームに入力し、送信まで完了できるか
• 途中でフォーカスが見えなくなったり、抜け出せなくなったりしないか

特に注意したいのは、ハンバーガーメニュー、アコーディオン、スライダー、モーダルウィンドウ、タブ切り替えなどの動きのある部品です。

見た目上は問題なく動いていても、キーボードでは操作できないことがあります。

また、フォーカス表示をデザイン上の理由で消してしまっているサイトもあります。フォーカス表示がないと、キーボード利用者は今どこを操作しているのか分からなくなります。

キーボードだけで主要な操作が完了できるかどうかは、Webアクセシビリティの基本的な確認項目です。

6-5. フォームのラベルやエラー表示は分かりやすいか

問い合わせフォーム、予約フォーム、資料請求フォーム、採用応募フォームなどは、Webサイトの成果に直結する重要な部分です。

フォームが使いにくいと、利用者は途中で入力をやめてしまいます。これは、アクセシビリティ上の問題であると同時に、ビジネス上の機会損失にもなります。

フォームでは、各入力欄が何を入力する場所なのか分かるように、ラベルを適切に設定する必要があります。

見た目では入力欄の近くに「お名前」「メールアドレス」と表示されていても、HTML上でラベルと入力欄が関連付けられていない場合、スクリーンリーダーでは分かりにくくなることがあります。

確認するときは、次の点を見てみましょう。

• 各入力欄に分かりやすいラベルがあるか
• 必須項目が文字でも分かるようになっているか
• 入力例が必要な場合、分かりやすく示されているか
• エラーが出たとき、どの項目を直せばよいか分かるか
• エラーの理由が具体的に表示されるか
• エラー後に入力内容が消えないか
• キーボードだけで入力から送信までできるか

よくない例として、「入力内容に誤りがあります」とだけ表示され、どの項目に問題があるのか分からないケースがあります。

この場合、利用者はページ全体を確認し直さなければならず、大きな負担になります。

「メールアドレスの形式が正しくありません」「電話番号は半角数字で入力してください」「お名前は必須項目です」のように、具体的なエラーメッセージを表示することが大切です。

フォームは、アクセシビリティの問題が成果に直結しやすい場所です。Webサイトを改善する場合は、優先的に確認しましょう。

6-6. リンクテキストだけで遷移先が分かるか

リンクテキストは、クリックした後にどこへ移動するのか、何が起こるのかが分かる表現にする必要があります。

よくある表現に「こちら」「詳しくはこちら」「詳細はこちら」があります。これらは文脈の中で見れば意味が分かる場合もありますが、リンクだけを一覧で確認する利用者や、スクリーンリーダーを使っている利用者には分かりにくいことがあります。

たとえば、ページ内に「詳しくはこちら」というリンクが複数あると、それぞれが何の詳細なのか判断できません。

リンクテキストは、できるだけ具体的にしましょう。

• 悪い例：詳しくはこちら
• 良い例：Webアクセシビリティ診断の詳細を見る
• 悪い例：こちら
• 良い例：お問い合わせフォームへ進む
• 悪い例：PDF
• 良い例：会社案内PDFをダウンロードする

また、リンク先がPDF、外部サイト、新しいウィンドウで開くページの場合は、必要に応じてその情報も分かるようにしておくと親切です。

リンクは、Webサイト内の案内標識のようなものです。

利用者が迷わず目的のページへ移動できるように、リンクテキストだけを読んでも内容が分かる表現を意識しましょう。

6-7. PDFや添付資料も読める状態になっているか

Webアクセシビリティでは、HTMLページだけでなく、PDFや添付資料にも注意が必要です。

自治体、学校、病院、企業サイトでは、重要なお知らせ、申込書、募集要項、説明資料、チラシなどをPDFで掲載することがよくあります。

しかし、PDFの作り方によっては、スクリーンリーダーで読み上げられなかったり、文字検索ができなかったり、読み順が崩れたりすることがあります。

特に注意が必要なのは、紙の資料をスキャンしただけのPDFです。

見た目には文字が表示されていても、実際には画像として貼り付けられているだけの場合があります。この場合、支援技術では本文として読み取れないことがあります。

確認するときは、次の点を見てみましょう。

• PDF内の文字を選択・コピーできるか
• 文書の読み順が自然か
• 画像だけで重要な情報を伝えていないか
• 表の内容が理解しやすいか
• ファイル名が分かりやすいか
• PDFの内容と同等の情報をHTMLページにも掲載しているか

PDFを完全にアクセシブルにするには専門的な対応が必要な場合もあります。

そのため、重要な情報については、PDFだけで提供するのではなく、Webページ本文にも同じ内容を掲載することをおすすめします。

たとえば、イベント案内のチラシPDFを掲載する場合でも、日時、場所、対象者、参加費、申し込み方法、問い合わせ先などの重要情報は、HTML本文にも記載しておくとよいでしょう。

これは、スクリーンリーダー利用者だけでなく、スマートフォンで素早く情報を確認したい人、PDFを開きたくない人、検索エンジンやAIに内容を正しく伝えたい場合にも有効です。

Webアクセシビリティを考えるときは、「ページが見えるか」だけでなく、利用者が必要な情報を最後まで取得できるかを確認することが大切です。

7. Webアクセシビリティ検査の考え方

Webアクセシビリティに取り組むときは、まず現在のWebサイトにどのような問題があるのかを把握する必要があります。

そのために行うのが、Webアクセシビリティ検査です。

ただし、Webアクセシビリティ検査は、ツールで点数を出して終わりというものではありません。機械的に確認できる項目もあれば、人が実際に見たり操作したりしないと判断できない項目もあります。

大切なのは、機械検査と人による確認の役割を分けて考えることです。

7-1. 機械検査で分かること

機械検査とは、専用の検査ツールを使って、WebページのHTMLやCSS、コントラスト、代替テキスト、フォーム、見出し構造などを自動的に確認する方法です。

機械検査のメリットは、短時間で多くのページを確認できることです。人が1ページずつ確認すると時間がかかる内容でも、ツールを使えば一定のルールに基づいて効率よくチェックできます。

たとえば、機械検査では次のような項目を確認できます。

• 画像にalt属性があるか
• フォームの入力欄にラベルが関連付けられているか
• 見出し構造に不自然な飛びがないか
• 文字色と背景色のコントラストが不足していないか
• リンクやボタンに識別できる名前があるか
• HTMLの構文に問題がないか
• ARIA属性の使い方に誤りがないか
• ページタイトルが設定されているか

これらは、Webサイト全体の問題を把握するうえで非常に有効です。

特に、複数ページを持つ企業サイトや自治体サイト、学校サイト、病院サイトなどでは、機械検査によって共通テンプレートの問題を早期に見つけられます。

たとえば、ヘッダーのメニューにアクセシビリティ上の問題がある場合、その問題は多くのページに共通して発生している可能性があります。機械検査を使えば、こうした共通問題を効率よく発見できます。

また、修正後に再検査することで、問題が改善されたかどうかを確認しやすい点もメリットです。

機械検査は、Webアクセシビリティ対応の出発点として非常に役立ちます。

7-2. 機械検査だけでは分からないこと

一方で、機械検査だけではWebアクセシビリティのすべてを判断することはできません。

検査ツールは、HTMLやCSSなどのコードをもとに、一定のルールに合っているかどうかを確認します。しかし、その情報が本当に利用者にとって分かりやすいか、目的の操作を迷わず完了できるかまでは、機械だけでは判断しきれません。

たとえば、画像にalt属性があるかどうかは機械で確認できます。しかし、その代替テキストが画像の内容や目的を正しく説明しているかどうかは、人が判断する必要があります。

また、リンクテキストが設定されているかどうかは機械で分かっても、「詳しくはこちら」というリンクが文脈上分かりやすいか、同じ表現が複数あって混乱しないかは、人が確認しなければなりません。

機械検査だけでは判断しづらい項目には、次のようなものがあります。

• 代替テキストの内容が適切か
• 見出しがページ内容に合っているか
• リンクテキストだけで遷移先が分かるか
• 文章が分かりやすいか
• フォームの説明やエラー表示が利用者に伝わるか
• キーボード操作の順番が自然か
• モーダルやメニューを実際に操作できるか
• 動画の字幕が内容と合っているか
• PDFの読み順が自然か

つまり、機械検査は「問題の可能性」を見つけるのに向いていますが、「利用者にとって本当に使いやすいか」を最終判断するには、人の確認が必要です。

また、検査ツールによっては、問題がない箇所を指摘することもあります。反対に、実際には利用しづらい問題があるのに、ツール上では検出されないこともあります。

そのため、機械検査の結果をそのまま鵜呑みにするのではなく、内容を確認しながら判断することが大切です。

7-3. 人による目視確認・操作確認が必要な理由

Webアクセシビリティ検査では、人による目視確認や操作確認も重要です。

実際の利用者は、ページを読むだけでなく、メニューを開く、リンクをたどる、フォームを入力する、エラーを直す、PDFを開く、動画を見るなど、さまざまな行動を行います。

そのため、画面を見ながら、またはキーボードだけで操作しながら、利用者が目的を達成できるかを確認する必要があります。

人による確認では、次のような点を確認します。

• ページの内容が分かりやすく整理されているか
• 見出しだけを読んでも流れが分かるか
• 画像の説明が本文や代替テキストで補われているか
• リンク先やボタンの目的が分かるか
• キーボードだけで主要な操作ができるか
• フォーカスの移動順が自然か
• フォーム入力から送信完了まで迷わず進めるか
• エラー発生時に修正方法が分かるか
• スマートフォンでも読みやすく操作しやすいか

特に、キーボード操作の確認は重要です。

マウスを使わずにTabキーでページを移動し、リンク、ボタン、メニュー、フォームに順番にアクセスできるかを確認します。現在どこを選択しているのかが見えるか、途中で操作不能にならないか、モーダルウィンドウやメニューから抜け出せるかも確認します。

また、スマートフォンでの確認も欠かせません。

パソコンでは問題なく見えていても、スマートフォンでは文字が小さい、ボタンが押しにくい、フォームが入力しづらい、横スクロールが発生する、といった問題が出ることがあります。

Webアクセシビリティは、コードだけの問題ではなく、実際の利用体験の問題です。

そのため、機械検査とあわせて、人が実際に見て、操作して、理解できるかを確認することが必要です。

7-4. 検査結果を「直すべき問題」と「確認すべき問題」に分ける

Webアクセシビリティ検査を行うと、多くの指摘が出ることがあります。

そのときに大切なのは、すべての指摘を同じ重さで扱わないことです。

検査結果は、大きく分けると「直すべき問題」と「確認すべき問題」に整理できます。

「直すべき問題」とは、明らかにアクセシビリティ上の問題があり、修正が必要なものです。

たとえば、画像ボタンに代替テキストがなく何の操作か分からない、フォームの入力欄にラベルがない、文字と背景のコントラストが不足している、キーボードで操作できないボタンがある、といったものです。

一方で、「確認すべき問題」とは、機械検査では問題の可能性が示されているものの、実際に不適合かどうかは人が判断する必要があるものです。

たとえば、画像の代替テキストが短すぎる、リンクテキストが文脈上分かりにくい可能性がある、見出し構造が意図通りか確認が必要、動画に十分な説明があるか確認が必要、といったものです。

検査結果を整理するときは、次のように分類すると対応しやすくなります。

• 修正必須：明らかに利用を妨げている問題
• 要確認：人が内容を確認して判断する問題
• 改善推奨：必須ではないが、改善すると使いやすくなる問題
• 適用なし：対象ページには該当しない項目
• 対応済み：修正が完了した項目

このように分類することで、制作会社、運営担当者、発注者の間で認識を合わせやすくなります。

また、限られた予算や時間の中で対応する場合にも、優先順位をつけやすくなります。

まずは、問い合わせや申し込み、予約、購入、採用応募など、利用者の行動に直接関わるページから優先して確認しましょう。

そのうえで、共通テンプレート、ヘッダー、フッター、メニュー、フォーム、PDF、動画など、サイト全体に影響する部分を整理していくと効率的です。

Webアクセシビリティ検査は、問題を見つけて終わりではありません。

検査結果を正しく読み取り、優先順位をつけ、修正し、再検査することで、Webサイトの品質を継続的に高めていくことが大切です。

8. 「みんなのやさしいWEB診断」でできること

Webアクセシビリティに取り組むとき、まず必要になるのは「現在のWebサイトがどのような状態なのか」を知ることです。

しかし、JIS X 8341-3やWCAGの達成基準を一つひとつ読みながら確認するのは、専門知識がない方にとっては簡単ではありません。

そこで活用できるのが、Webアクセシビリティ検査ツール「みんなのやさしいWEB診断」です。

「みんなのやさしいWEB診断」は、Webサイトのアクセシビリティ上の問題を確認し、改善につなげるための検査サービスです。具体的な検査手順はQiitaの記事「「みんなのやさしいWEB診断」で行う、無料のWebアクセシビリティ検査の方法 〜AI時代にも求められるWebアクセシビリティ〜」にまとまっています。

ブラウザから検査対象のURLを入力することで、HTMLの構造、画像の代替テキスト、フォーム、リンク、コントラスト、ロービジョン環境での見え方などを確認できます。

また、検査結果を一覧で確認したり、レポートとして整理したりすることで、制作会社、Web担当者、発注者の間で課題を共有しやすくなります。

8-1. ブラウザで使えるWebアクセシビリティ検査

「みんなのやさしいWEB診断」は、専用ソフトをパソコンにインストールしなくても、ブラウザから利用できるWebアクセシビリティ検査サービスです。

検査したいWebページのURLを入力し、検査条件を選択することで、Webページに含まれるアクセシビリティ上の問題を確認できます。

ブラウザで使えるため、制作会社だけでなく、企業のWeb担当者、自治体や学校の広報担当者、サイト運営者なども利用しやすいのが特徴です。

たとえば、次のような場面で活用できます。

• 自社サイトのアクセシビリティ状況を把握したい
• リニューアル前に問題点を洗い出したい
• 公開前のページを確認したい
• フォームや問い合わせページに問題がないか確認したい
• 自治体・学校・病院・企業サイトの品質確認に使いたい
• 制作会社と発注者の間で検査結果を共有したい

Webアクセシビリティ検査は、専門家だけが行うものではありません。

もちろん、最終的な適合判定や詳細な確認には専門的な知識が必要ですが、まずはツールを使って問題の傾向を把握するだけでも、改善の第一歩になります。

特に、画像の代替テキスト漏れ、見出し構造の問題、フォームのラベル不足、コントラスト不足などは、検査ツールを使うことで発見しやすくなります。

「どこから確認すればよいか分からない」という場合は、まず主要なページを検査して、問題の多い箇所を把握することから始めるとよいでしょう。

8-2. JIS X 8341-3:2016・WCAG 2.1/2.2基準での確認

Webアクセシビリティを考えるうえで、基準となるのがJIS X 8341-3:2016やWCAGです。

JIS X 8341-3:2016は、日本国内でWebアクセシビリティ対応を進める際によく参照される規格です。公共機関や自治体のWebサイトでは、この規格に基づいて試験や対応方針の公開が行われることがあります。

一方、WCAGは国際的に使われているWebアクセシビリティのガイドラインです。WCAG 2.0、WCAG 2.1、WCAG 2.2と改定されており、現在のWeb利用環境に合わせて確認すべき項目が追加されています。

「みんなのやさしいWEB診断」では、これらの基準を意識しながら、Webページに含まれる問題を確認できます。

たとえば、次のような観点での確認が可能です。

• 画像に代替テキストが設定されているか
• 見出し構造が適切か
• フォームの入力欄にラベルがあるか
• リンクやボタンの目的が分かるか
• 文字色と背景色のコントラストが十分か
• 支援技術で解釈しづらいHTMLになっていないか
• キーボード操作やフォーカスに関わる問題がないか

ただし、ツールによる検査だけで、JIS X 8341-3やWCAGへの完全な適合を自動的に判断できるわけではありません。

Webアクセシビリティには、機械的に検出できる項目と、人が目視や操作で確認しなければならない項目があります。

そのため、「みんなのやさしいWEB診断」は、Webサイトの問題を見つけ、改善の優先順位を考えるための検査ツールとして活用するのが現実的です。

検査結果をもとに、明らかに修正が必要な問題、担当者が確認すべき問題、適用なしと判断できる項目などに整理していくことで、実際の改善作業につなげやすくなります。

8-3. HTMLチェックとロービジョンチェック

「みんなのやさしいWEB診断」では、WebページのHTML構造に関するチェックと、ロービジョン環境での見え方に関するチェックを行うことができます。

HTMLチェックでは、ページの構造や各要素の使い方を確認します。

たとえば、画像の代替テキスト、見出し構造、フォームのラベル、リンクやボタンの名前、HTMLの記述、ARIA属性の使い方など、支援技術がWebページを正しく理解するために重要な項目を確認します。

HTMLは、Webページの見た目を作るだけでなく、情報の意味を伝える役割を持っています。

見た目では問題がないように見えても、HTMLの構造が不適切だと、スクリーンリーダーや検索エンジン、AIがページ内容を正しく理解できない場合があります。

そのため、HTMLチェックはWebアクセシビリティ検査の基本になります。

一方、ロービジョンチェックでは、弱視の方や見えにくさのある方にとって、Webページがどのように見えるかを確認します。

文字と背景のコントラストが低い、文字が小さい、背景画像の上に文字が重なっていて読みにくい、色の違いだけで情報を伝えている、といった問題は、ロービジョン環境では大きな障壁になります。

ロービジョンチェックを行うことで、次のような問題に気づきやすくなります。

• 文字色と背景色のコントラストが不足している
• 薄いグレーの文字が読みづらい
• 画像の上に重ねた文字が背景に埋もれている
• ボタンやリンクの文字が見えにくい
• エラー表示や注意表示が色だけに頼っている
• 視認性の低いデザインになっている

HTMLチェックとロービジョンチェックは、それぞれ確認できる問題が異なります。

HTML構造の問題は、見た目だけでは気づきにくい場合があります。一方、見え方の問題は、コードだけでは分かりにくい場合があります。

そのため、両方の視点で確認することが重要です。

8-4. PDFアクセシビリティの簡易確認

Webサイトでは、HTMLページだけでなく、PDF資料が多く使われています。

自治体、学校、病院、企業サイトでは、申込書、案内資料、募集要項、チラシ、報告書、パンフレットなどをPDFで掲載することがよくあります。

しかし、PDFは作り方によってアクセシビリティに大きな差が出ます。

たとえば、紙の資料をスキャンしただけのPDFは、見た目には文字が表示されていても、実際には画像として扱われている場合があります。この場合、スクリーンリーダーで読み上げられなかったり、文字検索ができなかったりします。

また、PDF内の読み順が正しく設定されていないと、読み上げたときに内容の順番が崩れることがあります。表や段組みがあるPDFでは、見た目通りに意味が伝わらない場合もあります。

「みんなのやさしいWEB診断」では、PDFについても簡易的に確認し、アクセシビリティ上の問題に気づくきっかけを作ることができます。

確認したいポイントは、たとえば次のような内容です。

• PDF内の文字を選択・コピーできるか
• 画像だけのPDFになっていないか
• 文書タイトルや見出しが分かりやすいか
• 読み順が自然か
• 画像や図表の内容が説明されているか
• PDFだけでなくHTML本文にも重要情報が掲載されているか

PDFアクセシビリティを完全に確認・修正するには、専用ツールや専門的な作業が必要になることもあります。

そのため、まずは簡易確認を行い、重要なPDFから優先的に見直すことが現実的です。

特に、申し込み、手続き、防災、医療、採用、学校からのお知らせなど、多くの人に必要な情報は、PDFだけで提供するのではなく、Webページ本文にも同じ内容を掲載することをおすすめします。

8-5. AIコメント・レポート出力機能の活用

Webアクセシビリティ検査では、問題を見つけるだけでなく、その結果をどのように理解し、関係者に共有し、改善につなげるかが重要です。

検査結果には、専門的な用語や技術的な指摘が含まれることがあります。

たとえば、「代替テキストが不足しています」「フォームコントロールにラベルがありません」「コントラスト比が不足しています」「ARIA属性の指定に問題があります」といった指摘は、制作担当者には理解できても、発注者や一般のWeb担当者には分かりにくい場合があります。

そこで役立つのが、AIコメントやレポート出力機能です。

AIコメントを活用することで、検査結果の内容を分かりやすく説明したり、どのような対応が必要かを整理したりできます。

たとえば、専門的な指摘を次のように言い換えることができます。

• 画像の説明が不足しているため、読み上げソフトでは内容が伝わりにくい可能性があります。
• 入力欄の名前が正しく関連付けられていないため、何を入力すればよいか分かりにくい可能性があります。
• 文字色と背景色の差が小さいため、見えにくい環境では読みづらくなる可能性があります。
• リンクの目的が分かりにくいため、リンク先を判断しづらい可能性があります。

このように、技術的なエラーを利用者目線の説明に変えることで、関係者に課題を共有しやすくなります。

また、レポート出力機能を使えば、検査結果を記録として残すことができます。

レポートは、次のような場面で役立ちます。

• 社内でWebサイトの課題を共有する
• 制作会社に修正を依頼する
• 発注者に検査結果を説明する
• 修正前後の状態を比較する
• Webアクセシビリティ対応の記録を残す
• 今後の改善計画を立てる

Webアクセシビリティ対応は、一度検査して終わりではありません。

検査し、結果を理解し、優先順位をつけ、修正し、再検査するという流れを繰り返すことで、Webサイトの品質を高めていくことができます。

AIコメントやレポート出力機能は、その改善サイクルを分かりやすく進めるための補助として活用できます。

特に、Webアクセシビリティに初めて取り組む企業や団体では、専門用語をそのまま共有するのではなく、「利用者にどのような不便が起こるのか」「どのように直せばよいのか」を分かりやすく伝えることが大切です。

「みんなのやさしいWEB診断」は、単にエラーを見つけるためのツールではなく、Webサイトをより使いやすく改善していくための出発点として活用できます。

9. 実際に検査してみよう

ここからは、「みんなのやさしいWEB診断」を使って、実際にWebアクセシビリティ検査を行う流れを紹介します。

Webアクセシビリティ検査というと難しく感じるかもしれませんが、基本的な流れはシンプルです。

アカウントを作成し、検査したいページのURLを入力し、検査基準を選択して実行します。検査が完了すると、結果一覧から指摘内容を確認できます。

最初は、サイト全体を一度に検査しようとするのではなく、トップページ、問い合わせページ、採用ページ、サービス紹介ページなど、利用者にとって重要なページから確認していくとよいでしょう。

9-1. アカウント登録とログイン

まずは、「みんなのやさしいWEB診断」にアクセスし、アカウント登録を行います。

アカウント登録では、氏名、メールアドレス、パスワードなど、必要な情報を入力します。登録が完了すると、ログイン画面から管理画面へ入ることができます。

ログイン後は、検査の新規作成、過去の検査結果の確認、レポートの出力などを行うことができます。

複数のWebサイトを管理している場合は、サイトごと、案件ごと、クライアントごとに検査結果を整理しておくと、後から確認しやすくなります。

特に制作会社やWeb担当者が利用する場合は、検査対象のサイト名、検査日、検査したページ、対応状況などを記録しておくことをおすすめします。

9-2. 新規検査の開始

ログインしたら、新規検査を開始します。

管理画面の「新規検査」またはそれに該当するボタンから、検査作成画面へ進みます。

新規検査では、検査名や対象サイト、検査対象URL、検査規格などを設定します。

検査名は、後から見ても内容が分かるように付けておくと便利です。

たとえば、次のような名前にしておくと管理しやすくなります。

• 株式会社〇〇 コーポレートサイト トップページ検査
• 採用サイト 問い合わせフォーム検査
• 自治体サイト 主要ページ検査
• リニューアル前 アクセシビリティ確認
• 修正後 再検査

検査は一度だけで終わるものではありません。

最初の検査で問題点を把握し、修正後に再検査することで、改善状況を確認できます。

そのため、「初回検査」「修正後検査」「公開前検査」など、検査の目的が分かる名前にしておくと、後から比較しやすくなります。

9-3. 検査対象URLの入力

次に、検査したいWebページのURLを入力します。

検査対象URLには、実際に確認したいページのURLを入力します。

たとえば、トップページを検査する場合はトップページのURLを、問い合わせフォームを検査する場合は問い合わせページのURLを入力します。

Webアクセシビリティ検査では、どのページを検査するかが重要です。

トップページだけを検査して問題が少なかったとしても、問い合わせフォームや予約ページ、採用応募ページに問題がある場合があります。

そのため、次のようなページは優先的に検査することをおすすめします。

• トップページ
• サービス紹介ページ
• 問い合わせページ
• 資料請求ページ
• 予約ページ
• 採用情報ページ
• 採用応募フォーム
• 料金ページ
• よくある質問ページ
• 重要なお知らせページ

特に、フォームがあるページは必ず確認しましょう。

フォームは、入力欄、ラベル、必須項目、エラー表示、確認画面、送信ボタンなど、多くの要素が関係するため、アクセシビリティ上の問題が起きやすい部分です。

また、公開前のテスト環境を検査する場合は、外部からアクセスできるURLである必要があります。アクセス制限がある場合は、Basic認証などの情報を設定して検査します。

9-4. 検査規格の選択

検査対象URLを入力したら、検査規格を選択します。

Webアクセシビリティの検査では、JIS X 8341-3:2016やWCAG 2.1、WCAG 2.2などの基準をもとに確認します。

どの基準で確認するかは、Webサイトの目的や求められる対応レベルによって変わります。

公共機関や自治体サイトでは、JIS X 8341-3:2016に基づいた対応が求められることが多くあります。

企業サイトの場合でも、公共性の高い情報を扱うサイト、医療・福祉・教育・金融・採用などに関わるサイトでは、JISやWCAGを意識した確認を行うことが望ましいです。

また、近年はスマートフォン利用やフォーム操作、認知的な負担への配慮も重要になっているため、WCAG 2.1やWCAG 2.2の観点も参考になります。

最初に検査する場合は、いきなり完璧な適合を目指すというよりも、現在のサイトにどのような問題があるのかを把握することを目的にするとよいでしょう。

検査規格を選ぶ際には、次のように考えると整理しやすくなります。

• 公共サイトや自治体サイト：JIS X 8341-3:2016を中心に確認する
• 企業サイト：JIS X 8341-3:2016とWCAGの考え方を参考にする
• スマートフォン利用が多いサイト：WCAG 2.1/2.2の観点も確認する
• フォームや予約機能があるサイト：操作性やエラー表示を重点的に確認する
• リニューアル前後の比較：同じ基準で再検査する

検査規格は、単なる形式ではなく、どのような観点でWebサイトを確認するかを決めるものです。

目的に合った基準を選び、検査結果を改善につなげましょう。

9-5. Basic認証付きページの検査

公開前のテストサイトや開発中のページでは、Basic認証が設定されていることがあります。

Basic認証とは、Webページにアクセスする際に、ユーザー名とパスワードの入力を求める簡易的な認証のことです。

通常の検査ツールでは、Basic認証が設定されたページにアクセスできない場合があります。そのため、「みんなのやさしいWEB診断」でBasic認証付きページを検査する場合は、検査設定画面で認証情報を入力します。

入力する情報は、主に次の2つです。

• Basic認証のユーザー名
• Basic認証のパスワード

認証情報を設定することで、公開前のテスト環境や確認用ページも検査できるようになります。

これは、リニューアル前の確認や、公開前の品質チェックにとても便利です。

特に、Webアクセシビリティ対応は公開後に慌てて修正するよりも、公開前の段階で確認しておく方が効率的です。

公開後にフォームやメニュー、見出し構造の問題が見つかると、修正範囲が広くなったり、利用者に不便を与えたりする可能性があります。

そのため、テスト環境でBasic認証を設定している場合でも、検査できる状態にしておき、公開前に主要ページを確認することをおすすめします。

ただし、認証情報は重要な情報です。検査が終わった後に不要なアカウントを削除する、検査専用の一時的な認証情報を使うなど、セキュリティ面にも注意しましょう。

9-6. 検査完了通知と結果一覧の確認

検査を開始すると、対象ページの内容を取得し、HTMLチェックやロービジョンチェックなどが実行されます。

ページの内容や検査項目によっては、検査完了まで時間がかかる場合があります。

検査が完了すると、管理画面の結果一覧から検査結果を確認できます。必要に応じて、メールなどで検査完了通知を受け取ることもできます。

結果一覧では、検査したページごとに、指摘件数や確認が必要な項目、検査ステータスなどを確認します。

まずは、細かい指摘を一つずつ見る前に、全体の傾向を把握しましょう。

たとえば、次のような観点で確認すると整理しやすくなります。

• どのページに指摘が多いか
• 同じ種類の問題が複数ページで発生していないか
• フォームやメニューなど、重要な操作部分に問題がないか
• 画像の代替テキスト不足が多くないか
• コントラスト不足が多くないか
• HTML構造に共通の問題がないか

同じ指摘が多くのページで出ている場合は、共通テンプレートに問題がある可能性があります。

たとえば、ヘッダー、グローバルナビゲーション、フッター、共通ボタン、問い合わせフォームなどに問題があると、サイト全体に同じ指摘が出ることがあります。

このような場合は、個別ページを一つずつ直すよりも、共通部分を修正する方が効率的です。

検査結果を確認したら、次に行うべきことは、指摘内容を整理し、優先順位をつけることです。

すぐに修正すべき問題、担当者が内容を確認すべき問題、適用なしと判断できる項目、後日改善する項目に分けていくと、実際の改善作業につなげやすくなります。

Webアクセシビリティ検査は、結果を見ることが目的ではありません。

検査結果をもとに、Webサイトをより使いやすく改善していくことが大切です。

10. 検査結果の見方

Webアクセシビリティ検査を実行すると、HTMLチェック、ロービジョンチェック、PDFチェックなど、さまざまな検査結果が表示されます。

最初は指摘項目が多く見えて戸惑うかもしれませんが、すべてを一度に理解しようとする必要はありません。

まずは、どのページにどのような種類の問題があるのかを把握し、利用者への影響が大きいものから順番に確認していきましょう。

検査結果を見るときに大切なのは、単に「エラーの数」を見ることではありません。

その指摘が、実際に利用者の情報取得や操作を妨げているのか、どの程度優先して修正すべきなのかを判断することが重要です。

10-1. HTMLチェックの確認方法

HTMLチェックでは、Webページの構造やHTMLの記述に関する問題を確認します。

HTMLは、画面に表示される見た目を作るだけでなく、見出し、段落、リスト、表、リンク、ボタン、フォームなどの意味を伝える役割を持っています。

そのため、HTMLの構造に問題があると、スクリーンリーダーや検索エンジン、AIがページ内容を正しく理解しにくくなる場合があります。

HTMLチェックでよく確認する項目には、次のようなものがあります。

• 画像に適切なalt属性があるか
• 見出しタグの順序が適切か
• フォームの入力欄とラベルが関連付けられているか
• リンクやボタンの目的が分かる名前になっているか
• ページタイトルが設定されているか
• 表の見出しセルが適切に設定されているか
• ARIA属性の指定に誤りがないか
• HTMLの構文に大きな問題がないか

検査結果では、指摘内容、該当する達成基準、対象となるHTML要素、問題の種類などを確認します。

たとえば、「画像に代替テキストがありません」という指摘が出た場合は、その画像が装飾目的なのか、意味のある画像なのかを確認します。

意味のある画像であれば、内容や目的が伝わる代替テキストを追加します。装飾目的だけの画像であれば、空のalt=""を設定することで、読み上げ対象から外すことができます。

また、「フォームコントロールにラベルがありません」という指摘が出た場合は、入力欄に対して<label>が正しく関連付けられているかを確認します。

見た目では「お名前」「メールアドレス」と表示されていても、HTML上で入力欄とラベルが結びついていない場合、スクリーンリーダーでは何を入力する欄なのか分かりにくくなります。

HTMLチェックの結果を見るときは、「コードとして正しいか」だけでなく、「利用者に意味が伝わるか」を意識して確認することが大切です。

10-2. ロービジョンチェックの確認方法

ロービジョンチェックでは、弱視の方や見えにくさのある方にとって、Webページが読みやすい状態になっているかを確認します。

特に重要なのは、文字色と背景色のコントラスト、文字の大きさ、背景画像との重なり、色だけに頼った情報伝達などです。

ロービジョンチェックでよく確認する項目には、次のようなものがあります。

• 本文の文字と背景のコントラストが十分か
• ボタンやリンクの文字が読みやすいか
• 薄いグレーの文字が読みづらくなっていないか
• 画像の上に重ねた文字が背景に埋もれていないか
• エラー表示や注意表示が色だけに頼っていないか
• スマートフォン画面でも文字やボタンが見やすいか

たとえば、白に近い背景色に薄いグレーの文字を配置している場合、デザイン上はやわらかい印象になりますが、利用者によっては文字がほとんど読めないことがあります。

また、写真の上に白文字を重ねている場合、写真の明るい部分では文字が背景に埋もれてしまうことがあります。

ロービジョンチェックの結果では、どの要素で視認性の問題が起きているのかを確認し、必要に応じて文字色、背景色、文字サイズ、余白、背景画像の処理などを見直します。

注意したいのは、コントラストの問題は見た目の印象だけでは判断しにくいことです。

制作者や担当者には読めるように見えても、利用環境や視力、画面の明るさによっては読みづらい場合があります。

そのため、感覚だけで判断せず、検査結果やコントラスト比を確認しながら改善することが大切です。

10-3. 指摘箇所のHTMLを確認する

検査結果で問題が表示されたら、次に指摘箇所のHTMLを確認します。

指摘内容だけを読んでも、ページ内のどこに問題があるのか分かりにくい場合があります。そのため、対象となるHTML要素や該当箇所を確認し、実際のページ上のどの部分に対応しているのかを把握します。

たとえば、代替テキストの指摘であれば、該当する<img>要素を確認します。

<img src="banner.jpg" alt="">

この画像が単なる装飾であれば、空のalt=""で問題ない場合があります。

しかし、キャンペーン情報や申し込み案内など、重要な情報を含む画像であれば、内容が伝わる代替テキストを設定する必要があります。

<img src="banner.jpg" alt="Webアクセシビリティ無料相談受付中">

フォームの指摘であれば、入力欄とラベルが正しく関連付けられているかを確認します。

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

このように、labelのfor属性と、入力欄のid属性が対応していることで、入力欄の意味が支援技術にも伝わりやすくなります。

指摘箇所のHTMLを確認するときは、次の点を意識しましょう。

• 指摘されている要素がページ上のどこにあるか
• その要素は利用者にとって重要な情報か
• HTMLの意味と見た目の役割が一致しているか
• 支援技術でも内容や操作が伝わるか
• 共通テンプレートに含まれる問題か、個別ページの問題か

共通テンプレートに含まれる問題であれば、1箇所の修正で多くのページが改善されることがあります。

一方、記事本文や個別ページ内の画像、表、リンクなどは、ページごとに修正が必要になる場合があります。

10-4. スクリーンプレビューとハイライト表示を見る

検査結果を確認するときは、HTMLだけでなく、スクリーンプレビューやハイライト表示も活用しましょう。

HTMLコードだけを見ても、実際の画面上でどの部分に問題があるのか分かりにくい場合があります。

スクリーンプレビューを使うことで、指摘された箇所がページ内のどこに表示されているのかを視覚的に確認できます。

ハイライト表示では、問題のある箇所が画面上で強調表示されるため、修正対象を見つけやすくなります。

たとえば、次のような確認に役立ちます。

• コントラスト不足がどの文字で発生しているか
• 代替テキストが不足している画像がどこにあるか
• ラベル不足のフォーム項目がどこにあるか
• リンクやボタンの指摘がどの部分に対応しているか
• 共通ヘッダー・フッター内の問題か、本文内の問題か

特に、同じ種類の指摘が複数出ている場合は、スクリーンプレビューで場所を確認することで、修正の優先順位をつけやすくなります。

たとえば、本文中の小さな装飾画像よりも、問い合わせボタンやフォーム項目の問題の方が、利用者への影響が大きい場合があります。

また、ロービジョンチェックでは、実際にどの部分が見えにくくなっているのかを画面上で確認することが重要です。

コントラスト比の数値だけでは分かりにくい場合でも、プレビューを見ることで、背景画像と文字が重なって読みにくい、薄い文字が目立たない、ボタンの文字が見えづらいといった問題に気づきやすくなります。

検査結果を見るときは、指摘一覧、HTML、スクリーンプレビューをあわせて確認することで、問題の内容をより正確に理解できます。

10-5. 誤検知・適用なし・要確認を判断する

検査ツールの結果には、明らかに修正が必要なものだけでなく、誤検知や適用なし、要確認の項目も含まれることがあります。

そのため、検査結果に表示された指摘をすべて機械的に修正すればよいわけではありません。

たとえば、画像に空のalt=""が設定されている場合、ツールによっては確認対象として表示されることがあります。

その画像が装飾目的であれば、空のaltは適切な対応です。この場合は、修正ではなく「適用なし」または「問題なし」と判断できます。

一方で、同じ空のaltでも、その画像がバナー、図表、ボタン、重要なお知らせなどであれば、内容が伝わらないため修正が必要です。

このように、同じ指摘であっても、画像の役割によって判断が変わります。

検査結果を整理するときは、次のような分類を行うと対応しやすくなります。

• 修正必要：明らかにアクセシビリティ上の問題があり、修正すべきもの
• 要確認：人が内容や文脈を確認して判断する必要があるもの
• 適用なし：そのページや要素には該当しないもの
• 誤検知：ツール上は指摘されたが、実際には問題ではないもの
• 改善推奨：必須ではないが、改善するとより使いやすくなるもの

特に、代替テキスト、リンクテキスト、見出し構造、表の読みやすさ、動画の説明、PDFの読み順などは、人による確認が必要になりやすい項目です。

また、検査結果を判断するときは、利用者への影響を考えることが大切です。

問い合わせフォームが使えない、予約ボタンがキーボードで操作できない、重要なお知らせの画像に説明がない、といった問題は優先度が高くなります。

一方で、装飾画像や軽微な表現上の問題などは、他の重要な問題と比べて優先度を下げられる場合があります。

Webアクセシビリティ検査の目的は、指摘をゼロにすることだけではありません。

利用者が必要な情報にたどり着き、目的の操作を完了できるようにすることが本来の目的です。

そのため、検査結果を正しく読み取り、誤検知・適用なし・要確認を整理しながら、優先順位をつけて改善していきましょう。

11. 検査結果を改善につなげる

Webアクセシビリティ検査は、結果を確認して終わりではありません。

大切なのは、検査で見つかった問題を整理し、実際の改善作業につなげることです。

検査結果には、すぐに修正できるものもあれば、デザインやシステムの設計から見直す必要があるものもあります。また、制作会社、Web担当者、発注者の間で認識がずれていると、修正の優先順位が分からなくなったり、対応が後回しになったりすることがあります。

そのため、検査結果を改善につなげるには、問題の重要度を整理し、関係者で共有し、修正後に再検査する流れを作ることが重要です。

11-1. 優先順位をつけて修正する

検査結果を見ると、多くの指摘が表示されることがあります。

しかし、すべての指摘を同じ優先度で扱う必要はありません。

まずは、利用者が情報を取得したり、操作を完了したりするうえで影響が大きい問題から優先的に修正します。

特に優先度が高いのは、問い合わせ、予約、購入、資料請求、採用応募、ログインなど、利用者の目的達成に直接関わる部分です。

たとえば、次のような問題は優先して対応すべきです。

• 問い合わせフォームの入力欄にラベルがない
• エラーが出ても、どこを直せばよいか分からない
• 送信ボタンや予約ボタンがキーボードで操作できない
• 重要な画像に代替テキストがなく、内容が伝わらない
• 文字色と背景色のコントラストが低く、本文が読みにくい
• メニューをキーボードやスクリーンリーダーで操作しづらい
• PDFだけに重要情報が掲載されており、本文で確認できない

一方で、装飾画像の扱いや、利用者への影響が小さい軽微な問題は、他の重要な問題を修正した後に対応してもよい場合があります。

優先順位を考えるときは、次の3つの視点で整理すると分かりやすくなります。

• 影響度：利用者が情報を得られない、操作できないなどの大きな不便につながるか
• 発生範囲：1ページだけの問題か、サイト全体に共通する問題か
• 修正のしやすさ：すぐに直せるか、設計やシステム改修が必要か

たとえば、共通ヘッダーのメニューに問題がある場合、1箇所の修正で多くのページが改善される可能性があります。

また、フォームのエラー表示の改善は、問い合わせ数や申込完了率にも影響するため、ビジネス上も優先度が高い対応になります。

検査結果をそのまま一覧で眺めるのではなく、利用者への影響と修正効果を考えながら、対応順を決めましょう。

11-2. すぐ直せる問題と設計から見直す問題

Webアクセシビリティの問題には、比較的すぐに修正できるものと、設計段階から見直す必要があるものがあります。

すぐに直せる問題としては、画像の代替テキスト追加、リンクテキストの修正、見出し文言の調整、本文中の重要情報の追記、PDFと同じ内容をHTML本文に掲載することなどがあります。

たとえば、「詳しくはこちら」というリンクを「Webアクセシビリティ診断の詳細を見る」に変更するだけでも、リンク先の意味は分かりやすくなります。

また、画像だけで掲載していたイベント情報を本文にも記載すれば、スクリーンリーダー利用者や検索エンジン、AIにも内容が伝わりやすくなります。

比較的すぐに対応しやすいものには、次のような例があります。

• 画像に適切な代替テキストを追加する
• リンクテキストを具体的な表現に変える
• 見出しの文言や順序を整理する
• 注意書きやエラー内容を文章で補足する
• PDFの重要情報をHTML本文にも掲載する
• 薄すぎる文字色を読みやすい色に変更する

一方で、設計から見直す必要がある問題もあります。

たとえば、メニューがキーボードで操作できない、モーダルウィンドウから抜け出せない、フォームの構造が複雑すぎる、JavaScriptで作られた部品が支援技術に対応していない、といった問題は、見た目の修正だけでは解決できない場合があります。

設計から見直す必要があるものには、次のような例があります。

• キーボード操作できないナビゲーション
• スクリーンリーダーで状態が伝わらない開閉メニュー
• 入力しづらい予約フォームや申込フォーム
• フォーカスの移動順が不自然なページ構造
• ボタンではなくクリックイベントだけで作られた操作部品
• スマートフォンで操作しづらいUI設計
• 画像化された文字情報に依存したデザイン

このような問題は、HTML、CSS、JavaScript、CMSテンプレート、フォームシステムなどに関わるため、制作会社や開発担当者と相談しながら対応する必要があります。

改善作業では、「今すぐできる修正」と「次回リニューアルやシステム改修で対応する修正」を分けて考えると現実的です。

すべてを一度に完璧に直すことが難しい場合でも、優先度の高い問題から順番に改善していくことで、Webサイトの利用しやすさは着実に向上します。

11-3. 制作会社・担当者・発注者で共有すべきこと

Webアクセシビリティ対応は、制作会社だけ、あるいは発注者だけで完結するものではありません。

Webサイトを作る人、更新する人、運用する人、発注する人が、同じ認識を持って進めることが重要です。

検査結果を共有するときは、単に「エラーが何件あります」と伝えるだけでは不十分です。

その問題が利用者にどのような影響を与えるのか、どのページで発生しているのか、どの程度優先して直すべきなのかを整理して共有する必要があります。

関係者で共有したい内容には、次のようなものがあります。

• 検査したページと検査日
• 使用した検査基準や検査ツール
• 主な指摘内容
• 利用者への影響
• 修正の優先順位
• 担当者と対応期限
• すぐ対応する項目と後日対応する項目
• 再検査の予定

たとえば、「画像に代替テキストがありません」という指摘だけでは、発注者には重要度が伝わりにくい場合があります。

その場合は、「この画像にはキャンペーンの重要情報が含まれていますが、代替テキストがないため、読み上げソフトでは内容が伝わりません」と説明すると、問題の意味が理解しやすくなります。

また、「フォームのラベルが不足しています」という指摘も、「スクリーンリーダー利用者が、どの入力欄に何を入力すればよいか分かりにくくなる可能性があります」と説明すると、利用者への影響が明確になります。

制作会社は技術的な修正方針を示し、Web担当者はコンテンツや運用面の修正を行い、発注者は予算や優先順位を判断する必要があります。

それぞれの役割を整理することで、Webアクセシビリティ対応は進めやすくなります。

11-4. 修正後に再検査する

Webアクセシビリティ対応では、修正して終わりではなく、修正後に再検査することが重要です。

修正したつもりでも、別の問題が残っていたり、新しい問題が発生していたりする場合があります。

たとえば、代替テキストを追加しても内容が適切でなければ、利用者には十分に伝わりません。文字色を変更しても、背景とのコントラストがまだ不足している場合もあります。

また、フォームやメニューなどの修正では、見た目は改善されていても、キーボード操作やスクリーンリーダーでの確認が必要です。

再検査では、次の点を確認します。

• 修正対象の指摘が解消されているか
• 代替テキストやリンクテキストの内容が適切か
• コントラスト不足が改善されているか
• フォームのラベルやエラー表示が分かりやすいか
• キーボードだけで操作できるか
• 修正によって新たな問題が発生していないか
• スマートフォンでも問題なく操作できるか

再検査の結果は、初回検査の結果と比較できるように記録しておくと便利です。

どの問題が改善されたのか、どの問題が残っているのか、次に対応すべき項目は何かを整理できます。

また、Webアクセシビリティは一度対応すれば終わりではありません。

新しいページを追加したり、バナーを差し替えたり、PDFを掲載したり、フォームを変更したりするたびに、新たな問題が発生する可能性があります。

そのため、定期的に検査する仕組みを作ることも大切です。

たとえば、次のようなタイミングで確認するとよいでしょう。

• サイトリニューアル前後
• 新しいフォームを公開する前
• 重要なページを追加したとき
• PDFや動画を大量に掲載したとき
• デザインテンプレートを変更したとき
• 年に1回の定期点検

検査、修正、再検査を繰り返すことで、Webサイトのアクセシビリティは少しずつ向上します。

Webアクセシビリティ対応は、単発の作業ではなく、Webサイトをよりよく運用していくための継続的な改善活動として考えましょう。

12. 検査結果表・レポートを作成する

Webアクセシビリティ検査を行った後は、検査結果を整理し、関係者が確認しやすい形にまとめることが大切です。

検査ツールの画面上で指摘を確認するだけでは、どの問題に対応したのか、どの項目が未対応なのか、どのページで問題が発生しているのかを後から把握しにくくなります。

そのため、検査結果表やレポートを作成し、対応状況を記録しておくことをおすすめします。

検査結果表は、制作会社、Web担当者、発注者の間で課題を共有するためにも役立ちます。また、修正前後の比較や、将来的な再検査の記録としても活用できます。

12-1. 適合・不適合・適用なし・対応予定を整理する

Webアクセシビリティの検査結果を整理するときは、各項目を「適合」「不適合」「適用なし」「対応予定」などに分類します。

この分類を行うことで、どの項目が問題なく対応できているのか、どの項目に改善が必要なのか、どの項目は対象外なのかを明確にできます。

一般的には、次のような分類を使うと整理しやすくなります。

• 適合：基準を満たしている項目
• 不適合：基準を満たしておらず、修正が必要な項目
• 適用なし：対象ページや対象コンテンツには該当しない項目
• 要確認：機械検査だけでは判断できず、人による確認が必要な項目
• 対応予定：現在は不適合だが、今後修正予定の項目
• 対応済み：修正が完了し、再検査で改善を確認した項目

たとえば、動画が掲載されていないページでは、字幕や音声解説に関する項目は「適用なし」と判断できます。

一方、画像に代替テキストがない場合でも、その画像が装飾目的であり、空のalt=""が適切に設定されていれば、問題なしと判断できる場合があります。

重要なのは、検査ツールの結果をそのまま機械的に転記するのではなく、ページの内容や利用者への影響を確認したうえで判断することです。

検査結果表には、判定だけでなく、判断理由や対応方針も記載しておくと、後から見返したときに分かりやすくなります。

項目	判定	内容	対応方針
画像の代替テキスト	不適合	キャンペーンバナーに代替テキストが設定されていない	画像の内容が伝わる代替テキストを追加する
動画の字幕	適用なし	対象ページに動画コンテンツがない	対応不要
フォームのラベル	対応予定	メールアドレス欄とラベルがHTML上で関連付けられていない	次回改修でlabel要素を修正する

このように整理しておくと、技術担当者だけでなく、発注者や社内担当者にも状況を共有しやすくなります。

12-2. ページ単位の検査結果表を作成する

Webアクセシビリティ検査では、ページ単位で結果を整理することが重要です。

同じWebサイト内でも、トップページ、サービス紹介ページ、問い合わせフォーム、採用ページ、PDF掲載ページなど、ページによって問題の種類は異なります。

そのため、検査結果表では、どのページでどのような問題が発生しているのかを分かるようにします。

ページ単位の検査結果表には、次のような項目を入れると整理しやすくなります。

• 検査対象ページ名
• URL
• 検査日
• 検査基準
• 主な指摘内容
• 判定
• 修正担当者
• 対応期限
• 対応状況
• 再検査日

たとえば、問い合わせページであれば、フォームのラベル、エラー表示、必須項目の示し方、送信ボタンの操作性などを重点的に確認します。

採用ページであれば、募集要項の表、エントリーボタン、PDF資料、動画コンテンツなどを確認します。

トップページであれば、メインビジュアル、ナビゲーション、見出し構造、リンク、バナー画像などを確認します。

ページ名	URL	主な指摘	優先度	対応状況
トップページ	https://example.com/	メインビジュアル画像の代替テキスト不足	中	対応予定
お問い合わせ	https://example.com/contact/	入力欄とラベルの関連付け不足	高	修正中
採用情報	https://example.com/recruit/	PDF募集要項の読み取り確認が必要	中	要確認

ページ単位で整理することで、どこから修正すべきかが分かりやすくなります。

特に、問い合わせ、予約、購入、採用応募など、利用者の行動に直結するページは優先して確認・修正しましょう。

12-3. サイト全体の検査結果表を作成する

ページ単位の検査結果に加えて、サイト全体の傾向をまとめた検査結果表も作成しておくと便利です。

サイト全体の検査結果表では、個別ページの細かい指摘だけでなく、共通して発生している問題や、優先的に改善すべき領域を整理します。

たとえば、複数ページで同じような指摘が出ている場合、共通テンプレートやCMSの部品に問題がある可能性があります。

ヘッダー、フッター、グローバルナビゲーション、パンくずリスト、共通ボタン、フォーム部品などに問題がある場合、1箇所の修正で多くのページを改善できることがあります。

サイト全体の検査結果表では、次のような観点で整理します。

• サイト全体で多い指摘は何か
• 共通テンプレートに起因する問題はあるか
• フォーム関連の問題はどの程度あるか
• コントラスト不足が多いデザイン要素はあるか
• PDFや動画など、HTML以外の課題はあるか
• 優先して対応すべきページ群はどこか
• 短期対応と中長期対応に分けられるか

分類	主な問題	影響範囲	優先度	対応方針
共通テンプレート	ナビゲーションのキーボード操作に課題	全ページ	高	メニュー部品を改修する
画像	バナー画像の代替テキスト不足	複数ページ	中	重要画像から順に代替テキストを追加する
PDF	申込書PDFの読み取り確認が必要	資料掲載ページ	中	重要情報をHTML本文にも掲載する

このようにサイト全体で整理すると、単なるエラー一覧ではなく、改善計画として使える資料になります。

また、予算やスケジュールを検討する際にも、短期的に対応するもの、中長期的に対応するものを分けて説明しやすくなります。

12-4. 公開用レポートとして使う場合の注意点

Webアクセシビリティ検査の結果は、社内や関係者向けの資料として使う場合と、Webサイト上で公開するレポートとして使う場合があります。

公開用レポートとして使う場合は、特に注意が必要です。

検査ツールの結果をそのまま掲載するだけでは、利用者にとって分かりにくかったり、実際の対応状況とずれたりする可能性があります。

公開用レポートでは、次のような情報を整理して記載します。

• 対象となるWebサイト名
• 対象範囲
• 検査したページ
• 検査日
• 検査に用いた基準
• 達成等級や対応方針
• 適合・不適合の概要
• 今後の対応予定
• 問い合わせ先

特に重要なのは、検査対象範囲を明確にすることです。

Webサイト全体を検査したのか、一部の代表ページだけを検査したのか、PDFや動画を含めたのか、外部サービスのフォームを含めたのかを明記する必要があります。

対象範囲が曖昧なまま「アクセシビリティ対応済み」と表現すると、誤解を招く可能性があります。

また、「完全対応」「すべての人が問題なく利用できます」といった断定的な表現は避けた方がよいでしょう。

Webアクセシビリティは、利用環境や支援技術、コンテンツの更新状況によって変わるため、継続的な改善が必要です。

公開用レポートでは、現在の対応状況と、今後の改善方針を正直に示すことが大切です。

たとえば、次のような表現が考えられます。

• 当サイトでは、JIS X 8341-3:2016を参考に、Webアクセシビリティの向上に取り組んでいます。
• 主要ページを対象に検査を行い、確認された課題について順次改善を進めています。
• 一部のPDF資料や外部サービスについては、今後の改善課題として対応を検討しています。
• ご利用にあたり不便な点がありましたら、お問い合わせ窓口までご連絡ください。

公開用レポートは、単なる検査結果の発表ではなく、利用者に対して「Webアクセシビリティに取り組んでいる姿勢」を示すものでもあります。

そのため、できていることだけでなく、現在の課題や今後の対応予定も含めて、分かりやすく伝えることが重要です。

検査結果表やレポートを適切に作成することで、Webアクセシビリティ対応は一時的な作業ではなく、継続的な改善活動として管理しやすくなります。

13. Webアクセシビリティ対応を継続するために

Webアクセシビリティ対応は、サイト制作時やリニューアル時に一度確認すれば終わりというものではありません。

Webサイトは、公開後もお知らせ、ブログ記事、採用情報、イベント情報、PDF資料、画像バナー、動画、フォームなどが追加・更新されていきます。

最初にアクセシビリティへ配慮して作ったWebサイトでも、日々の更新の中で画像に代替テキストが入っていなかったり、PDFだけで重要情報を掲載したり、見出し構造が崩れたりすることで、少しずつ使いにくくなってしまうことがあります。

そのため、Webアクセシビリティは「制作時の品質」だけでなく、「運用時の品質」として考えることが重要です。

13-1. リニューアル時だけでなく、日々の更新でも注意する

Webアクセシビリティ対応というと、サイトリニューアルのときにまとめて行うものだと考えられがちです。

もちろん、リニューアル時は、HTML構造、デザイン、配色、フォーム、ナビゲーション、CMSテンプレートなどを見直す大きな機会です。

しかし、実際にアクセシビリティの問題が起こりやすいのは、公開後の日々の更新作業です。

たとえば、次のような更新で問題が発生することがあります。

• お知らせ記事に画像だけで重要情報を掲載する
• チラシPDFだけを掲載し、本文に概要を書かない
• 画像の代替テキストを空欄のままにする
• 見出しを文字サイズ調整の目的で使ってしまう
• リンクテキストが「こちら」「詳しくはこちら」ばかりになる
• 表を見た目優先で作り、読み順が分かりにくくなる
• 動画を掲載するが、字幕やテキスト説明を用意しない

こうした問題は、制作会社ではなく、日々CMSを更新する担当者によって発生することも少なくありません。

そのため、Webアクセシビリティを維持するには、サイトを作る人だけでなく、更新する人にも基本的な知識が必要です。

特に、自治体、学校、病院、企業の採用サイトなど、頻繁に情報を更新するWebサイトでは、日々の運用ルールを整えておくことが重要です。

13-2. 広報・総務・採用担当者にも必要な知識

Webアクセシビリティは、Web制作会社やシステム担当者だけが理解していればよいものではありません。

実際のWebサイト運用では、広報担当者、総務担当者、採用担当者、各部署の情報発信担当者など、さまざまな人がコンテンツを作成・更新します。

たとえば、広報担当者はイベント告知やニュースリリースを掲載します。総務担当者は各種案内や申請書類を掲載します。採用担当者は募集要項、説明会情報、エントリーフォームへの導線を更新します。

これらの情報は、利用者にとって重要なものです。

そのため、担当者が次のような基本を理解しておくことが大切です。

• 画像だけで重要な情報を伝えない
• 画像を掲載するときは代替テキストを設定する
• PDFだけでなく、HTML本文にも重要情報を書く
• 見出しは文書構造に合わせて使う
• リンクテキストは具体的に書く
• 表はできるだけ分かりやすく整理する
• 動画には字幕や説明文を付ける
• フォームの入力項目やエラー表示を分かりやすくする

これらは専門的なプログラミング知識がなくても、日々の更新で意識できる内容です。

Webアクセシビリティは、専門家だけが対応する特別な作業ではなく、情報を発信する人すべてに関係する基本姿勢です。

社内や組織内で簡単な研修を行ったり、更新担当者向けのチェックリストを用意したりすることで、公開後のアクセシビリティ低下を防ぎやすくなります。

13-3. CMS更新時に起こりやすいアクセシビリティ低下

WordPress、baserCMS、Movable Type、独自CMSなどを使っているWebサイトでは、管理画面から簡単にページを更新できます。

これは便利な一方で、更新担当者の操作によってアクセシビリティが低下することもあります。

CMS更新時に起こりやすい問題には、次のようなものがあります。

• 見出しの順序が崩れる
• 本文中に空の見出しが入る
• 画像の代替テキストが未設定になる
• 画像内の文字だけで情報を伝える
• 表をレイアウト目的で使う
• 文字色や背景色を手動で変更してコントラストが不足する
• リンクテキストが曖昧になる
• PDFファイル名が分かりにくい
• 外部サービスの埋め込みが操作しづらい

たとえば、本文中で見出しを使うときに、見た目を大きくしたいという理由だけで<h2>や<h3>を使うと、ページ全体の構造が崩れてしまいます。

また、チラシ画像をそのまま貼り付け、本文に日時や場所を書かない場合、画像を見られない人には情報が伝わりません。

PDFを掲載するときも、「file.pdf」「scan001.pdf」のようなファイル名では内容が分かりにくくなります。リンクテキストも「PDFはこちら」ではなく、「イベント案内PDFをダウンロードする」のように具体的に書く方が分かりやすくなります。

CMSの管理画面で入力しやすいようにしておくことも重要です。

たとえば、画像登録時に代替テキスト欄を用意する、見出しの使い方をマニュアル化する、PDF掲載時に本文概要を必須にする、といった仕組みを作ることで、更新時のミスを減らせます。

CMSを使っている場合は、制作時だけでなく、運用画面や更新フローも含めてアクセシビリティを考えましょう。

13-4. 運用ルールとチェックリストを作る

Webアクセシビリティ対応を継続するためには、担当者の注意だけに頼るのではなく、運用ルールとチェックリストを作ることが有効です。

ルールがないまま更新を続けると、担当者によって判断が変わったり、忙しいときに確認が抜けたりします。

一方で、最低限のチェック項目を決めておけば、専門知識が深くない担当者でも、公開前に確認しやすくなります。

たとえば、記事やお知らせを公開する前に、次のような項目を確認します。

• ページタイトルは内容を表しているか
• 見出しの順序は自然か
• 画像に必要な代替テキストが入っているか
• 画像だけで重要情報を伝えていないか
• リンクテキストは具体的か
• PDFを掲載する場合、本文にも概要を書いているか
• 表の内容は分かりやすいか
• 文字色や装飾で読みにくくなっていないか
• スマートフォンで表示確認したか
• 問い合わせ先や申し込み方法が分かりやすいか

また、定期的な検査のタイミングも決めておくとよいでしょう。

たとえば、重要ページは半年に1回、サイト全体は年に1回、フォームやテンプレートを変更したときはその都度確認する、といった運用が考えられます。

チェックリストは、最初から完璧なものを作る必要はありません。

まずは、画像、見出し、リンク、PDF、フォーム、スマートフォン表示など、基本的な項目から始めるだけでも効果があります。

Webアクセシビリティ対応を継続するには、「担当者の善意」ではなく、「確認しやすい仕組み」を作ることが大切です。

運用ルールとチェックリストを整えることで、Webサイトの品質を長く保ちやすくなります。

14. まとめ：AI時代のWebサイト品質としてアクセシビリティを考える

Webアクセシビリティは、障害のある人だけのための特別な対応ではありません。

高齢者、スマートフォン利用者、一時的にけがをしている人、音声を聞けない環境にいる人、長い文章を読むのが苦手な人など、さまざまな利用者に関係するWebサイトの基本品質です。

また、2024年の障害者差別解消法改正により、民間事業者にも合理的配慮の提供が義務化されました。Webサイトそのものが直ちにすべて義務化されたという単純な話ではありませんが、企業や団体がWebを通じて情報提供や申し込み受付を行う以上、誰もが利用しやすい状態を目指すことはますます重要になっています。

さらに、AIの進化によって、Webサイトの情報は人だけでなく、AIにも読み取られ、要約され、音声で案内される時代になっています。

AIが情報を正しく理解するためには、見出し構造、代替テキスト、フォームのラベル、リンクテキスト、セマンティックHTMLなどが適切に整えられている必要があります。

つまり、アクセシビリティに配慮されたWebサイトは、人にとって使いやすいだけでなく、検索エンジンやAIにも理解されやすいWebサイトです。

Webアクセシビリティ対応では、まず基本的な項目から確認することが大切です。

• 見出し構造は正しいか
• 画像に適切な代替テキストがあるか
• 文字色と背景色のコントラストは十分か
• キーボードだけで操作できるか
• フォームのラベルやエラー表示は分かりやすいか
• リンクテキストだけで遷移先が分かるか
• PDFや動画、SNS投稿にも配慮できているか

そして、検査ツールを使って問題を見つけ、機械検査だけでは判断できない部分は人が確認し、優先順位をつけて改善していきます。

Webアクセシビリティは、1回の検査や1回の修正で完了するものではありません。

サイトリニューアル時だけでなく、日々の更新、PDF掲載、画像追加、フォーム変更、動画公開など、運用の中で継続的に意識する必要があります。

AI時代のWebサイトでは、「見た目がきれい」「情報が多い」だけでは十分ではありません。

誰にでも伝わり、誰でも操作しやすく、AIにも正しく理解されるWebサイトであることが、これからのWeb品質として重要になります。

Webアクセシビリティは、利用者のための配慮であると同時に、企業や団体の信頼性を高める取り組みでもあります。

まずは、自社サイトの現状を確認することから始めてみましょう。

小さな改善を積み重ねることで、より多くの人に情報が届き、使いやすく、信頼されるWebサイトに近づけることができます。