企業サイトのアクセシビリティ改善｜読む・操作する・申し込むを支える確認項目

企業サイトを改善するとき、写真や配色、アニメーションに目が向きやすい一方で、「文字を拡大したら読めなくなる」「マウスを使わないとメニューを開けない」「入力エラーの直し方が分からない」といった問題が残ることがあります。必要な情報にたどり着けない人がいるなら、見た目が整っていても、会社案内や問い合わせ窓口としての役割を十分に果たせません。

アクセシビリティは、障害のある人を含む多様な利用者が、情報を理解し、必要な操作を行えるようにするための取り組みです。本記事では、企業のWeb担当者が制作会社へ相談する前に整理したい確認項目を、読む、操作する、入力する、更新するという場面に分けて説明します。W3Cの公式資料と、GOV.UK Design Systemが公開した運用例を根拠に、改善の優先順位と依頼方法まで扱います。

アクセシビリティ改善を、利用者の目的から考える

「見られる」だけでなく、用事を済ませられるかを見る

サービスの詳細を読む、採用条件を比較する、営業時間を調べる、相談を申し込む。企業サイトには、それぞれの利用者が達成したい目的があります。ページが開くことだけでなく、情報を探して理解し、次の行動へ進めるかを確認します。視覚、聴覚、身体の動き、認知などの違いに加え、使用する端末や支援技術によって、利用の仕方は変わります。

例えば画面を音声で読み上げるスクリーンリーダーを使う人は、見出しやリンクをたどって内容を探す場合があります。キーボード中心に操作する人は、マウスを重ねたときだけ現れるメニューにアクセスできないかもしれません。自分が普段使う方法で問題がないことを、すべての利用方法で問題がないことと同一視しない姿勢が出発点です。

SEOや問い合わせ率と、確認する目的を混ぜない

見出しを整理し、画像の意味をテキストで伝えることには、情報の理解を助ける価値があります。しかし、アクセシビリティ対応をすれば検索順位が上がる、問い合わせが一定割合で増える、と約束することはできません。改善の直接の確認は、利用者が情報を取得し操作できるかです。集客や商談の成果を測る場合は、別途、実際のデータで確認します。

社内の説明でも、「検索対策だから最低限やる」だけでは、公開後の優先度が下がりがちです。「応募フォームで必要事項を入力できる」「料金表を拡大して比較できる」「メニューをキーボードで操作できる」のように、サイトが果たすべき役割に結び付けましょう。改善した結果を確認でき、次の担当者にも必要性を引き継ぎやすくなります。

簡易点検と、基準への適合評価を区別する

W3CのEasy Checksは、アクセシビリティを初めて点検するための入り口を示しています。同時に、簡易点検だけで全体を確定的に評価できるわけではないことにも注意を促しています。本記事の確認項目も、問題を見つけて相談を具体化するためのものです。すべてを確認しただけで、サイト全体が特定の基準に適合したと宣言するものではありません。

制作会社へは、目指す基準の名称と版、適合レベル、対象ページ、確認方法、結果の報告範囲を相談します。「アクセシビリティ対応」という一式だけでは、どこまで調べるかが分かりません。既存サイトの一部改善と、サイト全体の正式な評価では、必要な調査も工数も異なります。最初の点検で見つかった課題を材料に、段階的な計画を作ります。

読むための改善は、文字・配色・構造から始める

文字と背景のコントラストを、実際の組み合わせで確認する

淡いグレーの説明文や写真の上の白文字は、制作画面では美しく見えても、背景との区別がつきにくい場合があります。WCAG 2.2のコントラストに関する達成基準の解説では、通常の文字で原則4.5対1以上、大きな文字では3対1以上という基準が示されています。大きな文字の定義や例外があるため、すべての要素へ同じ数値を機械的に当てはめるのではなく、該当する条件で確認します。

発注担当者は、本文だけでなく、日付、注釈、フォームの説明、ボタン内の文字、画像上のキャッチコピーまで確認対象に含めます。写真の上に文字を置く場合は、端末によって写真の切り取り位置が変わっても読めるかが論点です。ブランドカラーを一律に捨てる必要はなく、背景を調整する、本文用の濃い色を設ける、重ねる位置を変えるなど、用途に応じた案を制作側と検討します。

拡大しても、情報と操作が失われないかを見る

ブラウザーで拡大したときに、文字が枠から切れる、固定メニューが本文を覆う、ボタンが画面外に出ると、読むだけでなく操作も難しくなります。W3Cのリフローに関する解説は、表示領域の変化に応じて内容を再配置し、情報や機能を失わないことを扱っています。単に文字が大きくなるかではなく、読み進めて用事を済ませられるかを確認します。

読み込み中に文字が見えない、表示後に文字やボタンの位置がずれる場合は、Google Fontsの読み込みと文字のずれを調べる手順も役立ちます。フォントの表示を点検し、拡大時の確認と合わせて修正後の読みやすさを確かめます。

社内点検では、サービスページ、料金表、問い合わせフォームのように構造の違うページを選びます。PCの拡大表示とスマートフォンの狭い画面を見て、隠れる箇所を記録します。横方向の比較が必要な表などは、通常の本文と扱いが異なる場合があります。ページ全体を左右に往復させる状態になっていないか、表だけを操作して必要な情報を確認できるかを、制作側へ具体的に伝えましょう。

見出しは、見た目と文書構造を一致させる

大きく太い文字にしただけでは、HTML上の見出しとして扱われない場合があります。逆に、装飾の都合で本文まで見出しにしてしまうと、内容の構造が分かりにくくなります。記事タイトル、章、小項目の関係を整理し、見た目の強弱と構造が一致するようにします。「概要」「詳細」のような抽象的な見出しだけでなく、その章で何が分かるかを具体的に表すことも重要です。

例えばサービスページを「対象となるお客様」「相談できる内容」「料金の考え方」「依頼の流れ」に分けると、探す情報に近づきやすくなります。制作担当へは、見出しだけを一覧にした状態でも内容の順序が伝わるかを確認してもらいます。本文中の箇条書きや表にも意味に合う要素を使い、スペースや改行を連ねて見た目だけを合わせる編集を避けます。

画像・図解・動画の意味を、別の方法でも伝える

代替テキストは、画像の役割から決める

画像の代替テキストは、写っているものを何でも詳しく説明すればよいわけではありません。W3Cの代替テキストの判断フローは、情報を伝える画像、操作に使う画像、装飾など、画像の目的に応じて考える方法を示しています。同じ写真でも、サービスの特徴を説明する場合と、雰囲気を添えるだけの場合では役割が変わります。

例えば導入手順を説明する図なら、「お問い合わせ、ヒアリング、提案、制作、公開確認の順に進む」と意味を伝えます。単に「導入フローの画像」とだけ書くと、内容は伝わりません。一方、本文ですでに同じ内容を説明し、画像が装飾として添えられている場合は、重複した長い説明が読み進める負担になることもあります。画像ごとに本文との関係を確認して決めます。

料金や条件を、画像の中だけに閉じ込めない

チラシをそのまま画像にして掲載すると、価格や期間、注意事項が小さくなり、拡大しても読みづらいことがあります。重要な条件は、ページ上のテキストとしても提供します。図解を使う場合は、本文に同じ判断材料がそろっているかを確認しましょう。図を見られない人が、料金の適用条件だけ分からない状態では、申し込みの判断に差が生まれます。

グラフでは、色分けだけで系列を示すのではなく、ラベルや説明を組み合わせます。長い数値表を代替テキスト一文に押し込むより、本文の要点と必要な表を用意した方が理解しやすい場合もあります。掲載担当者が画像を差し替えたときに、本文の数値や説明が古いまま残らないよう、セットで点検する運用にします。

会社案内や料金表をPDFで提供している場合は、公開用PDFの文字・見出し・読み上げ順の確認も進めましょう。HTMLとの役割の分け方、スマートフォンでの点検、旧版の差し替えまでをまとめています。

動画は、音声を聞かなくても内容を追えるようにする

サービス紹介動画や採用インタビューでは、話している内容を字幕で確認できるか、重要な視覚情報が音声やテキストでも伝わるかを考えます。自動で作られた字幕を使う場合も、会社名、専門用語、金額、否定表現などを点検します。意味が逆になった字幕を付けたままでは、動画の内容を正しく伝えられません。必要な対応は動画の内容と評価対象に合わせて決めます。

動画だけに営業時間や応募条件を載せず、関連する説明をページにも置くと、必要な情報を探しやすくなります。再生、停止、音量などをキーボードで操作できるかも確認します。動画を差し替える際には、字幕、説明文、リンク先も同時に更新する担当を決めます。作った時点で確認して終わりにせず、運用で保つことまで含めて制作範囲を相談しましょう。

キーボードで、メニューから問い合わせまで進めるか

フォーカスの位置と移動の順序を確認する

キーボード操作では、現在どのリンクやボタンを操作しようとしているかを示すフォーカスが手がかりになります。見た目をすっきりさせるためにその表示を消すと、操作位置が分からなくなることがあります。W3Cのキーボード操作の解説は、ポインター操作を前提としない利用を扱っています。企業サイトでも、主要な機能をキーボードでたどれることを確認対象にします。

担当者の点検では、ページを開いてTabキーで移動し、どこにいるかが分かるか、見た目の順序に沿って進むかを確認できます。途中のボタンが飛ばされる、非表示の要素へ移動する、固定ヘッダーの裏に隠れるなどの現象があれば記録します。この簡易操作だけで全機能を評価できるわけではありませんが、制作側へ問題を伝える具体的な手がかりになります。

メニューは開けるだけでなく、閉じて戻れるかを見る

ハンバーガーメニューやポップアップは、開いた見た目だけを確認しがちです。実際には、キーボードで開けるか、内容へ移動できるか、閉じられるか、閉じた後に適切な位置へ戻るかまでが一連の操作です。裏側のページへ予期せず移動したり、どこにも進めなくなったりするなら、途中の状態を含めて修正が必要になります。

制作会社に報告するときは「メニューがおかしい」ではなく、「PCでTabキーを使い、メニューを開いた後、次の移動先が見えなくなる」のように、入口と操作を記録します。使用したブラウザーと端末も添えると再現しやすくなります。画面の動画を残す場合は、個人情報や社内通知が映っていないか確認して共有します。

動きのある演出は、情報の取得を妨げないか確認する

自動で切り替わる見出しや、大きく動く背景がある場合、内容を読む時間が足りるか、操作中に位置が変わらないかを確認します。印象を作る演出であっても、サービスの主要な説明が一瞬しか現れない設計では、理解の機会が限られます。動きを抑える設定や停止方法を含め、想定する利用環境と必要な達成基準に合わせて制作側と検討します。

社内の好みだけで演出を増減するのではなく、何を伝えるための動きかを整理します。例えば複数の実績を紹介したいなら、静止した一覧からも同じ情報にアクセスできるようにする案があります。演出の有無と、情報が取得できるかを別々に確認することで、ブランドの表現を保ちながら、利用を妨げる箇所を具体的に調整できます。

フォームは、入力・修正・完了までを一つの流れで見る

入力欄の名前を、見た目とプログラムの両方で伝える

W3Cのフォームのラベルに関する解説では、入力欄などのコントロールと、その目的を示すラベルを関連付ける方法が示されています。近くに「メールアドレス」という文字が見えていても、プログラム上で入力欄と結び付いているかは別の確認です。見た目の位置合わせだけで完成とせず、制作側に実装を点検してもらいます。

入力を始めると消える補助文字だけで、項目名や入力条件を伝える設計にも注意が必要です。何を書いたか見直すときに、その欄の目的を確認できなくなる場合があります。必須か任意か、どの形式で入力するか、何のために求めるかを、必要な場所で確認できるようにします。会社の受付で使わない情報まで、慣習で必須にしないことも検討します。

エラーは、場所と直し方を具体的に伝える

「入力内容に誤りがあります」とだけ表示されても、どこをどう直せばよいか分かりません。W3Cのフォームの通知に関する解説は、エラーや完了を伝え、修正を助ける情報を提供することを扱っています。エラーが起きた項目、必要な入力、修正後に進む方法を確認できるようにします。赤い枠だけで知らせるのではなく、文章でも意味を伝えます。

企業サイトでは、電話番号の形式、添付ファイルの条件、メールアドレスの確認などを実際に試します。エラー後に正常な入力まで全部消えると、やり直しの負担が増えます。一方で、機密性の高い情報は保持の扱いを慎重に決める必要があります。単に項目数を減らすだけでなく、間違いから復帰できる流れを整えることが重要です。

送信完了と、その後の連絡を理解できるか確認する

ボタンを押した後、画面が少し変わっただけでは、送信できたか判断しにくい場合があります。完了状態が視覚的にも支援技術を使った操作でも伝わるかを確認します。さらに、何を受け付けたか、次に誰からどの方法で連絡するか、返信が届かない場合の連絡先を、実際の受付体制に合わせて示します。実行できない返信期限を安心感のために書き加えないようにします。

ここでは画面上の理解と、メールや受付データの処理を両方確認します。利用者には完了と伝えたのに担当者へ届いていない状態を防ぐためです。フォームを外部サービスで提供している場合も、自社ページからの入口、外部画面、完了後の案内を続けて確認します。どこからどこまでを制作会社が修正できるか、サービス側への相談が必要かを整理します。

フォームの質問や受付体制、計測も含めて見直す場合は、入力から受付までのフォーム改善ガイドをご確認ください。画面の点検に加え、担当者へ届いた相談まで確かめる手順を整理しています。

GOV.UKの公開例に学ぶ、問題を残さず追跡する運用

監査した範囲と、分かっている問題を公表している

GOV.UK Design Systemのアクセシビリティ声明は、対象となるサイトや部品、外部監査の時期と範囲を説明しています。声明に記載された2024年7月の監査では、異なる内容の種類を含むページのサンプルや、共通ヘッダーの検索機能が対象になっています。また、達成基準への不適合として扱うものとは別に、利用上の懸念も追跡しています。

同声明では、音声操作ソフトDragonとブラウザーの問題によって、ファイル選択が操作できないケースを紹介し、その改善のために作った部品と有効化の条件を案内しています。参照した声明の更新日は2024年12月18日です。ここで紹介するのは同文書に記載された運用例であり、現在のあらゆる製品版の動作を保証するものではありません。また、売上や問い合わせの改善率を報告する事例でもありません。

自社では、小さな改善台帳から応用できる

この公開例から自社に応用できるのは、確認した範囲、残る問題、対応方法を具体的に記録する姿勢です。大規模な政府サイトと同じ体制を用意する必要はありません。例えば「対象ページ」「起きる操作」「困ること」「対応担当」「対応状況」「再確認日」の六項目を一つの表にまとめるところから始められます。以下は説明用の架空例です。

修正ファイルを受け取っただけで、台帳を完了にしないことが大切です。問題が起きていた条件で再確認し、確認者と日付を残します。ブラウザーや外部サービスの影響で解決していないものは、未解決として扱い、代わりの利用方法や次の調査を決めます。「対応した」と「利用できることを確認した」の間を、記録でつなぐ運用です。

制作会社への依頼は、対象と成果物を明確にする

ページ数だけでなく、機能と状態を伝える

トップページ、サービス一覧、ブログ、フォームというページの種類に加え、開いたメニュー、入力エラー、送信完了などの状態を依頼範囲に入れます。同じテンプレートを使うページが多ければ共通修正が有効ですが、画像や原稿に固有の問題はページごとの確認が必要です。「全部で何ページだから同じ費用」とは限らない理由を、見積もりの段階で確認します。

依頼時には、利用者の主な目的、既に分かっている問題、更新する担当、使っている外部フォームや動画などを共有します。評価対象から外れる部分があるなら、その理由と影響を聞きます。自社サイトの入口だけ整えて、申し込み先の外部画面で操作できないままでは、利用者の用事は終わりません。契約上の担当範囲が分かれていても、利用の流れは一つとして整理します。

自動検査と、人の確認をどう組み合わせるか聞く

自動検査は一定の問題を見つける助けになりますが、説明文が利用者に伝わるか、代替テキストが画像の目的に合うか、操作が現実的に理解できるかまで、点数だけで判断することはできません。制作会社には、何をツールで検査し、何を手動で確認するかを聞きます。必要に応じて支援技術を使った確認や、実際の利用者による確認も計画します。

LPで利用者の理解や行動を観察する場合は、公開前のユーザーテストの準備・観察・修正手順も参考になります。これは正式なアクセシビリティ評価の代わりではなく、利用上の疑問を調べるための方法です。

報告書には、検査した日時、対象、環境、問題の内容、根拠となる基準、修正案、再確認の結果を求めます。高得点の画面だけでは、未確認の範囲や改善の優先度が分かりません。正式な適合評価を依頼する場合は、その方法と対象範囲を別途合意します。まず簡易点検を依頼する場合も、そこで判断できることとできないことを明確にします。

優先順位は、困る場面と影響から決める

予算が限られる場合は、問い合わせや応募が完了できない問題、重要な条件を取得できない問題、全ページに共通する操作の問題から検討します。利用者の目的を妨げる度合い、影響する範囲、修正の難しさを合わせて整理し、何を先に直すかを決めます。直しやすい軽微な項目だけを大量に処理して、重要な障壁を残さないようにします。

例えば共通メニューの修正は、多くのページから情報を探す行動に関わります。一方、一枚の古い資料の修正でも、現在の申し込みに必須なら優先度が高くなります。ページのアクセス数だけでは決めきれません。使えない人がすでに離れている可能性もあるため、利用者から届く連絡や実際の操作確認を含めて判断します。

公開後に品質を保つための編集ルールをつくる

記事を追加する人が守れる、短い確認表にする

公開時に整えても、その後の記事で画像だけの説明や不適切な見出しが増えると、品質は変わります。投稿担当者向けには、見出しの順序、リンク先が分かる文言、画像の役割と代替テキスト、重要情報のテキスト化、スマートフォンでの確認を、短いチェックリストにします。担当者が理解できる具体例を添え、専門用語だけの手順書にしないことが大切です。

例えばリンクを「こちら」だけにせず「採用条件を確認する」と書く、料金の変更時には画像と本文の両方を確認する、図解を追加したら同じ内容を本文でも説明する、といったルールです。編集画面の操作で迷う箇所があるなら、制作側に入力欄やテンプレートの改善も相談します。気を付けるよう伝えるだけでなく、間違いが起きにくい運用を作ります。

問い合わせを、次の改善へつなぐ窓口を決める

利用しにくいという連絡が来たとき、誰が受け、何を確認し、どの担当へ渡すかを決めます。利用者に専門的な原因分析を求めるのではなく、使っていたページ、行いたかったこと、起きた現象を分かる範囲で聞きます。情報の提供を受ける際は、パスワードや不要な個人情報を送ってもらわない案内にします。

修正がすぐにできない場合も、その人が用事を済ませる別の方法を検討し、サイトの改善記録に残します。代わりの窓口を用意したことだけで、元の問題を解決済みにしないことが重要です。似た連絡が繰り返されるなら、共通の原因がないかを確認し、単発の応対で終わらせないようにします。

デザインの更新と一緒に、利用の確認を繰り返す

新しいメニュー、フォーム、動画、表示演出を追加したときは、関係する利用経路を確認します。画面が変わっていなくても、外部サービスやプラグインの更新で操作が変わる場合があります。どの変更をしたら何を再確認するかを保守担当と共有し、重要なページは定期点検にも含めます。確認結果を残せば、次の改善で同じ調査を最初からやり直す負担を減らせます。

Acquaへのホームページ制作・改善の相談では、デザインの希望と合わせて、読みにくいと感じる箇所や、操作で困ったという連絡も共有してください。まず対象と現状を整理し、必要な調査、修正、公開後の確認を具体化します。企業サイトを継続して役立つ窓口にするには、見た目の完成と同時に、読む・操作する・申し込むという行動を支えることが大切です。

出典の確認日：2026年9月9日。参照資料はW3C WAIの各解説とGOV.UK Design Systemの公開声明です。公開事例と、本記事の架空の改善台帳例は区別しています。本記事は技術・運用面の改善の入り口であり、個別サイトの適合評価や法的な判定を行うものではありません。