double-team.orgでタグ「accessibility」が付けられているもの

ここ3ヶ月くらいずっと悩んでいる。どうにも解決方法と言うか、「これ！」と言う回答が見つからないので一旦整理する意味でブログに書いてみる。

よく、「ページトップに戻る」と言うリンクがある。
例えばドコモの製品ページ。ここでは「このページのトップへ」と言う表記でページ内の #top へリンクされている。この #top がどこに書かれているか探してみると、ドコモのロゴの a 要素に name 属性と id 属性の併記でなされている。
今度は mixi のヘルプページではどうか。「TOPへ戻る」と表記され、同様に #top へリンクされている。この #top はソースを見ると164行目に空の a 要素に name 属性で書かれている。

で、自分は何を悩んでいるのか。

1. ページトップなどの表記は正しいのだろうか
2. 本当にページの先頭に遷移するリンク先は #top（または #pagetop など）でよいのだろうか
3. ページの先頭はどこなのだろうか
4. そもそも古典的とも言えるこの手法は正しいのだろうか

この4点が全て。
今まで常識的にやっていたことを1回でも疑問に思うと、そこから先全てが疑問に思えてくるから不思議。うむむ。

ちなみにこのナビゲーションの存在そのものは否定しない。mixi のヘルプページのように、長いページであるとユーザビリティ上あってもよいと思う。だけどこれまで通りのやり方でよいのかが疑問視する点。

1. ページトップなどの表記は正しいのだろうか

ここで問題なのは「ページトップ」や「トップ」、「先頭」それに「戻る」の意味。これらの組み合わせでいろいろな表現がある。

• ページのトップへ
• ページの先頭へ戻る
• ページトップへ
• ページトップに戻る
• トップに戻る
• 先頭へ
• このページのトップに戻る
• このページの先頭へ
• TOPへ
• その他いろいろいっぱい

これらの言葉をかなり砕くと「あなたが現在閲覧しているページの最初に移動します」となる。

そもそもにおいて「トップ」や「先頭」と言う言葉の意味を考えると、header や footer と同じように、位置を意味することになるような気がする。だからそこから導かれるように #top が生まれたのではないかと思う。

2. 本当にページの先頭に遷移するリンク先は #top（または #pagetop など）でよいのだろうか

じゃあ #top と言う表記は正しいのだろうか。フラグメント識別子を含めた URI を1つのリソースとして見ると、top を示すリソースが固有名詞（例えば本のタイトル）であるなら問題ないが、それがページ内の位置を示すのであれば間違いではないか。

参照するリソースが固有名詞の例

<h2 id="top">山田太郎著「トップ」</h2>

参照するリソースがページの位置を表す例

<p id="top"><img src="logo.png" alt="ほげほげ株式会社"</p>

前項で header や footer と同じ、位置を表す意味となると言ったのはこうした理由である。

では代替案はあるのか。それはページの最初がどこであるか定義するかによると思う。

3.ページの先頭はどこなのだろうか

まずはこの double-team.org の大まかな構造から考えてみる。

1. ブログ名（double-team.org）
2. 検索窓
3. ナビゲーション
4. エントリのタイトル
5. エントリの内容
6. （上記2つが続くので略）
7. 最新のエントリ10件のタイトル
8. 月別ごとのエントリ
9. エントリのタグ一覧
10. コピーライト

これをもとに、ページの先頭として考えられる候補はいくつかある。

1. 純粋にページの最初から
   • ブログ名（double-team.org）
2. ヴィジュアル上の最初から
   • ブログ名（double-team.org）
   • 検索窓
   • 最新のエントリ10件のタイトル
   • これらのいずれか
3. ユーザが次に行動しやすいような箇所から
   • 検索窓
   • ナビゲーション
   • 最新のエントリ10件のタイトル
   • 月別ごとのエントリ
   • エントリのタグ一覧
   • これらのいずれか
4. 必要なのはコンテンツなのでエントリから
   • エントリのタイトル

考えようと思えばいくらでも考えられる。
恐らくその Web サイトまたは Web ページにあわせた、適切な箇所を参照するのが良いのだと思う。ただ、Web ページ単位で考えると制作者が思考迷路に陥る可能性が高いので、現実的ではないのかもしれない。
そしてもし Web ページ単体で考えるとなると、ページごとにフラグメント識別子を埋めて行く必要があり、それ以前に前項の #top が本当に正しいのかと考える必要がある。

4.そもそも古典的とも言えるこの手法は正しいのだろうか

フラグメント識別子を含めた1つの URI として考えるのならば、別の解決策を考えてみるのも1つかもしれない。

前項ではページの先頭がどこかを定義する必要があったが、純粋にページの最初であるのが多いと思う。アクセシビリティの分野で名高い富士通株式会社や株式会社インフォアクシアでは body 要素の開始3行以内にページの先頭へのリンク先として id 属性が記述されている。

つまり、極端な話をしてしまえばページの最上部へブラウザが表示してしまえばいいとなる。
これを実際にやっているのがニコニコ動画である。

ニコニコ動画では body 要素の開始直後にページの最初に戻るための id 属性が空の a 要素で記述され、そこにページ下部にあるリンクから参照されているが、その方法が JavaScript で id 属性値が PAGETOP であるところまでスクロールさせると言う手法である。

この方法であれば URI はフラグメント識別子を含めずにページの最初に遷移させることが可能となる。ただし、潜在的には #PAGETOP があるために、見た目上はフラグメント識別子を含めない URI であっても実質的にはこれまで通りの方法とあまり変わらないのは確かである。
さらに言えば、あくまでブラウザ上の表示位置をスクロールして変えただけであって、例えば音声ブラウザではそこに遷移したことにならないので意味が無い。

結論

ここまで書いても結局答えはでてないのだが、一番近いと思っているのはこれ。

<p><a href="filename.html">このページの最初から再度読む</a>

ただしこれも問題があり、再度同一のリソースを参照することになるので「最初から読む＝HTML の参照」となってしまう。意味合いが変わってくる。
また、最初から読むのが必ずしも HTML の先頭からとは限らないので、無駄が発生する可能性がある。
さらに、サーバへのリクエストが増える可能性もあるので、やはり無駄が発生する可能性がある。

なので、やはり結論が出ていない。この辺の考え方を偉い人がブックマークのコメントとかで教えてくれると助かったりします。

あー長かった。これ書くのに3時間かかるとかどんだけー。

参考サイト

• ハイパーリンク -- ごく簡単なHTMLの説明

今日はとても面白い1日だった。いや別に仕事とかプライベートとかじゃなく、ガリガリ CSS 書いてて楽しかった。
なんとなく「できるかなー」と思ってグリグリ2時間くらい費やした甲斐があった。でもあとで調べたらいい感じの記事があって、「こっち参照でいいんじゃない？」とも思ったが、せっかくなので残しておく。

と言うわけでまたここからで申し訳ないんですが、パンくずリストがベストとは限らない | WWW WATCH を見て「link 要素を可視化させちゃえば（ちょっとだけ）解決できるんじゃない？」と思ってやってみた。

XHTML の記述を例えばこんな感じに。

<link rel="start" href="index.html" title="最初のページへ" />
<link rel="next" href="next/index.html" title="次のページへ" />
<link rel="prev" href="prev/index.html" title="前のページへ" />

で、CSS はこう。

head {
display: block;
}

link {
display: block;
width: 100%;
}

link::after {
content: attr(title);
}

• サンプルその1

最小で書くとたったこれだけで可視化は可能。一番重要なのは head 要素を可視化するのが必要。ここでは display プロパティの値を block にしているが、inline でも問題ない。あくまで表示するだけならば値を inline でも良いですが、link 要素の display プロパティの値が block になっているのと、ルートの html 直下にインライン要素が配置されるのは不自然なので、head 要素はブロック要素として扱うのが良いです。
ちなみに link 要素に疑似要素の ::after が付随しているので当然のことながら IE だと無理です。IE 対応しようと思ったら JavaScript でアレコレやらないと多分無理だと思います。

ただこれだとちょっと味気ないので、ちょっとだけ装飾してみる。

head {
display: block;
padding: 5px 5px 10px;
border-bottom: solid 1px #ccc;
}

link {
display: inline;
font-size: 80%;
color: black;
padding: 3px 5px;
border: double 3px #ccc;
border-color: #ccc #666 #666 #ccc;
}

link:hover
{
border-color: #666 #ccc #ccc #666;
}

link[rel="start"]::after {
content: "ホーム";
}

link[rel="next"]::after {
content: "次へ";
}

link[rel="prev"]::after {
content: "前へ";
}

• サンプルその2

title 属性をそのまま使わず、単語で分かりやすく表記してボタンっぽいデザインにするとそれらしく見える。

ただこれらの方法ではいくつか問題点がある。

• Opera だとリンクなしで表示される
• tab キーで選択できない
• head 要素内にあるのを無理矢理可視化させたので、ページ内のコンテンツと組み合わせるのが難しい
  • position プロパティを使ってアレコレやればできるけど、またブラウザの問題（CSS の解釈とかなんとか）が出てくる

Opera の問題ですが、否定疑似クラスを使うっぽいと思ってるけどあまり理解してないので今回は見送りです。本当に否定疑似クラスなのかさえ定かでない。。。
tab キーによる選択が出来ないのは致命的です。こればっかりは Firefox の実装の問題なのでお手上げ。
position: fixed; でブラウザの上部または下部に固定してしまうってやり方はアリだと思いますが、また IE が邪魔するわけですよ。
結局のところ、使える場面があるのか無いのかはっきりしないです。やろうと思えば出来るけどクロスブラウザじゃないよ、って感じでしょうか。

余談ですが、リンクタイプの rel 属性の値 netx と prev は ブログのテンプレート内に入れて今回のようなナビゲーションとして使うと便利かもしれません。Movable Type のテンプレートタグを使って

<MTEntryNext><link rel="next" href="<$MTEntryPermalink$>" title="<$MTEntryTitle remove_html="1"$>" /></MTEntryNext>
<MTEntryPrevious><link rel="prev" href="<$MTEntryPermalink$>" title="<$MTEntryTitle remove_html="1"$>" /></MTEntryPrevious>

なんて書くといいかもしれません。（たぶんデフォルトのテンプレートにこれが記述されていると思います。さっぱりそんなの忘れ去ったので確認できませんが。）

さらに余談ですが、大元の記事であるパンくずリスト（Topic Path）のマークアップに関して、番号（順序）付きリストでマークアップするのがベターなのかと思います。あと番号なし（箇条書き）リストではちょっと意味が違うかなぁ、とも思うけど、入れ子にしていくのもアリだと思う。ただ、段落でマークアップするのを否定するわけじゃないし、それはそれで解釈として正しいはず。
仕様の方に話が飛ぶのもアレだけど、手元にある素材（要素）で料理（マークアップ）するのに、必要状況下でその素材（要素）が無い、もしくは当てはまらないとなったら何かしらで代替を用意するしかない。けどだからと言ってパンくずリストのための要素を用意（仕様策定）するのは本末転倒。だから今あるものでやるしかないのです。正解があるわけじゃないかもしれないけど（日本語がおかしい）、自分が正解だと思えるやり方でいいと思います。だから自分は番号付きリストでやる。それだけです。

追記 2007年2月9日 23：00

記述ミス修正

追記 2007年2月14日 10：51

head 要素の取り扱いについて加筆修正

元ネタ：ふりがなをフリガナで書かせるサイトの神経が理解できない

簡単に整理

• ウェブサイトにあるフォームにおいて、ふりがなを平仮名とカタカタ混在している
• そもそもにおいて、なぜカタカナで書かせるのか
  • ATOK が穢れる（学習してしまう）
• 別に平仮名であってもシステム側の影響がないのでは？
• F7 キーでカタカナに変換できるけど、それが出来ない人はどうすれば？
  • と言うかどうやらカタカナにしているのは外国の方の名前を表現するためにあるらしい（”ヴ”とか）

何と言うか、これって Web 上の問題と言うより、日本語変換ソフト側の問題でもあるし、もっと言えば OS のユーザビリティにも関わる、意外と根の深い話だったりするわけですが。
と言うか上記の話をさらに区分けすると、

• 平仮名で入力：外国の方はお断り
• カタカナで入力：変換が面倒とか ATOK が穢れると言う人はお断り

と（無理矢理感はあるけど）なるので。「じゃあ両方許容すればいいじゃん」って声が聞こえてきそうですが、それが今のところ聞こえてきていないのは現実的じゃないからなのかと。
とどのつまり、両方許容するためには

「ふりがな」 or 「フリガナ」

と表記していたのを

「ふりがな、もしくはフリガナ」

となる。
ただここで忘れてはならないのは、我々健常者ではなく障害者（特に視覚障害者）に対してはどちらも優しくないのが現実です。
音声ブラウザでは「ふりがな」と「フリガナ」の識別は出来ません。どちらも同じ音です。平仮名もカタカナも関係ありません。
なので、アクセシビリティを考慮すると

「ふりがな（平仮名）」

「フリガナ（カタカナ）」

となる。じゃあこれで両方許容する場合を考えると

「ふりがな（平仮名、もしくはカタカナ）」

となる。
それに視覚障害者が、入力した文字列が平仮名なのかカタカタなのか分からないと言うオチもあるので、あまり入力制限を設けるのはよろしくないと思う。
（同じように住所や電話番号を全角半角の識別をしなければならない場合もこれに当てはまる）

また残りはあとで。