スマートフォン版はデスクトップ版の縮小ではありません：カラム数より読み順を優先します

デスクトップでは、見出し、説明、UIのイメージを並べて見せられます。スマートフォンでは、それらの順序をもっと具体的に考える必要があります。読者が次の内容を理解するには、どの部分を先に読む必要があるか、ということです。

3カラムを1カラムに変えるだけでは、この問題は解決しません。重要な制約がずっと下にあったり、必要な説明より先に行動を促すリンクが現れたり、UIのイメージが最初の画面を埋めたりすると、内容がすべて残っていても、読者は理解の手がかりを見失うことがあります。

私はまず、内容を上から下へ読み進められる1本の流れとして整理し、そのあとで、広い画面で横に並べる意味がある部分を決めます。このノートでは、2026年10月24日に記録したこのサイトのサービス、ノート、製品ページの構造を例に、順序と実装上の取捨選択を考えます。スマートフォンでの見た目に問題がないと確認できた、という報告ではありません。

まず1カラムで読める順序を整え、デスクトップでの配置を決めます

このサイトのサービスカードは、サービス名と説明、対応項目と補足の制約事項、最後にUIのイメージという順序になっていました。中程度の幅では、テキストのグループとUIのイメージを2カラムに配置していました。さらに広い画面では、テキストのグループにdisplay: contentsを指定し、その内容を外側のグリッドに配置して3カラムにしていました。

スマートフォン用のカードを別に複製していたわけではありません。カラム数が変わっても、使うのは同じ見出し、説明、対応範囲のデータです。狭い画面では、何を扱うサービスかを知り、対応範囲を読んでからUIのイメージを見る順序になります。デスクトップの画面をそのまま比例縮小するものではありません。

内容を確認するときにも、この考え方が使えます。左右の位置はいったん考えず、見出し、段落、リストの順序だけで、そのセクションが何を伝えたいのか理解できるかを見ます。制約を理解するために「右側の図」に頼る必要があるなら、1カラムにしたときに関係が伝わるよう、文章をもっと明確にする必要があります。

ただし、1カラムから整理するのは私の設計の出発点であって、すべてのサイトに同じ読み順を求めるものではありません。ニュース、比較表、ワークフローでは、内容同士の依存関係が異なる場合があります。内容に合わせて考える必要があります。

DOMの順序、見た目の位置、フォーカス順序は分けて考えます

CSSでは、要素を別のグリッド位置に置いたり、orderで並びを変えたりできます。ただし、画面上で前に移したからといって、文書自体の順序やキーボードでたどる順序まで変わるわけではありません。

W3CのMeaningful Sequenceでは、順序が意味に影響するとき、正しい読み順をプログラムによって特定できることを求めています。妥当な順序が複数ある場合も明確に認めており、すべての内容に唯一の並べ方を求めているわけではありません。[1]

そのため、互いに依存しない2枚の記事カードの位置を入れ替えることと、必要な説明を送信ボタンのあとに移すことは、別の問題です。前者は順序を変えても理解できる場合がありますが、後者は操作の前に必要な情報を得られるかを確認する必要があります。見た目がよいという理由だけでは判断できません。

キーボードでたどる順序も、別に確認する必要があります。W3CのFocus Orderが重視するのは、フォーカス順序が意味と操作性を保っているかどうかです。すべてのフォーカス可能な要素を、見た目の座標どおりに機械的に並べるよう求めているわけではありません。[2] 見た目は左から右へ続いているのに、Tabを押すと、まだ理解していないセクションを何度も飛び越えるなら、レイアウトと文書構造を見直す理由になります。

私は、デスクトップで順序のずれた内容を見た目に合わせるために、まず正の値のtabindexをいくつも追加するような対処はしません。先に、内容の依存関係と、ネイティブのリンクやコントロールの順序を確かめ、そのうえで必要なレイアウトを考えます。

同じカードでも、長さの異なる内容を収められるようにします

このサイトの通常のノート一覧は、狭い幅では1カラムで、設定したブレークポイントに達すると2カラムになる構造でした。どちらの配置でも、同じ記事データとカードコンポーネントを使っていました。

ここから言えるのは、データと描画の入口を共用していたことだけです。どんな長さのタイトルでも収まりがよいと証明できるわけではありません。短いタイトルと2行の要約が整っていても、長めの英語や日本語に変えたあと、リンクが見つけやすい位置に残るとは限りません。

確認するときは、タイトルも要約も長めのカードを選び、カテゴリー、タイトル、要約、記事を読むリンクの順にたどります。まず情報が欠けていないかを見てから、余白、改行、カード同士の並びのリズムを確認します。先に高さを固定して、配置が難しい内容を切り落とすことはしません。

一方、ピックアップ用カードには、デスクトップ向けのグリッド配置が別にありました。通常の一覧が自然な順序で並んでいることから、サイト全体で並べ替えがないとは推測できません。レスポンシブなレイアウトを確認するときは、「スマートフォン版は問題なし」とだけ記録するのではなく、どの種類のカードと、どの階層のコンテナを見たのかを明確にする必要があります。

UIのイメージは、いつも同じ位置に置く必要はありません

このサイトの製品ページの機能説明では、見出し、説明、箇条書きのあとにUIのイメージを置き、広い画面では両者を横に並べていました。UIのイメージの領域にはaria-hidden="true"を指定し、機能を理解するための説明は、その前のテキストで伝える構造でした。

製品ページの冒頭は、別の配置でした。狭い画面向けの特定のブレークポイントでは、UIのイメージを絶対配置に変え、不透明度を下げてテキストの背後に置いていました。同じページの中でも、すべてを順番に縦に積む以外の方法が使われていたということです。

どちらも、1文の説明を理解するために、小さく縮めたUIを先に読み解かなくてよいことが判断の基準です。装飾は背景に回せます。ただし、図に本文では説明していない重要な情報が含まれているなら、隠したり薄くしたりするだけでは足りません。理解できる代替コンテンツも必要です。

サービスカードのUIのイメージも、操作できる製品画面ではなく、装飾的な構造でした。位置や比率はレイアウトに合わせて変えられますが、一緒に仕事を進めたり、内容を読んだりするために、そのUIのイメージをクリックする必要があると読者に誤解させてはいけません。

ブレークポイントだけでなく、ひと続きの内容を読んで確かめます

私は、セクションの冒頭から行動を起こすための入口までを通して読みます。何を扱っているかを知り、自分に関係する範囲を理解し、必要な制約を読んで、最後に何ができるかが分かる順序です。ある幅でカラムが下に移ったかどうかだけを確かめるより、内容そのもののつながりが切れている箇所を見つけやすくなります。

確認方法も切り替えます。見た目を確認したあと、キーボードでリンクまでたどり、必要に応じてアクセシビリティツリーや支援技術での読み上げも調べます。多言語のページには、それぞれの実際の文章を入れる必要があります。同じ短い仮の文言だけで、すべての言語版を代表させることはできません。

長い記事のコード、表、画像には、それぞれリフロー上の問題があります。このノートでは、セクション同士の読み順の依存関係を扱います。どちらも実際の内容で確かめる必要がありますが、一覧を一度確認しただけで、記事レイアウト全体の確認も済んだとは言えません。

このノートで整理したのは、当時の構造と、私が使う確認方法です。すべての端末、キーボード操作全体、支援技術での確認に合格したという記録はなく、WCAGへの適合を認証するものでもありません。スマートフォンでのレイアウトは、最後に人が実際に読む必要があります。左右の並びをなくすと内容が分からなくなるなら、カラム幅を微調整する前に、順序を見直すべきです。

参考資料

[1] https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html — W3C — Understanding SC 1.3.2 Meaningful Sequence [2] https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html — W3C — Understanding SC 2.4.3 Focus Order