• Your website should be built with HTML code that is clean, well-organized, uncluttered, standards-compliant, and generally free of errors.

• Your site should use some form of template system, so that a change to a header, footer, menu, or other element shared across pages does not require the editing of each individual page.

• Your site should be displayed almost identically in any browser used by more than 1% of your target audience.

• Your site should degrade gracefully to text in non-graphical browsers (such as cell phones or some PDAs).

• Your site should be accessible to vision-impaired readers who may be using screen-reader software.

• Your site should be aesthetically pleasing, and its appearance should be appropriate to the message you want to convey.

• Your site should have a natural and logical information structure, so that the average user can quickly find what he or she is looking for.

• Your site should not contain any code or content that serves to exploit search engine algorithms in an attempt to receive higher search result rankings.
  

• 綺麗で整理された正しい標準のHTMLにて記述されていること。
• ヘッダーやフッター、メニューなどが変更しやすいようなテンプレート機能が用意されていること
• シェア1％のブラウザでも完璧に予想通りに見える。
• テキストブラウザでも見やすい。
• スクリーンリーダーでも扱いやすい。
• 美的に優れていて、サイトの伝えたいメッセージに沿ったデザインが施されている。
• 自然で論理的な情報アーキテクチャである。普通の人が簡単に目指すものを見つけることが出来る。
• SEOの痕跡をきちんと隠している。

というものです。
かなり言い尽くされたもはや「権利章典」という名前が合っているものです。

あまり現実的ではないし、色々と反論がなされています。かなりピュアな内容ですな。

実際制作をしていると、客側の事情、制作側の事情こもごもで、これを最優先に考えることは無理なのが現実です。（というかもっぱらコスト？）
一応現場で作っている時には、そっちを出来るだけ実現させようとは思っていますが、納期やスキルの面でまずひっかかり、後は申し訳ないですがモチベーションが持たないとか('A`)

ただ、こういうのが望ましいと言う努力目標として、こういったものを頭の隅においておくことは価値が十分にあることだと思います。なので、もうちょっと抽象的でもいいんじゃないですかね、権利章典は。あんまり無理やり現実に落とし込んでも、論議を呼ぶだけなのではないかと。

Webサイトはどうあるべきか、ということで意見の一致をみていないし、それがあるかどうかも分からないときに、結論が出るものでもないかなぁ、と。Webを広告に置き換えたとしても、人間に置き換えたとしても、サラダボウルに置き換えたとしても、結論が出るものでもないでしょう('A`)

そういえば、ニールセン氏のサイトの記事って、日本語訳されてたんですね。知りませんした。
　　＃useit.com: Jakob Nielsen on Usability and Web Design
　　＃ニールセン氏の和訳はJakob Nielsen博士のAlertboxから。

■アクセシビリティの高いサイトを増やすには

制作側だけで見ると、結局現状で、もっとアクセシビリティ対応を進めるには、サポートするソフトが出回ることが不可欠な気がします。各人の努力に期待するのは現状の制作業界には厳しいです…。

また、制作側が対応できればいいかというとそうでもなくて、それに加えて、それを価値として認めてくれるお客さんがいないと、片手落ちですし。

「アクセシビリティが高いサイトを作ることで、わが社にこういった利益が出る」というビジョンを持った会社でないと、結局「何か良く分からないものに金を払った、どう商売に生かしていいか分からない」となってしまって、無意味です。

アクセシビリティについて、制作側を突っつくのも必要ですが、同時にクライアント側も突っついておかないと、いかんと思う梅雨前の夜。

そう言えば、Web Accessibility Initiative (WAI) Home PageではWCAG2.0のドラフトを議論中ですね。

<form action="index.htm" tmt:validate="true" tmt:callback="displayError">

の様にformタグに書き加えます。tmt:validate="true"で使用する状態になります。CallBackは、独自に関数を書いて、好みの処理をしたい場合に使います。以下のページに各formオブジェクトを取ってくる方法など書いてあるので、必要な方はこちらに。
　＃TMT Validator - Customizing errors notification

それぞれのinputタグには、同様に　tmt:pattern　等のattributeを追加してチェックのパターンを決めます。これは、submitをした時にアラートとして出るものです。例えば、tmt:pattern には、

• email
• lettersonly
• alphanumeric
• integer
• positiveinteger
• number

といったパターンが用意されてます。他にもファイルアップロード用にもいくつかデフォルトで用意されてます。日本語には対応していませんが…。

また、tmt:filters　というattributeにて、入力禁止文字を指定できます。デフォルトで以下のものが用意されています。

• ltrim
• rtrim
• nospaces
• nocommas
• nodots
• noquotes
• nodoublequotes
• nohtml
• alphanumericonly
• numbersonly
• lettersonly
• commastodots
• dotstocommas
• numberscommas
• numbersdots

これは先ほどのtmt:pattern　とどう違うかというと、サンプルをいじってもらうと分かりやすいかと思いますが、入力禁止文字を入れると、リアルタイムに消去されます。

数字しか入れてはいけないフィールドにアルファベットを連打すると、どんどん勝手に消えていきます。

注釈をつけておかないと、キーボードが壊れたんじゃないかと、などと思われる恐れがあるので、目立つ形で注釈をつける必要があると思いますが、これは有用な予感が。

できれば勝手に消す前にalertを一発出した方が、使用者にとっては分かりやすいと思います。

こんな感じで他にもcheckbox用のものやselect用のものや色々と用意されているので、フォームの入力チェックが面倒くさくなったら、これで済ませてしまうのも良いかと思います。DreamWeaverとかFrontPageとかでも簡単につけられると言えばそれまでですが('A`)

実は一番感銘を受けたのは、submit後の入力チェックではねられると、inValidな部分のフィールドの背景が黄色になることだったりします。これは間違った場所が分かりやすくてよさげ。

• 頻繁にアクセスされるページはGoogleのサーバにキャッシュ
• 出来るだけ差分のみダウンロード
• リクエスト内容を分析し、先回りして裏で読み込んでおく
• インターネット接続の設定を、よりよく再設定する
• やり取りするデータを圧縮する。

みたいな感じのようです。手法自体に特に目新しいものは無さげですね。Googleのブランドイメージや、これまでのWeb全体の分析結果を抱えている、ということが強みでしょうか。

この巨大なプロキシサーバ的なもの（？）に対して、やはり人々からは異議を唱える声が多いようです。海外のフォーラムでは例えばWebmasterWorld.comのGoogle Windows Web Acceleratorスレッドや、Thread Watchの「Google Web Accelerator」などでしょうか。

そういった「人々がどこにどういう経路で行って、どんな感じでうろついている」というデータは、みなのどから手が出るほど欲しがるものです。

Google社も、そのデータを何らかの形で得たいが為に、こういったツールを資金を投資して開発し、無償で提供しているわけですし、役立てようとすることは確実、というか当前のことです。それ自体は特に問題でもないでしょう。（もちろん、横流しなどしなければですが）

また、こういった情報は、通常なら設備投資などをしてプロバイダ業務を始めないと得られないようなデータですからなおさらです。お金を出して買ってこれるものではないです。
それを、下手をすればどのプロバイダよりも手に入れることが出来るかもしれないのですから、GWAはとても期待された企画と言えます。

Web Acceleratorへの反応としては

一般の反応としては、やはり各個人のデータが、履歴はもちろんパスワードなども流れてかねない（セキュアでなければ流れていってしまう）こと、そしてそれがGoogle一社集中することへの危機感があるようです。同様のデータjは各プロバイダがすでに得ているので、Google一社が一手に手に入れるというところにツボがあるということでしょう。スレッドでもそういった内容の書き込みがかなり多い印象を受けました。

確かに、気持ちのいいことではありえませんし、何よりWWWには、基本的に「何をしているかは外から知られるべきではない」という考え方が浸透しています。反発は必至かと。

ちなみに、自分はというと…私の危機感が薄いだけかもしれませんが、どうも、「世界中のこういったデータを集めたら何か興味深いものが浮かび上がってくるんじゃないかな」とか、「これによってもっと面白い検索の仕方が生まれるんじゃないかな」とか、そういう気持ちの方が、高まっていたりします。

自分のサイトの履歴とかうんぬんが知られるくらいなら、別にどうってことないような。どうせプロバイダはみんな知ろうと思えば知ることができるわけですし。ネット＝匿名であるべきとも思わないです。

面白いものが出来るなら、自分のサーフィン経路くらいくれてやる的な気持ちです。おかしな言い方ですが、これに引き寄せられてたくさんデータが集まれば、Googleが面白いもの出してくれるんじゃないかという期待もあります。もちろんパスワードとかはダメですよ…恥ずかしいフレーズもあるから('A`)

例えばGoogle Web Acceleratorのスレッドの7番の

1. The content of each webpage (text, images, video, anything really)
2. The number of pages that link to a page in question
3. The words that people use to link to a page
4. The sites that people click on after searching for a term

なんていうのとか。面白そうだなぁと。この辺りの温度差が何に起因しているのかが気になるところです。
technoratiで検索して出てきたブログを読んでいても、「GWAを（何がどうかは分からないけど、何となくあんまり良い気分がしないので）使わないよ」という感じの人が多い気もしますのでなおさら。
　＃Technorati: Search for web accelerator

ひとまず、前回のAutoLink問題なんかと絡みで動向を見ていきたいです。

Web Accelerator関連メモ

後は気になったことのメモをしておきます。

[1]Googleが立てたアクセラレータ用の（透過型プロキシ）サーバのIPが72.14.192.0 – 72.14.192.255
なので、それを.htaccessで弾いてしまう方法。
　＃Cloaking, IP delivery, search engine optimization and marketing with fantomNews Archive » fantomTip: How To Block Google’s Web Accelerator

[2]404が変わるみたいです。詳細は» Web Accelerator Changes Your 404 Page  InsideGoogle - part of the Blog News Channelへ。
「Please edit the URL , or search fot it using Google」っとなるらしい。

[3]インストールされるdllとかの情報
SlashdotからGoogle Web Acceleratorから引用

The firefox files are:
GoogleWebAccFirefox.dll (GUI controls, event forwarder)
GoogleWebAccFirefox.jar (look and feel elements)
GoogleWebAccFirefox.xpt (Event monitor)

The IE files are:
GoogleWebAccToolbar.dll

The controllers are:
GoogleWebAccClient.exe (Receives events, controls proxy to google)
GoogleWebAccWarden.exe (Manages cache and search)

※他のOperaなどのブラウザでも、ローカルにプロキシを立てて、127.0.0.1:9100 をプロキシにするように、ブラウザ側で設定すれば使えるといううわさも。

[4]社内用などでプロキシを使っている場合、問題がおこることもあるらしい。

[5]遅くなってしまう例もあるみたいです。　
　＃例：Google Webページ高速化ツール Web Accelerator?

で、やっぱりダウンロードして使ってみました。結果は、やっぱり効果なし、しかも遅くなります。ではなぜ遅くなってしまうのでしょうか？ブラウザーツールの表示ではたしかに数秒単位で高速化されたと表示（時間）されていますが、体感＆目視では確実に遅くなっています。

[05/05/12追記]
現在、グーグルのWeb Accelerator、プライバシーやセキュリティの問題続出 - CNET Japanなどもあってか、公開停止されています。Web Applicationに悪影響という話もありますね。そういえばMozilla系やOperaの先読みは、どういう風に問題を回避してるんだろう。
　＃関連記事：グーグル、Web Acceleratorの提供を中止 - CNET Japan

　＃Mozillaの場合はprefetch属性があるものしか先読みしない模様。あんまり意味無かったのか…
　　　→Link Prefetching FAQ[日本語訳]

CSSについては、例えば有名らしい（知らなかった'A`）"a glimpse of the Guillotine"バグがすでに対応済みとのこと。このバグの詳細は、IE/Win Guillotine Bugに載っています。ある特定のfloatとlink周りの環境がそろうと、リンク先のように一部の内容が消えるといった、困ったことが起きる模様。

具体的には

1. コンテナとなる要素があり


2. その中にfloat指定された要素がある（そして、それはclearされていない）


3. コンテナ内に、floatされていないlink要素が、先ほどのfloatされている要素の後にある


4. linkのhover擬似クラスに、Background、Padding、Text Style、Border等を変更するスタイルが書いてある


5. ブラウザはIE

という要素がそろうと、起こるとのこと。リンク先を見てもらうと一目瞭然かと思われます。
　＃その他の各ブラウザのCSS周りのバグについてはCSSバグリスト＠CSSバグ辞典スレッドが最強です。

というようなバグが潰されているそうです。ありがたや。ベータ版は今年の夏を予定しているそうです。

[05/05/02追記]

PNGサポートを実現するに至るまでの経緯が、開発者によって記事になっています。
　　＃IEBlog : Tuesday, April 26, 2005 - Posts

Slashdot JAPANでも記事になっています。
　　＃Slashdot.jp：IE7の透過PNG実装内訳話

ちなみに、透過度フィルターを透過PNGに適用するとダメ、とか、MSTimesではダメという制限があるそうです。MSTimesってなんだろう。Google 検索: HTML+TIME2のことだろうか…。どっちにしても、初耳です。

しかし、100以上のサイトが並んでいるのは壮観です。いくつかのサイトのソースを見ると、やっぱり綺麗です。テキストブラウザで見ても自然に読めます。
　　＃テキストブラウザでの見栄えチェックは私はinfoaxiaで行ってます。
　　　例えば29digitalはこんな感じです。29digital.comオリジナルはこれ。

Blog | Davy Van Den Bremt | Music & Webdesignとか、underlow uncorporatedとか、Spilt Cocoa - Welcomeとか。デザインもソースも学ぶところが色々ありそうです。

また、それぞれのサイトのコンテンツも、CSS好きが書いてるだけあって、面白いものが多いです。UK Banking Accessibility Review · 29digital Design Studioとか。