Webアクセシビリティ対応の現実味

Webアクセシビリティ対応の現実味

日本のWebアクセシビリティ基準であるJIS X 8341-3は、これまでWCAG 2.0相当の内容をもとに運用されてきました。しかし国際的にはWCAG 2.2への更新が進んでおり、それに合わせて日本のJISも改正に向けた検討が始まっています。 今すぐすべてのサイトが新基準に対応しなければならない、という話ではありませんが、今後のWeb制作・運用では、WCAG 2.2を意識したアクセシビリティ対応がより重要になっていくと考えられます。

ウェブアクセシビリティ基盤委員会（WAIC）は、JIS X 8341-3の改正原案について、ISO/IEC 40500:2025との一致規格とする方針を示しており、WCAG 2.2や日本語テキストの扱いなどが論点になっています。(ウェブアクセシビリティ基盤委員会（WAIC）)

つまり、実務側としては「まだ正式改正前だから関係ない」ではなく、いま作る・改修するサイトでは、WCAG 2.2を意識しておく方が後戻りが少ない、という見方ができます。

特に中小企業サイトや一般的なコーポレートサイトの制作・運用では、いきなりJIS適合レベルAAの達成や適合宣言を目指すよりも、日々の更新や改修の中で対応できる部分から見直していくことが、現場に合った進め方になります。

まず押さえたい視点

Webアクセシビリティ対応で誤解されやすいのは、利用者が全員同じ見え方・同じ操作方法でサイトを見ていると思ってしまうことです。

実際には、視覚に障害のある人は、画面を目で読むのではなく、スクリーンリーダーなどの支援技術で内容を音声化して利用することがあります。弱視の人は、画面拡大や高コントラスト設定を使うことがあります。手や腕を自由に動かしにくい人は、マウスではなくキーボードだけで操作することがあります。高齢者や一時的にけがをしている人、スマートフォンの小さな画面で操作している人にとっても、同じ配慮が役立つ場面があります。

WCAG 2.2自体も、視覚・聴覚・運動・認知・学習など、幅広い障害や利用状況を対象にしており、アクセシビリティ対応は結果的に一般ユーザーの使いやすさも高める、と説明しています。(W3C)

いまから実務で役立つ、後戻りの少ない対応

フォームのラベルと autocomplete 属性

フォームでは、まず 入力欄が何のためのものかを機械的に分かる状態にすることが重要です。

見た目上は「お名前」「メールアドレス」と入力欄の近くに書いてあっても、それが label として正しく関連付けられていなければ、スクリーンリーダーでは入力欄にフォーカスしたときに意味が伝わりにくくなります。

たとえば、次のような状態です。

<label for="name">お名前</label>
<input id="name" name="name" type="text" autocomplete="name">

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

このように label と input を for / id で関連付けると、スクリーンリーダー利用者にも「これは何を入力する欄か」が伝わりやすくなります。

また、autocomplete 属性は単なる入力補助ではありません。氏名、メールアドレス、電話番号、郵便番号、住所などをブラウザや支援技術が理解しやすくなり、入力の負担を減らせます。WCAG 2.2でも、入力欄の目的をプログラムが解釈できるようにする観点が含まれています。(W3C)

特に問い合わせフォームや申し込みフォームで重要です。フォームはCVに直結することが多いので、アクセシビリティ対応であると同時に、離脱防止にもなります。

ボタンやアイコンのコントラスト

テキストのコントラストだけでなく、ボタンの枠線、アイコン、入力欄の境界線、チェックボックス、ラジオボタン、フォーカス表示なども見えやすくする必要があります。

たとえば、淡いグレーの枠線だけで入力欄を表現している場合、視力が弱い人や明るい屋外でスマートフォンを見ている人には、どこが入力欄なのか分かりにくくなります。

WCAGでは、意味のある視覚的な手がかりについて、背景との十分なコントラストを求めています。非テキストのコントラストでは、重要なUI部品やグラフィックが背景に埋もれないことが求められます。(W3C)

実務で見落としやすいのは、次のようなものです。

  • 白背景に薄いグレーのアイコン
  • 境界線のない淡色ボタン
  • hover時だけ色が変わるが、キーボードフォーカスでは分からないボタン
  • エラー時に赤枠だけで知らせている入力欄
  • SVGアイコンに代替テキストやラベルがない状態

特にアイコンボタンは注意が必要です。虫眼鏡アイコンだけの検索ボタン、三本線のメニューボタン、×ボタンなどは、見た目では分かっても、スクリーンリーダーには「ボタン」としか読まれないことがあります。

<button type="button" aria-label="メニューを開く">
  <svg aria-hidden="true">...</svg>
</button>

このように、見た目のアイコンとは別に、機械が読める名前を持たせる必要があります。

キーボード操作

キーボード操作を確保することも、実務上とても重要です。

アクセシビリティというとスクリーンリーダーを想像しがちですが、実際には マウスを使わず、Tabキー、Enterキー、Spaceキー、矢印キーなどで操作する利用者もいます。手や腕に障害がある人だけでなく、一時的なけが、ノートPC操作、支援デバイス利用なども含まれます。

確認すべきことはシンプルです。

  • Tabキーで操作対象に順番に移動できるか
  • 現在どこにフォーカスしているか視覚的に分かるか
  • EnterキーやSpaceキーでボタンを実行できるか
  • モーダルを開いたあと、フォーカスがモーダル外に抜けないか
  • メニューやアコーディオンをキーボードで開閉できるか
  • display:none ではないが見えないリンクにフォーカスが当たらないか
  • カルーセルやスライダーがキーボード操作を妨げないか

WCAG 2.2では、フォーカスが他の要素に隠されないことや、フォーカス表示に関する項目も追加されています。新しい達成基準には、Focus Not Obscured、Target Size、Dragging Movementsなどが含まれており、現在のUI実装にかなり関係します。(W3C)

実務上で特に危険なのは、デザインで outline: none; を指定してしまっているケース。 フォーカスリングがデザイン上邪魔に見えるから消す、という対応は避けるべきです。消すなら、代わりに十分見える独自のフォーカススタイルを用意する必要があります。

:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

見た目を整えることと、操作できることは両立できます。

エラー表示のわかりやすさ

フォームのエラー表示では、単に赤くするだけでは不十分です。

色だけでエラーを示すと、色の違いが分かりにくい人には伝わりません。また、スクリーンリーダー利用者には、どの入力欄で何が問題なのかが分からない場合があります。

望ましいのは、次のような形です。

<label for="email">メールアドレス</label>
<input
  id="email"
  name="email"
  type="email"
  autocomplete="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">メールアドレスの形式で入力してください。</p>

ポイントは、エラーが起きたこと、どの項目に問題があるか、どう直せばよいかを明示することです。

悪い例は、

入力内容に誤りがあります。

だけで終わる表示です。 これでは、利用者はどこを直せばよいか分かりません。

より良い例は、

メールアドレスの形式で入力してください。例：example@example.com

のように、修正方法まで示す形です。

また、送信後にページ上部へエラー一覧を出す場合は、各エラーから該当入力欄へ移動できるリンクを付けると親切です。スクリーンリーダーやキーボード操作でも修正しやすくなります。

WCAG 2.2では、認証や重複入力の負担を減らす項目も追加されています。たとえば、一度入力した内容を同じプロセス内で再入力させない、認証で過度に記憶や認知テストを求めない、といった方向です。(W3C)

つまり、フォーム改善は「特定の利用者だけへの対応」というより、入力ミスを減らし、問い合わせ完了までの負担を下げる改善として捉えた方が現場には伝わりやすいです。

PDFや画像内文字の扱い

自治体、学校、医療機関、士業、製造業、協会サイトなどでは、今でもPDFが多用されます。チラシ、申込書、案内文、料金表、仕様書、報告書などをPDFで掲載すること自体は珍しくありません。

問題は、PDFや画像の中にしか情報がない状態です。

たとえば、次のようなケースです。

  • イベント案内が画像1枚だけ
  • 料金表が画像化されたPDFだけ
  • スキャンした紙資料のPDFだけ
  • 重要なお知らせがバナー画像内の文字だけ
  • 申込方法がチラシPDFの中にしか書かれていない

この場合、スクリーンリーダーでは内容を読めない、検索に引っかかりにくい、スマートフォンで拡大しないと読めない、コピーできない、翻訳しにくい、といった問題が起きます。

もちろん、PDFを完全になくす必要はありません。現実的には、PDFが必要な業務も多いです。 ただし、重要情報はHTML本文にも載せておくと、より多くの利用環境で伝わりやすくなります。

たとえばイベント告知なら、PDFチラシを掲載しつつ、ページ本文にも以下をテキストで書く。

  • イベント名
  • 開催日時
  • 会場
  • 対象者
  • 参加費
  • 申込方法
  • 問い合わせ先
  • 締切
  • 注意事項

画像バナーを使う場合も、画像内文字に頼り切らず、同じ情報を近くのHTMLテキストとして置く。これはアクセシビリティだけでなく、SEOやAI検索、サイト内検索、スマホ閲覧にも効きます。

画像の alt についても、単に「チラシ画像」とするのではなく、その画像が伝えている意味に応じて考える必要があります。ただし、画像内の長文を全部 alt に詰め込むより、本文側にテキスト化する方が実務上は扱いやすいです。

まとめ

Webアクセシビリティ対応は、特殊な人のための特別対応ではなく、さまざまな利用環境で“情報にたどり着ける・操作できる・間違えても戻れる”状態を作ることです。

JIS X 8341-3の改正検討やWCAG 2.2への流れを見ると、Webアクセシビリティ対応は今後ますます重要になります。ただし、最初からすべてを完璧に満たそうとすると、現場では負担が大きくなります。まずは問い合わせフォーム、ボタン、ナビゲーション、PDF・画像内文字など、利用者がつまずきやすい部分から見直すことが現実的です。

特に中小企業サイトや一般的なコーポレートサイトなら、いきなり「JIS適合レベルAAを完全達成」と考えるより、まずは次のような点から見直す方が現実的です。

  • フォームの項目名が分かり、入力しやすい
  • キーボードだけでも主要導線を操作できる
  • ボタンやリンクが見分けられる
  • エラー時に何を直せばよいか分かる
  • PDFや画像だけに重要情報を閉じ込めない

アクセシビリティ対応は、特別な機能を後から追加することではありません。HTMLを正しく書く、入力しやすいフォームにする、キーボードでも操作できるようにする、画像やPDFだけに情報を閉じ込めない。こうした基本的な積み重ねが、結果として多くの人にとって使いやすいWebサイトにつながります。

JIS X 8341-3の改正検討は、Web制作や運用の現場にとって、アクセシビリティを「余裕があれば対応するもの」から「最初から考えておくべき品質要件」へ見直すきっかけになると言えます。

このブログの人気の投稿

WordPressプラグインのサプライチェーン攻撃から考える、日々のセキュリティ運用

イメージ
WordPressサイトの安全性を保つうえで、WordPress本体だけでなく、プラグインの更新はとても重要です。 しかし近年、単に「更新していれば安全」とは言い切れない事例も出てきています。 その一つが、2026年4月に報告されたWordPressプラグインのサプライチェーン攻撃です。 何が起きたのか 今回の事例では、もともと正規に公開されていた複数のWordPressプラグインが、第三者に買収された後、不正なコードを含む状態に変更されていたと報告されています。 対象となったのは、Essential Plugin系の30件以上のプラグインです。 これらのプラグインは以前からWordPress.orgで公開され、多くのサイトで利用されていたものですが、事業・プラグイン群が売却された後、新しい所有者によって不正な処理が仕込まれたとされています。Anchor Hostの記事では、30件以上のプラグインが影響を受け、31件がWordPress.orgによりクローズされたと報告されています。( Anchor Hosting ) この不正なコードは、すぐに目立つ被害を出したわけではありません。 2025年8月にバックドアが仕込まれ、その後しばらく潜伏し、2026年4月5日〜6日ごろに悪用されたとされています。つまり、問題が表面化するまで約8カ月かかっていたことになります。 どのような被害があったのか 報告によると、不正なコードは外部サーバーと通信し、WordPressサイト内の重要ファイルである wp-config.php に不審なPHPコードを追加していました。 このコードにより、検索エンジン向けにスパムページや不正なリンク、リダイレクトなどを表示する仕組みが作られていたとされています。 ここで厄介なのは、サイト管理者が普通にブラウザで見ても異常に気づきにくい点です。 不正な表示はGooglebotなど検索エンジン向けに出され、一般の閲覧者や管理者には見えにくい形だったと説明されています。 つまり、見た目にはサイトが普通に動いていても、裏側では検索エンジン向けにスパムコンテンツを返していた可能性があります。 WordPress.org側の対応 問題発覚後、WordPress.orgのプラグインチームによって、対象プラグインは閉鎖され、2026年4月8...
Read more »

デザインは売上に影響するのか？

イメージ
データから見えた「選ばれるWEBサイト」の条件 WEBサイトを作るとき、次のような発言や考え方に遭遇することがあります。 「まずは内容が大事」 「デザインは後から整えればいい」 「見た目よりSEOが優先」 当然、どれも間違いではないのですが、いざWEBサイトを作る段階では優先順位をつけておく必要があります。その時に念頭に置いておく必要があることがあります。 それは、実際のユーザー行動は、とてもシビアだということです。 多くの人は、ページを開いた瞬間に、そのWEBサイトの内容を「読むかどうか」を判断しています。 つまりデザインに求められるのは、単なる見た目ではなく、 “読もうという気にさせるかどうか” なのです。 求められるデザインの「質」 先日、以下の記事を読む機会がありました。 「デザインの質」が男性の購買判断を左右？年代別で異なる意識を調査。Ryuki Designが明らかにしたデザインの影響力とは https://newscast.jp/smart/news/1361249 この調査では、全国の20〜69歳の男性100名を対象に、 「インターネットで商品やサービスを選ぶ際、ページのデザインの質は判断材料になるか？」 というアンケートを実施しています。 結果として、 「デザインの良し悪しで判断することが多い」 「ある程度は気にするが、内容の方が重要」 と回答した人を合わせると、約4割以上が“デザインを判断材料として見ている”ことが分かりました。 さらに興味深かったのが、年代による違いです。 20代では「デザインはそこまで重視しない」という意見も一定数ある一方で、40代以降では「見やすさ」や「安心感」を重視する傾向が強く見られました。 つまり、WEBサイトの利用者はデザインを重視するが、そこで重視されているのは 「綺麗かどうか」ではなく、“信頼できるか・ストレスなく内容を読むことができるか” ということです。 そこで今回は、 なぜデザインが売上や反応率に影響するのか なぜ「内容が良いだけ」では不十分なのか 初心者でも見直せる改善ポイント を、できるだけ分かりやすく整理してみたいと思います。 デザインは「入口のフィルター」になっている ユーザーは、想像以上に早くWEBサイト...
Read more »

小規模サイトの表示速度改善メモ：第１回　WordPressを毎回動かさないためのキャッシュの考え方

イメージ
小規模WordPressサイトが重いとき、まず見直したい「ページキャッシュ」の考え方 はじめに この記事は、小規模なWordPressサイト・企業サイトの制作・保守を担当している方向けです。 特に、共用レンタルサーバを使っているサイトで、コストを大きく増やさずに表示速度を改善する場合、まず何から考えるべきかを整理します。 表示速度の改善というと、サーバのスペックアップや高機能なCDNの導入を思い浮かべるかもしれません。もちろん、それらが有効な場合もあります。 ただ、小規模な企業サイトやブログでは、予算や運用体制の都合から、すぐに大きな環境変更ができないケースも少なくありません。 そのような場合にまず考えたいのが、 アクセスのたびに毎回WordPressを動かさない という考え方です。 小規模サイトでは、サーバを強くするだけが解決策ではない 小規模な企業サイトやブログでは、WordPressを共用レンタルサーバで運用しているケースも多いと思います。 共用サーバは低コストで使いやすい一方、サーバの混雑や同居サイトの影響を受けることがあります。 たとえば、次のようなケースです。 サイトを開くときに時間がかかる ページ遷移のたびに少し待たされる 自社サイトへのアクセスは増えていないのに、特定の時間帯だけ応答が遅い 管理画面や公開ページの表示が日によって不安定に感じる こういったサーバに依存する部分は、自社サイト側だけでは完全にコントロールできません。 もちろん、サーバのスペックを上げたり、より高性能な環境へ移行したりすることも選択肢です。しかし、予算や運用体制を考えると、すぐに実施できないケースも少なくありません。 そのため、まずは現在の環境でできることとして、 WordPressやデータベースの処理を毎回発生させない工夫 を検討する価値があります。 そこで重要になるのが、ページキャッシュの考え方です。 WordPressは、ページ表示のたびに処理が走る WordPressは、あらかじめ完成したHTMLファイルをそのまま置いている静的サイトとは異なります。 多くの場合、ユーザーがページにアクセスするたびにPHPが動き、データベースから必要な情報を取り出し、テーマやプラグインの処理を通してHTMLを生成しています。 たとえ...
Read more »