こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、freeeの伊原力也さんと、ビジネス・アーキテクツの太田良典さんです。

お二人のセッション「多様なユーザーニーズに応えるフロントエンドデザインパターン〜書籍「インクルーシブ HTML + CSS & JavaScript」より」に関するスライド資料は、こちらで公開されています。

「インクルーシブ」に込められた意味とは？

白石: 今回は取材をお受けいただきありがとうございました！簡単に自己紹介をお願いします。

太田: ビジネス・アーキテクツに所属している太田です。大規模企業サイトの構築、ガイドライン策定などを行ってきました。

Webアクセシビリティ関連に昔から取り組んでいまして、「Webアクセシビリティ基盤委員会」の翻訳作業部会主査を担当しています。

▲株式会社ビジネス・アーキテクツ 太田良典さん　　※写真提供：html5j [HTML5 Conference 2017事務局

伊原: freee株式会社の伊原です。Webサイトやアプリケーションの情報設計を行っています。私もWebアクセシビリティ基盤委員会に所属しており、「理解と普及作業部会」にて活動しています。

他には、HCD-Netという人間中心設計を推進する団体でも活動しており、UXデザインの普及に務めています。

▲freee株式会社 伊原力也さん　※写真提供：html5j [HTML5 Conference 2017事務局

白石: 本日は、HTML5 Conferenceでお話された内容を主にお聞きしたいのですが、このセッションは、今度出版される書籍を元にしてらっしゃるんですよね。

伊原: はい、11月4日に出版される「インクルーシブ HTML + CSS & JavaScript」という書籍の内容をベースにしています。

私たちは2年ほど前にデザイニングWebアクセシビリティという書籍を、その半年ほど前にはコーディングWebアクセシビリティという書籍を上梓しました。

今回のセッションの元になった書籍は、いわばそうした流れを組んだ最新のものだといっていいと思います。特にコーディングWebアクセシビリティとは、著者も同じヘイドン・ピカリング氏ですし、続編といって差し支えないかと思います。

白石: では、今回もWebアクセシビリティに関する書籍なんですね。

太田: そうです。「コーディングWebアクセシビリティ」では特に、WAI-ARIAの使い方について詳しく論じられていました。WAI-ARIAの基本的な知識はあっても、「なぜそう書くのか」「いつどう使うのか」を知らない方に向けて、具体的な例を挙げつつ語った本です。

白石: では、今回の書籍は「インクルーシブ HTML + CSS & JavaScript」となっているわけですが、これはどういう内容の本なのでしょうか？

伊原: 原著のタイトルは「Inclusive Design Patterns」と言うのですが、サブタイトルは「Coding Accessibility Into Web Design」（Webデザインの中にアクセシビリティをコーディングする）となっていて、こちらの方がわかりやすい(笑)。

ぶっちゃけて言えば、アクセシビリティに配慮したコーディング例を具体的に挙げていっているという本です。

原著者がなんで「インクルーシブ」という単語を用いたかというと、「アクセシビリティ」というと、「アクセシビリティガイドラインを満たしていくこと」とか、「特定の障害を持つ人に向けた配慮」というニュアンスが強く根付いてしまっているからだと言っています。

また、「アクセシビリティ」という言葉自体には、デザインや設計という意味は含まれていない。アクセシビリティとは単に「アクセスできる可能性の度合い」のことですから。

一方でインクルーシブというのは「包括的」とか「全てを包む」といったニュアンスを含む英単語で、「できるだけ受け入れる」とか「できるだけ含める」という意味合いがあります。原著者が「インクルーシブ」という単語を用いたのは、「できるだけ多くの人に使ってもらえる」「できるだけ多くの状況で使える」ものをデザインしていこう、という意図なんです。

太田: ただ、日本語版では元のタイトルにある「デザインパターン」という言葉は使いませんでした。Web制作の世界では、「デザインパターン」と言う単語からはWebデザインを想起してしまいがちなので…。

アクセシビリティにおいては、そういう（UI）デザインのニュアンスだけが強いわけではありませんからね。

白石: 「デザインパターン」という単語は、エンジニアの方であれば逆に馴染みはあるかもしれませんね。

しかし、「コーディングWebアクセシビリティ」や「デザイニングWebアクセシビリティ」という書籍がありながら、今回新しい書籍を出版されたのはどういう背景があるのでしょうか？

太田: ここ10年くらいで、JavaScriptを用いた動的なUIがすごく普及しました。Ajaxがその立役者で、JavaScriptを利用して非同期にUIを書き換えるような作り方が一般的になってきました。

おかげで、WebサイトのUXは全般的に向上しましたが、一方で、アクセシビリティ的には新たな課題を抱えることにもなったわけです。元々、HTMLはアクセシブルに設計されているのに、JSがそれを損なってしまうケースが散見されるようになったのです。

例えばフォーム送信などは良い例です。昔ながらのフォームで、「送信」ボタンを押したら次のページ…という流れであれば、アクセシビリティに問題はあまりありません。ただこれを、JavaScriptを用いてAjaxでデータ送信するようにした途端、アクセシビリティが低下してしまうことが多い。

伊原: そもそも、JSで「アプリ」を作ろうとすると、アクセシビリティへの配慮がされにくくなりがちです。ほとんどdivやspanでマークアップして、見た目上動けばOK…という場合が少なくありません。

それを、セマンティックなHTML要素とWAI-ARIAを活用して、アクセシブルでUXにも優れたWebアプリを作ろうというのが、この「インクルーシブ HTML + CSS & JavaScript」で述べていることです。

実践！アクセシブルな商品リストを作ってみる

白石: では、アクセシブルなマークアップの具体的なパターンを幾つかお話いただきたいと思います。

ただ、セッションの内容全体についてはスライド資料をご覧になってもらえればいいと思うので、ここでは、私が個人的に疑問に思ったことなどを遠慮なくツッコませていただきつつ、ポイントとなる部分をおさらいしていっていただけると嬉しいです。

伊原: わかりました。では一つ目の例として、商品リストを見ていきます。

このサイトは画像アセットを購入できるサービスという想定ですが、UIデザインについては、Amazonの検索結果のようなものを想像して頂ければいいと思います。

リストの項目それぞれは商品名やレビュー結果、そして「すぐに購入」ボタンなどがあります。

これが複数縦に並んでいるリストをイメージしてください。

白石: こういう一覧の実装方法っていろいろですよね。個人的には、単にdivを並べるときもあれば、表っぽければtableを使うときもあります。

伊原: まず、リストそのものはリスト要素（ulやol）を使ってマークアップした方がいいかなと思います。

ここでリスト要素をお薦めするのは、要素の意味合いがわかりやすいのと、スクリーンリーダーがリストを読み上げるのに特別な機能を持つからですね。

太田: 例えばスクリーンリーダーは、リストの項目数を先に読み上げたり、前後のリスト項目にジャンプしたりできるんです。項目数って結構大事で、項目数が多い場合と少ない場合では、ユーザーの行動も変わってきますからね。

白石: なるほど。

伊原: また商品名ですが、見出し要素を使用するのが最適です。スクリーンリーダーは見出しに直接飛んだり、直前の見出しを読みあげたりすることもできる。 リストと見出しを組み合わせることで、一覧の見出しを飛ばし読みしていくようなことが可能になるんです。

まとめると、以下のようなマークアップがおすすめですね。

<li>
  <h3>
  ガソリンスタンドにたたずむ裸の男 <a href="/artist/kenny-mulbarton">by <cite>ケニー・マルバートン</cite></a>
  </h3>
</li>

白石: liの中に見出し要素を置くと、リスト項目が全て個別のセクションということになりますが、それは問題ないんでしょうか。HTML5からは、見出し要素は暗黙的にセクションを構成するようになりましたよね。

太田: はい、確かにセクショニングアルゴリズムの観点から、liの中にh3を入れることを望ましくないと考える人もいるかもしれません。ここは意見が分かれるところでしょうね。 ただ、アクセシビリティの観点からは支援技術で実際に使えるかどうかが重要で、その意味では十分に実用的だと言えると思います。

「今すぐ購入」ボタンはボタンにする？それともリンクにする？

伊原: 次は、「今すぐ購入」ボタンをどうマークアップするかを検討してみましょうか。

白石: うーん、これはbutton一択じゃないですか？

伊原: それもアリです。buttonを使うケースとしては、JavaScriptと組み合わせて、購入処理をその場で行えるようにするような場合ですね。

でもこの例のサイトは一般的なプリント写真購入サイトをイメージしているものなので、「今すぐ購入」ボタンを押したら、写真の購入確認画面に飛ぶことになります。

白石: そうなると、写真の購入確認画面へのリンクとして実装したほうが良さそうですね。

伊原: はい、そのほうがJavaScriptがなくても動きますし、要素の意味合いも明確になります。ここではa要素を使いましょう。

以下のようなマークアップがまずは望ましいですね。

<a href="/product/naked-man-in-garage" class="button">今すぐ購入</a>

白石: このマークアップだと、class="button"となっていますし、CSSで見た目をボタンっぽくするイメージですね。例えばWAI-ARIAを使って、このリンクのロールをボタンにするというのはいかがでしょうか？

<!-- role要素でbuttonを指定 -->
<a href="/product/naked-man-in-garage" role="button">今すぐ購入</a>

伊原: あ、それはやめてください。これでは、元のHTML要素が持つセマンティクスが変わってしまい、この要素はリンクではなくボタンであるという意味合いになってしまいます。

白石: なるほど、ここでは見た目だけボタンにしておいて、セマンティクスは変えないのが望ましいと。

太田: そうなんです。WAI-ARIAって覚えると濫用されがちな技術でもありますが、基本的には「WAI-ARIAは使わない」のが正しい。

W3Cの「Using WAI-ARIA」という文書の先頭に書いてあるのは、「（HTMLでまかなえる場合は）WAI-ARIAは使うな」なんですよ(笑)。

例えばボタンや見出しがあったとしたら、素直に<button>や<h1>を使えば良い。WAI-ARIAを使う必要は必ずしもないんです。基本的にはHTML5の語彙を用いて、足りないところをWAI-ARIAで補う、という形が望ましい。

リンクテキストにも配慮しよう！

伊原: あともう一つ考えてみたいのは、リンクテキストです。このままだと全てのリンクが「今すぐ購入」になってしまいますが、それってアクセシビリティに優れていると言えるでしょうか？

白石: うーん…見出しに商品名はあるので、全くアクセシブルじゃないとは思いませんが。リンクテキストも読み上げられるんですよね？全部が「今すぐ購入」じゃ不親切かも？

伊原: そうです。「何を購入できるか」が、リンクテキストから分かると、よりアクセシブルですよね。

なので、非表示のテキストでリンクテキストをより詳細化すれば、UIデザインも損なわれません。

<a href="/product/naked-man-in-garage" class="call-to-action">
  <span class="visually-hidden">ガソリンスタンドにたたずむ裸の男を</span>今すぐ購入
</a>

白石: なるほど、不可視のテキストも利用してより説明的にするとは…！アクセシビリティへの配慮を真面目に考えてないと、まず出てこない発想ですね。

伊原:ちなみに他にもやり方はいくつかありますが、この本ではSEOにおける内部対策的な意味合いも込めて、このやり方が推奨されています。

検索結果ページ（SERP）にも配慮する

伊原: 最後に、検索エンジンの結果ページで商品（Search Engine Result Pages）がどう見えるか、についても配慮した方がいいでしょう。

白石: 検索結果ページですか？なんでですか？

伊原: 支援技術ユーザーの中には、目的のページに辿り着くために、検索エンジンのインターフェースを利用する人も多くいるんです。Google検索って、site:を前につけるとサイト内検索を行えるじゃないですか。

白石: ああなるほど。言われてみれば、ぼくもAmazonの中検索するのに、Google検索をよく使います(笑)。

伊原: 例えばマイクロデータとschema.orgを使えば、検索結果の表示をより充実させることが可能です。以下に、商品のレビュー結果を表すマークアップの例を示します。

<span itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating">
<span itemprop="ratingValue">4</span>つ星、
レビュー数<span itemprop="reviewCount">13</span>
</span>

白石: そうか、今までぼく、「マイクロデータ使っとけば検索結果ページで目立てるかな」くらいしか考えたことなかったんですが、アクセシビリティの点から考えても重要なんですね。あんまりちゃんと意識したことなかったです。

見た目ではなく機能でマークアップせよ！

伊原: では次の例に移らせてください。表示結果を絞り込んだり並び順を変えたりするUIを実装してみたいと思います。

白石: うーん、こういうの実装するんだったら、ぼくだったらどうするかなあ。ナビゲーションメニューみたいなものと捉えて、リストとa要素とかでやるかもしれません。

伊原: それも悪くないのですが、このメニューって、どれかが選択中の場合は他のメニューを選択できませんよね。それってどうします？

白石: …JavaScriptのお世話にならざるを得ないかもしれません。

伊原: そう、でも、標準のHTMLには、そういう「排他的」な選択を行うためのフォーム要素があります。

白石: …ラジオボタン、ですか？

伊原: そのとおりです！

このデザインだけからだと、見た目はラジオボタンとは似ても似つきませんが、ここではラジオボタンを使うことにします。マークアップの段階では、見た目ではなく機能に沿ってマークアップするのが重要ですから。

ラジオボタンのスタイリング…やりにくい！どうする？

白石: でも、ラジオボタンは「◎」みたいな余計なUIがくっついてきちゃいますよね？しかもあれがブラウザごとに異なる上、どのブラウザのデザインもあんまりカッコよくない(笑)。

伊原: そうなんです。ラジオボタンってスタイリングしにくいので評判が良くないですよね(笑)。だから、結局他の要素を使っちゃう…なんてことも起きちゃうんですが、そこは工夫次第です。

ここではlabel要素をうまく使って、目標とするデザインを実現しましょう。label要素は、それ自身をクリックすることで、対象となるラジオボタンやチェックボックスの状態を変更できますよね。

白石: ああ、なるほど！labelはクリッカブルな状態で表示しておいて、ラジオボタン本体は隠しちゃえばいいんだ。

伊原: そうです。labelさえあればラジオボタンのクリックは可能ですので、実際のラジオボタンは隠しちゃってもいいんですよね。ラジオボタンのフォーカス状態やチェック状態はCSSの擬似クラスで指定できますので、CSSだけで表示の切り替えが可能です。

例えばこんな感じになります。

<input type="radio" name="sort-method" id="most-recent" checked />
<label for="most-recent">新着順</label>

<input type="radio" name="sort-method" id="most-popular" checked />
<label for="most-popular">人気順</label>
...(略)...

[type="radio"] + label {
  cursor: pointer;
  /* その他、基本のスタイル */
}
[type="radio"]:focus + label {
  /* フォーカス時のスタイル */
}
[type="radio"]:checked + label {
  /* 選択時のスタイル */
}
/* ラジオボタンを見えなくする */
.sorter [type="radio"] {
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  padding:0 !important;
  border:0 !important;
  overflow: hidden !important;
  clip: rect(1px, 1px, 1px, 1px);
}

白石: なるほど、これならHTMLのセマンティクスもわかりやすいし、JavaScriptもいらない。素晴らしい。

伊原: ちなみに、このCSSの!important連打は「とにかく扱いづらいラジオボタンを消し去ってやりたい」という原著者のジョークなので、真似しないでください(笑)。

無限スクロールはやっぱり×？「もっと読む」はどう実装するか

伊原: 最後に、検索結果が複数ページに渡る場合、どういう風なUXが望ましいかを考えてみたいと思います。昔よく使われていたのはページングですが、今は無限スクロールを採用するサイトも多いですね。

白石: はい、ぼくも自社で運営しているTechFeedというアプリで無限スクロールを採用しています。

伊原: ただ、アクセシビリティ的には無限スクロールは使わないほうが無難です。

白石: えっ！いろんなサイトが採用しているし、使いやすいとも思うんですが…

伊原: 理由はいくつかあります。

まず、スクロールという操作が読み込みを誘発することが、ユーザーにとって望ましいことなのかどうか。ユーザーは次のページ読み込みを望んでいないかもしれないですよね。

あと、スクロールバーを使っているユーザーは、新たなページが読み込まれた瞬間スクロールバーが勝手に上下するので、混乱します。

最後に、ページのフッターにたどり着けないことがあります。フッターに要素を置いているにもかかわらず、無限スクロールがあるものだから、フッターに触りたくとも触れない…という事態が起こりうるのです。

白石: ふむ、理由はわかります。では、代わりにどうデザインすべきだと思いますか？

伊原: ページ読み込みをユーザーが制御できればいいので、「もっと読む」ボタンを明示的に設置するというのは一つの解決策ですね。

白石: でも、いちいちそのボタンを押さなくちゃならないというのも結構面倒な気がします…。あと、サービス事業者側としては、無限スクロールでどんどん下に読んでいってもらうことで、ユーザーの滞留時間を伸ばしたいという気持ちもあると思うんですよね。

伊原: この本では、ユーザーが「もっと読む」ボタンをよくクリックするようなら、その時に改めて「続きを自動的に読み込むか」を尋ねるようにするというやり方が紹介されています。その質問に「YES」と答えるのなら、そのユーザーにとっては、先ほど挙げられていた無限スクロールのデメリットが気にならないという証拠でもあると。

白石: なるほど。確かにそのほうがユーザー本位でもありますね。

太田: あとこういう動的にリストを追加する場合、アクセシビリティの観点から一点注意点があります。

読み込みが完了したら、新しく読み込んだデータの先頭にフォーカスを移すことです。そうしないと、スクリーンリーダーのユーザーが、次にどこに行けばいいかわからなくなってしまいますから。

そのために、新たに読み込んだデータの先頭にtabindex="-1"を指定しつつ、JavaScriptでフォーカスを与えます。

...
<li>
  <!-- tabindexを指定して、タイトルをフォーカス可能にする -->
  <h3 tabindex="-1">
    ガソリンスタンドにたたずむ裸の男<a href="/artist/kenny-mulbarton">by <cite>ケニー・マルバートン</cite></a>
  </h3>
  ...
</li>
<li><!-- 新たに表示された商品の2番目 --></li>
...

白石: おお、こういう配慮は全く考えていませんでした。勉強になります。ちなみに、tabindexにマイナス値を指定することなんてできるんですね…知りませんでした。

太田: tabindexにマイナスを指定すると、ユーザーはそこにフォーカスを当てられないのですが、スクリプトでなら当てられるようになります。

「アクセシビリティは0点か100点っていう話じゃない」

白石: 本日は、いろんな例についてマークアップを考えられて面白かったです。

ただ最後に質問があります。

最近のWebアプリはどんどん動的になっていて、「UIのほとんどをJavaScriptで構築する」という場合も少なくありません。Single Page Applicationなんかはその最たるものだと思います。

こうしたサイトでも、アクセシビリティを担保することは可能なんでしょうか？相当の工数をかけないと難しいんじゃないかという気がしているのですが。

伊原: 確かに、SPAのアクセシビリティは面白いテーマです。ただ、SPAだからアクセシビリティの担保が難しいということはないと思います。

というのも、Google DocsやGoogle SlidesはWAI-ARIAにかなり対応していて、コンテンツの読み上げに対応しているんですよ。

白石: え、そうなんですか！それらのアプリ、SPAの代表格みたいなもんだと思ってました…。「SPAはスクリーンリーダーになじまないんじゃないか」なんて思ってましたが、それは単なる思い込みですね。

伊原: どんなサイトでもまずは一回、スクリーンリーダーで読み上げを行ってみることをお勧めします。SPAであっても、意外なほどスクリーンリーダーが綺麗に読み上げてくれることもありますので。

太田: 私はいつも言っているのですが、アクセシビリティって0点か100点かだけではないんです。全くアクセスできないサイトもなければ、全世界のすべての人がパーフェクトにアクセスできるサイトもありません。全てのサイトがその中間のどこかに位置していて、少しでもよくしていこうという考え方が大事だと思います。

伊原: 「アクセシブルかどうか」はちょっとした改善で大きく変わったりもするものです。

例えば先日、とあるサイトをスクリーンリーダーで読み上げてみたのですが、ほとんど問題なく使える。ただ一点、そのページで一番重要なラベルだけ読み上げてもらえないんです。こういう点を改善するだけで、アクセシビリティはぐっと向上する。

なので、まずはアクセシビリティ上の問題を特定し、問題の重要度を判断して、重要なところから対応していく…という現実的なアプローチが、アクセシビリティを向上させていく上では大事だと思っています。

白石: 本日は、いろんなお話を聞かせていただき、ありがとうございました。

2014年10月28日にHTML5が勧告され、もうすぐ1年が経とうとしています。HTML5やその他のAPI、たとえばWeb StorageやService Workerを始め、WebではJavaScriptで操作するようなAPI技術が話題に上がることが多いように思えます。しかし忘れてはいけないのは、HTML5では検索エンジンなどのプログラムにサイトの情報を正しく理解してもらうことを可能とするマークアップができることです。

<header>や<article>といったタグレベルでの情報はたくさんあり、一般的になりつつあります。代表的なCMSのテンプレートでも実際に組み込まれているものがほとんどです。そこで今回は、Webサイトのコンテンツ情報をよりプログラムで構造的に取得できるように考えられた、構造化データ定義ボキャブラリ「schema.org」とそのシンタックスとして「JSON-LD（JSON for Linking Data）」を選ぶ理由をまとめたいと思います。

schema.org登場の背景

schema.orgが登場する以前は、検索サービスを提供しているYahoo!・Microsoft・Googleの3社がそれぞれ別々のボキャブラリ（語彙）で定義していました。しかし、検索サービス毎に定義が別では、その検索サービスに合わせたマークアップをそれぞれ行わなければいけません。そこで3社は2011年から共同で1つのフォーマットの策定を進めてきました。それがschema.orgです。最新バージョンは2.1で、2015年8月6日にリリースされたものです。

JSON-LDシンタックスの利点

JSON-LDは、2014年1月16日にW3C勧告になったオープンデータフォーマットです。その名のとおり、JSON形式で情報をセットします。schema.orgのほかのシンタックスとして、MicrodataやRDFaがありますが、どちらもタグの属性として値をセットします。Googleの構造化マークアップ公式サイトに掲載されている商品レビューのマークアップ方法で、JSON-LDとMicrodataシンタックスの記述を比較してみると以下のように違いがわかります。

<div> 
  <div> 
    <span>Legal Seafood</span> 
  </div> 
  <span> 
    <span>4</span> 
  </span> stars - 
  <b>"<span>A good seafood place.</span>" </b> 
  <span> 
    <span>Bob Smith</span> 
  </span> 
  <span>The seafood is great.</span> 
</div>

<div itemscope itemtype="http://schema.org/Review"> 
  <div itemprop="itemReviewed" itemscope itemtype="http://schema.org/Restaurant"> 
    <span itemprop="name">Legal Seafood</span> 
  </div> 
  <span itemprop="reviewRating" itemscope itemtype="http://schema.org/Rating"> 
    <span itemprop="ratingValue">4</span> 
  </span> stars - 
  <b>"<span itemprop="name">A good seafood place.</span>" </b> 
  <span itemprop="author" itemscope itemtype="http://schema.org/Person"> 
    <span itemprop="name">Bob Smith</span> 
  </span> 
  <span itemprop="reviewBody">The seafood is great.</span> 
  <div itemprop="publisher" itemscope itemtype="http://schema.org/Organization"> 
    <meta itemprop="name" content="Washington Times"> 
  </div> 
</div>

<script type="application/ld+json"> 
{ 
  "@context": "http://schema.org/", 
  "@type": "Review", 
  "itemReviewed": { 
    "@type": "Restaurant", 
    "name": "Legal Seafood" 
  }, 
  "reviewRating": { 
    "@type": "Rating", 
    "ratingValue": "4" 
  }, 
  "name": "A good seafood place.", 
  "author": { 
    "@type": "Person", 
    "name": "Bob Smith" 
  }, 
  "reviewBody": "The seafood is great.", 
  "publisher": { 
    "@type": "Organization", 
    "name": "Washington Times" 
  } 
} 
</script>

構造化マークアップを実装する前のソースコードにそれぞれ実装した例です。属性（itemprop、itemscope、 itemtype など）で設定するMicrodataはソースコードが複雑になり可読性が悪くなります。一方、JSON-LDではscript要素で別に定義しますので、本来のソースコードを汚染することはありません。おそらく属性値から情報を取得するよりJSON形式でデータをまとめておいてもらったほうが検索プログラムもデータを扱いやすいのではないかと考えています。

GoogleはJSON-LDシンタックスを推奨している

Googleのウェブマスター向け公式ブログの過去記事にもあるように、JSON-LDによるシンタックスを推奨しています。schema.orgの定義をWeb Componentと組み合わて、必要箇所にインポートすることができます。

では、基本です。JSON-LDの基本型は以下のとおりです。

<script type="application/ld+json"> 
{ 
  "@context": "http://schema.org/", 
  "@type": "xxxxxxxx" 
} 
</script>

script要素のtype属性にapplication/ld+jsonを設定します。そして定義するJSONデータをその中に記述します。@contextはschema.org定義です。これは変わらず。@typeでいろいろな種類の定義ができます。例えば、商品・商品レビュー・イベント・会社情報・レシピなど、schema.orgの公式サイトを見てもらうと設定値が詳しく記載されています。そのタイプに応じたパラメータを設定することで、正確な情報を伝えることができるようになります。Googleではそのページが構造化マークアップが正しくできているかテストができる「構造化マークアップテストツール」も準備していますので、マークアップ後にテストをしてエラーがないことを確認しましょう。

※ @type: “Organization”の構造化マークアップテストツールの確認例

構造化マークアップを行うことで検索プログラムに正確な情報を収集してもらいます。検索プログラムはこの情報をもとに検索結果を最適化することはもちろんですが、ナレッジグラフにもこの情報が影響することが公式サイトに記載されてあります。サイトに構造化マークアップをして、その情報を検索プログラムが認識したかどうかはGoogle Search Consoleの「検索デザイン」→「構造化データ」で確認することができます。下図は、schema.orgのOrganizationやBreadclumbListなどが認識された例です。

私が注目しているのは、構造化マークアップで検索結果ページに絞り込み検索（サイト内検索）のボックスを表示させることができる設定です。下図は、「LinkedIn」を検索した結果です。サイト名の下に検索ボックスが表示されています。

例えば「高見和也」と入力して検索すると「高見和也 site:linkedin.com」とGoogleの検索ボックスに入力した状態と同じになります。しかし、検索ボックスが検索結果に表示されているほかのサイトで使用してみると、サイト内に設置してある検索ボックスを使用して検索を実行するものもありました。これはおそらく、Google が自動で検索ボックスを認識したパターンの場合です。LinkedInのサイトのソースコードにはschema.org定義のマークアップはありませんでした。ナレッジグラフや企業情報も同じだと思うのですが、Googleが自動的に情報を読み取って表示してもらえるパターンがあるがschema.orgで正確に情報を渡してあげればこういった対応の揺れがなくなる、そういうことだと理解しています。

話は検索ボックスに戻りまして、通常そのサイトで探したいものがある場合、サイトにアクセスして、サイト内検索ボックスに検索キーワードを入力するという流れになります。しかし、このマークアップを実装していてGoogleが検索結果として表示してくれるようになれば、一手少なくすみます。少しでも短い導線で必要な情報にアクセスする仕組みを考えるのもフロントエンドエンジニアの仕事の一つではないかと考えています。

メールも構造化マークアップができる

Webサイトだけが構造化の対象というわけではありません。Gmailを使用している方は、お気づきかもしれません。例えば、Googleカレンダーから招待メールを送ります。すると、下図のようなメールが届きます。

「出欠確認」のプルダウンボタンが表示されています。これをクリックするとメールを開かなくても一覧の状態のままで出欠の返信ができます。

これは、HTMLメールのソースコード内にJSON-LDでschema.org定義をマークアップすることで実現できます。公式サイトにGASから実装する例が掲載されていたので実際に組んでみました。

<html> 
  <head> 
    <script type="application/ld+json"> 
    { 
      "@context": "http://schema.org/", 
      "@type": "EmailMessage", 
      "description": "Check this out", 
      "potentialAction": { 
        "@type": "ViewAction", 
        "target": "/" 
      } 
    } 
    </script> 
  </head> 
  <body> 
    <p> 
      This a test for a Go-To action in Gmail. 
    </p> 
  </body> 
</html>

function testSchemas() { 
  var htmlBody = HtmlService.createHtmlOutputFromFile('mail_template').getContent(); 
 
  MailApp.sendEmail({ 
    to: Session.getActiveUser().getEmail(), 
    subject: 'テスト', 
    htmlBody: htmlBody, 
  }); 
}

Googleスプレッドシートからスクリプトエディタを起動して、mail_template.htmlを作成します。それからmain.gsを新規作成しメールを送信する処理を記述します。getContent()で作成したテンプレートのHTMLを取得してメールの本文とし送信を行う単純な処理です。送られてきたメールは以下のとおりです。

この例は、potentialActionの@typeで「ViewAction」を指定しているので、「表示」をクリックするとtargetで指定している「/」のサイトに遷移します。クリック以外にもカレンダーからの出欠確認やレビュー、Google Nowでのリッチスニペット化、Inboxにおけるハイライトなどさまざまなアクションが準備されています。

GitHubやAmazonからのメールでも使用されているようです。Amazonで注文した際に送られてくる確認メールを見てもらうと「注文を表示」というボタンが表示されていました。この技術を利用するには、Googleにホワイトリスト登録を行う必要があるようで、ECサイトなどからのメルマガを配信したいといった場合は、ドメインを専用フォームから申請しなければいけません。

この形式が正式に定義されれば、今はGmailだけが使用できているこの機能を、ほかのメールアプリケーションでも独自の機能が組み込めていけるのではないでしょうか？ECサイトではメルマガからのユーザーの流入は集客の王道です。競合他社との差別化を図るにはこういった細かい改善や工夫が必要です。

構造化とSEO

では構造化マークアップを行えば、検索結果の上位に表示されるようになるのか？と思われるでしょうが、そうではありません。構造化することで検索プログラムに正確な情報を収集してもらい、理解してもらうことでユーザーにとって最適な検索結果を提供するというものです。もちろん、前述したとおりメールでの構造化では別の利点もあります。

しかし、先日行われたWebマスター向けのGoogleハングアウトで、John Mueller氏の発言に驚きました。

> 構造化データのマークアップをランキングアルゴリズムに組み込むかもしれない

構造化された情報を収集してもらうことで、検索時にGoogleが推測せずともそのサイトがどのような情報を持っているか事前に把握しているわけです。そう考えると、そのサイトの順位を上げるのは自然な考え方に思えます（これを利用したスパムサイトが横行しないかが懸念材料ですが）。

ここまで、schema.org + JSON-LDのお話をしてきましが、すぐに導入すべきということではありません。 まだJSON-LDのサポートを実装する過程で、GoogleとしてはMicrodataかRDFaで実装することを推奨している定義もあります。

We are in the process of implementing JSON-LD support for this Rich Snippet type. At the current time, we recommend using microdata or RDFa.

しかしこれから除々に実装していく事は確かですので、これから必要になる知識として憶えておいて良い技術ではないでしょうか？

参考サイト

• schema.org
• JSON-LD
• Google：構造化マークアップの推奨
• Google：Email Markup

本記事は2015年1月に開催されたHTML5 Conferenceでお話させていただいた、 「Beyond CSS Architecture」というCSS設計のセッションをフォローアップする記事です。

本記事では、このセッションの概要と補足、またセッション中に説明できなかった点などについて書いていきます。

※当日のセッションの動画・スライドも公開されているので、文末からご覧ください。

CSSの難しさと、昨今のCSS設計事情

この近年、CSSにおける設計論というのが話題に出てくるようになりました。筆者も拙著『Web制作者のためのCSS設計の教科書』を書いたり、各地でCSS設計をテーマとした講演をする機会が多くありました。

CSSの難しさというのは、石本氏によるCSSコードの評価についての記事にも書かれているのですが、CSSは良くも悪くも厳格なコード規約は少なく、ただ宣言的に書けばいいだけです。セレクタとその詳細度や、後出しされたルールの方が優先されるという、シンプルがゆえに「書く」のは簡単ですが、「直す」のは容易ではありません。

Normalize.cssの作者であり、現在Twitterのエンジニアであるニコラス・ギャラガー氏（@necolas）のツイートを引用するならば、次のように考えられるかどうかです。

Replace "can you build this?" with "can you maintain this without losing your minds?"
— Nicolas Gallagher (@necolas)

複数人のチームでの開発はもちろんですが、自分のひとりの開発であったとしても、いざメンテナンスするとなったときに、数日前に自分が書いたCSSを呪うようなことはよくあります。

中長期的に運用されるWebサイト、Webサービスにおいては、その運用に耐えうるメンテナブルかつ、拡張性のあるCSSを書くことは非常に重要です。 こうしたCSS設計の話題が以前よりも見かけるようになったのは、単純な数ページのWebサイトよりも、少しリッチで複数のテンプレートが必要なWebサイト、Webサービスが増えてきていることもあり、メンテナブルなCSSにするための設計とは何か、というのが求められているからかもしれません。

OOCSSとBEM

セッション内でも取り上げているOOCSSとBEMは、CSS設計を考える上で避けられない方法論のひとつです。

OOCSSは、ページ上で繰り返されるビジュアルパターンをオブジェクトと考え、そのオブジェクトはHTML/CSSまたはJavaScriptのコードの固まりで構成されます。それはボタンやリスト、見出しというような単位であったり、場合によってはただ文字色を赤くするためのものかもしれません。こうした作られた小さなオブジェクトをレゴのように組み合わせてUIを作るというのが、OOCSSの基本的なアプローチです。

BEMは、Yandexという会社のフロントエンド開発チームによって考えられた開発手法です。BEMはUIをBlock,Element,Modifierという分類で設計するのですが、BEMで使われている命名規則とその記法が特徴的で、Blockを名前空間として使うのが良いアイデアとされています。

.menu { ... } /* Block */
.menu__item { ... } /* Block + Element */
.user { ... } /* Block */
.user_login { ... } /* Block + Modifier */
.user__avatar { ... } /* Block + Element */
.user__name { ... } /* Block + Element */

このコード例では.menuがBlockの単位となり、またそれがセレクタの接頭辞にすることで、マークアップ上でつけられたクラス名を見るだけで、どのUI（Block）に依存するものかが分かります。例えばclass="item"だと抽象的すぎて何に依存しているかわかりませんが、.menu__itemであれば分かる、ということです。

また_、__の記号の組み合わせは、設計上のルールとして、単語間がどういう関係性を持つのかを明確にしています。__は一見冗長で、普通に名前をつけるときには使わなそうですが、それが良い意味でただの命名ではなく、デリミタ（区切り）として使われているということです。

このBEMのアプローチの細かなルールは必ずしもオリジナルのBEMに倣っているものばかりではなく、MindBEMdingのような独自のルールで運用されることもあります。筆者のFLOCSSも、いろいろなものを参考にして作成したものです。

モダンなCSS設計の誤解

OOCSS、BEMについて言及される記事を見ると、これらやCSS設計における大きな誤解を招いていると感じることがあります。

OOCSS派か、BEM派か、というような表現も見かけますが、多くの場合、OOCSSは複数のクラスを組み合わせるアプローチ、BEMは単一クラスのアプローチ、というような解釈をされているようです。

OOCSSが体系化された当時にはSassのようなメタ言語もなく、OOCSSを実現するためには複数のクラスを組み合わせるアプローチが適切だったというだけでしょう。事実、彼女自身が“OOCSS and Preprocessors in a tree, K-I-S-S-I-N-G”という講演で、OOCSSとSassを組み合わせたアプローチについて述べています。

また提唱者であるニコール・サリバン氏が関わったプロジェクトにおいては、font-sizeという単位でもオブジェクトとして分解することが、数百と宣言されるfont-sizeプロパティを、たった数個のクラスで管理することに意味がありました。

ただそのいくつかの例が拡大解釈され、.red {color: red;}や.large {font-size: 36px}というような、見た目だけの、コンテンツ派生の意味をもたないクラスを複数組み合わせるアプローチがOOCSSである、と考えられることは少なくありません。

しかし、OOCSSの本質は、現在のHTML/CSSでは難しいモジュラーなアプローチを実践するためのパラダイムである、と筆者は考えています。

一方、BEMについてもいくつかの誤解があるように感じています。Block、ElementあるいはModifierとしての命名と設計は、マークアップを見て、その構造をセレクタにするものではありません。

<nav class="globalNav">
  <ul>
    <li>
      <a href="/home">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

例えばこのようなマークアップがあった時に、その構造を意識してしまい、次のようなCSSにしてしまうことがあります。

<nav class="globalNav">
  <ul class="globalNav__menu">
    <li class="globalNav__menu__item">
      <a href="/home">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

極端な例ではありますが、近いコードを見ることはあるのではないでしょうか。こうなってしまうと、BEMが冗長すぎる、気持ちが悪い、というのは素直な感情だともいえます。

しかし本来のBEMらしい考え方であれば、このようなマークアップを元にセレクタに命名するものではなく、UIをBlock,Element,Modifierのツリー構造で考え、それが名前にも与えられるものです。

この例でいえば、globalNavをBlockとするならば、それを構成する要素は次のようになるかもしれません。

<nav class="globalNav">
  <ul class="globalNav__menu">
    <li class="globalNav__menuItem">
      <a href="/home">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

そもそも、もっと小さな単位にするべきかもしれません。

<nav class="globalNav">
  <ul class="globalNav__menu menu">
    <li class="menu__item">
      <a href="/home" class="menu__target">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

どちらが正しいかというものではなく、その時々で適切な命名や分割があるはずですが、少なくともマークアップの構造をなぞって親子関係を命名で表すのが、BEMの命名規則というわけではありません。

最後の例を見ての通り、BEMの記法であっても、複数のBlockとElement、つまりはそれぞれはOOCSS的にいえばオブジェクトであり、組み合わせによって作られるわけです。

つまり、OOCSS派かBEM派かという天秤があるわけではありませんし、思想として良いところを取り入れて、プロジェクトに適切な方法論、設計を考えることが重要です。

逆にいえば、これらは銀の弾丸というわけでもありませんから、OOCSSやBEMがすべての問題を解決するわけでもありません。プロジェクトの規模やその運用の方向性によっては、もっと単純な規約のもとでCSSが書かれていても構いません。

いずれの場合も、そのプロジェクト内において一貫性が保たれていることのほうが大事で、Ideomatic CSSから引用するならば、次のようなことです。

どんなに多くの人が貢献したとしても、どのコードも一人で書いたようにすること。
— Ideomatic CSS

セッションで紹介しているツール、スタイルガイドやStyleStatsのようなツールは、一貫性を保ったCSSを書くための補助となるものです。

これらもまたツールでしかなく、導入しただけで問題が解決するというわけではないので、どのように運用するか、自動化などを含めた仕組みを考えることがより重要です。

まとめ

セッションの最後にWeb Componentsに触れていました。Shadow DOMによって、今のHTML/CSSにないスコープの概念がもたらされれば、現状HTML/CSSをモジュラーに設計・実装するためのいくつかの課題は解決するかもしれません。

しかし、それによってCSS設計が簡単になるか、といえば決してそうではありませんし、どちらかといえばより難しくなるかもしれません。

またWeb Componentsの実用は少し先かもしれませんが、現在でもReactのようなものを採用したプロジェクトにおいては、CSSはどのように設計するか、というのは課題として出てきています。個人的にはそれを考えることは、HTML/CSSをより面白くするものでもあります。（その分の苦しみも多くありますが）

どのような未来がくるにせよ、よりよいCSS設計をするためには、より多くのパターンを知ることだと考えています。

同じリスト型のUIを組むにしても、どのようなパターンが目の前のプロジェクトにおいて適切か、それはパターンを多く知らなければいけません。

そのためには、世の中に多く公開されているフレームワーク、またはプロダクトとして公開されているWebサイトやWebサービスのコードを読むことが大事です。続々と出てくる、新たなOOCSSやBEMのような方法論たちも、食わず嫌いはせず一読してみてください。

CSS設計は非常に難しく、壊れないCSSを書くというのは不可能です。私は次の言葉を胸に、いつもCSSを書いています。

壊れない完璧な設計を求めるのではなく、壊れたときに勇気を持って修復できる設計を
— 斉藤 祐也

はじめから作ることはもちろん、どれだけシミュレーションや設計をしても壊れるときはありますから、それをいかに直しやすいものにするか、そしてそれが他の開発者にとって可能であり、数日後の自分でも直せるようなCSSを書くようにしましょう。

当日のセッションの動画・スライドは、こちらからご覧ください。

Youtube / Slideshare

こんにちは！html5jマークアップ部 部長の村岡です。
この記事では2014年3月8日に開催されたMarkup Cafe FUKUOKA Vol.1のイベントレポートをさせていただきます。

大阪に続く地方開催でのMarkup Cafe、今回も20名以上の方々に参加いただいて様々なマークアップ案が披露されました。

Markup Cafe FUKUOKAの開催にあたっては準備や開催告知などで地元のHTMLマークアップコミュニティである福岡マークアップ勉強会、通称「マカベン」の方々にご協力いただきました。この場を借りて改めて御礼申し上げます。ありがとうございました。

福岡マークアップ勉強会「マカベン」（敬称略）

• 西村 宗倫（左）
• 筆者（中央左）
• 卜部 加奈子（中央右）
• 田村 章吾　ましじめ（右）

FUKUOKA Vol.1 マークアップ事例の解説

今回は地域スタッフの方々から「普段マークアップで疑問に思ってることをみんなで検討したい」というご意見があったので、出題を2題にし、残りの時間でQ&Aを行う構成にしました。

このタイムテーブルは実際やってみてよかったです。普段は3題出題するんですが、結構頭が疲れるし、ゆっくりコーヒーを飲む時間もなかったりするので（笑）。2題がんばった後にQ&Aコーヒーを飲みながら談笑するくらいがカフェっぽくていいです。これからはこの時間配分でやろうかなと思いました。

1問目 記事のヘッダ

今回の2題はマカベンの方々に考えていただきました。最初のお題は記事ページのヘッダ部分のマークアップです。ブログなどでよく使われるレイアウトですね。サンプルとしてこのHTML5 Experts.jpのヘッダ部分を採用しました。よくみるとパンくず、タイトル、著者の写真、日付、ソーシャルボタンなどなど……このヘッダの情報量はかなり多いですね。みなさん結構苦戦してたみたいです。

お題1:Aチーム

<article>
<nav>
<ul>
<li>HTML5Experts.jp</li>
<li>中島直博</li>
<li>続・よくある3つのデザインから考える、マ...</li>
</ul>
 </nav>
<header>

<div id=”flame”>
<figure> picture  </figure>
<h1>続・よくある3つのデザインから考える、マークアップの最適解</h1>
<p>中島直博</p>
<ul>
<li><a href=”#”>CSS</a></li>
<li><a href=”#”>マークアップ</a></li>
</ul>
<time datetime=”2013-11-08”>2013年11月8日</time>
</div>

<aside>
<ul>
<li>facebook</li>
<li>twitter</li>
<li>google+</li>
<li>hatebu</li>
<li>pocket</li>
<li>☆</li>
</ul>

 </aside>

</header>
</article>

Aチームのポイントは以下です。

• 全体をarticle要素とした
• パンくずはnav要素とし項目をul, li要素でリストとした
• nav要素内に見出しを入れるかどうか悩んだが、入れなかった
• パンくずの下、タイトル、ソーシャルボタン等をheader要素とした
• ソーシャルボタン群はaside要素とした
• 著者名はp要素とした

まず、HTML5で新たに登場したarticle要素で記事全体を囲っています。このお題ではヘッダの下に記事本文が続くことが想定できるので、本文や記事のフッタがあればそのフッタもarticle要素内に入るでしょう。

Aチームはnav要素がセクショニング・コンテンツであることに着目して、見出し要素を入れるべきかどうか悩んだようです。ここは悩むケースが出てくるところですね。個人的にはレイアウト上見出し表記がない場合には必要がないと考えていますが、スクリーンリーダー等に配慮して見出し要素で「パンくずナビゲーション」などと記載しCSSでdisplay:none;してもよいかもしれないです。

article要素は自己完結するコンテンツを表します。HTML5を学ぶ上で、articleやsectionといった新しい要素は使いどころが難しいとよく言われますね。個人的には新聞の紙面から記事をスクラップするようなケースで理解しています。

新聞中のひとつの記事をハサミで切り取ってスクラップファイルに収録する場合は、記事のタイトルや本文、補足事項など、後から読んだときに情報が欠損しない範囲を切り取るでしょう。そのようなイメージでarticle要素を使うのが適当だと考えています。

お題1:Bチーム

<nav>
<ol>
<li>xHTML5Expert.jp</li>
<li>中島直博</li>
<li>続・よくある3つのデザインから考える、マークアップの最適解</li>
</ol>
</nav>

<article>
<header>
<h1>続・よくある3つのデザインから考える、マークアップの最適解</h1>
<figure>
<img src="" alt="">
<figcaption>中島直博</figcaption>
</figure>

<ul>
<li><a href="">CSS</a></li>
<li><a href="">マークアップ</a></li>
</ul>
<time datatime="2013-11-08">2013年11月8日</time>

<ul>
<li>facebook</li>
<li>twitter</li>
<li>google+</li>
<li>はてぶ</li>
<li>pocket</li>
<li>評価</li>
</ul>
</header>
</article>

Bチームのポイントは以下です。

• パンくずより下の部分をarticle > header要素とした
• パンくずの階層を意識してol要素とした
• 著者の写真、著者名やfigure, figcaption要素とした。

Bチーム中の参加者の方が終わってからブログを書かれています。勉強会の経験をもとにマークアップを再考されてるのはとても素晴らしいですね！ボクも読んで勉強になりました。

このチームでは、パンくずには階層（≒順序）があると考えてol要素でリスト化しています。また、著者の写真と著者名の関連性を意識してかそれらをfigure, figcaption要素でマークアップしています。

figure要素は図表を表し、figcaption要素はその説明を表します。なるほど…著者近影と著者名が図表とその説明にあたると解釈できるかもしれないですね。興味深いです。その他、日付をtime要素で囲っているのも特徴的ですね。

お題1:Cチーム

<!doctype html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title>Document</title>
</head>
<body>

<article>

	<header>
		
		<nav prefix="v: http://rdf.data-vocabulary.org/#">
			<span typeof="v:Breadcrumb">
				<a href="#" rel="v:url" property="v:title">
					HTML5Experts.jp
				</a> ›
			</span>
			<span typeof="v:Breadcrumb">
				<a href="http://www.example.com/dresses/real" rel="v:url" property="v:title">
					中島 直博
				</a> ›
			</span>
			<span typeof="v:Breadcrumb">
				<a href="http://www.example.com/dresses/real/green" rel="v:url" property="v:title">
					続・よくある3つのデザインから考える、マ...
				</a>
			</span>
		</nav>

		<div prefix="v: http://rdf.data-vocabulary.org/#" typeof="v:Person">
			<img class="avatar" src="#" alt="中島 直博">
			<h1>続・よくある3つのデザインから考える、マークアップの最適解</h1>
			<span property="v:name">中島 直博</span>
			<div>
				<ul class="tags">
					<li><a href="#"><data value="css">CSS</data></a></li>
					<li><a href="#"><data value="markup">マークアップ</data></a></li>
				</ul>
			</div>
			<time datetime="2013-11-08">2013年11月8日</time>
		</div>

		<div>

			<div class="social_buttons">
				<ul>
					<li>各SNSタグ</li>
					<li>各SNSタグ</li>
					<li>各SNSタグ</li>
					<li>各SNSタグ</li>
					<li>各SNSタグ</li>
				</ul>
			</div>

			<div class="rating">
				<img src="#" alt="評価4.5" class="star">
				(<span class="counting">6</span>人が評価しています。)
			</div>
			
		</div>

	</header>

	<section>
		
		本文〜

	</section>

</article>
	
</body>
</html>

Cチームのポイントは以下です。

• HTML5バリデーション合格
• RDFa Breadcrumb, Personを使用

CチームはマークアップをHTMLバリデーターに通し、合格してから発表に臨んでいました。そのためにdoctypeやhtml要素もマークアップされています。そこまで考えていたとは。なんかかっこいいですねｗ

情報をよりセマンティックにするためパンくずはBreadcrumb, 著者写真、著者名はPersonのRDFaスキーマを使いマークアップしています。このチームの後からの反省点として、Personスキーマはちょっとおかしかったかも。というのがありましたが、まあこれはこれでいいんじゃないですかね。
全体的に情報の順番とCSSの装飾のバランスが意識されたマークアップです。

お題1:Dチーム

<article>
 <nav>
   <ol>
    <li><a href="">ホーム</a></li>
    <li><a href="">現在地</a></li>
</ol>
 </nav>   

<header>
    <h1>タイトルタイトル</h1>
    <figure>
     <img src="">
     <figcaption>名前</figcaption>
    </figure>
    
    <dl>
        <dt>タグ</dt>
        <dd>tag</dd>
        <dd>tag</dd>
        <dd>tag</dd>
    </dl>
    <time>2013年9月25日</time>
</header>

<aside>
    <div>sns</div>
    <div>記事の評価</div>
 </aside>
    
  <section>本文</section>
  </article>

Dチームのポイントは以下です。

• タイトル、著者情報、タグ、日付をheader要素とした
• ぱんくずはnav, ソーシャルボタン群はaside要素とした
• パンくずはol要素とした
• 著者の写真、著者名やfigure, figcaption要素とした

他のチームと比べてheader要素の範囲が限定的なのが特徴的です。パンくずやソーシャルボタンがヘッダなのかどうかについては、各チームでもいろいろな意見が出たようですが、この辺りは制作者の解釈によって様々ありそうですね。

パンくずでol要素を使う、著者情報にfigure, figcaption要素を使うという考え方はBチームに似ています。タグをdl要素で定義リストとしているところも特徴的ですね。

お題1:Eチーム

<header>
		<div itemscope itemtype="http://">
		    <a href="http://" itemprop="url">
		      <span itemprop="title">HTML5Experts.jp</span>
		    </a>
		    <img src="img/arrow.png" alt="の中の">
		    <div itemprop="child" itemscope itemtype="http://">
		      <a href="http://" itemprop="url">
		        <span itemprop="title">中島 直博</span>
		      </a>
		    	<img src="img/arrow.png" alt="の中の">
		      <div itemprop="child" itemscope itemtype="http://">
		        <a href="http://" itemprop="url">
		          <span itemprop="title">続・よくある３つのデザインから考える、マークアップの最適解</span>
		        </a>
		      </div>
		    </div>
		</div>

		<section>
			<h1>続・よくある3つのデザインから考える、マークアップの最適解</h1>
		</section>
		<figure itemprop="image"><img src="author.png" alt=""></figure>
		<span itemprop="author">中島直博</span>
		<time itemprop="pubdate" datetime="2013-11-08">2013年11月8日</time>
		<dl class="tags">
			<dt>タグ</dt>
			<dd>
				<ul>
					<li><a href="#">CSS</a></li>
					<li><a href="#">マークアップ</a></li>
				</ul>
			</dd>
		</dl>
		<aside class="sns-share">
			<ul>
				<li>いいね</li>
				<li>ツイート</li>
				<li>g+</li>
				<li>B!</li>
				<li>Pocket</li>
				<li>
                    <img alt="4.5個の星です" class="star">
                    <img alt="" class="star">
                    <img alt="" class="star">
                    <img alt="" class="star">
                    <img alt="" class="star-half"> 6人が評価しています。</li>
			</ul>
		</aside>
	</header>

Eチームのポイントは以下です。

• 全体をheader要素とした
• パンくずの構造をitempropで定義、矢印画像のalt属性値を”の中の”とした
• <dt>タグ</dt>はCSSで非表示にすることを想定
• スター評価の画像グループはWEBアクセシビリティガイドラインに沿ってマークアップした

この問題では、パンくず、ソーシャルボタン群をヘッダとして扱うかどうかが議論の焦点となっていましたが、Eチームは記事ヘッダの一部とみなしてheader要素内としています。

Eチームは特にスクリーンリーダーに配慮された印象が強いマークアップです。
パンくずのデザインで使われている”＞”を画像とし、alt属性値を”の中の”とすることで、スクリーンリーダーで「◯◯の中の◯◯」と読み上げる配慮をしています。さらにDチームと同様タグブロックにdt要素でタイトルを記載し、CSSで非常時とすることでスクリーンリーダーでの読み上げに配慮しています。

スター評価の画像グループでは、一番上の画像のalt属性値を”4.5個の星です”とし、その他の画像のalt属性値を空にしています。これはG196: 画像のグループにある一つの画像に代替テキストを提供して、そのグループの全ての画像を説明するの実装例に沿ったもので、同じくスクリーンリーダーでの読み上げに配慮したものになっています。

部長はこう書く

お題1:部長

<article itemscope itemtype="http://schema.org/Article">
    <header>
        <div xmlns:v="http://rdf.data-vocabulary.org/#">
           <span typeof="v:Breadcrumb">
             <a href="#" rel="v:url" property="v:title" class="link">
                 HTML5Experts.jp
            </a>
           </span>
           <span typeof="v:Breadcrumb">
            <a href="#" rel="v:url" property="v:title" class="link">
              中島直博
            </a>
           </span>
           <span typeof="v:Breadcrumb">
            <a href="#" rel="v:url" property="v:title" class="current">
              続・よくある3つのデザインから考える、マークアップの最適解
            </a>
           </span>
        </div>
        <div>
            <div class="author-photo">
                <img alt="中島直博" src="photo.jpg">
            </div>
            <div class="title">
                <h1 itemprop="name">
                    続・よくある3つのデザインから考える、マークアップの最適解
                </h1>
            </div>
            <div class="author">
                <span itemprop="author">中島直博</span>
            </div>
            <div class="tags" itemprop="keywords">
                <a href="#">CSS</a>,
                <a href="#">マークアップ</a>
            </div>
            <div class="publish-date">
                <time itemprop="datePublished" datetime="2013-11-08">2013年11月8日</time>
            </div>
        </div>
        <aside>
            <ul class="sns-buttons">
                <li>いいね！</li>
                <li>ツイート</li>
                <li>g+</li>
                <li>B!</li>
                <li>Pocket</li>
            </ul>
            <div class="stars">
                <img src="star.jpg" alt="星5つ中、星4.5個">
                <img src="star.jpg" alt="">
                <img src="star.jpg" alt="">
                <img src="star.jpg" alt="">
                <img src="star.jpg" alt="">
            </div>
            <span itemprop="interactionCount" content="UserLikes:6">(6人が評価しています)</span>
        </aside>
    </header>
</article>

• schema.org Articleを採用し、記事情報をマークアップした
• パンくずはRDFa Breadcrumbを採用
• スター評価、ソーシャルボタン群はaside要素とした
• スター評価の画像グループはG196の実装例に沿ってマークアップした

懸案のパンくず、ソーシャルボタン群はheader要素内に入れています。その上でソーシャルボタン、スター評価はaside要素としました。特に厳密に考慮したわけではないですが、まあヘッダの一部でよいと思っています。

パンくずは前回の時と同様Googleのリッチスニペットのマークアップを参考にしました。記事全体の情報の記述もGoogleウェブマスターツールの記事をヒントにArticleスキーマを使っています。

別にGoogle信者というわけじゃないですが、ウェブマスターツールのヘルプにあるように、将来的に検索エンジン等でサーチフレンドリーとなる可能性が高まるのは良いことだと思います。

スター評価の画像グループはEチームと同様WCAGのG196の実装例に沿いました。このような画像グループのケースごとの実装はWCAGのドキュメントのほか、最近公開されたWAI Web Accessibility Tutorials – Groups of Imagesのドキュメントも参考になります。

2問目 複数のリンクリスト／ナビゲーション

2問目は、ページのサイドによくあるリンクのリスト、ナビゲーションなどのレイアウトです。画像中のグローバルナビゲーションの下、メインコンテンツの右側の部分です。ウェブページではこのような上部のグローバルナビゲーションのほかにサイドペインにサブナビゲーションやバナーなど複数のテキストリンク、ボタンなどが並ぶレイアウトがよくありますね。一見単純なマークアップになりそうな気がしますが、ここでも細かいところでいろいろな疑問やアイデアが出てきました。

お題2:Aチーム

<aside>
<section class="article_list">
<h1>マークアップカフェ</h1>
<ol>
<li><a href=”#”>タイトル01</a></li>
<li><a href=”#”>タイトル02</a></li>
<li><a href=”#”>タイトル03</a></li>
<li><a href=”#”>タイトル04</a></li>
<li><a href=”#”>タイトル05</a></li>
<li><a href=”#”>タイトル06</a></li>
<li><a href=”#”>タイトル07</a></li>
<li><a href=”#”>タイトル08</a></li>
<li><a href=”#”>タイトル09</a></li>
<li><a href=”#”>タイトル10</a></li>
</ol>
</section>

<div class=”banner”>
<ul>
<li><a href=”#”><img src=”#” alt=”マークアップカフェについて”></a></li>
<li><a href=”#”><img src=”#” alt=”マカベンについて”></a></li>
<li><a href=”#”><img src=”#” alt=”マカベンについて”></a></li>
</ul>
</div>

<section class=”link”>
<h1>福岡のIT勉強会</h1>
<ul>
<li><a href=”#” title=”ダミーテキスト”>ダミーテキスト</a></li>
<li><a href=”#” title=”ダミーテキスト”>ダミーテキスト</a></li>
<li><a href=”#” title=”ダミーテキスト”>ダミーテキスト</a></li>
<li><a href=”#” title=”ダミーテキスト”>ダミーテキスト</a></li>
</ul>
</section>
</aside>

Aチームのポイントは以下です。 * 全体をaside要素とした * 1番目のリストをol要素とした * 1, 3番目のリストをsection要素とした

まず、このブロック全体をaside要素としています。aside要素はコンテンツには関連があるが、切り離しても問題がないようなセクションを表します。1番目のリストをローカルナビゲーションとみなした場合、asideにするのは違和感がないか？という意見がありました。Aチームではaside=サイド部分というような感覚で考えていたようなので、解釈が違っていたという反省があったようです。

1番目のリストはulかolか悩んだようですが、テキストに番号が降ってあったのでolにしたそうです。テキストの番号がリストの順序に意味的に直結している場合はそうかもしれませんが、これは文書構造をどう設計したいかによるかもしれないですね。

1, 3番目のリストをsectionとし、2番目をdivとしています。この場合は文書のアウトラインがおかしくなるのでは？という指摘がありました。

実際にこのマークアップをHTML5 Outlinerにかけてみると図のようになります。

アウトライン上に2番目のリストが現れていません。2番目のリストもセクショニング・コンテンツでよいかもしれないという意見がありました。

全体的に情報の文脈と、文書構造をどう切り分けてマークアップしていくかということをよく考えさせられるマークアップでした。

お題2:Bチーム

<section>
<nav>
<h1>マークアップカフェ</h1>
<ol>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
</ol>
</nav>

<aside>
<section>
<h1 class="hide">広告</h1>
<div><a href=""><img src="" alt=""><p>マークアップカフェについて</p></a></div>
<div><a href=""><img src="" alt=""><p>マークアップカフェについて</p></a></div>
<div><a href=""><img src="" alt=""><p>マークアップカフェについて</p></a></div>
</section>

<section>
<h1>最近のIT勉強会</h1>
<ul>
<li><a href="" target="_blank"></a></li>
<li><a href="" target="_blank"></a></li>
<li><a href="" target="_blank"></a></li>
<li><a href="" target="_blank"></a></li>
</ul>
</section>
</aside>
</section>

Bチームのポイントは以下です。

• 1番目のリストをol要素とした
• 2番目のリストに見出しをつけ、CSSで非表示とする
• 1番目のリストをnav, 2,3番目のリストをそれぞれsection要素とした
• 2, 3番目のリストをaside要素とした
• 全体をsection要素とした

1番目のリストはAチームと同様、順番を意識してol要素としています。2番目のリストに見出しをつけてCSSで非表示とすることで、スクリーンリーダー等での読み上げに配慮しています。

セクショニングは1番目をnav、2,3番目をsectionとし、2,3番目をasideとし、全体をsectionとしています。これをHTML5 Outlinerにかけてみると次のようになります。

Untitled Section（見出しのないセクション）が余分に現れてきています。特に「広告」、「最近のIT勉強会」がUntitled Sectionで下げられてしまっていますね。チームではHTML5の要素でできるだけ意味的なまとまりをつくろうと考えたようですが、結果的にアウトラインがおかしくなっています。

HTML5で登場したarticle, section, nav, asideといったセクショニング・コンテンツは文書のアウトラインを表現するので、意味づけだけを意識して使うとアウトラインの構造がおかしくなる可能性があります。ここが使いどころに悩むところですね。その意味で非常に参考になるマークアップです。

お題2:Cチーム

<!doctype html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title>Document</title>
</head>
<body>

<div class="side_menu">

	<div class="side_menu_block">
		<nav class="nav_local">
			<h1 class="cat_title">マークアップカフェ</h1>
			<ul>
				<li><a href="#" rel="prev">タイトル01</a></li>
				<li class="current"><a>タイトル02</a></li>
				<li><a href="#" rel="next">タイトル03</a></li>
				<li><a href="#">タイトル04</a></li>
				<li><a href="#">タイトル05</a></li>
				<li><a href="#">タイトル06</a></li>
				<li><a href="#">タイトル07</a></li>
				<li><a href="#">タイトル08</a></li>
				<li><a href="#">タイトル09</a></li>
				<li><a href="#">タイトル10</a></li>
			</ul>
		</nav>
	</div>
	
	<div class="side_menu_block">
		<aside class="banners">
			<ul>
				<li><a href="#" target="_blank"><img src="#" alt="xxxのバナー"></a></li>
				<li><a href="#" target="_blank"><img src="#" alt="yyyのバナー"></a></li>
				<li><a href="#" target="_blank"><img src="#" alt="zzzのバナー"></a></li>
			</ul>
		</aside>
	</div>

	<div class="side_menu_block">
		<aside class="external_link">
			<h1>福岡のIT勉強会</h1>
			<ul>
				<li><a href="#" target="_blank">ダミーテキスト</a></li>
				<li><a href="#" target="_blank">ダミーテキスト</a></li>
				<li><a href="#" target="_blank">ダミーテキスト</a></li>
				<li><a href="#" target="_blank">ダミーテキスト</a></li>
			</ul>
		</aside>
	</div>
	
</div>

</body>
</html>

Cチームのポイントは以下です。

• HTML5バリデーション合格
• 1番目のリストはnav要素とした
• 2, 3番目のリストはそれぞれaside要素とした
• それぞれのリストをdivで囲い同一のクラス名を割り当てた

1問目と同様バリデーションに合格していますｗ 1番目のリストはローカルナビゲーションとみなしnav要素としました。ulで順番なしリストとし、a要素中のrel属性でカレントページの前後を表しています。

2,3番目のリストはそれぞれをaside要素としています。ページコンテンツから切り離せる部分という考えはBチームと同様ですが、アウトラインとCSSを考慮してのようです。

各リストはCMSではウィジェット機能で提供されるのが多いことに配慮して各リストをdivとし、同一のクラス名を当てています。現実的な配慮ですね。

お題2:Dチーム

<article>メインコンテンツ</article>

<article>
  <section>
      
    <h1>マークアップカフェ</h1>
    <ul>
      <li><a href="">タイトル01</a></li>
      <li class="current"><a href="">タイトル02</a></li>
      <li><a href="">タイトル03</a></li>
      <li><a href="">タイトル04</a></li>
      <li><a href="">タイトル05</a></li>
      <li><a href="">タイトル06</a></li>
    </ul>
  </section>
  <aside>
    <section>
      <h1>バナーリンク</h1>
      <ul>
        <li><a href="" class="js-blank"><img src="" alt="マークアップカフェについてへリンク"></a></li>
        <li><a href="" class="js-blank"><img src="" alt="マカベンについてへリンク"></a></li>
        <li><a href="" class="js-blank"><img src="" alt="マカベンについてへリンク"></a></li>
      </ul>
    </section>
    <section>
      <h1>福岡のIT勉強会</h1>
      <ul>
        <li><a href="" class="js-blank">ダミーテキスト<img src="" alt="外部へリンク"></a></li>
        <li><a href="" class="js-blank">ダミーテキスト2<img src="" alt="外部へリンク"></a></li>
        <li><a href="" class="js-blank">ダミーテキスト3<img src="" alt="外部へリンク"></a></li>
        <li><a href="" class="js-blank">ダミーテキスト4<img src="" alt="外部へリンク"></a></li>
      </ul>
    </section>
  </aside>
</article>

Dチームのポイントは以下です。

• 全体をarticle要素とした
• 各リストをsection要素とした
• 2, 3番目のリストをaside要素とした
• 外部リンクにクラス名を割り当て、JavaScriptで別タブを開く想定

全体をarticle要素としています。このリンクリスト／ナビゲーションの部分だけで完結したコンテンツと言えるかどうかは、微妙な気がしますね。article要素の解釈が難しいところですが、ここはarticleでなくてもいいのではないでしょうか。

アウトラインの取り方はBチームとほぼ同様、HTML5 Outlinerでも同様のアウトライン構成が見られました。各リストを意味的にまとめたいという意図が伝わりますが、結果的にアウトラインがおかしくなっているのはおしいですね。

外部リンクについては、各チームがterget=”_blank”を利用しているのに比べてクラス名を割り当てJavaScriptでの制御を想定しているのが特徴的です。terget属性はリンク先の表示方法を指定します。_blankを指定すると強制的に別ウィンドウ（タブ）で開く動作になりますが、このような動作に慣れないユーザーに対して混乱を与える可能性があります。

SCR24: プログレッシブ・エンハンスメントを用いて、利用者の要求に応じて新しいウィンドウを開くではこれに配慮するためのJavaScriptによる実装例が収録されています。このような配慮は、Webアクセシビリティとしても重要ですね。

お題2:Eチーム

<div>
	<nav role="navigation">
		<h2>マークアップカフェ</h2>
		<ul>
			<li><a href="">タイトル01</a></li>
			<li><a href="">タイトル02</a></li>
			<li><a href="">タイトル03</a></li>
			<li><a href="">タイトル04</a></li>
			<li><a href="">タイトル05</a></li>
			<li><a href="">タイトル06</a></li>
			<li><a href="">タイトル07</a></li>
			<li><a href="">タイトル08</a></li>
			<li><a href="">タイトル09</a></li>
			<li><a href="">タイトル10</a></li>
		</ul>
	</nav>
	<aside>
		<h2 class="reader">広告</h2>
		<ul>
			<li><a href="" target="_blank"><img src="" alt="マークアップカフェについて"></a></li>
			<li><a href="" target="_blank"><img src="" alt="マカベンについて"></a></li>
			<li><a href="" target="_blank"><img src="" alt="マカベンについて"></a></li>
		</ul>
	</aside>
	<aside>
		<h2>福岡のIT勉強会</h2>
		<ul>
			<li><a href="" target="_blank">ダミーテキスト</a></li>
			<li><a href="" target="_blank">ダミーテキスト</a></li>
			<li><a href="" target="_blank">ダミーテキスト</a></li>
			<li><a href="" target="_blank">ダミーテキスト</a></li>
		</ul>
	</aside>
</div>

Eチームのポイントは以下です。

• 全体をdiv要素とした
• 1番目のリストはnav要素としrole=”navigation”を設定
• 2, 3番目のリストはそれぞれaside要素とした

テーマは「年度末の納期の案件」だとかｗ
忙しい中で無駄なく的確にマークアップするという条件を自ら設定してのトライです。

まず、全体をdivとしてCSSの割り当てを想定しました。レスポンシブデザインによるレイアウトのダイナミックな変更をも視野に入れたそうです。2番目のリストに見出しを設定し、非表示としました。B, Dチームと同じ配慮ですね。

1番目のリストはローカルナビゲーションとみなしnav要素としARIAのrole=”navitaion”を指定。2,3番目のリストはそれぞれをaside要素としました。

セクショニング・コンテンツの使い方はCチームとほぼ同様です。ちなみにnav要素のロールはデフォルトでnavigationなので省略可能です。

なるほど、繁忙期という条件だけあって、そつのないマークアップですねｗ

部長はこう書く

お題1:部長

<div>
    <nav>
        <h2>マークアップカフェ</h2>
        <ul>
            <li><a href="">タイトル01</a></li>
            <li><a href="">タイトル02</a></li>
            <li><a href="">タイトル03</a></li>
            <li><a href="">タイトル04</a></li>
            <li><a href="">タイトル05</a></li>
            <li><a href="">タイトル06</a></li>
            <li><a href="">タイトル07</a></li>
            <li><a href="">タイトル08</a></li>
            <li><a href="">タイトル09</a></li>
            <li><a href="">タイトル10</a></li>
        </ul>
    </nav>
    <aside>
        <h2 class="sr-only">広告</h2><!-- http://getbootstrap.com/getting-started/#accessibility -->
        <ul>
            <li><a href="" rel="external"><img src="" alt="マークアップカフェについて"></a></li>
            <li><a href="" rel="external"><img src="" alt="マカベンについて"></a></li>
            <li><a href="" rel="external"><img src="" alt="マカベンについて"></a></li>
        </ul>
    </aside>
    <aside>
        <h2>福岡のIT勉強会</h2>
        <ul>
            <li><a href="" rel="external">ダミーテキスト</a></li>
            <li><a href="" rel="external">ダミーテキスト</a></li>
            <li><a href="" rel="external">ダミーテキスト</a></li>
            <li><a href="" rel="external">ダミーテキスト</a></li>
        </ul>
    </aside>
</div>

• 1番目のリストをnav要素とした
• 2番目のリストに見出しをつけた
• セクショニングはC, Eチームと同様
• 外部リンクにrel=”external”を設定

1番目のリストはローカルナビゲーションとみなしてnav要素としました。セクショニングの考え方はC, Eチームと同様です。

2番目のセクションにはB, D, Eチームと同様に広告だとわかる見出しをつけています。なくてもいいかなと思ったんですが、読み上げの脈絡を考えると、このケースではあったほうがいい感じかなと思いました。CSSでの非表示を想定しています。

余談ですが、このクラス名”sr-only”はBootstrapで使われているクラス名を参考にしています。BootstrapのようなCSSフレームワークでもアクセシビリティが考えられているんですね。

広告、福岡のIT勉強会リンクリストのリンク先は外部リンクとみなして、rel=”external”を設定しました。外部リンクを開く制御はDチームと同様JavaScriptの利用を想定しています。

rel属性のexternal値はそのリンクが外部のリンクであることを示します。jQuery Mobileではrel=”external”のリンクはAJAXでのページ遷移処理がオフになり内部ページヘとのアクセスと異なる挙動になります。このような事例があるのも参考に、マークアップしてみました。

福岡のマークアップ熱はすごかった！

MarkupCafeを楽しんだ後は、みんなでやったマークアップの反省や、普段疑問に思ったことを話し合いました。福岡はマカベンの活躍もあって昔からHTMLマークアップに対する関心が高い地域です。皆さんが熱心に意見交換されており、なにより間違いをおそれず積極的にHTML5マークアップを実践していこうという意識が素晴らしかったです。

個人的には懇親会で食べた手羽先、ラーメンが忘れられません（笑）。福岡の皆さん、また行きたいと思いますのでぜひよろしくお願いします！！

さて、今日の問題、皆さんならどうマークアップしますか？

2013年11月30日に開催された「HTML5 Conference2013」において行われた数々のセッション。その中で今回は、マークアップに関する活動を展開している「マークアップ部」メンバー3名によるセッション「Markup Maniax – マークアップ部が語り合うHTML5仕様のいま・これから」の一部に関してレポートする。

HTML5といえばAPIや周辺技術の話題を目にすることが多くなった一方、Webサイトで重要なのはやはりマークアップ。HTML5がLast Callになってからも仕様に随時変更が加わっている。また、独自の要素を定義できる仕組みも登場している。今回のセッションでは「マークアップの今後はどう向かうのか？」マークアップ部から3人、バスタイムフィッシュ村岡正和氏、WEBCRE8.jp酒井優氏、矢倉眞隆氏がそれぞれの持論を展開した。

H1の使い方はどうあるべき？

村岡：今、HTML5.1の方で、新しい要素がどんどん追加されています。要素や属性も含め、どうしたらやりやすく解決できるか？ 世界中で議論されています。

酒井：最近のマークアップに注目すると、特に見出しに関して大きな変化がありましたよね。　

矢倉：HTML5以前は、そもそもセクショニングコンテンツがなかった。そこにHTML5で新たにセクションがでてきて、H1 H2と数字を見て判断できていたことが行えなくなりました。H1 H2 H3と重要度に応じた見出しを使い分けていましたが、HTML5では数字は関係ない。そうすると見出しはH1だけでいいのでは、という考えもあり仕様にもそう書かれている。

村岡：僕も昔からH1 H2とマークアップしていたし、Hの見出しでアウトライン考えていました。しかしそれがすべてH1になってしまうと、人間的レベルの気持ち悪さを感じてしまうんですよね。

酒井：コーダーとして困っていることがあって、それはサイトトップのロゴをH1でマークアップしたら、記事中にもまたH1を使う。H1はどうなっていくのだろう、という困惑が私の中にはあります。

矢倉：そもそもH1を2回使っちゃいけないという明確なルールはなく、仕様で決まっているわけではないので。ニュース記事を伝えるサイトの構造　側としてのレベルとコンテンツ、そうした混在したものをH1にするかしないかで意見は分かれると思います。「ロゴはH1だろう」という考えもあれば、「そもそもサイトのトップページはいろんなものが混在しているのでH1はあり得ない」という人もいる。本当に正解はないですよね。

パンくずリストから考える「マークアップに正解はない」

村岡：どういう目的でどういうサイトを作るのかによって、マークアップの仕方も変わってくる。

矢倉：マークアップ部は正解を出すより「おまえの考えで文章構造とはなんぞや」を問う部活動ですから。

村岡：「目的に応じたマークアップができてます」と自信を持って言い切れればそれでいいんですよね。

矢倉：パンくずリストを例に考えてみたいと思います。これまでと違い、HTML5.1では「→（矢印）」がパンくずだとされ、Webサイトの階層構造と認識されている。

村岡：私、実はこれが非常に気持ち悪くて、やりたくない人も多いんじゃないでしょうか？　そもそもパンくずをマークアップする専用のタグがないから、こんなことが起こる。「Breadcrumbs」というタグがあればいいのに。

矢倉：最近「Web Components」が登場して、マークアップやスクリプトをコンポーネントとして組み込んでいるので、ｐだのなんだの議論すること自体が無駄になるかも、という議論も。

酒井：コーダーとしてWeb Componentsにどう向き合うか？　Web Componentsを使ってソースコードを公開し、それを真似して使ってデファクトにしていく。そうするとHTML仕様に組み込まれる可能もでてくるのか？

矢倉：Web Componentsがもてはやされる理由として、みんなの要望に答えられていない現状があって、そこでもっと下のレイヤーで答えていこう、という流れがある。そこから標準化の検討課題になるのではないでしょうか。

村岡：私としては2つの立場があるんですよ。マークアップを研究する立場でいえば「どこまでパンくずのことを考えられるか？」ぜひやりたい。でもそれは、一切ご飯が食べれないからきついですよね（笑）。

仕事をする立場としては、人が作ったものを使いたいという思いもある。例えばモジラが作っているBrick というWeb Components frameworkがあって、「x-fripbox」というタグを入れるだけで、フリックボックスが作れてしまう便利なものもある。

矢倉：やがてマークアップでUIをつくるWeb Componentsが出てきてもおかしくない。そうすると、あれこれ考えなくてもパンくずつかえるわけです。

酒井：一見、思考停止に見えるかもしれないけれど、いいことだと思います。文書構造で考えると、Webサイトにしかパンくずはない　

村岡：HTML5の仕様策定では、実装が仕様になるスキームで動いているので、とりあえずみんながトライして「いいね！」が一番多いマークアップが仕様になる気がします。自分がいいと思ったものが一番いいし、そういう意味では今が無法地帯。いつか「Breadcrumbs」というタグができると信じてその時、「理想の構造は？」「パンくずリストは何か？」を自分で考え、出した答えをよしとしよう。まだ正解はないんです。

矢倉：「マークアップに正解はない」これがマークアップ部の座右の銘になりますかね（笑）。

エンジニアがデザインに「文句を言える」ようになってほしい

村岡：マークアップ部では「マークアップカフェ」というイベントを定期的に開催しています。先ほど話したようにマークアップに正解はない以上は、もうみんなで決めるしかない。そこで「どれが一番いい感じか？」を議論しています。その中で例えばあるお題を出して「これ、あなたならどうマークアップしますか？」と30分考えて答えを出してもらう。ふつう、業務でマークアップの方法について30分もまず考えないですよね。でもあえて考えることで、いろんな疑問や考え方が出てくるわけです。

酒井：確かに仕事では時間の制約上、マークアップについてそこまで深く考えることができずに不完全燃焼で終わること多いですね。でも仕事を離れたこうした場で改めて考えると、割と迷うことに気付くんです。結局のところ、結論を出すことより構造を考えることがマークアップにとって重要で、意義があるのではないでしょうか。

矢倉：実は提示されているお題にも構造的なミスがあるケースもあります。その場合、そもそもデザインの方で直せないのか？といった議論も起こる。

村岡：「マークアップエンジニアがデザインに文句を言える」これが重要だと思うんですよ。「これでは正しい文書構造を表現できない」と思ったとき、論理的に言い切れる知識と経験・根拠を持った説明ができるマークアップエンジニアになってほしいし、そうやって正しいものになっていくのだと思います。

酒井：そもそも仕様を策定する人も人間だし、自分らも同じ土俵に立っている。じゃあ、正解がないのになぜ考えるのか？　それは仕様を理解することからはじめて、その上で「自分はこう思う」という考えを持つことが大事だから。

村岡：皆さんにはぜひhtml5jのメーリングリストで「これどうデザインします？」と気軽に投稿してほしい。少なくとも僕が必ずレスつけます（笑）。

酒井：私もちょいちょい投げ込んでます。「もしかして自分だけ気になっていることかも？」という不安もありましたけど、実は結構有名な人が返してくれたりするんですよね。だから気軽に質問放り込んでほしい。

村岡：何度も言いますけど、マークアップに正解はない以上、どんな著名な人も「これはこうです」とはいえなくて、「僕はこう思います」としかいえない。その上で「僕はこう思う」をたくさん共有したらいいと思っています。

【講演資料・セッション映像】

マークアップシリーズの第2回は、前回のよくある3つのデザインから考える、マークアップの最適解と同じく、html5jマークアップ部主催のイベント「MarkupCafe」で出題された3つのお題から最適なマークアップを探ります。

イベントではAからDの4つのチームにわかれてマークアップを考えました。それぞれのチームごとに違ったマークアップへの考えが表れていてとても興味深いです。また今回はイベント終了後に「HTML5 Experts.jp」のエキスパート兼マークアップ部の部長でもある村岡正和氏に、氏自身ならこうするといったマークアップを公開してもらいました。

本記事ではWebサイト制作の際にありがちな”ページング”、”フォーム”、”データテーブル”の3つについて要素の使いどころや仕様、アクセシビリティやユーザビリティといった観点からマークアップを考えていきます。

1.ページングの中身と重要度

最初のお題はページング。
ブログのページ送りや検索結果でページが多い場合に使われますが、あまり深く考えてマークアップしたことはないのではないでしょうか。

このお題で注目したポイントは以下の3つです。

• 現在地をどう示すか
• 重要と強調の違い
• 前へと次への扱い

それぞれのチームのマークアップから考えていきます。

各チームのマークアップ

• お題1：チームA

<div class="pagination">
    <p class="prev"><a rel="prev">前へ</a>
    <p class="next"><a href="/next" rel="next">次へ</a>
    <ol class="sequential">
        <li><a class="current">1</a>
        <li><a href="/page2">2</a>
        <li><a href="/page3">3</a>
        <li><a href="/page4">4</a>
        <li><a href="/page5">5</a>
    </ol>
</div>

• お題1：チームB

<div class="paginate">
    <p>
        <a href="" rel="prev" class="prev">＜＜前へ</a>
    </p>
    <ol>
        <li><em>1</em>
        <li><a href="2">2</a>
        <li><a href="3">3</a>
        <li><a href="4">4</a>
        <li><a href="5">5</a>
    </ol>
    <p>
        <a href="" rel="next" class="next">次へ＞＞</a>
    </p>
</div>

• お題1：チームC

<nav>
    <a href="#">&lt;&lt;前へ</a>
    <ol>
        <li><a href="#">1</a></li>
        <li><a href="#">2</a></li>
        <li><a href="#">3</a></li>
        <li><a href="#">4</a></li>
        <li><a href="#">5</a></li>
    </ol>
    <a href="#">次へ&gt;&gt;</a>
</nav>

• お題1：チームD

<nav>
    <strong><a>&lt;&lt;</a></strong>
    <ul>
       <li><span>1</span></li>
       <li><a>2</a></li>
       <li><a>3</a></li>
       <li><a>4</a></li>
       <li><a>5</a></li>
    </ul>
    <strong><a>&gt;&gt;</a></strong>
</nav>

現在地の表し方

チームAは

<li><a class="current">1</a>

チームBは

<li><em>1</em>

現在どこのページにいるのかをページングで表現する場合、主に視覚的な観点からスタイルを変えるというアプローチを取ることが多いと思います。ですがセマンティクスを考える場合には、こういった表し方も意識する必要があるのではないでしょうか。

重要か強調か、strongとemの違いは？

チームDは前へと次へのリンクに対してstrong要素でマークアップしています。
strong要素はHTML5の仕様では強調ではなく強い重要性を表す要素とされています。

em要素はニュアンスとしての強調ですがstrong要素を使った場合そのコンテンツの中でその部分が重要であると意味付けしていることになります。
ページングというコンテキストにおいて、重要かどうかといった意味付けをするのが適しているかは、判断するのがかなり難しいと思います。

リンク先との関係から考えられるもの

チームAとチームBは

<a href="#" rel="prev">前へ</a> <a href="#" rel="next">次へ</a>

rel="prev"

ブラウザの中にはrel属性を解釈してブラウザ自体のナビゲーションに前のページや次のページへのリンクを表示するといった実装をしているものもあります。(prestoの頃のOperaなど)

普段外部CSSの読み込みの際に

rel="stylesheet"

視覚的・構造的順番の分離がもたらす効果

またチームAは他のチームと大きく違い、”次へ”のリンクをページ番号のリストより前にマークアップしています。
これはスクリーンリーダなど音声による読み上げを考えた場合に「”前へ”の次に数字が読みあげられるよりも”次へ”を読み上げたほうが良いと考えた」という観点からでした。

視覚的な構造をスタイルシートで表すようにすることで、アクセシビリティを意識するといった違った視点からマークアップをすることができると、とても考えさせられるマークアップです。

部長はこう書く！

このお題に対しての村岡氏のマークアップです。

<head>
    <link rel="next" href="p2.html">
</head>
<body>
    <div>
        <p><a class="prev">前へ</a></p>
        <ol>
            <li><a class="current-page">1</a></li>
            <li><a href="p2.html">2</a></li>
            <li><a href="p3.html">3</a></li>
            <li><a href="p4.html">4</a></li>
            <li><a href="p5.html">5</a></li>
        </ol>
        <p><a class="next" href="p2.html">次へ</a>
    </div>    
</body>

マークアップ自体はチームAとチームBに似ていますが、”＜＜”や”＞＞”はスクリーンリーダなどで読み上げてほしくないといったことから、CSSの擬似要素で視覚的に挿入しています。

アクセシビリティを意識したとき、順番を考えるのも大事ですが、そのコンテンツ自身も意識することが大事だと考えられます。

2.進化するフォームに対応できるか

2つ目のお題はフォームです。
このお題で注目したポイントは以下の3つです。

• アスタリスク
• label要素の使い方
• input要素の属性

各チームのマークアップ

• お題2：チームA

<section class="reservation">
    <h1>バスタイム商事 会議室予約フォーム</h1>
    <p class="note"><span class="mark-req">*</span>は必須入力です</p>
    <form>
        <table>
            <tr><th><label for="room">会議室名</label>
                <td><input id="room" required aria-label="会議室名（必須）">
                    <span class="mark-req">*</span>
            <tr><th><label for="date">ご利用日</label>
                <td><input id="date" type="date" required aria-label="ご利用日（必須）">
                    <span class="mark-req">*</span>
            <tr><th><label for="time">ご利用時刻</label>
                <td><input id="time" type="time" required aria-label="利用開始時刻（必須）"> 〜 <input type="time" required aria-label="利用終了時刻（必須）">
                    <span class="mark-req">*</span>
            <tr><th><label for="number">ご利用人数</label>
                <td><input id="number" type="number" min="1" step="1" required aria-label="ご利用人数（必須）">
                    <span class="mark-req">*</span>
            <tr><th><label for="name">代表者氏名</label>
                <td><input id="name" required aria-label="代表者氏名（必須）">
                    <span class="mark-req">*</span>
            <tr><th><label for="name-reading">代表者氏名ローマ字<br><span class="note-label">（半角英字）</span></label>
                <td><input id="name-reading" pattern="[A-Za-z\. ]+" required aria-label="代表者氏名ローマ字（必須、半角英字）">
                    <span class="mark-req">*</span>
            <tr><th><label for="email">E-Mail</label>
                <td><input id="email" type="email" required aria-label="E-Mail（必須）">
                    <span class="mark-req">*</span>
            <tr><th><label for="tel">TEL</label>
                <td><input id="tel" type="tel">
            <tr><th><label for="url">URL</label>
                <td><input id="url" type="url" pattern="^https?\:\/\/.+">
        </table>
        <button>予約する</button>
    </form>
</section>

• お題2：チームB

<form action="">
    <p>
        <strong>
            <label for="f1">会議室名</label><input type="text" name="f1" id="f1" required autofocus="autofocus"><span>*</span>
        </strong>
    <p>
        <strong>
            <label for="f2">ご利用日</label><input type="date" name="f2" id="f2" required><span>*</span>
        </strong>
    <p>
        <strong>
            <label for="f3">ご利用時刻</label><input type="time" name="f3" id="f3" required>〜
            <label for="f4"></label><input type="time" name="f4" id="f4" required><span>*</span>
        </strong>
    <p>
        <strong>
            <label for="f5">ご利用人数</label><input type="number" name="f5" id="f5" required><span>*</span>
        </strong>
    <p>
        <strong>
            <label for="f6">代表者氏名</label><input type="text" name="f6" id="f6" required><span>*</span>
        </strong>
    <p>
        <strong>
            <label for="f7">代表者氏名ローマ字</label><input type="text" pattern="^[A-Za-z]+$" name="f7" id="f7" required><span>*</span>
        </strong>
    <p>
        <strong>
            <label for="f8">E-Mail</label><input type="email" name="f8" id="f8" required><span>*</span>
        </strong>
    <p><label for="f9">TEL</label><input type="tel" name="f9" id="f9">
    <p><label for="f10">URL</label><input type="url" name="f10" id="f10">
    <p><input type="submit" value="予約する">
</form>

• お題2：チームC

<header>
    <h1>バスタイム商事 会議室予約フォーム</h1>
</header>
<p><span>※</span>は入力必須です</p>
<form action="#">
<div>
    <label for="muraoka1">会議室名</label>
    <input id="muraoka1"  type="text" name="btf1"><span>※</span>
</div>
<div>
    <label for="muraoka2">ご利用日</label>
    <input id="muraoka2" type="date" name="btf2"><span>※</span>
</div>
<div>
    <label>ご利用時刻
    <input  id="muraoka3" type="time" name="btf31">〜
    <input type="time" name="btf32"><span>※</span>
    </label>
</div>
<div>
    <label for="muraoka4">ご利用人数</label>
    <input  id="muraoka4" type="number" name="btf4"><span>※</span>
</div>
<div>
    <label for="muraoka5">代表者氏名</label>
    <input  id="muraoka5" type="text" name="btf5"><span>※</span>
</div>
<div>
    <label for="muraoka6">代表者氏名ローマ字(半角英字)</label>
    <input  id="muraoka6" type="text" name="btf6"><span>※</span>
</div>
<div>
    <label for="muraoka7">E-Mail</label>
    <input  id="muraoka7" type="email" name="btf7"><span>※</span>
</div>
<div>
    <label for="muraoka8">TEL</label>
    <input  id="muraoka8" type="tel" name="btf8">
</div>
<div>
    <label for="muraoka9">URL</label>
    <input  id="muraoka9" type="url" name="btf9">
</div>
<input type="submit" value="予約する">
</form>

• お題2：チームD

<h1>バスタイム商事 会議予約フォーム</h1>
<p><small><i>*</i>は入力必須です</small></p>
<form action="">
    <ul>
        <li><label>会議室名 <input type="text" required></label><i>*</i></li>
        <li><label>ご利用日 <input type="date" required></label><i>*</i></li>
        <li><label>ご利用時刻 <input type="time" required></label><i>*</i></li>
        <li><label>ご利用人数 <input type="number" min="1" required></label><i>*</i></li>
        <li><label>代表者氏名 <input type="text" required><i>*</i></label></li>
        <li><label>代表者氏名ローマ字<small>(半角英字)</small> <input type="text" pattern="^[0-9A-Za-z]+$" required></label><i>*</i></li>
        <li><label>E-Mail <input type="email" required></label><i>*</i></li>
        <li><label>TEL <input type="tel"></label></li>
        <li><label>URL <input type="url"></label></li>
    </ul>
    <input type="submit" value="予約する">
</form>

i要素は日本語に合わない？

チームDは必須項目を表しているアスタリスクをi要素でマークアップしています。i要素は最近ですとスプライトアイコンを使用する際に使われていることが多いように思います。
仕様的にはi要素は文章中で他と区別したいテキストや印刷の際に斜体になるテキストに対して使うとされています。
ただこの仕様は欧文の文章慣習に拠っている部分が大きいので「そもそも日本語の文章慣習には合っていないのではないか」という意見もありました。

そう考えるとi要素を使わずにem要素やb要素でマークアップするといったことも考えられるかもしれません。

アスタリスクじゃ伝わらない

Webのフォームにおいて、赤いアスタリスクで”入力必須項目”であることを表しているページが多いと思います。
しかしこれについて「赤いアスタリスク自体には必須項目であるという意味はないので、そもそもこういった使い方がよくないのでは」という意見がありました。
また、このお題ではデザイン的にアスタリスクが後ろに来ていることから、アスタリスクを項目の後ろにマークアップすると思います。ですが読み上げされる場合を考えると、項目名の読み上げを行なった後にその項目が必須であるかどうかがわかります。

アクセシビリティやユーザビリティをしっかり考えた場合、項目の前に”(必須項目です)”といったような記述をすることが望ましいのではないかと筆者は考えます。

囲むか分けるか、label要素の使い方

label要素はinput要素を内包する書き方と、for属性によって対象のinput要素を指定する書き方の二通りあり、マークアップ的にはどちらの書き方も正しいです。
今回の場合デザイン的にラベルの右側にマージンが空いてる様に見えるので、スタイル付けがしやすいようにlabel要素とinput要素を分けて書く方が適していると考えることができます。

type=”?”

HTML5ではinput要素のtype属性に色々なtypeが設定できるようになっています。 数字にはnumber、メールアドレスにはemailなど、JavaScriptを使わずに入力項目のフォーマットを指定することができます。
typeを上手く使い分けることで、ユーザが入力の際に迷わないフォームが作れるのではないでしょうか。

なお、これらのtypeに対応していないブラウザでは

type="text"

input要素で使える便利な属性たち

いくつかのチームでinput要素の属性にrequired属性やautofocus属性といった指定をしています。
requiredはその項目が必須であることを表し、送信ボタンを押した際にはその項目が未入力であった場合に未入力であると警告して送信処理を行いません。
autofocus属性はそのページを開いた際に自動的に入力欄にフォーカスされ、ユーザーが項目を選択することなく入力を開始することができます。

ほかにもautocomplete属性やstep属性、またpattern属性といったものもあり、これらを使えばJavaScriptを書かずに入力内容に制約をかけることもできます。

入力チェックは万全に

input要素の属性を使う上で注意しておきたい点があります。required属性やpattern属性といった属性は確かに便利なのですが、データの入力チェックをこれだけで済ましてはいけません。
これらの属性はあくまでも入力の補助的な機能であって、送信されてくるデータは保証していません。
悪意のある第三者が、入力フォームを通さずにフォームの送信先に直接データを送ることも十分に考えられます。そういった場合これらの属性は無力です。

フォームで入力必須にしてあるし正規表現で形式指定してあるから送られてくるデータは必ず正しい、と思わずに、送信されてきたデータはしっかりとサーバサイドで整合性をチェックする必要がある、ということを覚えておいてください。

部長はこう書く！

<h1>バスタイム商事 会議室予約フォーム</h1>
<p class="note"><span class="mark-req">*</span>は必須入力です</p>
<form>
    <div>
        <label for="room-name">会議室名</label>
        <input id="room-name" required placeholder="A会議室">
        <span class="required">*</span>
    </div>
    <div>
        <label for="date">ご利用日</label>
        <input id="date" type="date" required placeholder="2013/01/23">
        <span class="required">*</span>    
    </div>
    <div>
        <label for="time">ご利用時刻</label>
        <input id="time" type="time" required placeholder="01:13">
        〜
        <input type="time" required placeholder="02:34">
        <span class="required">*</span>    
    </div>
    <div>
        <label for="number">ご利用人数</label>
        <input id="number" type="number" placeholder="1">
        <span class="required">*</span>        
    </div>
    <div>
        <label for="name">代表者氏名</label>
        <input id="name" required placeholder="神戸　太郎">
        <span class="required">*</span>    
    </div>
    <div>
        <label for="name-roma">
            代表者氏名ローマ字<br>
            <span class="notes">（半角英字）</span>
        </label>
        <input id="name-roma" pattern="[A-Za-z/ .]+" required placeholder="Taro Kobe">
        <span class="required">*</span>    
    </div>
    <div>
        <label for="email">E-Mail</label>
        <input id="email" type="email" required placeholder="kobe@bathtimeshoji.com">
        <span class="required">*</span>        
    </div>
    <div>
        <label for="tel">TEL</label>
        <input id="tel" type="tel" placeholder="0123456789">        
    </div>
    <div>
        <label for="url">URL</label>
        <input id="url" type="url" placeholder="http://bathtimeshoji.com/">    
    </div>
    <input type="submit" value="予約する">
</form>

前述したように、ブラウザが対応していないtypeが指定されている場合には

type="text"

3.tableを見直す

最後のお題は業績の表です。

このお題で注目したポイントは以下の2つです。

• tableの構造
• scope属性

お題のデザインをHTMLとCSSで見た目的に表すのにそれほど時間はかからないと思います。 table要素でマークアップして見出しのセルをcolspanで適宜結合すれば数分で終わる作業です。 ですが各データと見出しの関係性をしっかりとマークアップで表そうとした場合、table要素への理解が必要になります。

各チームのマークアップ

• お題3：チームA

<table border>
    <thead>
        <tr>
            <th>
            <th>2012年3月
            <th>2013年3月
    </thead>
    <tbody>
        <tr><th colspan="3" scope="rowgroup">連結経営成績
        <tr><th scope="row">営業収益
            <td>1,000
            <td>1,000
        <tr><th scope="row">営業利益
            <td>1,000
            <td>1,000
        <tr><th scope="row">税引前利益
            <td>1,000
            <td>1,000
        <tr><th scope="row">当期利益
            <td>1,000
            <td>1,000
    </tbody>
    <tbody>
        <tr><th colspan="3" scope="rowgroup">連結財政状態
        <tr><th scope="row">資産合計
            <td>1,000
            <td>1,000
        <tr><th scope="row">資本合計
            <td>1,000
            <td>1,000
        <tr><th scope="row">帰属持分比率（％）
            <td>10.0
            <td>10.0
    </tbody>
    <tbody>
        <tr><th colspan="3" scope="rowgroup">キャッシュフローの状況
        <tr><th scope="row">営業活動によるキャッシュフロー
            <td>1,000
            <td><span class="mark">△</span>1,000
        <tr><th scope="row">投資活動によるキャッシュフロー
            <td><span class="mark">△</span>1,000
            <td><span class="mark">△</span>1,000
        <tr><th scope="row">財務活動によるキャッシュフロー
            <td>1,000
            <td>1,000
        <tr><th scope="row">現金及び現金同等物<br>期末残高
            <td>1,000
            <td>1,000
    </tbody>
</table>

• お題3：チームB

<div>
    <table>
        <caption>連結経営成績</caption>
        <thead class="thead">
            <tr>
                <th>項目</th>
                <th>2012年3月</th>
                <th>2013年3月</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>営業収益</td><td>237,409</td><td>203,423</td>
            </tr>
            <tr>
                <td>営業利益</td><td>237,409</td><td>203,423</td>
            </tr>
            <tr>
                <td>税引前利益</td><td>237,409</td><td>203,423</td>
            </tr>
            <tr>
                <td>当期利益</td><td>237,409</td><td>203,423</td>
            </tr>
        </tbody>
    </table>
</div>

<div>
    <table>
        <caption>連結財政状態</caption>
        <thead>
            <tr>
                <th>項目</th>
                <th>2012年3月</th>
                <th>2013年3月</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>営業収益</td><td>237,409</td><td>203,423</td>
            </tr>
            <tr>
                <td>営業利益</td><td>237,409</td><td>203,423</td>
            </tr>
            <tr>
                <td>税引前利益</td><td>237,409</td><td>203,423</td>
            </tr>
            <tr>
                <td>当期利益</td><td>237,409</td><td>203,423</td>
            </tr>
        </tbody>
    </table>
</div>

<div>
    <table>
        <caption>キャッシュフローの状況</caption>
        <thead>
            <tr>
                <th>項目</th>
                <th>2012年3月</th>
                <th>2013年3月</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>営業収益</td><td>237,409</td><td>203,423</td>
            </tr>
            <tr>
                <td>営業利益</td><td>237,409</td><td>203,423</td>
            </tr>
            <tr>
                <td>税引前利益</td><td>237,409</td><td>203,423</td>
            </tr>
            <tr>
                <td>当期利益</td><td>237,409</td><td>203,423</td>
            </tr>
        </tbody>
    </table>
</div>

• お題3：チームC

<table border="1">
    <thead>
        <th></th>
        <th>2012/3</th>
        <th>2013/3</th>
    </thead>
    <tbody>

        <tr><th colspan="3">連結経営成績</th></tr>
        <tr>
            <th>AAA</th>
            <td>123,456</td>
            <td>7,890</td>
        </tr>
        <tr>
            <th>AAA</th>
            <td>123,456</td>
            <td>7,890</td>
        </tr>
        <tr>
            <th>AAA</th>
            <td>123,456</td>
            <td>7,890</td>
        </tr>

        <tr><th colspan="3">連結財政状態</th></tr>
        <tr>
            <th>AAA</th>
            <td>123,456</td>
            <td>7,890</td>
        </tr>
        <tr>
            <th>AAA</th>
            <td>123,456</td>
            <td>7,890</td>
        </tr>
        <tr>
            <th>AAA</th>
            <td>123,456</td>
            <td>7,890</td>
        </tr>

        <tr><th colspan="3">キャッシュフローの状況</th></tr>
        <tr>
            <th>AAA</th>
            <td>123,456</td>
            <td>7,890</td>
        </tr>
        <tr>
            <th>AAA</th>
            <td>123,456</td>
            <td>7,890</td>
        </tr>
        <tr>
            <th>AAA</th>
            <td>123,456</td>
            <td>7,890</td>
        </tr>

    </tbody>
</table>

• お題3：チームD

<table border="1">
    <thead>
        <tr>
            <th></th>
            <th id="year2012" scope="col">2012年3月</th>
            <th id="year2013" scope="col">2013年3月</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <th colspan="3" scope="col" class="title">連結経営成績</th>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th colspan="3" scope="col" class="title">連結経営成績</th>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2012">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th colspan="3" scope="col" class="title">連結経営成績</th>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2012">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th colspan="3" scope="col" class="title">連結経営成績</th>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2012">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
        <tr>
            <th scope="row">営業収益</th>
            <td headers="year2012">2000円</td>
            <td headers="year2013">2000円</td>
        </tr>
    </tbody>
</table>

みんなが悩んだscope属性

参加者を大いに悩ませたのは右上にある年月の表示です。年月の見出しはデータ的に列方向のセルに掛かっています。しかし先頭に空行の見出しセルがあったり、”連結経営成績”などのカラム全体にまたがるセルが存在してたりと、見出しとセルの関連付けが一見してやりづらそうな見た目です。

こういった単純ではない表で有効とされているのがscope属性の指定です。
“年月”の見出しには

scope="col"

scope="row"

また、scope属性を指定することでユーザーエージェントに見出しの方向を正しく伝えることができるので、データをよりアクセシブルにするために有効であるという見方もできます。データの関係性をしっかりとマークアップすることで、アクセシビリティ的にもより良いマークアップにすることができると考えられます。

CSS is Power !?

チームBはこのデザインを3つの表の集まりとして捉えてマークアップしています。「年月の見出しなどで一つの表に見えるだけで、それぞれ独立した表である」と考えてのことでした。3つの表では見出しセルとしてtheadに年月を入れていますが、CSSによって1つ目の表の見出しだけを表示するようにしています。

見た目と構造の分離という観点から見ると、スタイリングによって解決することも一つの手法なのではと筆者は考えます。

部長はこう書く！

<section>
    <table border="1">
        <thead>
            <tr>
                <th></th>
                <th scope="col">2012年3月</th>
                <th scope="col">2013年3月</th>
            </tr>        
        </thead>
        <tbody>
            <tr>
                <th scope="rowgroup" colspan="3" class="group">
                    連結経営成績
                </th>
            </tr>
            <tr >
                <th scope="row">営業収益</th>
                <td>237,409</td>
                <td>203,423</td>
            </tr>
            <tr>
                <th scope="row">営業利益</th>
                <td>15,530</td>
                <td>14,577</td>
            </tr>
            <tr>
                <th scope="row">税引前利益</th>
                <td>13,600</td>
                <td>10,213</td>
            </tr>
            <tr>
                <th scope="row">当期利益</th>
                <td>2,562</td>
                <td>7,962</td>
            </tr>
            <tr>
                <th scope="rowgroup" colspan="3">
                    連結財政状態
                </th>
            </tr>
            <tr >
                <th scope="row">資産合計</th>
                <td>2,455,368</td>
                <td>7,793,387</td>
            </tr>
            <tr>
                <th scope="row">資本合計</th>
                <td>320,905</td>
                <td>330,535</td>
            </tr>
            <tr>
                <th scope="row">帰属持分比率（％）</th>
                <td>17.9</td>
                <td>12.2</td>
            </tr>
            <tr>
                <th scope="rowgroup" colspan="3">
                    キャッシュフローの状況
                </th>
            </tr>
            <tr >
                <th scope="row">営業活動によるキャッシュフロー</th>
                <td>9,618</td>
                <td>△32,954</td>
            </tr>
            <tr>
                <th scope="row">投資活動によるキャッシュフロー</th>
                <td>△13,021</td>
                <td>△16,160</td>
            </tr>
            <tr>
                <th scope="row">財務活動によるキャッシュフロー</th>
                <td>7,487</td>
                <td>23,699</td>
            </tr>
            <tr>
                <th scope="row">現金および現金同等物<br>期末残高</th>
                <td>129,833</td>
                <td>110,362</td>
            </tr>        
        </tbody>
    </table>
</section>

table要素に

border="1"

テーブルレイアウトは一般的に推奨されていませんが、レイアウト目的でtable要素を使いたい場合には

role="presentation"

border="0"

cellspacing="0" cellpadding="0"

マークアップの奥深さ

前回同様に今回のイベントでも各お題に対して30分の考察時間が設けられましたが、どのお題も30分ではまとめられないほどの議論がありました。
いろいろな考えがありますが、人それぞれに違ったマークアップがあり、どれが一番といった答えはありません。

要素の使い方や属性への理解など、より良いマークアップをする際には相応の知識が求められます。また、知識だけでなくユーザビリティやアクセシビリティといったことも考慮する必要があると思います。

誰にとって、何にとって良いマークアップなのか、マークアップをする際に考えてみてください。

Web制作においてHTMLのマークアップには絶対の正解というものがありません。ページを制作しているとき、特にセマンティクスを意識したとき「このマークアップで正しいのだろうか」と悩むことがあると思います。

そんなマークアップについて考えるイベント「MarkupCafe」がhtml5jマークアップ部の主催のもと開催されました。「MarkupCafe」では参加者同士がチームに分かれ、お題となるデザインに対して議論し、自分たちならこうマークアップするといった考えを発表し合いました。

本記事では「MarkupCafe」で出された”フッター”、”パンくずリスト”、”求人情報”の3つのお題をもとに、Web制作におけるマークアップの捉え方、誤った使い方をしがちな要素などについて考え、マークアップの最適解を探ります。

※html5jは、HTML5などのWebプラットフォーム技術を使った「ものづくり」に関わる、すべての人々を応援する非営利・中立のコミュニティです。

1.フッターの要素が持つそれぞれの意味は？

最初のお題として出されたのはページ最下部によくある、フッター部分のデザインからのマークアップです。お題で使われた画像には、筆者が印象から決めたパーツの構成がわかるようにキャプションをつけています。筆者はAからFの6つのパーツに分解してマークアップを考えました。パーツをいくつかピックアップして、参加者のマークアップを見ていきます。

パンくずリスト？ナビゲーション？

意見が分かれるところだと思いますが、Aのパーツはパンくずリストにもナビゲーションにもとれるパーツです。実際に各チームのマークアップは、大きく分類してリストを使うか、使わないかに二分されました。

<nav><!-- nav要素で囲むチームもいれば -->
    <ul>
        <li>
            <a href="">HOME ＞</a><!-- リンクにしないチームも -->
        </li>
    </ul>
</nav>

リストにしたチームの中でもnav要素で囲んでいたり、li要素の中をリンクにしたりといった差異がありました。リストにしなかったチームのマークアップはp要素一つというもので、「意味をもたせるほど重要な情報ではない」と判断してのもの。捉え方の違いでマークアップは大きく変わる、ということ象徴していると思います。

水平線に潜む罠？

Bのパーツの水平線は、一見hr要素を使って線が引けそうですが、どのチームもhr要素は使っていません。hr要素は話題の区切りなどを表す際に使う要素なので、この場合のマークアップには適さないという判断でした。見た目的な水平線を引きたい場合は、スタイルシートで行うべきだとされています。

address要素から考える”良いマークアップ”とは？

このお題の中で、どのチームも一番時間をかけたのがDとEのパーツです。電話番号やメールアドレス、住所といった情報に意味をもたせようと思ったとき、一番に浮かぶのはaddress要素です。どのチームもaddress要素を使用しましたが、その使い方はバラバラでした。

<address>
    <p>
        <span><a>お問い合わせ：0120-0000-0000</a>, <a>infomation[at]bathtimeshoji.com</a></span>
    </p>
</address>
<dl>
    <dt>神戸本社：</dt>
    <dd>兵庫県神戸市◯◯◯◯◯ 11-11-11 ◯◯ビル 11</dd>
    <dt>東京本社：</dt>
    <dd>東京都渋谷区◯◯◯◯◯ 22-22-22 ◯◯ビル 22</dd>
</dl>

<p>
    <span>お問い合わせ：</span>
    <address itemprop="telephone">0120-0000-0000</address>
    <address itemprop="email">infomation[at]bathtimeshoji.com</address>
</p>
<dl>
    <dt>神戸本社：</dt>
    <dd>兵庫県神戸市◯◯◯◯◯ 11-11-11 ◯◯ビル 11</dd>
    <dt>東京本社：</dt>
    <dd>東京都渋谷区◯◯◯◯◯ 22-22-22 ◯◯ビル 22</dd>
</dl>

<address>
    <p>お問い合わせ：<span>0120-0000-0000</span> <span>infomation［at］bathtimeshoji.com</span></p>
    <p>神戸本社：<span>兵庫県神戸市◯◯◯◯◯ 11-11-11 ◯◯ビル 11</span></p>
    <p>東京本社：<span>東京都渋谷区◯◯◯◯◯ 22-22-22 ◯◯ビル 22</span></p>
</address>

お問い合せの部分だけをaddress要素にするチームもあれば、Microdataを使った上で電話番号とメールアドレスを分けてaddress要素を使う、住所も含めてaddress要素にする、といったようにaddress要素の使い方はバラバラになりました。

address要素は特に誤った使われ方をされる要素の一つですが、仕様をざっくりと意訳すると”そのドキュメントの問い合わせを受ける人に関する情報に用いる”とされています。このお題の場合、ドキュメントの問い合わせ先として適していそうなのは電話番号とメールアドレスの2種類だと捉え、所在地の情報は適していないと考えることができます。 要素の名前がもっていそうな意味からマークアップするのではなく、仕様に基づいて正しい使い方をすることが良いマークアップのためには必要です。

2.パンくずリストに正解はあるのか

次のお題に出されたのはパンくずリストです。先のお題の中にもパンくずリストとして扱える要素がありましたが、このお題では明確にパンくずリストとしてマークアップします。

ほとんどのチームが要素にメタデータを付与して、細かく意味付けをしていました。パンくずリストというシンプルなお題なだけに、同じようなマークアップになるのではと思いましたが、それぞれのマークアップからは様々な部分に思考を巡らせたのが見えてきます。

メタデータはだれのため？

このマークアップでは、Microdataで各要素にメタデータで意味付けをしています。

<nav>
    <ol itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
        <li itemprop="child">
            <a itemprop="url" href="">
                <span itemprop="title">Markup Cafe トップページ</span>
            </a>
        </li>
        <li itemprop="child">
            <a itemprop="url" href="">
                <span itemprop="title">店舗情報</span>
            </a>
        </li>
        <li>ドリンク・フード</li>
    </ol>
</nav>

Microdataを使った理由としては、Googleなどの検索エンジンに対して優位なマークアップにしたいといった意図からです。

ここではol要素を使っていますが、パンくずリストを順序ありリストとするか順序なしリストとするか、この点だけを取っても意見が分かれると思います。

これからはRDFaがくるかも

このマークアップではMicrodataではなくRDFa Liteで意味付けをしています。

<nav vocab="http://rdf.data-vocabulary.org/" typeof="Breadcrumb">
  <h1>ページ階層</h1>
    <ul>
        <li>
            <a property="url" href="">
                <span property="title">Markup Cafe トップページ</span>
            </a>
        </li>
        <li>
            <a property="url" href="">
                <span property="title">店舗情報</span>
            </a>
        </li>
        <li>
            <a property="url" href="">
                <span property="title">ドリンク・フード</span>
            </a>
        </li>
    </ul>
</nav>

先日W3Cより勧告されたRDFa 1.1では、HTML5への対応やRDFa Liteで簡潔なマークアップが可能になったこともあり、RDFaの利用が増えていくかもしれません。

先のマークアップとの他の違いとして、h1要素を使ってる箇所があります。nav要素はセクショニング・コンテンツなので、見出し要素を使うことでアウトラインを意識したマークアップにできる、と考えることもできます。

リストってなんだろう

このマークアップはMicrodataを使っていますが、リスト要素を使っていません。

<div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
    <a itemprop="url" href="">
        <span itemprop="title">Markup Cafe トップページ</span>
    </a>
</div>
<div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
    <a itemprop="url" href="">
        <span itemprop="title">店舗情報</span>
    </a>
</div>
<div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
    <a itemprop="url" href="">
        <span itemprop="title">ドリンク・フード</span>
    </a>
</div>

これは「パンくずリストはリストではない」という解釈からでした。階層構造を表すためにリスト要素を使うのが本当に正しいのかどうか、非常に考えさせられるマークアップです。

意味付けだけに囚われることなかれ

このマークアップは、メタデータを使わず非常に簡素なマークアップです。

<ul>
    <li>
        <a href="">Markup Cafe トップページ</a>
    </li>
    <li>
        <a href="">店舗情報</a>
    </li>
    <li>
        <a href="">ドリンク・フード</a>
    </li>
</ul>

同じようにリスト要素を使っている他のチームと比べるとnav要素を使っていません。これはnav要素の”重要なナビゲーションブロックからなるセクションだけがnav要素に適している”という仕様を意識し、パンくずリストはそこまで重要ではないと判断してのものでした。

また、nav要素を使わなかったもう一つの理由として「スクリーンリーダなどでアクセスしたときに重要なリンクを見失わないように」という意図も込められています。セマンティクスを与えてマシンが意味を理解できるようにすることも大事ですが、その先を考える必要もあるのかもしれません。

Microdata VS RDFa、決着か？

MicrodataとRDFaはどちらもメタデータを付与して意味づけを行うための仕様ですが、Microdataが7月にW3C HTML WGによってHTML5.0の勧告候補から削除されてしまいました。(詳しい理由と顛末は白石編集長の記事でふれていますのでそちらをご覧ください) Microdataがこの先どう落ち着くのか、先にふれたRDFa 1.1が勧告されたという点からもこれからの動向に要注目です。

3.求人情報は独立した記事か

最後のお題は、よくある求人情報のデザインからのマークアップです。このお題では4つのパーツに分解して考えました。中でもAの”求人情報全体”については特に意見が分かれ、多くの議論が交わされました。

tableの出番？いやいやdlでしょ

Dの求人内容の部分は、table要素とdl要素とでマークアップが分かれました。

<dl>
    <dt>給与</dt><dd>時給1500円</dd>
    <dd>月額20.3万円〜22.3万円＋残業代</dd>
    <!-- 略 -->
</dl>

給与や勤務時間といった情報を定義と解釈するか、表の項目の一つとして解釈するかで使用する要素も変わってきます。どちらを使うのが正しいのか決められることではないですが、その情報が何を表したいのか考えることは良いマークアップへと繋がります。

文章構造は視覚的に決まる？

Cの”その他の情報”部分のマークアップですが、チームごとにバラバラになっていたのがとても興味深いです。

<p><img src="" alt=""></p>
<p>未経験！派遣初めてさん！大歓迎！<br>
★履歴書不要！らくらく登録！<br>
★正社員のような待遇！嬉しい「月給制＋交通費支給 」<br>
★IT・美容・マスコミ・金融など業界も様々<br>
★正社員を目指す！紹介予定派遣のお仕事多数
</p>

<p><img src="" alt="">未経験！派遣初めてさん！大歓迎！</p>
<p>★履歴書不要！らくらく登録！</p>
<p>★正社員のような待遇！嬉しい「月給制＋交通費支給 」</p>
<p>★IT・美容・マスコミ・金融など業界も様々</p>
<p>★正社員を目指す！紹介予定派遣のお仕事多数</p>

<img src="" alt="">
<p>未経験！派遣初めてさん！大歓迎！</p>
<ul>
    <li>★履歴書不要！らくらく登録！</li>
    <li>★正社員のような待遇！嬉しい「月給制＋交通費支給 」</li>
    <li>★IT・美容・マスコミ・金融など業界も様々</li>
    <li>★正社員を目指す！紹介予定派遣のお仕事多数</li>
</ul>

p要素の中でbr要素で改行してるものもあれば、全てp要素にしたり、リストを使ってるマークアップもあります。一行目に星マークがついていないテキストがあるから箇条書き、という解釈もできますし、一行目以外は星マークがついているからリスト、という解釈もできます。

では、もしこの一行目のテキストにも星マークがついていたらどうでしょうか。それぞれ似たようなマークアップになっていたかもしれません。これらのマークアップから「構造が曖昧な文章への意味付けは、整った文章への意味付けよりも解釈の仕方が多様になる」と筆者は考えます。

articleという名の迷宮

HTML5で定義された要素の中でも、特にarticle要素の使いどころについてはさまざまな意見があると思います。article要素を使ったチーム、article要素ではなくsection要素を使ったチーム、2つのマークアップを比較します。

<article>
    <h1><!-- 見出し --></h1>
    <div><!-- その他の情報+求人内容 --></div>
    <aside><!-- 関連する求人 --></aside>
</article>

<section>
    <h1><!-- 見出し --></h1>
    <div><!-- その他の情報+求人内容 --></div>
    <div><!-- 関連する求人 --></div>
</section>

この2つのマークアップはaside要素を使っているという違いこそあるものの、文書構造的にはとても似ています。article要素をどこで使えばいいか悩んだときは、「RSSとして配信されたときに単独の記事として成り立つかどうかを意識すると良い」と言われていますが、それも見る人や状況によって違ってきます。article要素とsection要素のどちらを使うかは、前後の文章構造によっても変わりますが、主観による部分が大きいのではないでしょうか。構造の解釈は一緒なのに意味の解釈は違うものになる、マークアップの奥深さが垣間見えます。

MarkupCafeから見えたもの

今回筆者が参加したMarkupCafeでは一つのマークアップについて、30分間考える時間がありました。自分自身でマークアップに向き合えたのもよい体験でしたが、同じデザインから自分と違うマークアップをした理由を直接聞ける機会はなかなかないと思います。解釈の仕方でマークアップが変わる、というのを実感できたイベントでした。

この記事で紹介したマークアップや要素の使い方も、すべて考え方の一つでしかありません。答えを決めることはできないかもしれませんが、良いマークアップを作っていくことはできるはずです。

最後に「MarkupCafe」主催の村岡正和氏の言葉を引用して、記事を締めくくりたいと思います。

「HTMLのマークアップには決まった答えがありません。 どんなウェブページを作りたいか。アクセスした人になにを伝えたいか。どういう気持で伝えたいか。 それがページごとに違うから、それぞれのページにそれぞれのマークアップがあるのです」

＜MarkupCafe Tokyo Vol.2 開催のお知らせ＞ 10月19日（土）13:00～17:00に「MarkupCafe Tokyo Vol.2」を開催します。 プロのWebデザイナーから初心者まで、みんなで気軽に会話しながらイマドキのHTMLマークアップの知識を深めましょう！ 詳細はこちらから。

HTML5化によるSEO効果の影響はあるか

WebサイトをHTML5でマークアップをする際、特にHTML4などからHTML5にリニューアルする場合に、それによって検索エンジンによる評価が変化するのかどうかは非常に気になる問題です。

各検索エンジンでは、この疑問について公式に説明しています。GoogleはHTML5化することでプラスにもマイナスにもならないと度々公式に言及していますし、Bingは「List of things you really ought to know as an SEO today(今SEOとして本当に知っておきたいこと)」と題した記事の中で、HTML5について言及しています。こうした情報を併せて考えると、主要な検索エンジンは、HTML5化は問題ない、もしくは推奨しているとさえ言っても良いでしょう。

しかし、本当にHTML5化することでSEO上の問題は起きないものでしょうか。 私はSEOの専門家として、HTML5のWebサイトに多く関わってきました。お客様のWebサイトでのHTML4からHTML5への変更も何度か経験しましたが、実際HTML5化で検索流入が伸びたことも減ったこともありません。しかし過去に数度、HTML5化を含むリニューアルの結果、大幅に検索流入を落としたWebサイトの話を聞いたことがあります。

「問題ない形のHTML5化」であれば、検索エンジンはその評価を変えることはないと私は考えています。しかし、SEOの知識を一切持たずにHTML5化すると、犯しがちなミスもあります。 本稿では、SEO上の問題を起こさずにHTML5化するために注意すべきポイントを説明しましょう。

HTML5のマークアップをする際の注意点

FlashからHTML5へ。リッチな表現のSEO手法

ほんの1～2年前までWebでリッチな表現をするには主にFlashが使われていましたが、FlashコンテンツのSEOには明確なベストプラクティスがありました。それは、FlashコンテンツはJavaScriptを使って呼び出すようにし、JavaScriptを扱えない環境向けにテキスト情報を追加するという方法です。noscript要素やSWFObject等を使った代替要素としてのテキスト情報を加えることや、それに加えてページ分割やSWFAddressを併用することで、Flashであっても非常に高いレベルの検索エンジン対応が行うことが可能でした(この詳細は4年前の拙筆ですがこの記事に詳細を記してあります)。

FlashコンテンツのSEOは、このように代替要素を使用する方法が一般的でした。その手法を検索エンジンも公式に推奨する場合もありましたし、検索エンジンのアルゴリズムとしても、Flashを認識するようになっていきました。その結果、Flashを活用したリッチなコンテンツを検索できる状態にする方法が確立したのです。しかしそのようなFlashの登場から、そのSEOのベストプラクティスが確立するまでには、長い期間を必要としました。

さて現在ではFlashを使う機会は減り、同じニーズに対してHTML5を使うシーンが多くなりました。HTML5では様々な描画を行うcanvas要素や、動画を再生するvideo要素、音声を再生するaudio要素などが追加されています。それらの新要素を中心としたWebページを制作する場合、どのように検索エンジンに認識させるべきか、という議論はほぼ行われていません。

この方法として、いくつかの方法が考えられます。例えばcanvas要素は、要素内にフォールバック・コンテンツとして、テキスト情報を組込むことができます。2013年9月1日現在、このテキスト情報はGoogle、Bingの検索エンジンでは認識しています。しかし一部の検索エンジンでは、canvas要素のフォールバック・コンテンツを認識しませんし、サイト内検索等で使われるシステムでは認識しないことがありました。対応されている検索エンジンにおいても、検索エンジンが公式にサポートしているものではありません。今後扱いがどのように変わっていくかも不透明でしょう。フォールバック・コンテンツだけに頼ることは不安があります。

Flashコンテンツが一般化することで、検索エンジンに認識させる様々な方法が試されて検索エンジンも対応を始めたように、今後HTML5が一般化した後にリッチコンテンツを検索エンジンに認識させるためのベストプラクティスが出てくるものでしょう。しかしそれが確立していない現状では、いろいろと試す必要があるのです。

さて、実際に現段階ではどのようにするべきでしょうか。まず考えられるのは別ページを作ることです。Flashが一般化する前は、Flashを中心としたページとは別に同じ内容をテキスト中心で知らせるWebページが作られていたように、テキスト中心の別ページを作ることが確実でしょう。ただそれが困難な場合には、何らかの方法でテキストでの代替要素を配置するしかありません。FlashはJavaScriptで呼び出すことが多かったため、代替要素が配置しやすかったのですが、JavaScriptを使わないHTML5の新要素では別の方法を考える必要があります。

代替要素を作るためには、CSSを利用した切り替えを用意しておくことが、現段階では一番お勧めできる方法です。ユーザへの適切な情報提供を目的としてテキストを切り替える形で配置することは問題がないと、Googleは公式に説明していますので、Canvas等のリッチな表現を使いたくない人向けの情報も同ページで提供した上で、切り替えて使用できるようにするのが最も適切でしょう。

canvas要素の場合にはフォールバック・コンテンツとしてのテキスト情報追加も選択肢の一つです。先にも書きました通り、一部検索エンジンは対応していませんし、今後の扱いは不透明です。しかし日本で圧倒的なシェアを持つGoogleは現段階では対応していますし、今後についても、HTML5の公式仕様に基づいたマークアップを大きく不利にする可能性は低いものです。対応しなくてはならない検索エンジンがGoogleだけなのであれば、フォールバック・コンテンツは良い選択肢でしょう。

ここまで、リッチな表現のSEO手法について書いてきましたが、本来リッチな表現を検索させる上で、最も重要な事は技術的な要件ではありません。そもそもの話ですが、検索される必要がある情報をリッチコンテンツを中心として制作するのが誤りでしょう。そのWebページで伝える事を表現するのに適切な手法は何なのか、ということから考えてみることをお勧めします。

SEO効果があるh要素の使い方

HTML5とSEOを考える上で、よく言及されるのはhx要素をどうするかということです。

HTML5ではh1要素を複数設置できるようになりました。しかしh1要素の扱いはSEOの観点で極めて重要です。Googleが公式に配布しているSEO初級者向けの「検索エンジン最適化スターターガイド」でも「見出しタグを適切に使おう」として、1ページ丸々を費やしてユーザに説明をしています。実際、数年前のように、h1要素とするだけで順位アップといった単純な効果はありませんが、hx要素をうまく使って文書を整理することは、検索エンジンもその文書の構造を把握しやすくなり、様々な面でプラスとなります。

h要素のSEO要件が語られる際に必ず言われることとして、「h1要素はそのページのテーマを示す内容として、1ページに1つのみにする」があります。しかしHTML5では、h1要素を複数使用することは、仕様として推奨されています。では、HTML5の仕様どおりにh1要素を複数でマークアップすることは、SEOにとって不利になるものでしょうか？

これは不利になる場合もあるし、ならない場合もあるというのが私の考えです。実際にWebページによって、hx要素の番号がどうなっていても検索エンジンの評価に影響を与えないような場合もあれば、甚大な影響を与えるケースも確認しています。

有力な検索エンジンは。ページ内のどこが重要な情報かを識別しようとしています。サイドバーやフッターなどに記された情報は、あまり検索結果に表示されづらいですし、メインカラムの情報は表示されやすいということは、少し注意して検索エンジンを利用しているとわかることでしょう。これはサイドバーなどに共通の情報が記載されがちなことが原因である場合もありますが、例えそのページにしかない情報がサイドバーに記載されていても、検索結果には表示されづらいものです。

どこの部分が重要かという検索エンジンの判別は、一つの要因だけで行うものではありません。様々な要因を使って判定していると考えられますが、私はその要因の一つとしてhx要素の番号が使われていると考えています。hx要素の番号がその判別に重要な役割を果たしているようなWebページでは、hx要素を全てh1要素とすると流入の減少につながりますし、他の要因が重要なページでは大きな影響が出ないことでしょう。

そのため、必ずしも全サイトで必須とは言い切れませんが、SEOを考えるとやはりh1要素は1つで、h2要素以後もうまく使って文書構造を示しておくのが安全と考えられます。

先に述べたとおり、HTML5化したサイトではh1要素を複数使うことが一般的です。hx要素は全てh1要素にした上で、section要素の入れ子構造で文書構造を示すのはHTML5の仕様上正しいとされていますが、h1要素は1つとしてh2要素を中見出し、h3要素を小見出し……と使っていっても問題はないとされています。どちらでもよいのであれば、SEOには確実に問題がない後者の方法を使うべきでしょう。

とは言え、大規模サイトでページ内のパーツを様々なページで流用する場合に、hの番号の整合性が取りづらいため、全てh1要素にするWebサイトも多くあります。そのような場合もページのテーマとなる部分一箇所だけにh1要素を適用して、流用するパーツにはh1要素を使わずにh2要素から始めるようにしておくだけで大きなSEO上の問題は避けられるでしょう。流用する部分は全てh2要素から始めておくことは全ての使用ケースで問題がないわけではないかもしれません。しかし、全てh1要素にすることで発生するSEO上のリスクを考えると、どちらかというと問題は小さいと考えます。

HTML5の把握でレベルが高いGoogleの検索システムは、日本では圧倒的なシェアを持っています。しかし、100%ではありません。Google以外の検索エンジンでは、まだHTML5をうまく扱えないものがあります。その際に一番大きな問題となるのはこのhx要素です。実際、HTML5化した際にある検索エンジンでは、h1要素が複数あることで大きな問題となっている事象を確認しています。h1要素は検索エンジンスパムにもよく使われるため、非常に問題を起こしやすいものでもあるのです。

ご存知の通り、HTML5は普及したといえる段階ではありません。現状ではHTML5に対応していない環境のことを考える必要があります。そのためにもh1要素は1つにしておくべきでしょう。

HTML5で追加・削除・復活した要素

HTML5では、いくつかの要素が追加・削除・復活しました。

まず気になるのは、nav要素やfooter要素などの意味を持った要素でしょう。これらの要素は、現段階での私の観測の範囲では、検索エンジンからはこれまでのdiv要素と同じ扱いを受けているようです。しかし今後HTML5が普及した際には、様々な形で検索エンジンも活用し出すことが考えられます。

今後を考えれば、ページの情報を正しいHTML5でマークアップをしておくことが、唯一の対策となるでしょう。検索エンジンは正しいHTMLしか評価しないわけではありません。インターネット上で公開されているWebページのほとんどは、マークアップ上のミスを含んでいますので、主要検索エンジンはそのミスを織り込んでWebページを認識しようとしています。HTML5は、現段階では人によって使い方に大きなブレがあります。そのため必ずしも正しいHTML5しか評価できないように、アルゴリズムを組んでくるはずはないと考えられます。しかし今後どのような評価を行ってくるかはわかりませんし、全ての検索エンジンが、HTMLのミスを織り込めるほどの技術を持っているとは限りません。やはり最大限仕様上は、正しい形でのマークアップをお勧めします。

次に注意するべきポイントとして、これまでは推奨から外れていたものの復活した要素です。

特に注意するべきはiframe要素でしょう。XHTMLで非推奨とされていたiframe要素も、HTML5で復活したことで、使用するWebサイトも増えているようです。しかし、検索エンジンはiframe要素の扱いが得意ではありません。検索エンジンは、iframe要素を呼び出すURLへのa要素と同様に扱うのが通常ですが、iframe要素で呼び出すコンテンツをそのページのコンテンツとして認識している例もあります。

iframe要素に関わるアルゴリズムも進化を続けていますが、現段階では「iframe要素内のコンテンツは、ページ内のコンテンツとして認識されることもあれば、されないこともある」という非常に微妙な状態です。そのためiframe要素で呼び出されるコンテンツは「検索対象になるかもしれないしならないかもしれない」ものとして扱う必要があります。検索されるコンテンツを作る上では非常に使いづらいものですので、HTML5で復活したといっても、SEOを考える必要があるWebページでは使用しないことをお勧めします。

b要素やi要素など、スタイルを使いながら目立たせるために使われることが多いものの、セマンティクス上、重要という意味を持たない要素があります。それとは違い、strong要素については「他の部分に比べて重要」という意味を持ちます。SEOの知識としてstrong要素は「他に比べて重要」という意味であり多く使うと意味が薄れるため、限定的に使うべきとご存知の方もいるかもしれません。

ではHTML5で復活したb要素などは、無制限に使ってもいいのでしょうか。私はそれを勧めません。それは過去の期間において、b要素もstrong要素と同様に「他に比べて重要」という意味を検索エンジンが認識していたことがあります。現段階の認識が変わっているか確認できていませんが、継続している可能性もあります。その場合は、b要素・i要素が大量にあることで、strong要素も意味がなくなる可能性はあります。

HTML4では、b要素やi要素は使わずにCSSで表現するのがWeb制作の常識でした。HTML5でb要素が復活しましたが、使うことが義務づけられたわけではありません。これまで通りのspan要素とCSSを使ったマークアップをしておくことが無難と考えられます。

SEOを考えるとHTML5を使うべきか？

SEO観点でのHTML5でのマークアップにおいて注意するべきポイントを説明してきました。

現段階ではHTML5は普及しきっていませんので、検索エンジンの対応も中途半端です。その状況で何も考えずにサイトをHTML5化した場合、SEOに悪影響を及ぼす可能性はあります。

では、SEOのためにはHTML5は選択すべきではないのでしょうか。それは違います。今後の長期的なWebサイト運営を考えると、私はHTML5化を強くお勧めします。今後、HTML5を採用したWebサイトにはSEO観点でも何らかの利点が出る可能性が高いと考えます。ページの論理構造を作りやすいマークアップや、セマンテックウェブとの適合性は、今後のSEOで利点が出てくると考えられますし、様々な拡張性はより魅力的なコンテンツを作るのにも有益になります。それはSEOには極めて重要なポイントです。通常のWebサイトでは、HTML5を採用するかどうかという選択が行えるタイミングは、数年に一度しかないでしょう。選択できるタイミングでHTML5を選択しなければ、次に変更できるのは数年後かもしれません。その頃にはすでに、HTML5のSEO観点での利点は発生している可能性は否定できません。

冒頭でHTML5化を含むリニューアルで、大幅に検索流入を落としたWebサイトの実例があると述べました。それは詳細を調査すると、必ずしもHTML5が悪いわけではありませんでした。あるWebサイトでは、テキストでの代替コンテンツを含んだFlashコンテンツを全廃して代替コンテンツを含まないCanvasに置き換えたり、iframeを使い始めて検索流入を落としたということもありました。この問題についても、HTML5が悪いわけではありません。SEOの基礎知識がないことと、HTML5の正しい知識が少なかったことが問題です。その二つの知識があれば、HTML5はSEO観点で怖いものではありません。

まずは、今回ご紹介した3つのポイントに注意していれば、大きな問題になることはないでしょう。さらにHTML5を活用するために、SEOも少し配慮してWebサイト構築を進められることをお勧めします。

Brickは、Brickは、X-Tagというフレームワークの上で構築されています。 X-Tagは、Web Components仕様に準拠したカスタムコンポーネントを容易に作ることができるようにするフレームワークです。 また、X-TagはPolymerというライブラリが提供するPolyfillを使用しており、IE9を含むモダンブラウザ上でWeb Componentsを利用可能にします。

そもそもWeb Componentsってなに？

Web Components仕様は様々な機能を提供しますが、その最も大きなものは、「カスタム要素を作れる」というものです。 例えば、Web Componentsを使用すると、以下の様なタグを記述するだけでその場にカレンダーを貼り付けることができるようになるというわけです。

:html:
<x-calendar></x-calendar>

これだけでも、Web制作/開発に大きな影響を及ぼすということを感じていただけるのではないでしょうか。 その他、コンポーネントの内部をカプセル化する仕組み（Shadow DOM）や、外部のコンポーネントをlink要素で参照する仕組み（HTMLインポート）などもWeb Componentsは規定しており、HTMLそのものをUIコンポーネント基盤として再構築しようとする、大胆な試みだと言っても過言ではないでしょう。

Brickを試す

繰り返しになりますが、BrickはX-Tag上で構築されたUIコンポーネントライブラリです。 それらのコンポーネントは、お使いのブラウザ上（IE9含む）で簡単に試すことができます。

・・・と言いたいところなのですが、現在のBrickにはバグがあるようで、うまく動かないコンポーネントもいくつかありました。 とりあえず、現在Brickが提供している14のコンポーネントのうち、一部を以下に紹介します。 以下の解説は、Brickのドキュメント上のサンプルを、Google Chrome 29上で動作させたものになります。

アプリケーションバー

スマホアプリの上部に表示されるナビゲーションバーを簡単に作ることができます。

    :html:
<x-appbar>
    <div>=</div>
    <header>Title</header>
    <div>+</div>
    <div>?</div>
</x-appbar>

カレンダー

カレンダーを貼り付けることができます。うまく動作しなかったので、画像はこちらのページに貼り付けてあったものを拝借しました。

    :html:
<x-calendar></x-calendar>

アイコンボタン

アイコン付きのボタンを簡単に作ることができます。src属性に、アイコン画像のURLを指定します。しかし、現在のバージョンではアイコンがうまく描画されませんでした。

    :html:
<x-iconbutton src="firefox.png">
  アイコンボタンには＜code＞どんなマークアップでも＜/code＞書けます
</x-iconbutton>

レイアウト

ヘッダー・ボディ・フッターというレイアウトを簡単に構築できます。ボディ部分は、コンテンツの高さに応じて自動的にスクロール領域となります。

:html:
<x-layout>
    <header>
        I'm the header!
    </header>
    <section>
        I'm the main body! <p>(I will automatically overflow if necessary.)</p><p>Filler text</p><p>Filler text</p><p>Filler text</p><p>Filler text</p><p>Filler text</p><p>Filler text</p><p>Filler text</p><p>Filler text</p><p>Filler text</p><p>Filler text</p>
    </section>
    <footer>
        I'm the footer!
    </footer>
</x-layout>

カスタムコンポーネントを自作する

こうしたコンポーネントを自作することもできます。 X-Tagフレームワークを用いると、コンポーネントを簡単に作ることができます。 例えば以下に、前述したアプリケーションバーのソースコードに、日本語でコメントを付与したものを示します。コンポーネントを容易に自作できるという雰囲気を感じ取って頂ければと思います。

:javascript:
(function(){
  // カスタムタグの定義
  xtag.register('x-appbar', {
    // タグのライフサイクルメソッド
    lifecycle: {
      // タグが生成された時に呼び出されるコールバック
      created: function(){
        // 入れ子になったheader要素を取得する
        var header = xtag.queryChildren(this, 'header')[0];
        if (!header){
          header = document.createElement('header');
          this.appendChild(header);
        }
        this.xtag.data.header = header;
        this.subheading = this.subheading;
      }
    },
    // 要素の属性にアクセスする手段を提供する
    accessors: {
      heading: {
        // 属性の設定
        attribute: {},
        // 属性に値をセット
        get: function(){
          return this.xtag.data.header.innerHTML;
        },
        // 属性に値をセット
        set: function(value){
          this.xtag.data.header.innerHTML = value;
        }
      },
      subheading: {
        attribute: {},
        get: function(){
          return this.getAttribute('subheading') || "";
        },
        set: function(value){
          this.xtag.data.header.setAttribute('subheading', value);
        }
      }
    }
  });
})();

まとめ

Brickはまだ正式公開前ということもあり、バグも多く、デザインも洗練されていないのは仕方のないところです。今後に期待といったところでしょうか。

しかし、Web Componentsに関するライブラリをMozillaが公開したというところに、筆者は大きな意義を感じます。 Google主導で進められていると思われていたWeb Componentsに、Mozillaも強くコミットしていくということの現れとも言えるからです（実際Firefoxは、カスタム要素を作るためのdocument.register APIを実装しています）。

エキスパートNo32のえーじさんに昔教えていただいた情報によれば、Web Components仕様にはMicrosoftも強く関心を示しているとのこと。 そうなると、Microsoft, Mozilla, GoogleがWeb Componentsに前向きということになりますし、ChromiumをベースとしているOperaはもちろん、以前はGoogleが大きくコミットしていたWebKitにもWeb Componentsの一部は実装されているはずですので、SafariでもそのうちWeb Componentsを使えるようになる可能性があります。

Web Componentsによるマークアップ作業の大変革が起こるのは、意外とそう遠くない未来なのかもしれませんね。

• HTML+RDFa 1.1
• RDFa 1.1 Core – Second Edition
• XHTML+RDFa 1.1 – Second Edition

RDFaとは、コンテンツのメタデータを記述するためのフォーマットであるRDF (Resource Definition Framework) を、要素の属性（attribute）で指定できるようにした仕様です。HTML Microdataと競合する仕様ですが、Microdataと異なり、RDFaは（もともとXML由来の技術であった）RDFの流れを組むため、XHTMLをはじめとするXML文書全般でも利用が可能であるなどの違いがあります（その代わりMicrodataのような、JavaScriptによるDOM APIは持ちません）。

例えば、RDFaを使用したマークアップは以下のようになります。

:html:
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Example Document</title>
  </head>
  <body vocab="http://schema.org/">
    <p typeof="Blog">
      Welcome to my <a property="url" href="http://example.org/">blog</a>.
    </p>
  </body>
</html>

同じメタデータを、Microdataを使用してマークアップすると以下のようになります。マークアップの手間はあまり変わらないように思います。

:html:
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Example Document</title>
  </head>
  <body itemscope itemtype="http://schema.org/Blog">
    <p>
      Welcome to my <a itemprop="url" href="http://example.org/">blog</a>.
    </p>
  </body>
</html>

ちなみに、RDFaのもろもろが勧告に至ったのに比べ、Microdataは未だにワーキングドラフト。仕様の成熟度で言うと、少しMicrodataに分が悪いか、というところ。

その他のサービスによる対応状況ですが、GoogleもBingも、MicrodataとRDFaの双方をサポートしています。また、OGPよりもMicrodataを優先することで知られているGoogle+が、RDFaに対応しているかどうかは、ちょっと調べきれませんでした。

少なくとも、Microdataもここまで普及している以上、RDFa勢に押されてすぐに駆逐されるということはあり得ません。 当面、安心して使えるテクノロジーと言ってよいのではないでしょうか。

追記（2013/9/2）

[エキスパートNo.18 矢倉 眞隆さん]から、この件に関して有用な追加情報をいただきましたので、以下に追記します。

Microdataについては、W3C HTML WGにより、7月23日に以下のような決定が下されています。

• HTML5.0の勧告候補から、Microdataへの参照を全て削除する
• MicrodataのJavaScript APIを仕様から削除する
• HTML Microdataという拡張仕様として公開し直す

JavaScript APIが削除されるに至った主な理由は、実装の欠如です。具体的には、FirefoxとOpera (Presto)が一度は実装したものの、OperaがChromiumに移行したため実装例が減ってしまい、勧告の条件（二つ以上の相互運用可能な実装が存在すること）を満たせるか怪しくなったというもの。 Blinkからはすでに実装が削除されており、Firefoxでも削除を検討中、WebKitからもMicrodataのAPIに関連するコードは削除されたそうで、MicrodataのJavaScript APIは実質上「終わった」と言っても良いかもしれません（ただし、WHATWG仕様においては、「代替案がない」という理由で仕様が残されることが決定しています）。