今年、玄海原発の稼動再開の可否を巡って社会的なトラブルがありました。知らなかった、あるいは忘れてしまった、という人はWikipediaの記事をどうぞ；「九州電力やらせメール事件」。

この問題は、九電社長の進退や佐賀県知事の関与、第三者委員会の立ち回りなど、なかなか複雑な様相を呈しています。あるいは、曖昧模糊としたままで決着が図られるのかもしれません。ただ、私は、仮に、経営陣や政治家たちが全て辞職したとしても、まだ割り切れない部分が残ると思います。すなわち「やらせメール」そのものの倫理的な是非です。

話はガラリと変わりますが、米国のTIME誌が年度の表紙を飾る人物をインターネット上で募集した時に、「田代まさし」さんが1位になった、という件をご存知でしょうか？あるいは、ポケットモンスターの人気投票で「レアコイル」が2位になったり、イナズマイレブンの人気投票で「五条勝」が1位になったという話でも結構です。

雑誌社やアニメの放送者は、本来、彼らの好きなようにコンテンツを作り、また、作られたコンテンツについての責任を被ります。ここまでは良しとしましょう。しかし、「読者や視聴者の意見を反映させる」という手法をとると、とたんに話がややこしくなります。「発信者が作成して、受信者が消費する」という形ではなく、「『投票者』が作成して、発信者が中継し、受信者が消費する」という形になるからです。

ここでいう「投票者」は「発信者」側の想定では「受信者」と同一であって、その仮定が正しい限りにおいて大きな問題にはなりません。しかし、実際の結果を眺めてみると、「投票者」と「受信者」は同一ではありません。投票の母集団は偏っており、その結果が「田代まさし」「レアコイル」「五条勝」なのです。ひとつ注意を喚起しておきたいのは、この結果は偏ってはいても、必ずしも「不正」と見做すことはできない(まあ、「田代まさし」に関しては微妙ですが)という点です。想定通りではないが、不正でもない、そういう現象なのです。

発信者はコンテンツに飢えています。新聞にはその黎明期から投書欄がありますし、深夜ラジオが電話やFAXで音楽曲のリクエストを募集するのも同じ理由です。その延長線上に「ケータイ大喜利」なんかがあって、さらにその先に「原発再開について、視聴者のメール紹介」があるのです。

放送者と視聴者の関係を一つのシステムになぞらえるなら、「九州電力やらせメール事件」は次に挙げた2つの要因からなる不具合です。

1. 視聴者は放送者を信用するあまり、放送内容が妥当なものだと思い込まされてしまう。
2. 放送者ではない第三者が放送内容を操作できてしまう。

九州電力は、このセキュリティホールを突いて、「自らの意見」を「妥当な意見」へと特権昇格させました(*I)。九州電力やそれに関わった人々が何らかの責任を取らなければならない、という点には、私も同意します。しかし、これは「不正」だったのですか？罰則を与えるとして、その根拠は誰が示すのでしょうか？巨大な利益が絡む以上、一罰百戒はありえません。経営陣や政治家の首とは比べ物にならない額の金銭の問題だからです。この種の企業努力が、念仏のようにコンプライアンスを唱えることによって解決された例もありません。

再発防止を謳うのなら、2.の穴を塞ぐべきではないでしょうか？

近年、いろいろな放送局、とりわけNHKが「視聴者のご意見」を熱心に紹介するのを見て、不安な気持ちになります。特に、番組中に意見をファックスやメール、あるいはテレゴングのようなリアルタイム性の高い手段で募集して、終了前に放送するタイプが最も危険です。コメントを選ぶスタッフや読み上げるアナウンサー達は、十分な教育が施されているはずですし、その点に不満はありませんが、彼らとて専門外の分野もあるでしょうから、限られた時間の中では、つい、うっかりと、という事態は十分に考えられます。

明日にも、ワイドショーのアナウンサーが、「他多数からいただきました」と前置きして、「砂糖水で希釈したら、病気が治りました」とか、「納豆を食べて○Kg痩せました」とか、「水に『ありがとう』と言ったら、…」といった偏った意見を公共の電波で流すかもしれない、そういう時代に我々は生きているわけです。科学知識のように、白黒をはっきりつけやすい話題ならまだマシですが、政治問題になると、放送者や視聴者が十分注意していても防ぐことはできません(*II)。それを証明したのが九州電力であり、その意義は大きい、と私は考えます。

*I.
ちなみに、1.の穴を予め塞いであるある人、すなわち「マスコミの言うことは1から10まで信用できない」という社会不適合系の妄想癖がある視聴者には通じなかったはずです。

*II.
「やらせメール」は内部告発が元で発覚しましたが、逆に言うと、金銭をケチらずに職業的にこの種のマーケティングを行っている人々に頼んでいたら、今でも真相は闇の中だった、ということです。

ウェブに限らず、コンピューター関連の機能は、日夜、新しいものが生み出されています。しかし、人間の扱いきれる量には限りがあるものですから、それは、生き残ることができないモノが沢山ある、ということでもあります。誰にも見向きもされずに、比較的早い段階で消えてくものもあれば、５年、10年、といった、この世界では由緒を誇れる年月を経たものでも、いつの間にか無くなっていたりします。裏を返せば、「化石のような時代遅れの機能だった」ということになるのでしょうか。まあ、消えていくのは、大抵の場合、ほとんどの人にとって不要なものですから、そういう意味での「惜しさ」というものはありませんが、一方で、妙に心惹かれるものがあります。

Firefoxに関して言うなら、今まさにMicrosummariesが消えようとしています。私自身は一度も使ったことがないので、その点には痛痒を感じませんが、対応ページの提供者・利用者にとっては残念なことでしょう。大局的な観点からは、失敗(と、もう、この時点で言ってしまっていいと思うんですけれど)の理由はいくつかあるでしょうけれど、機能カットの直接的な理由はメンテナンス不足、つまり、人的資源が足りていないということです。何分、ユーザーのある話ですから、この機能を拡張で再実装して軟着陸、といきたいところでしょうが、拡張に移すのは「人が足りない」という現象への解決策になっていませんからね。相応にハードなランディングになりそうです。

では、img要素のlongdesc属性について。

HTML4.01には、img要素の属性にlongdescというものがあります。これはその名(=LONG DESCription)の通り、(主に視覚障害者のために)画像に対する詳細な記述をつけるための属性です。使い方に関してはfaireal.netの「<img longdesc=...>について」が詳しいです。しかし、この属性はHTML5で廃止となりました。一見、便利そうな機能であり、放っておいても害はなさそうなのに、わざわざ「廃止」にしてしまったのです。

無論、これは様々な人の意見や思惑を反映しているのですが、とりわけ、その決定打となったのは、「The longdesc lottery(longdesc籤)」という記事でしょう。要点をまとめると、以下のようになります。

• Googleのキャッシュから抽出した10億のimg要素のうち、longdesc属性があるのは130万(0.13%)。
• 130万のうち、書式が間違っているものを除くと5万(4%)。
• 5万のうち、意味が無いものを除くと1万。
• 視覚障碍者側からも、あまり歓迎されていないように見える。

つまり、これは、2007年の時点で、「任意のimg要素に役に立つlongdesc属性がついている確率は、10万分の1である」という調査結果なのです。ちなみに宝くじで言うと、10万分の1は大体1000万円の当選確率です。例：みずほ銀行の「1000万サマー」。

生データでさらっと10億を持ってこれるGoogleも凄いですが、確かに、10万分の1はかなりインパクトのある数字です。この低さの理由を挙げるなら、やはりUAの不備に言及しないわけにはいかないでしょう。実際、「longdescは使われていないので付けない方が良い」といったような文言を見た記憶があります。UA側が対応していなければ、ウェブデザイナがその「対策」をとるのは当然の話であり、そういった悪循環が高じて、この数字になってしまったのでしょう。

longdesc属性の値がURIである、ということは、ウェブサーバ側は別のファイルを用意しなければいけない、ということです。しかし、画像にだって文脈があるわけですから、ある画像について、文書Aにおける説明が、そのまま文書Bで使えるとは限りません。そうなると、URIで指定するメリットは、「同じ事を何回も書く手間を省く」という方向よりは、むしろ「マークアップを許すかどうか」、「詳細な説明方法を提供できるかどうか」という点に現れているように思われます。単純な文字情報なら、alt属性で十分ですからね。

「百聞は一見に如かず」の諺にある通り、画像・映像に由来する視覚情報を言語で説明する場合、あるいは千言万語を費やしても追いつかない、という状況は容易に想像できます。そういった場合、説明のための文章が長くなるのであれば、マークアップできたほうが確かに便利でしょう。しかし、この理想論はやはり空論であって、その結果が前述の散々な数字なのです。あのエラーの割合は、つまるところ、longdescにURIを記入しなかった、ということに他ならないのですから。

目的が崇高で一見して合理的に見えても、実用段階における方法論にささやかなケチが付けばあっけなく沈んでしまう、それを体現しているのがこのlongdesc属性ではないでしょうか。良いところも悪いところもある、というのは一般論として当然の話で、この数字を伏せてディベートをすれば結構戦える、という程度にはlongdesc要素の存在意義に説得力があると思うのですが、現実は非情なのです。

では、longdescを使わないとして、先に挙げたような状況にどう対応するのか、という問題がありますが、この答えはそれほど簡単ではありません。各人にそれぞれ主張があって、統一的な見解はないといっていいでしょう。

1つ考えられるのは、「かなり長いalt属性をつける」ということです。IEは8からalt属性がポップアップしなくなっているので、本来の意味でalt属性を使っても、さほど問題は起きなくなっています。ですから、alt属性に全ての説明を詰め込むのは理に適っています。

また、ややマニアックですが、html5ではaria-が接頭辞についた属性が正式に採用されています。「3.2.7 WAI-ARIA」

Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in the ARIA specifications, except where these conflict with the strong native semantics described below.

ですから、画像の説明にマークアップをしたい場合、aria-descirbedby属性が本命かな、と私は思っています。もっとも、「WAI-ARIA 1.0 Authoring Practices」ではlongdescとの差別化について触れられていますが、もはや、今となっては詮の無い話でしょう。

HTML5はHTML4.01の後継規格ではありますが、完全にHTML4.01を置き換えるものではありません。音声ブラウザを含む各UAはHTML5への対応を進めるとともに、HTML4.01をサポートしつづけるべきだと思います。そういう意味では、longdesc属性は完全に死んでしまったわけではありません。ただ、現時点では将来性がないのも事実ですから、やはり、これから書くウェブページにlongdesc属性を入れるのはやめておいた方が良いでしょう。とはいえ、aria-descirbedby属性がlongdesc属性と同じ道を辿らない、とは誰にも言えないわけで、今、ベストに見える選択肢を他人に奨めるという行為にはなかなか難しいものがあります。そもそも、ハイフンがアリなら、XML系で名前空間を決めていたのは何だったのか、とか、こんなに長いのでタイプミスしないのか、とか、ariaDescribedbyがinterCaps表記で将来後悔しないのか、とか、いろいろ気になる点はあります。

最初に言ったように、栄枯盛衰(というほど栄えてもいませんでしたが)を眺めるのは興味深いものです。が、対応策が今日明日にも必要だ、という人はそんなことも言っていられないでしょう。とりあえずは、w3に置いてあるレポート「Techniques for providing useful text alternatives」が参考になると思います。少なくとも、選択肢だけは十分に用意されているのです。

1.
ずっと後に(年単位で)日記を読む人のために予めことわっておきますが、これを書いているのはFirefox 4.0がリリースされてまだ数日という状況です。

現在Firefox4のクラッシュレポートのうち、トップを走っている「mozalloc_abort...」は2位以下にダブルスコアをつけている優秀なやつなんですが、どうもこれはマルウェアが引き起こしているんじゃないか、という疑惑が濃厚です。Bug 633445のコメントを綜合すると、

• Firefox4のベータ版から報告が出るようになった。
• DLL名がバラバラ。
• ナイトリービルドの被害はゼロ。

とあって、まあ多分そうなんでしょう。

「ナイトリービルドの被害がゼロ」というくだりは、プロセス名(あるいは実行ファイルのパス)が"Minefield"の時は活動せずに、"Firefox"だけを狙い撃ちしている、という観測が出ています。つまり、プロファイルフォルダやその他の場所に正規の方法でインストールされている拡張(例えばツールバー系)の類ではない、ということです。私はこの道の専門家ではありませんが、想像するに、いろんなソフトウェアの皮を被ってインストールされているバイナリが、Firefoxにちょっかいをかけていて、それがFirefox本体のバージョンアップについて来れずにクラッシュしている、というストーリーなのでしょう。

この例は、たまたまクラッシュしているから目立っている「氷山の一角」と考えるべきで、おそらくよくできている奴はFirefox4でも変わらずに動いていると想像できます。クラッシュレポートに付いているコメントによると、特定の動作がトリガになっているというよりも、起動直後にクラッシュして、その後も再起動とクラッシュを繰り返す症状のようです。各アンチウィルスベンダの対応はまだ鈍いようですね。特に目新しいものでもないはずですが、まずは原因を特定しないことには、対策は難しいでしょう。そして、次のバージョンはこんなに目立つはずもありませんから、我々の心の裡には疑惑だけが残ることになります。

ブラウザのアップデートに追随しなければいけないマルウェアの作者も大変だな、という感想が頭をよぎったことは否定しません。しませんが、冗談は抜きにしても色々考えさせられる事例じゃないですかね、これは。

2.
input.mozilla.comのコメントは(bugzillaや掲示板に比べたら)結構面白い意見がちらほらあるんですけれど、その中でも面白いと思ったのが、apple.comのビデオが表示されないという件です。まあ、当たり前というかなんというか、携帯電話の広告をするのに「Quicktimeをインストールしてください」って言えてしまうAppleは、決して悪い意味ではなく、すごいと思いました。

(APIについて)
俗にアクセシビリティAPIと呼ばれているものがあります。具体的に言うと、WindowsならMSAAで、GNOMEならAT-SPIなどのことです。プログラミングに興味がない人はあまり耳に馴染みの無い用語でしょうが、細かい固有名詞はともかく、そういった人にも決して無関係な話ではありません。

そもそも、アクセシビリティAPIとは、音声読み上げソフトや拡大鏡ソフトのために、プラットフォーム側が用意した規格に沿って、対応するアプリケーション側で実装されている機能のことです。誤解を恐れずに言えば、音声読み上げソフトや拡大鏡ソフトのためのバックドアです。ただし、これはプラットフォーム公認でアプリケーション側がわざと開けている広義のバックドアなので、セキュリティホールの類を心配する必要はありません。ただ、この事実をある程度正確に把握しておくべきだとは思います。

例えば、「現在ブラウザで閲覧中のウェブサイトのURLを知りたい」とします。この時、人間ならば、画面を見て、ブラウザのURLバーに表示されている文字を読めば、すぐ分かります。しかし、ソフトウェア的な解決はそう簡単ではありません。人間の手順に倣うなら、まずアプリケーションのスクリーンショットを取って、URLバーの位置を判断し、画像をOCRにかけて書かれている文字を文字列に変換する、という手順を踏むことになります。

無論、これは馬鹿げた方法です。なぜなら、ブラウザ自身はURLを文字列として保持しているはずなので、これをデータとして教えてもらえば済む話だからです。ここで、素直に考えると、ブラウザに寄生して、こちらの要求に応じてURLを漏らしてくれるようなソフトウェアがあればいいということになります。このようなソフトウェアはMozillaの用語では「拡張」といいます。そしてこれが正解です。適切な拡張を作ってインストールすれば、別にスクリーンショットを解析しなくても、ソフトウェア的な解決でURLを知ることができます。

もう勘のいい人は分かっていると思いますが、「現在ブラウザで閲覧中のウェブサイトのURLを知りたい」という技術的な要求には、実はスクリーンショットの解析も、拡張のインストールも必要ありません。近代的なブラウザにはウェブサイトのURLを漏らす機能が予め備わっています。それがアクセシビリティAPIです。実際のところ、Firefoxの場合は、前二者の方法に比べて遥かに簡潔にこのようなソフトを書き上げることができます。ここに設計上のブレイクスルーがあります。

もともと、「現在ブラウザで閲覧中のウェブサイトのURLを通知する」という機能は、介助ソフトに必要な機能として実装されているわけですが、この機能が介助ソフトにだけ有用な機能ではないことは自明でしょう。例えば、アクセスログを作成する時などにも使えます。従来、「URLを知りたい」というFAQに対しては「プロクシを設置しろ」とか「netstat系で確認しろ」と答えるのが一般的であり、ブラウザから直接答えを引き出すのはあまり筋が良い技術とは考えられていませんでした。

(続く)
(続き2011-03-11)

もともと、「現在ブラウザで閲覧中のウェブサイトのURLを通知する」という機能は、介助ソフトに必要な機能として実装されているわけですが、この機能が介助ソフトにだけ有用な機能ではないことは自明でしょう。例えば、ローカルのアクセスログを作成する時などにも使えます。従来、「URLを知りたい」というFAQに対しては「プロクシを設置しろ」とか「netstat系で確認しろ」と答えるのが一般的であり、ブラウザのように複雑なアプリケーションから直接答えを引き出すのはあまり筋が良い技術とは考えられていませんでした。しかし、アクセシビリティAPIを通じてURLを取得するのは、「プロクシでログを取る」に匹敵するくらいには十分合理的な方法であり、データの蓄積・評価方法によっては、より相応しい場合も多々あります。従業員のブラウザを監視するシステムの場合、「休み時間中にスラッシュドットにアクセスする」のと「就業時間中にそれを眺める」のは決定的に異なった評価をされるべき行動であるにもかかわらず、ネットワークのアクセスログやブラウザの履歴ではこの2者の区別がつきません。しかし、アクセシビリティAPIを使えば「ブラウザで閲覧中のURL」がわかるので、就業時間に閲覧中のURLをシステムが記録しておけます。少なくとも、この用途においてアクセシビリティAPIを使った方法は、プロクシその他の方法に比べて頭1つ飛びぬけています。

繰り返しますが、アクセシビリティAPIは、アクセス能力の弱者への救済を目的に作られた機能です。しかし、この機能をその目的からのみ理解しようとすると、前段の例のような、ある種の「実用性」を見逃してしまいます。目的を理解した上でさらに、「アクセシビリティAPIとは何なのか」という問いに対する理解が必要なのです。

URLバーのようなGUIは、「人間のユーザー」がブラウザを操作するための機能です。これに対して、「現在ブラウザで閲覧中のウェブサイトのURLを通知する」といったアクセシビリティAPIは、音声読み上げソフトなどがブラウザを操作するための機能です。つまり、「『ユーザーとしてのソフトウェア』のためのUI」がアクセシビリティAPIの本質です。アクセシビリティAPIが救済している弱者はソフトウェアだったのです。そのソフトウェアには音声読み上げソフトや拡大鏡ソフトも含まれますから、最終的には人間の弱者も救済されますが、一方で、そのソフトウェアにはブラウザ監視ソフトも含まれている、と、そういうわけです。ですから、アクセシビリティAPIという通称の「アクセシビリティ」の部分はやや誤解を招くので、十分広まってしまう前に何かもっと適当な名前を付けた方が良いのかもしれませんね。そこまで私はフォローしきれませんけれど。

とまれ、アクセシビリティAPIの用途は、「アクセシビリティの向上」という所期の目的より広大です。ソフトウェアが人間向けのアプリケーションを使いこなす時代に差し掛かってきた、と言えるのかもしれません。俄かには適当な使い道が思いつきませんけど、例えば、実際のブラウザを使ったクローラやボットを簡単に作ることができます。なにしろ、UAが本物なのですから、サーバー側からは全く見分けがつかないでしょう。また、ウェブアプリケーションの開発者にとってみれば、各種ブラウザを使いこなしてウェブサイトをテストしてくれるボットに何か感じるところがあるのではないでしょうか。さらに、「従業員の監視」は、「アクセシビリティの向上」よりも実用的であり、有体に言って金の匂いがする目的ですよね。ですから、技術者は福祉目的でないアクセシビリティAPIについて、もう少し検討してみることを薦めます。いや、福祉目的の方も検討してもらっていいんですけどね。

その半面、ここまで読んだブラウザの利用者には、アクセシビリティAPIの応用の結果、なにか窮屈な世界が展開されるような印象を与えてしまったかもしれません。まあ、実際のところ、ある種のスパイウェアが作りやすくなるのは事実ですから、副作用がゼロとは強弁できません。そこまで恐れるほどのものでもないのですが、そういった懸念を解決するには、アクセシビリティAPIに対する理解を深める以外にないわけで、究極的にはそれがリテラシなんだろうと思います。

当初の予定より随分長くなってしまったので、まとめておきます。

• アクセシビリティのガイドラインを引き合いに出す時は慎重に。
• アクセシビリティAPIはUIのようなもので、アクセシビリティの向上とは直接関係ない。

私は、アクセシビリティに一家言あるような専門家ではありませんが、それでも、アクセシビリティに関しては語りたいことが山のようにあります。どれくらいかというと、多分、目次が必要になるくらいの分量です。ですが、ほとんどの人にとってはつまらないと思いますので、改めて重要だと思われる部分をここで整理してみようと思います。

まずは用語の問題があります。

「アクセシビリティ」(英語はaccessibility、略記するとa11y)は本質的にはバズワードです。まあ、その成り損ないと言った方がいいのかもしれませんが、とにかく、様々な人がそれぞれの場所で使っている多義語ですから、この単語を見たらとりあえずは眉に唾をつけるべきでしょう。詳しい語義はWikipediaなどを参照してもらうとして、その意味するところは、大きく3つに分かれると私は捉えています。1つは「広義の『アクセスしやすさ』」を意味する用例、もう1つはその「『アクセスしやすさ』を確保するためのガイドライン」に関する用例、最後は「『アクセスしやすさ』を実現するためのAPI群」に対する呼称です。まあ、あやふやな言葉の意味を分類するのは無意味かもしれませんが、少なくともこの文章はそういう構成をとっているので、その通りに順を追って紹介していきます（ちなみに、先走って言うと3番目のAPI群がこの文章のテーマです）。

広義のアクセシビリティは、たとえば、田舎のA氏の家と都会のB氏の家を比べて、「Aの家はBの家よりもアクセシビリティが低い」といったような使い方をします。いや、実際にはしませんけど、意味はこれで合っているはずです。あるいは、「手すりの付いていない坂道はアクセシビリティが低い」ですし、「パソコンのブラウザでは綺麗に表示されていても、携帯電話では表示が崩れるウェブサイトもアクセシビリティが低い」ということです。ですから、バズワード界隈(?)では「バリアフリー」や「ユニバーサルデザイン」がかなり近いところにあって、それらを包括する概念と言えるでしょう。

つまり、アクセシビリティを向上させるという行為は、「色の見分けが難しい、足が不自由である、記憶力に自信が無い」等の身体能力に関する弱者や「使っている画面が小さい、パソコンを持ち込めない場所にいる」といった情報化社会における環境面での弱者を救済する、という点で積極的な意義を持っています。逆に言うと、アクセス方法における強者はそういった障害を苦も無く突破できているわけです。例えば、ウェブを見るときはいつでもパソコンという人は、携帯電話向けへの配慮の有無を気にせずにすむ強者ですし、手すりが無かろうが段差があろうが気にせずに登れる人も強者です。瞬間移動能力者にとってみれば、A氏の家がどんな辺鄙な場所にあっても、そこへの訪問を阻む原因とはならないはずです。

  (ガイドラインについて)

とはいえ、例え強者が世間の大多数だとしても、社会は弱者への救済を怠るべきではありません。特に、それがコストをかけずに「ちょっとしたこと」で実現できるのなら、全ての人はアクセシビリティの向上という大義を実現すべく努力を注ぐべきです。これが、2番目の意味である「『アクセスしやすさ』を確保するためのガイドライン」が存在している理由です。例えば、「歩道を作るときはなるべく段差を少なくするように心がける」といったガイドラインは全国的に実施され、また遵守されているようです。ただ、このガイドラインがきちんと機能しているのは、ガイドラインを知っているプロが歩道を発注して監督しているからです。いくらアクセシビリティ向上のためのガイドラインがきちんと定まっていても運用者が知らなければ効果がありません。

話は飛びますが、スラッシュドット・ジャパンに投稿されたコメントには、本文に「(T/O)」とだけしか書かれていないものがあります。これは「自分の言いたいことはタイトルの部分に書いた」という意味です。また、タイトルと本文を続けて読まないと意味が分からないように書かれている投稿も時々あります。例えば、タイトルが「今日の空模様は…」で本文が「とても怪しい。」となっているようなものです。これらは無作法だと私は思います。前者に関して言えば、「タイトルしかない」というのはウソです。本文があまりにも短すぎて、それをタイトル欄に書いてしまったために本文の欄が空いているわけで、実際には「タイトルがない(=無題)」と言うべきなのです。言いたいことがすなわち本文ですからね。後者に関しても、題名が題名になっていない、という点では同様で、だからこそ本来は本文であるべき文を2つにちぎってタイトルの欄と本文の欄を埋めているわけでしょう。「題名」と「本文」という言葉の意味が理解できているなら、このような投稿はしてはいけません。

ただ、この意見はあくまで私の個人的な規範に照らしてのものであり、この無作法さに関する世間的な合意が取れているわけではないことに注意する必要があります。この文章を読んでいる人の中には私に賛同してくれる人もあるかもしれませんが、上記のような投稿が実際に存在している以上、全ての人が同意しているわけではないことは明らかでしょう。そこで思わず縋りたくなるのが、「『アクセスしやすさ』を確保するためのガイドライン」です。「今日の空模様は…」+「とても怪しい。」の例でいくと、音声読み上げソフトを使ったときに、

今日の空模様は(スコア:1)Anonymous Coward : 2011年01月01日 00時00分 (#00000000)とても怪しい。

と発音されるはずなので、これが悪習であることは一目瞭然です。しかし、ちょっと待ってください。この論法は正しいのですが、この正しさはある種の背徳感に満ちた正しさでもあります。「お前の書き方はアクセシビリティが低い」という主張は、「お前の書き方が気に入らない」という主張の言い換えになってしまっているわけですからね。私がどれだけ弱者に配慮しているかを他人が把握するのが難しいからこそ、尤もらしく聞こえてしまうわけです。

しかしながら、実際のところ、音声読み上げソフトに不利な記述方法は上記の無作法以外にもたくさんあります。例えば、縦読みなどはその最たるものであり、もちろんAAなどは厳に慎むべきです。では、これらのアクセシビリティを低下させる投稿を行ってはならないのか、というのは難しい問題です。縦読みはともかく、AAは余の方法をもっては代えがたい表現です。硬い内容ならともかく、ラフな受け答えまでアクセシビリティを理由に制限すべきか、というのはよく考えなければなりません。

もとより、スラッシュドット・ジャパンは、キャッチフレーズ入りのロゴマークを、imgタグを使わずにdiv要素の背景をCSSで指定する、というおよそ考えつく最低のアクセシビリティで表示しています。編集者はHere Syndromeに侵された記事を修正せずに掲載していますし、そもそもslashdotというドメインからしてアクセシビリティを意図的に下げるために命名されたものです。略称である"/."は検索することすらできません。ただ、こういう細かい点をあげつらってもあまり意味が無いとも思います。弱者のための配慮というのは、他の分野においてもその程度には頼りないものでしょう。

2年ほど前、慶応大学(湘南藤沢キャンパス)のトップページがFlashになった際に、その件を「アクセシビリティの低下である」として弾劾したブログがありましたが、指摘している側もアクセシビリティのガイドラインに違反していました。Re:指摘側のblogも大概わかりにくい。アクセシビリティに十分配慮したサイトを作るのも難しければ、それを指摘するのだって難しいものなのです。「お前のサイトはアクセシビリティのガイドラインに違反している」というのは「お前のやり方が気に入らない」と「お前のやり方は間違っている」を兼ね備えた婉曲表現なので、つかみ合いの喧嘩に発展してもおかしくないですからね。

ただ、他のサイトを批判するときにアクセシビリティを持ち出さない方が良い、とも言えません。慶応の例ように、Flashになってしまったのを批判するときは、(上記の無作法とは違って)アクセシビリティを抜きにすると感情論しか残らないので、やはり、どこかでアクセシビリティの話題を持ち出さざるをえないでしょう。そういう時は、これまで説明してきたような事情を踏まえた上で上手くやる必要があると考える次第です。

ちょうど今から3年ほど前、はてなブックマークで"erogeek"というキーワードを見てから、何かしらエロに関連することを書こうと頭を悩ませていたのですが、これが案外難しいものです。

そんな中、ひとつだけ温めていたネタがあります。それが、

「世界で最も有名なオザワさんは、セイジでもイチロウでもなければ、もちろんケンジでもない。マリア。」

です。

一郎さんが幹事長を辞任したころにGoogleの検索結果で気付いたのですが、不勉強にしてマリアさんが何者か知らなかったので、その圧倒的な結果にかなり驚きました。しかし、これって、他に客観的なデータがないんですよね。なんとか数字の裏づけを取りたいと思っていたところ、今度は(おそらく)Googleのランク評価からエロ系が軒並み落ちてきてしまって、今では残念な感じになっています。

http://www.google.com/search?q=ozawa
(google.co.jpにリダイレクトされたりする場合は、言語関係の設定を変えてみてください。)

音楽愛好家としては、ぜひとも征爾さんに頑張ってもらいたいのですが、どうやら、既に太刀打ちできるレベルではないようです。とはいえ、先程述べたように、客観的な数字は無いのですがね。

これは一見「VHSがベータマックスに勝ったのは…」と同種の話のように思われますし、確かに根本的な原因にそれがあることは間違いないでしょう。しかし、もう1つ忘れてはならないのが、おそらく(国内はともかく国際市場における)商業的な成功ではない、という点です。すなわち、彼女の雷名を轟かせしめたもう1つの原動力は「違法コピー」なのでしょう。これは、ある種の寒気を覚えるべき現象なのです。

時々、私は海外で違法にアップロードする人のことを考えます。中には違法行為によって直接(広告収入などの)利益を得ている人もいるでしょう。しかし、全く利益を得ずに違法行為に手を染めている人も、また、多いはずです。マキャベリ的な損得勘定で考えると、明らかに損しかない違法アップロードの動機に、あえて理由をつけるなら、それは、善意と呼ぶべきでしょう。義侠心と言ってもいいかもしれません。

それは、昏い善意です。法的にも倫理的にも決して許されることではありません。しかし、動機を善意というラベルで分類するなら、多くのことが見えてくるようです。

「違法コピー」は他人の権利を蹂躙することによって利益を得る仕組みであり、その大局的な動機は極めて利己的です。違法コピーのグループはその外の社会から一方的に搾取しています。一方で、違法コピーのグループの内部では、そのメンバーによる献身がなければ機能しません。メンバー全員が完全に利己的である場合、「違法アップロード→違法ダウンロード」というプロセスは起こりえないはずです。あるいは、存在したとしても、有限回で違法行為が停止してしまいます。しかし、現実に「違法アップロード→違法ダウンロード→違法アップロード→違法ダウンロード…」のプロセスは確かに繋がっています。かくして違法コピーのサイクルは外の社会のデータを全て食いつぶすまで、半永久的に回り続けるのです。

つまり、この「大局的な利己主義」は、一般的な意味の「利己的」ではなく、ドーキンスさん的な意味の「利己的」であり、ベンサムさん的な意味の「功利主義」なのです。そして、それを成立させるために得体の知れない力が働いており、それこそが「昏い善意」です。普通、功利主義を実現するために、我々は人工的な力、例えば「法」であったり、「政府」であったりを想定します。法も無く政府も無く、例えば、「所得の再分配」が出来得るものでしょうか？しかし、この「昏い善意」は完全無欠にアナーキーなものです。

違法コピーのもう1つの姿として、「大局的にはファイル交換である」という点が挙げられます。しかし、この「交換」にしても、一般的な意味合いの「交換」とは全く違います。「違法にアップロードすること」と「違法にダウンロードすること」は、因果関係こそあれ、人間の行動としては厳然とした区別を伴うものです。従来的な区分で考えると、アップロードは贈与に相当し、ダウンロードは収得に相当しますが、贈与が必ずしも収得の見返りとはなりえていません。この高度に断片化された「交換」のかけらを繋ぎ合わせることによって、大局的交換が成立しています。犯罪者たちは、何の担保もなく互いを信頼して与えることによって、自らが受け取っているのです。ですから、ファイル交換はあくまで集団犯罪の姿であり、個別の犯罪の形態は違法な贈与と違法な収得が独立しているのです。

つまり、この犯罪は我々の良く知る現代的な「交換」ではなく、むしろマルセル・モースさんやレヴィ・ストロースさんの例に出てくる未開社会の交換である「互酬的な贈与」や「クラ交換」なんかに非常に近い形態の「交換」じゃないですか？世の社会学者は、もっと真剣に違法ファイル交換コミュニティを研究して、その力の構造を解き明かすべきだと思います。それをせずに、ただ、対処療法を重ねたり、複雑な法を組み上げるのは拱手に似て、あまり役に立っていません。

私が思うに、「著作権者が犯罪者から賠償金を取る」というシステムが、既にダメだと思います。むしろ、取り締まった人(=警察)に罰金を原資とした「報奨金」を支払うシステムに切り替えるべきではないでしょうか。仮に警察に「昏い善意」に対処するだけのマンパワーが足りなかったとしても、後は市場に任せるだけで、勝手にシステムが回っていきます。それが資本主義の一番素晴しい点です。「犯罪者を減らせば得をする」という事実はもっとわかり易く示されるべきなのです。たとえ、それが斬新を通り越して旧態以前とした賞金稼ぎ方式だったとしても、です。

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1448399714

おそらく、"You're welcome."のことを言っているのだと思いますが、人工知能と集合知(?)の欠点を同時に見せつけられて、やるせない気分になりました。

現在、ラスタ画像をウェブ上で取り扱うとき、可逆圧縮ではPNG、非可逆圧縮ではJPEGが主流と言っていいと思います。

PNGは様々な変遷を経てこの地位に至ったわけで、これまでは不甲斐無い一面覗かせることもありましたが、これからの将来は安泰です。一方、非可逆圧縮の分野におけるJPEGの地位は、必ずしも楽観視できない、と私は思います。なぜなら、同じ分野で、JPEG 2000、JPEG XR、WebPという3つの後継フォーマットが鎬を削っているからです。

JPEG 2000、JPEG XR、WebPは、それぞれ圧縮の効率の面ではJPEGを上回っているという利点があります。さらにこれらを比べると、JPEG 2000は、この3つの中では最も古いので利用実績の面で大きく水をあけています。また、JPEG XRとWebPは、それぞれMicrosoftとGoogleという2大巨人が推すフォーマットですから、将来どう伸びてゆくか、計り知れない面がある、と言えるでしょう。

どれが勝つか、というのは非常に難しい問題です。というよりも、どれかが勝つかもしれない、という点こそが真の問題と言えるかもしれません。私が思うに、ネット上の非可逆ラスタ画像に限って言えば、3者と比べても、まだJPEGの優位は揺るがないでしょう。全ての人にとって理想的な状況は、JPEG 2000、JPEG XR、WebPがウェブ上で使われていない状況(=現状)であり、私としては、これらがウェブへと流入してくるのを食い止めるべきだと思うのです。JPEGとPNGで十分ですから。

しかし、これはウェブ本位な意見であって、デジタルカメラは(需要を先読みして)高解像度低容量に惹かれていくかもしれません。その時、カメラメーカーが参考にするのがウェブ上での普及率、ということになれば、ウェブブラウザの対応が最も重要な要素になります。MicrosoftとGoogleはともにブラウザベンダです。また、両者とも高機能携帯電話(ブラウザ+カメラ)の基幹部分の設計開発に大きく関わっています。こういった泥臭い面まで勘定に入れると、やはりJPEG 2000だけは先行きが暗い、と言わざるを得ません。これまで以上の何らかの梃入れがない限りは、ですけれど。

となると、業務用途でJPEG 2000を採用している業界が、今後、いつまで使い続けるのか、どうやって死に筋を確認するのか、心配の種は尽きません。フタを開けてみれば、余計なお世話となっている可能性も捨て切れませんけれど。

私の記憶が確かなら、『銀河鉄道の夜』の主人公の職業は「活字拾い」なるものだったと思います。つまり、原稿を元に活版を作成するアルバイトですね。機械化・及びデジタル化が進んだ昨今では、ジョバンニさながらの活字拾いは姿を消しつつあるのかもしれませんが、この広い社会のどこかでは、だれかがこの職に相当する作業を行っているはずです。例えば、マンガのセリフを貼る人とか。よく知らないのですが。

こういった仕事は、従来、印刷業でしかできないし、また、それ以外では意味の無いものでした。しかし、今ではウェブを使っていれば、当たり前のようにこの作業が要求されます。すなわち、CAPTCHAというやつです。ある程度難読化された視覚情報を文字コードに変換するのが、いかに大変か、もはや議論の余地もないでしょう。しばらくすれば、一定の書法に基づいた手書き文字をある程度の精度で認識できるOCRは、開発されると思います。しかし、逆に、既存の手書き文字をある程度の精度で認識するOCRの開発は、なかなか難しいのではないでしょうか。

そこで、この困難さを笠に着て、自主的にCAPTCHAを行う遊び、「活字拾いごっこ」あるいは「ソリティア・キャプチャ」を提案します。

遊び方

1. 字の書いてある画像(なるべく手書きが望ましい)を用意する。
2. 画像を読みながら、その通りに字を入力する。
3. 出来上がったら、それを眺めてニヤニヤする。
4. (上級編)他人が入力したデータのあら捜しをする。

字の書いてある画像の入手法は、俄かには思いつかないかもしれませんが、例えば、奈良女がスキャンしている坂本龍門文庫など、まとまった量があっておすすめです。

我々は、現在、急速に膨張する文字コード群、とりわけ、Unicode/UCSに包まれて生きています。それは、とりもなおさず、我々に使える字体・フォントの数が増えて行っていることを意味します。漢字ひとつをとってみても、今まで代用字で諦めていたものが、フォントまで含めて簡単に入手できるようになっている、ということです。入力には未だ難がありますけれど、この状況は、過去の世代にも未来の世代にも味わい得ない、我々現代人だけの特権でしょう。

まあ、そういった御託はともかくとして、とりあえず、私もやってみました。

ファーヴニルの箴言

ちなみに、画像のソースはhttp://www.am.hi.is:8087/です。あと、まともに表示するにはMedieval Unicode Font Initiative準拠のフォント、例えばJunicodeなどのインストールが必要です。

結論から言うと、HTMLのtitle要素は失敗で、最初から全てtitle属性にしておけば良かった、と私は思っています。ただ、title要素が要素であることにもきちんとメリットはありますし、互換性を考えると今さらどうしようもないことではありますが、まあ、こういう意見もある、ということでひとつ。

HTMLは既に1.0の時から、title要素とtilte属性の役割を区別していました。title要素は書かれている文書のタイトルで、title属性はリンク先の文書のタイトルです。現在のtitle属性はリンク先に限りませんから、少し用途が広くなっているものの、基本的な用途は概ね同じと言えるでしょう。後知恵ですが、これは、そもそも、分ける必要がなかったと思います。どちらも親ノードの表題ですから、何を指しているのか、少なくともパーサーにとっては自明です。

(SGMLの)属性は要素に比べて少し窮屈な機能です。属性の内容(属性値)はマークアップされていない素のテキストに限られますし、兄弟ノードに同じ名前(属性名)の属性を持つことも許されません。さらに、属性自身が複数の子ノードを持つことはできません。

1. 内容はテキストだけ
2. 兄弟で重複禁止
3. 子供なし

他方で、要素にはこれら3つの制限は存在しない上に、属性にできて要素にできないこともありません。つまり、現在要素で定義されているような機能を属性で定義しなおすことは出来ませんが、逆に属性で定義されている機能を要素で定義しなおすことのできる上位互換なのです。
例えば、

<a href="www.example.com">Hello, world!</a>

の代わりに

<a>
  <href>www.example.com</href>
  <value>Hello, world!</value>
</a>

のようなタグをつけても、まあ、それはそれでうまくいっていたはずです。文字数が気になるなら終了タグを暗黙にして、

<a>
  <href>www.example.com
  <value>Hello, world!
</a>

としておけば、マークアップの使い勝手はさほど変わらなかったでしょう。HTMLは「テキストノードをなるべく描画する」という縛りを入れているので、"www.example.com"をテキストノードとしてユーザーに晒したくない場合はそれには違反してしまいますが、それはスタイルのポリシーですから、まあ、言ってしまえばどうとでもなることです。仕様策定者にとって、要素は属性より便利なのです。

しかし、DOMを使う側から考えるとこの評価は逆転します。試しに、先ほどのアンカーからhref属性・要素の内容を取得してみると良く分かります。

まず、属性の場合は次のようになります。

var hyperLinkURI = anchorElement.getAttribute("href");

次に、要素の場合はこうです。

var hrefElements = anchorElement.getElementsByTagName("href");
var hrefElement = hrefElements[0];
var hrefNode = hrefElement.firstChild;
var hyperLinkURI = hrefNode.nodeValue;

この程度のスクリプトに4行も使うことはないかもしれませんが、気の利いたエラー処理を行おうと思ったら区切りは必要です。href要素を書き落としていたり、hrefの中身が空だったり、hrefの子がテキストノードではなかったりする可能性もあるわけですから。しかし、このスクリプトで最も問題なのは"0"や"firstChild"といった決め打ちを行わざるを得ない点で、これは仕様の罪です。

まあ、DOM L3を使えば、スクリプトの量自体は半分に減らせますし、DOM HTMLで丁寧にラッピングしておけば(例えば、element.hrefといったプロパティを定義しておくと)、スクリプトを書く手間はさほど問題になりません。が、筋が悪いことには変わりありませんから、反省も込めて理由を検討しておきましょう。

DOM APIのgetElementsByTagNameは、子ノードをNodeList、つまり配列で返します。これは当たり前のことですが、非常に重要なことです。hrefを文字列として取得したい場合、DOMの利用者は、要素そのものを直接渡して欲しいと思っているはずです。ここで、配列を渡されるのは、同名の子要素が複数あることをAPIが想定しているからです。同名兄弟の存在を否定されている属性ではありえません。また、firstChildを指定しなければならないのは、複数の子を持っているかもしれないからです。これも属性ではありえません。nodeValueを……、属性値はテキスト表現に収まりますから、これもありえません。

DOM APIは、DTDという空気を読まずに自分の流儀を押しつけてきますが、逆に言うと、DTDで細かく制御された要素は、要素の本来的な姿を歪めてルールを押し付けていることになり、DOM APIのような一貫性を欠いているのです。結果として、href要素の流儀には「間違えた記法」が数多く存在することになり、それがエラー処理の多さに繋がっています。おそらく、この割りをもっとも喰っているのは、文書を書く人間です。DTDに「あれは禁止、これも禁止」と書かれているため、要素の使い方が直観的にわかりにくく、教育にコストが転化されているはずですから。

人間はあまりにもソフトなソフトウェアなので、普段こういうことは意識しませんが、DOM APIのように愚直な物差しを当てると不合理が浮かび上がってきます。属性の3つの制限は、自由を求める時には邪魔ですが、制限つきで問題ない場合は、制限されている方が曖昧さが減ってむしろ楽なのです。

さて、href属性の素晴らしさを再確認したところで、title要素に話を戻しましょう。title要素は中身がテキストでなければいけません。title要素は文書につき１つです。title要素はhead要素の子要素でなければいけません……

そこまで制限を付けるなら、最初からhead要素の属性にしておいてくれたら話が早かったのに、と思いませんか？一応、title要素はlang属性を設定できることになっていますが、実用性皆無の上、(xhtmlのように)文書内のtitle属性にもlangが設定できないと対象性が保てないので、どのみちtitle属性で事足りるはずなのです。

更に問題なのは、HTMLのtitle要素が他へ及ぼした影響力です。ざっと思いつくXMLベースの規格だけでも、XBEL、A9.com OpenSearch、DocBookと枚挙に暇がありません。おそらく、私のようなことを考えている人はあまりいないのでしょう。その点、SVGはtitle要素の内容にマークアップを許しているので、納得がいくんですけどね。まあ、XULみたいに、場当たり的(失礼)に設計されていても、なぜか属性になっている規格もあるのですが。

例えば、

The "ShortName" element

Contains a brief human-readable title that identifies this search engine.

• Parent: OpenSearchDescription
• Restrictions: The value must contain 16 or fewer characters of plain text. The value must not contain HTML or other markup.
• Requirements: This element must appear exactly once.

Example:

<ShortName>Web Search</ShortName>

と、書いてあるのを見ると、何か、こう、こみ上げてくるものがあります。

まとめると、属性の方が制限が厳しいので、どちらでもよい場合は「属性」を選択すると"lean and mean"になります。それを覆すのは、もう、好みとか、拘りとか、惰性とか、とにかく理屈ではない何かだと思うのですが、ほとんどの仕様はその辺に無頓着です。

もっとも、(私を含めて)マークアップ言語のサブセットを設計する予定がない人には、どうでもいい話なんですけど、一人でも「ああ、気になって仕方がない」と感じてくれる人が増えると溜飲も下がるというものです。私だけ気にしているのも馬鹿みたいですから。