はじめに
この文章はhtml5で静的webページを制作するにあたって気になった点を、ボックスモデルを中心にまとめた個人的な考察です。
正確な情報やわかりやすい実例などは聖典(仕様書)や、各セクション冒頭のリンクや、「参考」セクションのリンクをなど参照してください。
また誤りがあればコメントをいただければ嬉しいです。
参考
html5/css3におけるボックスモデル
cssにおいて、ブロックレベル・インラインなどを利用してレイアウトを組める仕組みを「ボックスモデル」という。
この「ボックスモデル」はcssの仕様であると共にhtml4.01の仕様でもあったが(「divタグはブロックレベル要素」など、特定のhtmlタグが特定種類のボックスと紐付いていた)、 html5では「コンテントカテゴリ」という新しい区分けに置き換わり、cssの「ボックスモデル」と明確に区分けされた。 つまり、html5ではどのタグにどの種類のボックスを割り当ててもいいようになった。
とはいえブラウザのデフォルトcssにおいて、html4.01の時のブロック・インラインの区分けはhtml5にも引き継がれている。html5では、大まかにはflow contentがブロックレベル要素に当たり、phrasing contentがインライン要素となっているが、これは仕様書には明記されていない、付加的な区分けである。
なお、css3の「ボックスモデル」とcss2の「ボックスモデル」は仕様が違う(どのくらい違うかは知らない)ということなので興味があれば仕様書参照。
画像引用元: https://developer.mozilla.org/ja/docs/Web/HTML/Content_categories
sectioning content
セクション(章)を構成する要素。DOMが解析される際、 html4.01まではh1~h6(heading content)が現れた所からそのhタグのレベルに応じてセクションが構成されたが、html5ではsectioning contentが現れたところからセクションが構成される。
そのためセクションの構成にheading contentは必須ではなくなった(しかし一般的に各セクションには表題が設けられているため、sectioning contentの小孫要素にはheading contentを置くべきである)。
- article
- aside
- nav
- section
sectioning roots
sectioning rootはアウトラインを持ち、そこに含まれるsectioning contentsは(親のアウトラインにのみ影響し、)自身の祖先のアウトラインには影響しない。
- blockquote
- body
- fieldset
- figure
- td
heading content
各セクションの「ヘッダー」を定義する。各セクションはsectioning contentによって明示的に定義されるか、 そうでなければheading content自身が暗黙的にセクションを定義する。
bodyの構成するアウトライン中で使われた時は、各セクションやアウトラインではなく、そのwebサイト全体の表題を表す。nav(目次)やfooter(著作権・法的通知)も同様の使われ方をした場合、webサイト全体の目次や著作を表す役割を持つ。
※headerタグは単にもっとも近い祖先の、sectioning contentの前書きのグループを定義するためのflow contentに過ぎず、sectioning contentあるいはheading contentではない事に注意。
- h1 ~ h6
flow content
body内で使用されるほとんどの要素がこれに含まれる。
flow contentはそれぞれに様々な意味と役割を持つ。
WAI-ARIA
現在、音声ブラウザやスクリーンリーダーなどでは、多くのwebページに含まれるajaxに対応できず、アクセシビリティが低い。
これはajaxはほとんどの場合マウス・タッチパネルによる操作を前提としているためで、例えばajaxによって動的に更新されるDOM要素は、従来のスクリーンリーダーでは検知されず読まれない。あるいは折り畳み式のメニューは、スクリーンリーダーだと折りたたまれていることがわからない。
googleではこれらの問題に対応するため(また自社のクローラーが正確に動作するようにするため)、javascriptを用いない環境でもwebページが正常に動作するように設計するよう勧めている。表題にもあるWAI-ARIAを利用しないならば、これが最善の解決策となる。
しかしこれらの問題はajaxを多用したwebアプリケーション(javascriptによる動的更新がなければ正常に動作しない、デスクトップアプリケーションに近い機能を持つページを指す)において特に顕著であり、また根本的な問題としても、多様化・高機能化するwebコンテンツの情報を、htmlによるマークアップのみで表現するには限界がある。
そこで、ajaxで動的に生成される要素に対してもアクセシビリティを確保するための規格がWAI-ARIA(Web Accessibility Initiative-Accessible Rich Internet Applications)である。より詳細な情報はリンクを参照してほしいが、google glassやApple watchといったウェアラブル端末の普及を考えると、WAI-ARIAの重要性は今後増していくと考えられる。
複数のh1を使用することについての、アクセシビリティ上の懸念
結論から言えば、 英語圏においては 各セクションごとにh1を複数使用することは、2015年現在ほとんど問題ない。
過去(2011年頃)にあった懸念としては、音声ブラウザなどのhtml5対応が進んでおらず、DOMツリーの解析ができずにアクセシビリティに支障をきたすというものだった。音声ブラウザは文章の階層構造を認識できない(できなかった)ため、すべてのh1タグが最重要として読まれてしまうのだ。cssによるスタイリングによって情報を補完できない音声ブラウザユーザーにとって、これは重大な問題となる。
しかし現状、英語圏のユーザーに限って言えば、ほとんどのアクセシビリティを必須とするユーザーはchromeあるいはfirefoxなどの(html5をサポートする)モダンブラウザを利用しているため、このような懸念はもはやほとんど存在しない。
国内の主要音声ブラウザがhtml5に対応しているかは、確認する必要がある。おそらくIE9以上なので問題はないだろうと思われる。