SEO関連では裏技なんてない。本来の用途でHTMLを作成し、人間が読みやすいという絶対的な観点で施策をせず、ハック的な考えを遂行してしまうと必ず報いを受ける。
table要素は昔、ハック的にレイアウトを作るために使われていたが、アクセシビリティの観点で現代では広く知られるバッドプラクティスのひとつになっている。
F49: 達成基準 1.3.2 の失敗例 － 線形化したときに、意味を成さない HTML のレイアウトテーブルを使用している
WCAG 2 はレイアウトテーブルの使用を禁止していないが、HTML の
https://waic.jp/docs/WCAG-TECHS/F49table要素の定義されたセマンティックな意味を保持し、コンテンツから提示を分離するコーディングの慣習に従うためにも、CSS ベースのレイアウトが推奨される。それにもかかわらずレイアウトテーブルを使用する場合、線形化したときにコンテンツが意味をなすことが重要である。
この失敗例は、コンテンツの視覚的配置を制御するために使用される HTML テーブルが正しく「線形化」されないことによって、提示を通じて伝えられる意味のあるコンテンツの順序が失われた場合に発生する。テーブルは、横及び縦の二つの視覚的な次元でコンテンツを提示する。しかし、スクリーンリーダーは、この 2 次元コンテンツを最初の行の最初のセルから最後の行の最後のセルまで、ソース内のコンテンツの線形的順序で提示する。スクリーンリーダーは、上から下にテーブルを読み上げ、次の行に移動する前に各行の内容全体を読み上げる。セル内にネストされたテーブルのすべての内容を含む、各行の各セルのすべての内容が読み上げられる。これは線形化と呼ばれる。
あるウェブページが 22 行 9 列のテーブルによってレイアウトされているとしよう。スクリーンリーダーは最初に 1 行目の第 1 セル、続いて第 2、第 3、第 4 と第 9 セルまで読み上げる。しかし、いずれかのセルがネストされたテーブルを含む場合、スクリーンリーダーはネストされたテーブルのすべての内容を、元の (外側の) テーブルの次のセルよりも先に読み上げる。 たとえば 6 行目 3 列のセルに、5 行 6 列のテーブルが含まれる場合、含まれたテーブルのすべてのセルが、元の (外側の) テーブルの 6 行目 4 列のセルよりも先に読み上げられる。その結果、視覚的提示によって伝えられている意味のある順序がスクリーンリーダーによる読み上げでは知覚できないかもしれない。
つまり、視覚的にうまく配置できるからといってtableを使うと、スクリーンリーダーはtableのソースコード上の上の列の一行目から順に読むため、見えているコンテンツとソースコードの内容が異なってしまうかもしれない。
あるいは意図しないところで分割されるなどの現象が起こってしまうかもしれない。
表題だが、うまい儲け話などないのと同じで割と広範に適用できるかもしれない。
ただ、本来の使い方でしかものを使わないという頭の固さを持つのはダメで、柔軟な発想がクリエイティブには大切で、その意識は忘れてはいけない。
あくまでSEOという世界ではという話である。