文字を大きくすると使えないサイトの見直し方

文字を大きくすると読めない・押せないサイトを見直すため、ブラウザ拡大、文字のみ拡大、狭い幅を区別。欠ける内容、必要操作、改修範囲を確認表に記録する方法を解説します。

普段の大きさでは読めるページでも、ブラウザで文字を大きくすると、問い合わせボタンが隠れる、入力欄の説明が途中で切れる、表を読むためにページ全体を左右へ動かし続けることがあります。担当者が「スマートフォン表示は整っている」と判断していても、拡大した画面では利用者が必要な操作を完了できないかもしれません。必要なのは崩れた画面の印象だけで改修を発注することではなく、表示条件、失われた内容、必要になった操作、直す範囲を一つの記録にまとめ、制作会社と何を直すかを相談できるようにすることです。

この記事は、自社サイトの表示と操作を見直したいWeb担当者向けです。視覚に関する一般論や規格の全項目を列挙するのではなく、文字拡大、画面幅による再配置、横スクロールを区別して、制作会社と改修範囲を決める方法を扱います。以下の表は架空の記録例です。特定サイトの不具合や改善実績を示すものではありません。

みやあじよのマルチデバイス対応では、画面幅ごとの表示だけでなく、文字、メニュー、フォームを実際の操作で確かめ、部分調整と再設計を比較する支援を案内しています。既存のアクセシビリティ改善の優先順位の記事は、重要な導線を選んで確認・修正する全体の進め方を扱います。ここではその中の「文字を大きくしたときに内容と操作がどう変わるか」に絞って説明します。

文字拡大と狭い画面を区別する

最初に、どう表示を変えたのかを記録します。ブラウザ全体の拡大は、文字だけでなく画像や部品の見た目も大きくし、ページに使えるCSS上の幅が狭くなることがあります。文字サイズだけを変える設定では、画像や枠の幅がそのままで文字だけが大きくなる場合があります。スマートフォンの小さな画面で標準表示した状態は、さらに別の条件です。同じように文字が切れて見えても、原因となるレイアウトの制約が違います。

W3CのWCAG 2.2「文字のサイズ変更」の解説は、字幕や画像化された文字を除き、支援技術を使わず文字を200％まで拡大しても、内容や機能を失わないことを説明しています。これは「どの端末でも全く同じ配置にする」という意味ではありません。拡大に伴って一列表示へ変わっても、情報と操作が使えればよいのです。担当者が確認するときは、倍率の数字だけを残さず、使ったブラウザの拡大方法、元の画面幅、対象URLも書き添えます。

見た目の拡大と、必要な情報に到達できることも分けます。カードの高さが伸びる、見出しが二行になる、ボタンが次の行へ回ること自体は、問題とは限りません。一方で「送信する」の文字が枠からはみ出して押す位置が分からない、入力条件が途中で消える、固定ヘッダーが本文を覆い続けるなら、目的の達成に影響します。「崩れた」ではなく、何が読めないか、押せないかを言葉にします。

どの画面で何が読めず、どの操作ができないかを記録する

文字拡大で使えない箇所を表示条件、欠ける内容、必要操作、対応方針で記録する図 — 表示条件、欠ける内容、必要操作、対応方針を結ぶ編集図。実際の不具合は対象サイトで再現して記録します。

表示の確認記録には、スクリーンショットに加えて操作の経過も残します。画像には「どの条件で」「どの操作をしたら」「どこまで進めたか」が残りにくいからです。対象URL、表示条件、発生箇所、期待する見え方、実際に欠けた内容、回避のために必要だった操作、対応方針を一行にします。修正後に同じ条件を再現するため、ブラウザ名と倍率、画面の向きも入れます。

表は左右にスクロールして確認できます。

確認する場所	表示条件と操作	欠ける内容・必要操作	対応方針の例
サービスページの見出し	デスクトップでブラウザ拡大、見出しを読む	二行目が隣の写真に重なり、文末を読めない	見出し枠の固定高さと写真の配置を確認する
問い合わせフォーム	文字のみ拡大、必須項目を入力	説明文が欄の下に隠れ、入力条件が分からない	ラベルと説明の高さ、入力欄との関係を確認する
比較表	幅を狭め、各列を読む	表だけ左右移動が必要。各行の見出しは見える	横移動の範囲と、行の意味を保てる表示を確認する
共通メニュー	ブラウザ拡大後に開閉	項目が画面外に続くが、スクロール位置が動かない	開いた状態の高さ、内部移動、閉じる操作を確認する

表の内容は設計例です。実際の画面で同じ現象があると決めつけず、URLごとに記録します。スクリーンショットのファイル名に日時と表示条件を付け、表の行から対応する画像へたどれるようにします。問題が起こらなかった条件も残しておくと、たとえば「標準幅では使えるが、一定の拡大から入力説明が消える」という境目を制作側へ伝えられます。個人情報を含む入力内容は撮影前に伏せます。

横スクロールの範囲と読みやすさを確認する

狭い画面で横スクロールが現れたら、まずページ全体が動くのか、比較表など限られた部分だけが動くのかを確認します。W3Cの「再配置」の解説は、縦に読む内容を幅320 CSSピクセル相当で示す場合、原則として二方向のスクロールを必要とせず情報と機能を保つ考え方を説明しています。一方、二次元の配置が意味や利用に必要な一部の内容には例外があります。表を横に動かせるだけでページ全体の本文がはみ出す状態を、同じ扱いにはできません。

比較表では、列同士を同じ行で見比べる必要があるかを考えます。横移動が必要でも、表の範囲に収まり、どこを動かせるか分かり、各行の見出しや値を追えるなら、読み方を設計できます。逆に、行の名前を見失ったまま値だけが横に現れると比較できません。長い表を小さな文字で収めようとする前に、列を減らせるか、情報をカードへ組み替えられるか、表のままなら見出しをどう保つかを検討します。

フォームや本文がページ幅からはみ出している場合は、表の例外を当てはめません。横へ動かないと一行を読み終えられない、入力欄の送信ボタンが画面外に残るといった現象は、利用者が同じ行を読むたびに二方向へ移動する負担になります。ページ全体、部品の中、閲覧する情報のどの階層で横移動が起きたかを書けば、修正すべき幅の指定や部品を特定しやすくなります。

入力欄と固定部品は操作完了まで確かめる

文字が大きくなると、ラベル、補足説明、エラー文、入力欄の間隔が変わります。枠の高さだけを固定していると、画面上は一部が隠れても、クリック位置だけ残る場合があります。正常に送信できる状態だけでなく、必須欄を空にした状態、長めの内容を入力した状態、エラーから戻る状態で、説明と操作が追えるかを確認します。送信結果まで見て初めて、フォームを「使える」と判断できます。

ページの上下に固定されたヘッダーや相談ボタンも確認対象です。文字が折り返して高さが増えた結果、本文と重なる、開いたメニューの下に操作対象が隠れる、といった問題が起きます。画面に収めるために文字を小さく戻すのではなく、固定する必要のある部品、画面内の高さ、重なりの順序を再検討します。デスクトップの拡大表示、タブレットの中間幅、スマートフォンの縦横で、問題が同じ部品に現れるかを表へ追加します。

本文やボタンの文字間隔を利用者が変えたときも、固定高さの枠は影響を受けます。W3Cの文字間隔の解説は、利用者側が行間などの文字設定を変更しても、内容と機能が失われないことを扱っています。サイトの標準表示を特定の値に固定せよという説明ではありません。拡大で欠ける箇所が見つかったら、同じ枠で行間や折り返しにも余裕があるかを確かめる材料になります。

不具合があるページを調べ、直す範囲を制作会社と決める

改修の相談前に、同じ問題がどの範囲に及ぶかを確かめます。一つの記事の長い見出しだけなら、そのページの見出し文と配置を確認します。全サービスページのカードで文字が切れるなら、共通のカード部品やテンプレートを調べます。メニューやフォームが複数ページで隠れるなら、一ページの余白調整では終わらない可能性があります。確認表に「同じ部品を使うページ」と「問題が出ないページ」を並べると、制作側が原因を絞りやすくなります。

文章の改善で対応できる箇所もあります。見出しを短くして意味を保つ、ボタンの文言を具体的にする、比較表に入れる項目を整理することです。ただし、短い文に置き換えた結果たまたま枠に収まったとしても、次の更新で再び切れるなら、部品の作りを見直す必要があります。編集できる文字と、CSSやスクリプトが決める表示範囲を分けて記録します。画像に焼き込まれた文字が情報を担う場合は、拡大や折り返しを文章と同じように扱えないため、テキストとして出せるかも確認します。

依頼書には「200％で直してください」だけを書くより、画面条件、URL、操作の始点と完了、欠けた内容、再現画像、影響を受けるページ群を添えます。制作側には、部分調整で済む箇所と共通部品の再設計が必要な箇所を分けて提案してもらいます。対象ブラウザや実機、受け入れ時の確認条件は、自社の利用環境と重要な導線を踏まえて決めます。例示の表だけでWCAGへの適合を証明したと扱わないようにします。

一件の不具合を再現できる形で伝える

たとえば「お問い合わせの説明が読めない」という連絡を受けた場合、担当者は、どのページからフォームへ来たか、ブラウザ全体を拡大したのか文字だけを大きくしたのか、何％またはどの設定で現れたかを聞き取ります。続いて同じ条件で、最初の説明から入力、エラー、送信確認へ進みます。途中で隠れた文が「必須項目の説明」なら、利用への影響を表に記します。「スクロールすると読めた」のか、「別の操作をしても見えない」のかも分けます。スクリーンショット一枚では、この違いを記録できません。

制作側へ渡す記録では、現象と原因の推測を別欄にします。「固定高さが原因」と思っても、実際は隣の画像の重なり、文字の折り返し、外部のフォーム部品など複数の要因があり得ます。依頼時には、誰でも再現できる条件と期待する結果を確定し、実装上の原因は調査結果として更新します。修正方針を先に断定しないほうが、原因と異なる箇所だけを調整して問題が残ることを避けられます。例として「説明文と入力欄が両方読め、エラー後も送信まで進める」を受け入れ条件にします。

問い合わせなどを完了できない箇所から優先して直す

同じ倍率で複数の問題が見つかったら、見た目の大きさだけで順番を決めません。見出しの余白が広がっても読める箇所と、送信ボタンが隠れて問い合わせを完了できない箇所では、後者が先です。ページ上部の共通メニューで選択先が見えなければ、複数の用件へ影響します。表には「何を完了できなくなるか」「同じ部品を使うページ数」「回避方法があるか」を添えます。件数や影響範囲は実際のサイトで確認し、例示の数字を成果として使いません。

修正の優先度と、改修に必要な工数は別の列で扱います。共通部品の改修が大きくても、その部品が主要導線を止めるなら、後回しにする理由にはなりません。一方、個別ページの表現を直せば読める箇所まで、全ページの再設計へまとめる必要もありません。制作会社の調査で影響範囲が分かった段階で、すぐ直す対象、追加調査が必要な対象、次回更新時に扱う対象を決めます。公開後は、コンテンツを追加したときにも同じ確認表を使い、長い見出しや新しいフォーム項目の文字が再び切れないか確かめます。

同じ倍率・幅で、修正後の表示と操作を確かめる

修正を受け取ったら、標準表示の見た目だけで完了にしません。最初に欠けた条件と同じブラウザ、倍率、幅、操作でページを開き、見出しの全文が読めるか、表やメニューを追えるか、フォームのエラーから送信結果まで進めるかを確認します。共通部品を変えた場合は代表的な別ページも確かめます。前後の画面と操作結果を確認表に並べ、残った問題には担当と次の確認日を付けます。