【ITニュース解説】A Wide HTML Table Broke the Mobile Page. I Fixed the Generator.

ウェブサイト開発において、特にモバイルデバイスでの表示は重要な課題だ。今回の事例は、まさにその課題に直面し、解決したプロセスを示している。システムエンジニアを目指す初心者にとっても、このような具体的な問題解決のプロセスは非常に参考になるだろう。

このウェブサイトでは、一部のページをスマートフォンなどのモバイル端末で見た際、ページ全体が横に広がり、読者が横スクロールをしないとコンテンツ全体が見えないという問題が発生していた。通常、モバイル向けに最適化されたウェブサイトでは、画面の幅に合わせてコンテンツが自動的に調整され（これを「リフロー」と呼ぶ）、縦方向のスクロールだけで閲覧できるのが理想だ。しかし、このサイトでは幅の広いデータテーブルが表示されると、ページ全体がテーブルの幅に合わせて広がってしまっていたのだ。

なぜこのようなことが起きるのだろうか。ウェブページはHTMLという言語で構造が定義され、CSSという言語で見た目がデザインされる。特にHTMLの<table>タグ、つまり表を作成する要素は、その中に入れるデータ（テキストや数字など）の量や種類に合わせて、自動的に自身の幅を調整しようとする性質がある。例えば、半角スペースで区切られたり、改行されない長い単語やコードの塊がセルの中に入っていると、テーブルはそれらを無理に折り返さず、自身の幅をどんどん広げてしまう傾向がある。

問題は、このテーブルの広がりが、テーブル自身の枠内に収まらずに、ページ全体の幅に影響を与えてしまったことにある。一般的なウェブページの表示では、ブラウザはコンテンツの幅に合わせてページ全体の幅を決定する。もしコンテンツの中に画面幅を超える要素があれば、ブラウザはページ全体をその要素の幅に合わせて広げ、結果としてページ全体に横スクロールバーが表示されることになる。これでは、文章を読んでいる途中でいちいち横にスクロールしなければならず、読者にとって非常に不便だ。ウェブの標準を定めるW3C（World Wide Web Consortium）のガイドラインでも、文章を読むようなコンテンツは画面幅に合わせてリフローし、横スクロールなしで読めるべきだとされている。ただし、データテーブルのように元々二次元的なレイアウトを必要とするコンテンツについては、その要素自身の内部でスクロールできるようにするのが望ましい、と区別されている。つまり、テーブルを無理やり狭めてデータを隠すのではなく、テーブル自体がスクロールできるようにすることが適切な解決策なのだ。

この問題に対処するため、ウェブサイトの管理者はまず修正箇所を特定する必要があった。一般的にウェブサイトのデザインはCSSファイルで管理されているため、単純に「スタイルシートを編集すればいい」と考える人もいるかもしれない。しかし、このウェブサイトでは新しい記事が作成される際、直接HTMLやCSSを手書きするのではなく、「md2canonical.py」というPythonスクリプト製の変換ツールが使われていた。このツールは、Markdown形式で書かれた原稿を、CSSも埋め込まれた一つのHTMLページに自動的に変換する役割を担っている。つまり、CSSファイルを直接修正しても、新しく生成される記事にはその変更が反映されない。常に最新の記事が生成される経路、つまりこの変換ツール自体を修正しなければ、根本的な解決にはならない、と判断されたのだ。今回の修正は、今後生成される記事にのみ適用され、既に公開されている古い記事、つまり横スクロール問題が確認された44ページは対象外とされた。これは、過去のデータをすべて修正するよりも、将来の問題発生を防ぐことを優先した判断だ。

具体的な修正内容は以下の通りだ。変換ツールは、Markdown形式のテーブルを見つけると、それを単にHTMLの<table>タグに変換するだけでなく、その<table>タグを <div class="table-scroll">という新しいHTML要素でラップ（包み込む）するように変更された。このdiv要素が、テーブルの幅が画面を超えたときに横スクロールを可能にする「コンテナ」となる。

このdivコンテナには、アクセシビリティを高めるための属性も追加された。

• role="region"：これは、このdivがページ内で独立した重要なコンテンツ領域であることを、スクリーンリーダーなどの支援技術に伝える役割を持つ。視覚に障がいのあるユーザーが、この領域にアクセスしたときに、それが何であるかを理解しやすくなる。
• tabindex="0"：キーボード操作だけでウェブサイトを閲覧するユーザーのために、このコンテナにキーボードでフォーカス（選択状態）を当てられるようにする属性だ。フォーカスを当てれば、矢印キーなどでテーブルの中を横スクロールできるようになる。
• aria-label：この領域が何についてのテーブルであるかを、スクリーンリーダーなどの支援技術に明確に伝えるためのラベルだ。このラベルは、テーブルの直前にある見出しから自動的に生成される。

そして、この新しいdivコンテナに対して、以下のCSSルールが適用された。

• overflow-x: auto：これが最も重要なプロパティだ。コンテナのコンテンツが横方向に自身の幅を超えた場合に、自動的に横スクロールバーを表示させる。これにより、テーブル全体がページを広げるのではなく、テーブルがこのdivコンテナの中で横スクロールするようになる。
• max-width: 100%：これは、このコンテナの最大幅を親要素（この場合はページ全体の幅）の100%に制限する。これにより、コンテナ自身が画面幅を超えて広がることを防ぐ。
• overflow-wrap: break-word：これはbodyタグ全体に適用されたCSSプロパティだ。非常に長い単語やURL、コードなどが改行されずに横に飛び出すのを防ぎ、必要に応じて単語の途中で改行して、コンテンツが親要素の幅内に収まるようにする。これにより、テーブル以外の部分でも、長すぎるテキストがページ幅を広げることを防げる。

また、この修正作業のついでに、全てのh2とh3タグ（見出し要素）に一意のIDが自動的に付与されるように変更された。これにより、ウェブページ内の特定のセクションへの直接リンク（アンカーリンク）を作成できるようになり、コンテンツのナビゲーションが向上する。ただし、「FAQ」や「Related notes」といった特定の文字列の見出しは、他のスクリプトがそのテキストに依存しているため、意図的にID付与の対象から外された。既存のシステムとの互換性を保つための配慮だ。

修正が完了したら、それが本当に問題を解決したのかを徹底的に確認する必要がある。今回のケースでは、まず新しいテスト用のノートを生成し、幅の広いテーブルや長いインラインコード、繰り返し出現する見出しなど、問題を引き起こしそうな要素を意図的に含ませた。そして、このテストページを、モバイル端末をエミュレートした複数の画面幅（320、375、768 CSSピクセル）で表示し、確認を行った。

最も重要な確認事項は二つだ。一つは、「ドキュメント（ページ全体）の幅が、閲覧している画面（ビューポート）の幅と正確に一致しているか」という点。確認の結果、いずれの画面幅でもページ全体の幅はビューポート幅と一致しており、ページ全体が横スクロールすることはなくなっていた。もう一つは、「テーブル内の全てのデータに、キーボード操作でアクセスできるか」という点。テーブルをラップしたdivにキーボードでフォーカスを当て、矢印キーで横スクロールできることを確認し、テーブルの左右両端のデータまで到達できることを確かめた。これにより、データが隠れてしまうことなく、誰もがアクセスできるようになった。

さらに、既存の自動テストも実行され、変換ツールやその他の関連スクリプトの機能が、今回の変更によって損なわれていないことが確認された。一部のテストは失敗したが、それらは今回の変更以前から存在していた既知の失敗であり、今回の修正とは関係がないと判断された。

ただし、この修正にはいくつかの限界もある。テストは主に「Playwright」という自動テストツールを使って「Chromium」というブラウザエンジン（Google Chromeの基盤）上で行われた。そのため、Safariのような他のブラウザでの表示や、実際のスマートフォンデバイスでの動作は確認されていない。また、スクリーンリーダーを使って、アクセシビリティが本当に向上したのか、音声で正しく読み上げられるか、といった点も直接は確認されていない。role="region"やtabindex="0"といった属性を追加することで、理論上は支援技術への対応が進むはずだが、実際に使ってみての検証は今後の課題だ。

そして、この修正はあくまで「今後に生成される記事」にのみ適用される。既に公開されて横スクロール問題を起こしている44ページについては、今回手は加えられていない。また、今回の修正がウェブコンテンツアクセシビリティガイドライン（WCAG）全体への完全な準拠を保証するものではないことも明確にされている。これは、特定の具体的な問題に対する修正であり、ウェブサイト全体のアクセシビリティを網羅的に検証したわけではないからだ。

今回のプロジェクトから得られた教訓は二つある。一つは、「次に生成される成果物が実際に通る経路を修正する」ということ。表面的なCSSファイルを修正するのではなく、コンテンツが生成される根本的な仕組みを理解し、その経路を修正することが重要だ。もう一つは、「幅の広いコンテンツを修正する際には、単にテーブルがスクロールするかどうかだけでなく、ページ全体の幅がビューポートと一致しているか、そしてキーボード操作で全てのコンテンツにアクセスできるかを、別々に測定して確認する」という点だ。これらの教訓は、システムエンジニアとしてウェブ開発に携わる上で、常に心に留めておくべき重要なポイントとなるだろう。