パンくずリストのマークアップ
ちょっと前に パンくずリスト（Topic Path）を作成する際に使えそうなサンプル8種（CSS HappyLife）というエントリーが盛況でしたが、今日はパンくずナビゲーションの論理構造面を補強する意味も込めて、(X)HTML マークアップの例を、サイト構造やサイトの目的に応じて、いくつか挙げてみました。CSS の話まで入れると長くなるので、今回は（も？）(X)HTML マークアップに話を絞ります。CSS については、特にセレクタまわりが結構 変わってしまいますが、ひとまず、HirasaWa さんのエントリーなどを参照してください。（気が向いたら、別エントリーを立てますけど、実際に書くかどうかは未定。）
階層型構造（tree structure）
- ［2006-02-11 追記］
- 石川一靖さんより、「セマンティクスを重視するならa要素にrel/rev属性を加えてリンクの関係性を明示するのが先ではないか」（HTMLとセマンティクス：メモランダム）とのご指摘をいただきました。非常に良い方法なので、早速、採り入れてみました。以下、階層型・リニア型構造のサンプルに追加した rel, rev 属性が、それを反映したものです。なお rel, rev 属性については、以下のリソースをご参照下さい。
- Links in HTML documents（W3C HTML 4.01 Recommendation）
- HTML - link要素の使い方（The Web Kanzaki）
- パンくずリストがベストとは限らない（WWW WATCH）
- linkのススメ （kuruman.org > 駄的HTML改善計画）
サイト全体がツリー構造（ルート（根幹）ページの下に、下位ページが枝のように分岐している構造）を成している場合は、パンくずナビゲーションも階層化するのが分かりやすいと思います。「階層」という概念（セマンティクス）を重視するので、次のようにリストを入れ子にします。ちょうど、ナビゲーションメニュー用のリストを、現在位置とその上位階層のみを表示するために、不要なノイズを極限まで削ったような格好になります。
このマークアップだと、CSS で装飾を加える場合に、遠近法のイメージで階層が現在位置に近いものほど font-size を大きくするといった、従来のパンくずナビゲーションとはひと味違ったデザインにすることも可能です。（現在位置からの距離を文字の大きさで、遠近法的に表現する。）
リニア型構造（sequential structure）
サイトコンテンツが、プレゼンのスライドのような、順序にしたがって直線的に進む線形モデルになっている場合には、階層を持たないフラットな順序つきリスト（ol 要素）が適しています。この場合、もちろん先頭ページへのリンクを提示するのも大事なことですが、"どこから来て" → "今、どこにいて" → "次にどこへ行けるのか" を把握しやすいように提示できるとさらに素敵です。
<li>page 2</li>
<li><a href="/page3.html" rel="next">Page 3</a></li>
視覚障害者向け（for screen reader users）
- ［2006-02-07 追記］
- スクリーンリーダーユーザーには、パンくずナビゲーション自体が余計で不要なものという意見が多数あるようです。詳しくはこのエントリーのいしださんのコメントや、TRANS - alt=""を越えてをご参照ください。
スクリーンリーダー（音声ブラウザ）のユーザーを特に強く意識するような場合は、上記の事例だと、若干 不親切な部分があります。（もちろん、見出しや注記を加えるなどで、補強することも可能ですが、マークアップの焦点をはっきりさせるため、上掲の例ではそういった補強策の部分は意識的に省いてます。）そうしたユーザーに、よりわかりやすくパンくずナビゲーションを提供するために、パンくずナビゲーションをリストではなく、自然文にしてしまうという手段もあります。
CSS の都合で、マークアップ的に余計な span 要素が入ってしまうのと、サイト構造の情報が落ちてしまう点が、上の例の気持ちの悪いところですが、@media screen, print { p.breadcrumbs span { display: none; } } とすることで、音声ブラウザでは自然文として読み上げさせつつ、ブラウザの画面や、印刷媒体に対しては span 要素で括られている部分だけを隠して、パンくずナビゲーションのように見せることができます。
（それにしても、見栄えのために構造に妥協を強いていることを差し引いても、もう少し、改善の余地がありそうなもんですよね..。良案・改善策をご存知の方は、是非、ご教示くださいませ。）
なお、パンくずリスト（Topic Path）を作成する際に使えそうなサンプル8種でも、画像 + 代替テキストという手法（サンプル 3）が紹介されていましたけど、最初から画像ありきの文書よりも、「の中の」という自然文のセマンティクスを、background-image か何かで画像に置き換える形の方が、文書としての汎用性がより高まります。
XHTML 2.0 では..（おまけ）
ちょうど、X/HTML 5 Versus XHTML 2 というエントリーでも紹介されている手法ですが、次世代規格となる XHTML 2.0 では nl 要素で括ることになります。（HTML 5 なら nav 要素。）nl 要素には role という、要素の "役割" を指定する属性をつけることができます。この role 属性の値は、名前空間を利用することで拡張もできます。なお、XHTML 2.0 では、以下の li 要素の例のように、a 要素を用いなくとも、大半の要素にハイパーリンク（href 属性）を適用することができるようになります。
<li href="/">トップ</li>
<li href="/category/">カテゴリー</li>
<li href="/category/subcategory/">サブカテゴリー</li>
ひとくちにパンくずナビゲーションと言っても、目的や状況に応じて、色々な選択肢があるもんですね。
［2006-02-06］追記 1: 音声ブラウザの media query 実装
留意しておきたい指摘や見解があったので、ちょっとだけ、補足しておきます。
@media screen, print { p.breadcrumbs span { display: none; } }を本当に音声ブラウザがスルーするか確認の必要あり。仕様的にはOKだけど、実装されているかどうかが問題。
このあたりは CSS hack の media query hack とも絡む話ですけど、上記 @media は、確か PC 用ブラウザでは、以下のブラウザだけが非対応だったと記憶してます。（本当は、実際に自分で確認・検証しておかないとダメなんでしょうけど、それは追々 チェックすることにします。）
- Netscape 4.x
- Mac IE 4, 5
- Win IE 4
- Konqueror 3.0
問題は音声ブラウザ側が @media screen を選別できるかどうか（PC ブラウザ限定指定のスタイルをちゃんと無視するかどうか）なんですが、これについては完全に音声ブラウザの実装に依存する話で、実際に確認してみないと何とも言えません。実は display: none; についても、音声ブラウザによって、読み上げるものと、読み上げないものとがあって実装が分かれています。（Screen Reader Visibility Test Results（Access Matters））なかなか、悩ましいところですね。良きポインター、もしくは、まとまった情報をお持ちの方は、是非、ご教示くださいませ。
［2006-02-06］追記 2: 音声ブラウザにパンくずリストは必要か？
また、TRANS の id:aratako0 さんの指摘も見逃せません。
ただ、思うのは、肝心のシニア層はパンくずリストをほとんど使わないということ。…また…本文に辿り着くのに、パンくずリストがあるせいで「ロゴ」、「グローバルナビゲーション」、「パンくずリスト」と1箇所分多く時間が取られてしまいます。
TRANS - alt=""を越えてより引用:
これ、一見 些末なことのように見えますが、日常的に音声ブラウザを利用している人には、間違いなく大事な要素だと思います。確かにパンくずナビゲーションは、音声ブラウザ（+ 印刷媒体）には不要かも知れませんね。
やっぱり、音声ブラウザを、最低一本、使い倒してみないと、問題点が実感として見えて来ないもんですね..。精進しないと。(- -;ゞ
［2006-02-07］追記 3: "視覚障害者向け" の自然文とは？
ミツエーリンクスの木達一仁さんからのご指摘。確かに自然文の文脈自体にも、改善の余地がありそうです。
その自然文は、本当に"視覚障害者向け"なのでしょうか？と疑問に思ってみ たり。
［2006-02-07］追記 4: 批判コメントに注目してください！（重要）
追記 3 の指摘については、目下、Web・紙媒体の両面で調査中ですが、ソーシャルブックマークをご利用の方は、是非、こういう疑問や批判意見を重点的に見ていただくようお願いします。かなり高い確率で良い意見や鋭い指摘を含んでます。僕も誤ったことを広めてしまうのは本意ではないので、こうしたコメントはどんな形であれ、本当にありがたいです。
それにしても、非健常者を対象としたアクセシビリティの理解が全然だな..と、あらためて痛感。時間を見つけて、WCAG や JIS X 8341-3 も、もう一度、読み直してみないと。(- -;)
| 固定リンク
「［Web］XHTML」カテゴリの記事
- HTML の見出しをめぐる議論(2007.07.11)
- Re: XHTML+CSS (r)evolution, 3rdの内容は信ずるに値するか?(2007.06.03)
- 論理構造を文脈に読み換えながら class 名を考える(2007.05.30)
- 定義リストの違和感（続）(2007.05.28)
- 定義リストの違和感(2007.05.26)
この記事へのコメントは終了しました。
コメント
コメント、ありがとうございます。
おっしゃる通り、確かに「〜用」という言い方は、色々と誤解を招きそうな感じがしますね。「〜の場合」も似たようなものだし、「のサイト用」はまるまる削ってしまっても良いのかも。（検討の上、あとで対処しておきますね。）
"マークアップは原則として構造を意味づけするものであって機能ではない"とか、"（見栄えや振る舞いの）選択権は常にユーザー側に持たせるべき"..という限りにおいては、僕もまったく同感です。ただ、肝心のおっしゃっている「正しい文書（構造？）」の意味（というか、どういう状態を意識されているのか）について、できればもう少し具体的にご説明いただけるとうれしいです。
少なくとも、ここで挙げている「階層型構造」と「リニア型構造」のマークアップについては、サイト構造の典型そのものをモデル化（抽象化）したもので、我流・亜流とは対局にあるものではないでしょうか？もちろん、「誰もがこのようにマークアップしなくてはならない」と言っているわけではありませんが、情報の適切な構造化を指向している限りは、ある程度、上掲のような形に収斂されてくるものと思います（class名の部分はともかく）。その意味で、僕にはどの部分がどういう風に Web 標準から逸脱しているのかがよくわかりません。もし、僕が見落としている点にお気づきでしたら、是非、忌憚なくご指摘いただければ幸いです。
投稿: ゆう＠管理人 | 2007-02-07 16:46
そもそも「～～用」って考え方を見直すべきかと。
正しい文書があって、
それを「普通に」表示（or読み上げ）できるUAがあって、
それをいろんな人が使う。
って方向にしないと、
我流・亜流ばかりが増えて余計に混乱する可能性もあるのでは？
（何が、正しい・普通を議論する意図はないです。
Web標準ってそういう話ですよね。って話です。）
コンテンツとしてサポートすることは必要だけど、
マークアップでサポートしようとすると
どっかに無理が生じますよね。
投稿: 匿名 | 2007-02-07 15:32
こちらこそ、はじめまして。貴重なご意見、ありがとうございます。
確かにスクリーンリーダーの実装だけでもまちまちなのに、その上、ユーザーごとの多様な使い方やスキルレベルの違いまで考慮に入れると、なかなか穏当なマークアップモデルや CSS モデルって定まりませんよね。
それにしても、すごく意外というか気になるのが「旬の話題」。視覚障害者の作ったブログとかポッドキャスティングとか、すごく興味深いです。そういうのを集めた、視覚障害者用のポータルとかあると、健常者 Web デザイナーや教職関係者でも、関心を示される方が意外と多いかもしれません。もちろん、僕も含めて。
投稿: ゆう＠管理人 | 2007-02-07 12:58
はじめまして、音声読み上げソフトの使い方というのはユーザーさんによって、実にまちまちなので、難しい問題があります。
すべて棒読みされている方から、ショートカットキーを使い倒している方まで、レベルが本当に違います。
なので、棒読みされている方に使いやすい仕組みと、ショートカットキーを使われている方でも違いますし、音声読み上げソフトの種類によっても違うと思います。
私はスクリーン・リーダー3本と音声ブラウザを2本持っていますが、いつも使っているわけではないので、実際のユーザーさんの立場には立てません。
いろいろなユーザーさんの声を聞くしかないかなと思っています。
ちなみに、視覚障害の方々でパンくずリストが問題になったことはないですね、Gyaoを閲覧しにくいとか、ポッドキャスティングを聞きたいとか、ブログを作りたいとか、メディアプレイヤーを上手く操作できないとか、そういう旬の話題が多いです。
投稿: いしだ | 2007-02-07 08:34