長い記事の読みやすさを保つ：コード、表、画像とキャプション

記事の段落がすべて問題なく折り返されても、スマートフォンで読みやすいとは限りません。長いコマンドがページ全体を横に広げたり、表が圧縮されて各セルに数文字しか入らなくなったりします。画像が縮小されても、その中のラベルが読めないこともあります。

こうした問題は、文字を小さくするだけでは解決しません。本文、コード、データ表では、情報を保つために必要な扱いが異なります。画像とキャプションも、並べて置くだけで説明が伝わるわけではありません。私が重視するのは、狭い画面に移ったあとも、読者がもともとの目的に沿って読み進められるかどうかです。

このノートでは、2026年10月23日に確認した当サイトの記事レイアウトをもとに、当時の対応と、人の判断が必要な点を整理します。

まず、元の構造を保つ必要がある内容を見分けます

本文はコンテナの幅に合わせて折り返せますが、コードのインデントや表の行・列の対応関係は、内容の理解に必要な場合があります。すべてを強制的に折り返せば横スクロールバーはなくせても、別の読みづらさを見えにくくしてしまうことがあります。

私はまず、読者が何をする必要があるかで分けます。

内容	読者にとって保つ必要があるもの	レイアウトで最初に考えること
通常の本文	文の順序と段落同士の関係	利用できる幅に合わせて折り返し、1行を読むためにページ全体を左右に動かさずに済むようにする
インラインの識別子やURL	名前と、その前後の文との関係	必要に応じて折り返し、長い文字列1つで本文が横に広がらないようにする
コードブロック	インデント、行の区切り、コピーできる内容	先に例を簡潔にし、そのうえで局所的な横スクロールを残すか決める
データ表	表の見出しと各行・列の対応関係	不要な列を先に減らし、必要な場合は表の範囲内でスクロールさせる

W3CのReflow（リフロー）の解説でも、通常のコンテンツと、理解のために二次元のレイアウトが必要な領域は区別されています。データ表は専用のスクロールコンテナを持てますが、その例外があるからといって、隣の段落まで横にはみ出してよいわけではありません。[1]

つまり、ある表を左右にスクロールできることは、その表が記事ページ全体を横に押し広げてもよい理由にはなりません。逆に、長いコードならどれでもリフローが不要な例外として扱えるわけでもありません。

コードを要点まで絞ってから、スクロール方法を決めます

当時のレイアウトでは、コードブロックの横スクロールをその領域内に収め、インラインコードでは長い文字列を折り返せるようにしていました。関連するルールを通常のCSSで抜き出すと、次のような違いになります。

.note-body pre {
  max-width: 100%;
  overflow-x: auto;
}

.note-body :not(pre) > code {
  overflow-wrap: anywhere;
}

この抜粋が示しているのは、幅と折り返しの取捨選択だけです。フォント、余白、外観に関するすべてのスタイルを載せているわけではありません。記事のメインカラムと本文コンテナには、レイアウト内で内容が縮められるようにmin-w-0もありました。overflow-x: autoだけをコピーしても、どのような外側のレイアウトでもはみ出さないとは保証できません。

ただし、スクロールできるのは内容の収め方が決まったというだけで、例が読みやすい証拠にはなりません。1つの判断を説明するために設定ファイル全体を貼り付ければ、読者は関係のない行の中から要点を探すことになります。

私は先に、論点と関係のないコードを削り、注意が必要な条件をその近くで説明します。読者が本当に1行を完全な形で読む必要がある場合や、インデントと元の構造を保つ必要がある場合に限って、横スクロールの負担を受け入れます。「コードはもともと長いものだから」と編集を省くことはできません。

表はセルを狭めるより、比較できる形を保ちます

表は、同じ項目に沿って複数の対象を比較するのに向いています。スマートフォンの幅に縮めた結果、どのセルも縦に長い文章になってしまうと、比較しやすいという利点が失われることがあります。

当時、当サイトの表にはdisplay: block、width: fit-content、max-width: 100%、overflow-x: autoを使い、必要な横方向の移動を表の中に収めていました。これは、比較のための構造と利用できる幅の間での取捨選択です。どの表も同じ形のまま使うべきだという意味ではありません。

原稿を見直すときは、説明を繰り返しているだけの列がないか、セルが1つの段落になるほど長くなっていないかを先に見ます。行同士を比較する必要がなければ、小見出しごとの節に分けたほうが適しているかもしれません。列ごとの比較が必要なら、表の見出しとデータの関係を保ち、画面に押し込むために重要な情報を削らないようにします。

横方向に続く内容に読者が気づけるか、キーボードでスクロール領域に到達して操作できるかも、別に確認する必要があります。このノートの元になった当時のプレビューでは、コードブロックにtabindex="0"があり、表には同じ属性がありませんでした。両者の操作条件は分けて確認すべきで、CSSや1つのtabindexだけを根拠に、キーボード操作の検証がすべて済んだとは言えません。

画像が画面に収まっても、情報が読めるとは限りません

当時の記事画像にはmax-width: 100%と自動の高さを指定し、元の画像幅で本文が広がらないようにしていました。ただし、小さな文字が多いフローチャートは、画像全体が画面内に収まっていても、描き直し、複数の画像への分割、文章による説明の追加が必要になることがあります。

キャプションが補うべきなのは、読者がその画像をどう解釈すればよいかです。図が扱う範囲、比較の条件、模式図と実際の状態の違いなどを伝えます。「これはフローチャートです」と書くだけでは、たいてい十分な情報は加わりません。

HTMLのfigureは、自己完結した画像、図表、その他のコンテンツを1つのまとまりとして扱い、figcaptionはそのまとまりのタイトルや説明を提供します。[2] 当サイトにはすでにfigcaptionのスタイルがありましたが、セレクターがあるだけで、すべてのMarkdown画像にキャプションが付くわけではありません。出力にも、それに対応する内容と構造が実際に必要です。

キャプションとaltの役割分担も、文脈によって変わります。画像が周囲の文章では説明されていない情報を伝えているなら、理解できる代替コンテンツを補う必要があります。情報がすでに文章ですべて繰り返されている場合は、扱いが異なります。WAIのaltの判断フローが最初に問うのも、その画像が今の文脈でどんな意味を加えているかであり、目に見えるキャプションの有無だけではありません。[3]

画像の読み込みと失敗時の状態は、別に対応を考える必要があります。ここでは記事の読者が画像を理解できるかを扱い、レイアウトの設定を、読み込みやパフォーマンスが改善した証拠とはしません。

読みやすさは、実際に配置が難しい内容で確かめます

空のレイアウトや短い文章を数段落並べただけでは、長い記事で問題が起きやすい箇所は見えてきません。確認するときは、長い識別子、コードブロック、比較が必要な表、小さな文字を含む画像が実際にある記事を選び、本文を通して読む必要があります。

私は、「実装が正しい内容を出力しているか」と「無理なく読めるか」を分けて考えます。前者では、HTML、見出し、表の見出し、キャプションの有無を確認できます。後者ではさらに、狭い画面、文字の拡大、実際の操作方法で、情報が切れていないか、スクロールに気づけるか、対応する説明を読者が何度も探し直す必要がないかを確かめる必要があります。

このノートは、レイアウトが担う役割と原稿の見直し方を整理したもので、サイト全体のアクセシビリティ認証ではありません。すべての端末での読みやすさを測定したものでもありません。2026年10月23日時点で、当サイトには局所的なスクロール、画像幅の指定、キャプションのスタイルがありましたが、最終的には実際の記事を読む必要があります。文字を何度も小さくして、ようやく収まるような内容なら、情報の組み立て方を見直す価値があります。

参考資料

[1] https://www.w3.org/WAI/WCAG22/Understanding/reflow.html — W3C — Understanding SC 1.4.10 Reflow [2] https://html.spec.whatwg.org/dev/grouping-content.html — WHATWG — Grouping content: figure and figcaption [3] https://www.w3.org/WAI/tutorials/images/decision-tree — W3C WAI — An alt Decision Tree