スマホで図解が読みにくいとき、PNGをHTML/CSSに作り直した理由

PCで作った図解をスマートフォンで見ると、文字が思ったより小さくなることがあります。画像の幅を画面に合わせるだけでは、説明の順序も文字の大きさも変えられません。

GAOCRAFTでは、日本語の見出しの改行を検証した記事を作る際、3点の説明図をPNG画像からHTML/CSSの図解に置き換えました。見出しそのものの直し方は「スマホで日本語の見出しが崩れたとき、GAOCRAFTが直したこと」で扱っています。この記事では、図解の情報を、狭い画面でも読める形に組み直すという別の課題を記録します。

「HTMLの図解なら常に正解」という話ではありません。写真や複雑なイラストには画像が適しています。今回HTML化したのは、短い文章、比較項目、修正手順、CSSの設定値が主役の図解でした。

3点のPNGを、そのまま縮小するだけにはしなかった

対象は、FIELD NOTESの記事に用意した次の3点です。

• 改行例：見出しの最後の一文字だけが次行へ送られた状態を説明する図

• 修正履歴：複数のPRでCSSの調整を重ねた順序を示す図

• CSSの役割：text-wrap、word-break、overflow-wrap、line-breakを整理した図

PNG版は一定の大きさに文字と配置を固定しています。そのため、横長の配置を小さな画面に収めようとすると、文字まで縮小されるおそれがあります。画像をタップして拡大する方法もありますが、毎回の拡大を前提にするより、ページを開いた状態で読み取れる配置にしたいと考えました。

そこで、図解の主な情報をHTML/CSSで表現し直しました。改行例は2枚の比較カード、修正履歴は番号付きの縦型タイムライン、4つのCSSの説明は項目カードへ分けています。

この判断は「PNG画像に欠陥があった」と証明したものではありません。図解の主役がテキストだったため、画面幅によって配置を組み替える余地を作ったという設計上の選択です。

旧PNGの原図と現在のHTML図解を見比べる

当時のローカルChromiumでは、375pxと768pxでPNG版とHTML/CSS版の画面を記録しました。375pxのHTML版は図解の一部が画面外にあり、記録画像の文字を大きく引き伸ばすと読み取りにくくなります。比較スクリーンショットは制作時のQA資料として保持しています。

旧PNG版の原図

図：PR #22に保存された1200×900pxの旧PNG原図。画面幅375pxや768pxでの撮影画像ではありません。タップすると原寸で確認できます。

現在のHTML/CSS版

上の図は現在のサイトの実際のHTML/CSS図解です。375pxでは1列、768pxでは2列になる設計です。過去のスクリーンショットの再撮影ではなく、現在の表示幅に応じて描画されます。

旧PNGの設定値は当時の記録で、現在のHTML版と異なります。現行の見出し設定については「スマホで日本語の見出しが崩れたとき、GAOCRAFTが直したこと」を参照してください。画面比較で確かめたのは配置の違いであり、読者の理解度や閲覧時間の改善を計測したものではありません。

実装は「データ」「表示」「配置」を分けた

GAOCRAFTの実装では、図解に使う文章や項目をsrc/lib/notes/visuals.tsで管理し、src/components/NoteVisual.tsxがReactの要素として描画しています。列数や余白はsrc/components/NoteVisual.module.cssで調整します。

記事のMarkdownは、登録済みの図解IDをvisualコードブロックで指定する構造です。図解のHTMLをMarkdownに直接貼り付ける方式ではありません。

役割を分けることで、文章を修正するときにCSSを触らずに済み、カードの配置を変えるときに記事本文を変更する必要も小さくなります。一方で、登録用のコードが増えるため、図解の数が少ないサイトでは必ずしも最小工数になりません。

Reactで比較カードを作る最小例

実際のGAOCRAFTの図解コンポーネントは複数の種類を扱いますが、基本の考え方を取り出すと次のようになります。

const items = [
  { title: "text-wrap", detail: "行の長さや折り返し方を調整する" },
  { title: "word-break", detail: "文字を分割できる場所に関係する" },
  { title: "overflow-wrap", detail: "収まらない文字列の追加分割を扱う" },
  { title: "line-break", detail: "日本語の禁則処理などを扱う" },
];

export function PropertyDiagram() {
  return (
    <figure className="diagram">
      <ul className="diagramGrid">
        {items.map((item) => (
          <li className="diagramCard" key={item.title}>
            <strong>{item.title}</strong>
            <p>{item.detail}</p>
          </li>
        ))}
      </ul>
      <figcaption>図：見出しの折り返しに関わる4つのCSS指定</figcaption>
    </figure>
  );
}

これは仕組みを説明するための簡略例です。実際には既存サイトのCSS Modulesを使い、見出しや説明文の長さによって余白・折り返し・強調の仕方も調整しています。

CSS Gridで狭い画面を1列にする

4つのカードは、広い画面では2列、560px以下では1列に切り替える構成にしました。

.diagramGrid {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 0.85rem;
  list-style: none;
  padding: 0;
}

.diagramCard {
  min-width: 0;
  padding: 0.95rem;
  border: 1px solid #b8c4ec;
}

@media (max-width: 560px) {
  .diagramGrid {
    grid-template-columns: minmax(0, 1fr);
  }
}

これは移植しやすいようクラス名を簡略化した例です。現在のサイトではbreakCardsとpropertyCardsに同じ列数の切り替えを適用しています。minmax(0, 1fr)やmin-width: 0は、長い内容がグリッドの最小幅を押し広げる事態を避けるための指定です。ただし、CSSの設定だけで日本語のすべての改行位置を保証することはできません。

図解②のタイムラインは別の構造です。順序を読む図では、2列に詰め込むより、番号付きの縦方向の並びを保つ方が意図を示しやすいと判断しました。

実テキストにしたことで、何が変わるか

HTML/CSS版では、カードのタイトル、説明、番号、図のキャプションをブラウザー上の文字として出力しています。元のPNGと違い、文字を選択でき、画面幅に応じた折り返しやテキストサイズの調整も可能です。

ただし、HTMLになっただけでアクセシビリティが保証されるわけではありません。情報の順序がDOM上でも自然か、装飾だけで意味を区別していないか、文字拡大で表示が崩れないかなどは別に確認する必要があります。

W3Cの複雑な画像に関するガイド（外部サイト）も、図やグラフの内容を伝えるためのテキスト表現を重視しています。画像のまま提供する場合でも、短い代替テキストだけでは情報が不足することがあり、必要に応じて図の内容を文章で説明することが重要です。

写真や装飾的なイラストまで無条件にHTMLへ置き換える必要はありません。GAOCRAFTでも、写真の軽量化と配信は別の記事「水族館の写真7枚をWebPに変換したら容量はどれだけ減る？実測と再現手順」で扱っています。

表示検証は6つの幅で実施した

当時のQA資料では、ローカルChromiumのPreview buildで320・375・390・430・768・1280pxを確認しています。3点のHTML図解とページ全体について、横方向のはみ出しがないことを記録しました。また、図解のキャプション、記事の見出し、コード、関連記事リンク、下書きのインデックス制御も確認対象でした。

その段階の資料には、iPhone Safariの読みやすさについてHuman確認待ちと明記されています。ローカルChromiumの検証を、その時点ですべての実機確認が終わっていたかのように言い換えることはできません。

第8記事の公開前の実機確認については、この比較資料から確認できる範囲に含めていません。PNG版とHTML版の理解度を比較した試験も行っていません。

自分のサイトで同じような変更を行うなら、少なくとも次を分けて確認します。

1. 内容の一致：図解で伝える項目・数値・注釈が書き換わっていないか。

2. 狭い幅：カードが意図した順番に並び、長い用語が枠から出ないか。

3. 大きい幅：列が広がっても視線の順序が分かるか。

4. 本文との関係：図だけで説明を完結させず、重要な情報を本文にも置いているか。

5. 実機と公開環境：正式フォントを使った表示、リンク、公開後のURLを確認したか。

この5項目は、今回の制作記録をもとに整理した確認手順です。すべてのサイトにそのまま適用できる合格基準ではありません。

画像かHTMLかを、情報の性質で選ぶ

今回の3点は「文章を読む」「設定を比較する」「順序を追う」ための図でした。そこでGAOCRAFTでは、見た目を一枚の画像に固定するより、構造を持つHTMLとして描画する方式に変更しました。

一方、図版の細かな形状そのものが情報である場合や、写真・イラストが中心の場合、画像のまま提供し、適切な代替テキストと本文の説明を組み合わせる方が合理的なこともあります。

重要なのは、図解を作ったかどうかではなく、読者がその内容を画面の大きさに左右されず受け取れるかを確かめることです。今後も、表示幅と実機の両方で確認し、改善が必要なら図の構造から見直していきます。