IE7同封のVirtualPC用イメージファイルの準備

まず、Virtual PC 2007＋InternetExplorer7、InternetExplorer6のイメージファイルを落とします。これを使ってVirtualPCでXPをブートします。一番下の方の「IE6_VPC.EXE」か「IE7_VPC.EXE」が、そうです。IE7の方を選べば、すでにIE7が入った状態で後々起動してくれます。
Download details: IE App Compat VHD

実行すると中身が出てきます。途中で期限が今年の12月7日までだよ！といわれます。

そのまま進めて、vhdという拡張子のファイルができたらOKです。

VirtualPC2007のインストール

続いてVirtualPC本体がないとダメです。これは以下のサイトからダウンロード。無償です。
http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=04d26402-3199-48a3-afa2-2dc0b40a73b6

事実上昔はMac専用だったVirtualPCが今は無償とは…。
Connectix社が作ってましたねぇ。マイクロソフトに吸収されてしまいました。
ちなみに当時はSoftWindowsなんていう対抗馬が居ましたが、結局OSXに対応できずに消え去ってしまいました。懐かしい。

さてさてちなみに、VirtualPC内で動かすOSによって推奨スペックが違います。こんな感じ。

• Windows 98 Second Edition Mem:64 MB / HD:500 MB


• Windows 2000 Professional Mem:96 MB / HD:2 GB


• Windows XP Professional Mem:128 MB / HD:2 GB


• Windows Vista Enterprise Mem:512 MB / HD:15 GB

なんかVistaだけ格が違う…

要求スペックの詳細はこちら
→http://www.microsoft.com/windows/downloads/virtualpc/sysreq.mspx

インストールは特に問題なく進むと思います。
メモリーは迷いましたがとりあえず512MBにしたところ、現在ブラウジング用途だけですが全く快適です。

そしてインストールの最後で、さっき解凍しておいたvhdファイルを指定します。これでXPが起動します。
ただし、英語版です。

CPUは起動マシンのCPU、メモリは設定した容量が出ます。
そしてIE7入りならデスクトップにIE7があり、すんなり起動します。こんなん。

InternetExplorer7の日本語化

IEは最初は英語しか表示できませんが、右クリックからエンコーディングで「Japanese」を選ぶと、「LanguagePackのインストールをするので、XPのCDを入れてください」と求められます。

ひとまずこのマシンのCDを入れてみたところ（これはもしかしたらライセンス的にまずい？）、いくつか足りないファイルをスキップしたものの無事完了。

再起動したら、とりあえず日本語表示ができました。
これで表示確認には必要十分かと思います。

ちなみにPentium4 3.2GBですがタスクマネージャ上ではそれほどCPU使ってないのですが、どうも動かしているとファンが回りっぱなしです。なんだろ。

VirtualPC、色々応用が利きそうで面白いのでもっといじってみたいですね。
検索するとLinux系入れたりしている人が多い模様です。

Vistaの人がきちんとライセンス買って、XPや2kを入れるのもいいかも？
パフォーマンスがどれくらい落ちるかがネックでしょうか。

Macの時は相当落ちたなぁ…。G4-733で、PenIIIの500MBもなかったような…。

■関連サイト
マイクロソフト Virtual PC 2007（公式）

Virtual PC & SoftWindows（Mac時代のベンチが載ってます）

Flashの容量をどれくらいにすると、だいたい何割くらいの人に、広告主としては一番見て欲しい「スーパーバナーMega（Flash）」を見てもらえるかは

　http://yac.yahoo.co.jp/download/megarate.pdf

に簡単なグラフがあります。

一応広告自体は、「スーパーバナーMega（Flash）」は、1フレーム目30KBでswfファイル自体は1.8MBまで、アニメーションは30秒以内、フレームレートは30fps以内という制限になっています。

しかし、だからと言って1.8MBギリギリで制作すると、基準は1フレーム目のファイルサイズなので一概には言えませんが、さっきのグラフによると25％以下の人にしか見てもらえず、ほとんどの人にはその下の「スーパーバナーMega（ミドルFlash）」が表示されることになります。これはかなり痛いです。

なぜ痛いかと言うと、二つ目の「スーパーバナーMega（ミドルFlash）」は、恐ろしく制限がきついので、なかなか望むものが作れないからです。

「スーパーバナーMega（ミドルFlash）」の制限は、"ファイルサイズ12KB以上15KB以内"です。MBじゃないです。

15KB以内でFlashを作るのは、かなり割り切ってもともとのFlashに鉈をふらないと、結構きついです（きつかった）

三つ目の代替画像も容量が15KB以内なので、728×90pxの画像としてはかなりきつい。JPEGではまず無理ではないかと。

自分は背景をイラスト調に加工した後に、GIFで24色位でまとめてなんとかしのぎましたが、ものによっては全然別のデザインを起こさないとダメかもですね。

また、その他にもFlashには以下のような制約があります。

　　・互換性はFlashPlayer6以上
　　・フォントは全て分解してグラフィック化
　　・単純ループは不可。
　　・ムービーの圧縮は使用不可
　　・ClickTagを埋め込む必要がある。
　　・外部参照のデータを呼び込むActionScriptは禁止

詳しくは、Yahoo!のAd Creativeという広告主が見るサイトをご覧下さいませ。
　　→Yahoo! Japan Ad Creative

ちなみにClickTagちゅうのはこういうヤツです。

on(release) {
　　　if ((clickTAG.substr(0, 5) == "http:") or (clickTAG.substr(0, 6) == "https:")) {
　　　　　　getURL(clickTAG, targetTAG);
　　　}
}

<param name="movie" value="sample.swf?clickTAG=http://yahoo.co.jp/">
<embed srv="sanple.swf?clickTAG=http://yahoo.co.jp/">

と書いておけば、そこにジャンプするようになります。Flashの中身をいじらずにリンク先を変更できるので便利ですね。

この辺の資料が後から来たので、二度手間になってしまいました…。
バナー広告だからと言って十把一絡に甘く見るといかんですな…。

The report finds, among other things, that the majority of people browse maximized or very close to it. That Mac user have bigger screens, but their browser are the same size as on any other platform. And, in order to support 95% of your visitors, you need to design for a maximum size of 776x424px.

ほとんどの人が最大化か、それに近いサイズまでブラウザを広げているようです。また、Macユーザは大きいディスプレイを持っていることがおおいが、ブラウザ自体のサイズは他のプラットホームとあまり変わらないと。

そして、95%のユーザをカバーするには、776x424pxのサイズにしておけばいいそうです。縦幅に関しては、一目で目に入る高さですね。デザインと言うよりはマーケ的に気になるとこですな。

ちなみに測定法はこの辺のプロパティからです。
　Baekdal|TEST - Browser screen sizes

さらに詳しい説明はこのムービーから。
　Actual Browser Sizes - the Movie - Baekdal.com

前回の結果とほぼ同じですね。参考にさせていただきまぅ。
特に縦幅の情報は貴重だ…。

他にも、OSごとの最大化割合とか、面白いデータが揃ってます。デザイナーな方もディレクターの人も是非。
　

この記事では一ヶ月集計とのこと。

結果としては

The size of the browser's content area. The most common browser width is 1008px, and the most common height is 600px.

で、幅は1008px、高さは600pxにピークがきているようです。
記事の方にグラフが載っているのでそちらをどうぞ。
　＃ちなみにこれは、全ての解像度のユーザを対象にした結果です。
　＃640×480から、1920×1400等の大きいモニタ使用者まで一括で集計しています。
　
　

また、どのくらいの人が最大化しているかのグラフも載っています。
例えば、幅800pxの人は約90%が最大化。1280pxでは70%超が最大化、1600pxの人は、50%弱の人が最大化しているようです。

モニターが大きくなっても、あまりブラウザ自体の大きさは変えない傾向にあるようです。

大体のWebサイトがその辺りに最適化されているせいですかね。それとも、小さめのモニターを使っていた時代の慣れが関係しているのでしょうか。

そして、この辺りのデータの対応関係から導き出された、Webサイトの最適値は

e.g. if you want to support 90% of you visitors with a fluid layout, you need to make it work between 784x432px and 1268x896px. Similarly, supporting 90% of your visitors with fixed layout means fitting the design within 800x512px.

リキッドレイアウトを採用しているなら"784x432px〜1268x896px"に対応できるデザインであれば95％のユーザはカバーできる。フィックスなデザインをしているなら、800x512px以内にすれば95％のユーザをカバーできる、とのことです。

なるほど。

ちなみに値をどうやって取っているかはこのあたりをどうぞ。
http://www.baekdal.com/test/screen.asp

また、類似の調査をしている人もいました。
うう、フランス語かぁ…。

http://www.gwix.net/web_gwix/article.asp?filID=303
http://www.gwix.net/web_gwix/article.asp?filID=300
http://www.gwix.net/web_gwix/article.asp?filID=286

<h1><span>タイトル</span></h1>

としてマークアップして、cssでh1の背景に従来の画像を出し、さらにh1の中のspanの内容を見えないところに配置するだけです。

h1
　　{
　　　　background: url(header_img.gif) no-repeat;
　　　　width : 768px ;
　　　　height : 200px ;
　　}

h1 span
　　{
　　　　position: absolute;
　　　　left:-2000px;
　　}

という感じで。
spanが気になる人はspanを取って、h1に直接text-indent : -3000px とかでも良さそうです。

ところで、うちのサイトもそうですが、ページ全体を常にウィンドウの真ん中に表示するレイアウトは沢山使われています。

そしてそこに、別にcssで絶対配置したオブジェクトがあった場合、ウィンドウサイズによって絶対配置された要素とその他の要素の位置関係が変わってしまって参ったことはありませんか。

あれ、自分だけ…？('A`)
上から落ちてくるホバーウィンドウの時に悩んだんですが…。

とりあえずこれは、同じ記事の項目9番にも便利な例が載っています。

親要素の配置をrelativeにしておけば、その要素の中でabsolute指定された要素は、その親要素の原点を基準に配置することが出来ます。つまり、ウィンドウサイズが変わっても、相対的な位置関係が維持できます。

-------------

しかし、このevolt.orgでも、WinIEのサイズ計算のバグ対策が乗っていますが、これはDoctype宣言で標準モードにすれば良い気もするのですが、なぜ未だに語られるのでしょう。…何か罠が？

　＃追記05/07/25
　　　　WindowsIEの6より前ではDoctypeスイッチが効かないとのこと。うぅむ…。

それはともかく、CSS周りはまだまだ苦労するところが多いですね。
ちなみに、個人的には、WinIEの「floatさせた要素のmarginが2倍くらいになってしまう」というバグが一番今のところ悩みの種です。
他は個人的にはあんまり不満は無かったり。

どちらかというと、CSSをどう書けば、他の製作者に意味が伝わりやすいか、他の人が読みやすいか等の方が最近は気になります。

CSSもHTMLもフリーな記述形式なので、非常に製作者ごとに書き方に差が出やいですね。また、少し大きなサイトになれば、量も結構な量になります。

自分が書いたものでさえ、後で見ると意味不明だったり。
きちんとポリシーを作ってやろうと思っても、途中で辛くなってきて適当になってしまったり('A`)

…CSSの各セレクタごとにタグをつけて管理できるツールが切に欲しいです。適用箇所、作った意図、注意点、作成日などを参照できるようなものが。

-------------

ちなみに自分がやっていることは、
「全体に適用されるCSSと個別のページごとのCSSの分割」
「CSSへのコメント付け」
「全体を"header"、"menu"、"contents"、"footer"のような感じでIDを振り、セクションに分割。そしてその中の要素は特に必要が無くとも、それらを親とした、子孫セレクタとして記述」
「クラス名を考えてつけることをサボらない」

くらいでしょうか。

具体的な作り方

具体的な作り方としては。
デモページは以下のところにあるので、こちらのソースを見てもらうのが早いと思います。
http://www.456bereastreet.com/lab/flexible_custom_corners_borders/

単純化すると、
ひとまず以下のようにブロック要素を並べていきます。

一番外側（上のコードで言うfor_leftborder）と2番目のボックス（上のコードで言うfor_rightborder）は、入れ子になっていますが、役割的には同列です。
このサイトの場合、外側のボックスで

として、右寄せで縦線画像を配置し、内側のボックス（上のコードで言うfor_rightborder）にて、

として、左寄せで縦線の背景を置いています。paddingは、置く画像次第で変わる部分です。

そして、そのボックス（上のコードで言うfor_rightborder）の中に、並列に二つのブロック要素と、内容になるブロック要素を放り込みます。上で言う

の部分です。

最初の"box_top"は、フレキシブルな枠の上部を作っている部分です。

先ほどのサンプルページの"box.gif"と言う画像を、最初のbox_topにて右寄せで配置し、さらにその中のdivで、逆に左寄せで置くことで、横幅が可変になっています。（厳密に言えば、元の画像の幅までが限界ですが…1600pxあるので問題ないかと。）

同様のことを"box_bottom"にて行い、これで可変ボックスが完成です。

概観的にはこんな感じですが、外側のパディングの分を内側のマイナス指定のマージンで取り返したりと調整が行われていますので、ソースを見てもらった方が良いかと思います。CSSもヘッダーに書いてありますし。

1)仕事とそれ以外の時間をきっちり分けること。また、出来れば仕事空間も生活空間から切り離すこと。だらだらと一日中仕事をしないこと。

2)人脈を重視すること。顧客から顧客を紹介してもらうことも大切。また、一日家にいるのではなく、積極的に外部と関わりを持つようにすること。

3)支払いなどの方針をきっちりと決めておくこと。簡単にそれを曲げないこと。

4)プロジェクト管理と同じくらい、健康管理に気をつけること。

5)ネコを飼うこと。

という感じでした。
寝巻きで仕事をするな、とか、一日中机にかじりつくな、とか身に染みることがたくさんありました。

生活空間からすぐに仕事空間に移れるので、ケジメをつけるのが本当に難しいと思います。また、生活が苦しい時等は、何もしないこと休むことが辛くて、無理やり仕事や技術習得などの勉強をしたりしてしまって、精神的に厳しくなったり。

お金のやり取りなどは、非常に向き不向きがある分野だと思いますが、フリーならきっちりやらなければいけません。お金の話をいきなりするのは何か気まずいなー、と思ってしまう自分は非常に辛いです（なのでフリーはもはや諦めている訳ですが('A`)。

フリーできちんとやれる人は、中々いないと思います。そんなフリーの人達がフリーの人達に送るTipsが、Andy Budd::Blogography: Top Tips For Freelancersには詰まっていました。

その中から、気になった部分を抜き出してみました。
本当は全てコメントをつけた人の名前まで引っ張った方がいいのですが、ひとまず原文引用だけで今回は…。

-----------------------------------------------------------

At the end of each project ask the client for three colleagues who might benefit from your services, and be sure to follow up!

それぞれのプロジェクトの終わりに、あなたのサービスで手助けしてあげられそうな知り合いを三人紹介してくれるように頼んでみよう。そして、その３人に目を向けよう。

-----------------------------------------------------------

Get out there. There’s a tendency as a freelancer to stay in the office and just work, work, work. You need to get out in the community and be known.

外に出るべし。フリーの人は机にかじりつきがちですので。外に出て人と交わって知り合いを増やそう。

-----------------------------------------------------------

everything takes 3 times longer than your worst-case estimate

何においても、最悪の想定の3倍は時間がかかる。

-----------------------------------------------------------

it will always seem that your larger clients are deliberately trying to put you out of business by not paying you in a timely fashion despite really relying on you and your work

どんなにあなたとあなたの仕事を信頼してくれている大口顧客でも、きちんと支払いをしてくれずにあなたを倒産に追い込むことはあり得る。

-----------------------------------------------------------

Try to work always at the same time. From 9 to 5 or from 2 to 10 for example. Never work in a pyjama.

いつも同じ時間に規則正しく仕事をすること。9時〜5時とか、2時〜10時など。寝巻きで仕事をするのは絶対に止めた方が良い。

-----------------------------------------------------------

Phone, don’t email, especially if you’re contacting web agencies. They get hundreds of emails every week and even if you’re exactly what they’re looking for, unless you’re lucky they just won’t read your message.


特に相手が制作会社だったら、メールではなくて電話を使ったほうがいい。もし製作会社が探している人物にあなたが合致していたとしても、彼らは何百ものメールを毎週受け取っていて、幸運でもない限り目に入らないものだ。

-----------------------------------------------------------

Get your invoices, quotes, standard forms etc. in working order. Determine your payment (and any other) policies, inform clients of them up front, and stick to them

きちんと請求書の書式や雛形を作っておこう。また、支払いについてポリシーをきちんと決めておき、顧客に提示しておくこと。何か頼まれても、簡単にそれを変えてはいけない。

-----------------------------------------------------------

Set aside a work area, preferably in a seperate room which you can close the door on… In the corner of a lounge/dining room/bedroom etc is no good, because it’ll remind you of those stresses you have at work while you’re trying to relax

仕事をする部屋は、できればきちんと区別されたところが良い。居間や寝室の一部を使うのはあまり好ましくない。リラックスしたい時にも仕事中の緊張を引きずってしまうから。

-----------------------------------------------------------

The best advice I can give (which people have already mentioned here) is to remember why you’re doing what you do.

（みなさん気づいていることだとは思いますが）私は、何かをする時に、何故それをするのかを忘れないようにした方がいいと思います。

-----------------------------------------------------------

It’s an old chestnut, but it’s so true: you’re not going to look back on your life at 65 and think, “I should have worked more.” Make it a priority early on to make sure your social and personal life is as vibrant as your career, and stick to it.

これは、陳腐な話ですが、本質を突いていると思います。"65歳になって自分の人生を振り返って「もっと働かないといけない」等と思ってはいけません。もっと、自分の人生は自分のキャリアと同じくらい鮮やかで美しいものだと感じられるようにすることに重きを置いた方が良いです。

-----------------------------------------------------------

Start a monthly newsletter to your existing and potential clients to tell them about all the great work you’ve been doing.

At least once a month they will think of you, and there is a good chance you will have developed a solution for one client, and another client will realize they could use something just like that.

顧客や見込み客に対して、月に一度のニュースレターを出すのもいいと思う。

少なくとも月に一度は彼らにあなたのことやあなたの仕事を考えてもらえるし…（略）

-----------------------------------------------------------

こんな感じでした。
他にもたくさんのコメントが寄せられているので、是非原文をご覧下さい。

基本的にフリーというのは、厳しいですね。
フリーでないと出来ないことがあって、それがやりたくてフリーという流れでないと、色々と厳しい野ではないかと思います。

Webデザインの雑誌などを見ると、フリー志望の人がたくさんいるみたいですが、うぅむ、と思ってしまいます。

仕事が好きでやっているなら、面倒くさいことはまかせておける会社勤めのほうがいいと思うのですが…。いかがでしょうか。

1. あらかじめ決まっている締め切りの為、プロジェクトの遂行に極めて短い時間しか与えられていない。この状況では、プロジェクトを提案してきている人達は、前からその締め切りを知っていたが、計画を立てるのに予想より時間を使ってしまったため、制作の方に何とかしてほしいと思っていたりする。

2. プロジェクトを提案してきた客が、予算のことを考えていなさそうな時は、彼らはあまり下準備もせず、あまりそのプロジェクトを真剣に考えていないかもしれない。

3. 潜在的顧客が予算があることはほのめかすが、あまり具体的に語らない場合、しばしば客はあまりあなたを信用しておらず、予算を知らせると、それより高い額を請求されるんじゃないかと思っている。

4. 顧客が出来るだけ安価にサイトを作ってほしいとか、極めて少ない予算しか提示してこない場合がある。この場合、客はWebサイトを作る意義をあまり感じていないことがよくある。この状況では、自腹を切って予算を出しているような顧客は、極めて厳しい要求をし、大したことの無いものに、多くの期待をすることがありうる。

5. 顧客が許された予算より多くのものを期待する場合。この状況では顧客をなんとか満足させることすら難しいかもしれない。

6. コンペ形式でデザインを提示してほしいと言う場合。
   初期段階で、あなたがそのプロジェクトについてあまりよく知らない場合、トラブルの原因となりうる。こういった場合、コンペは制作者のスキルや履歴を見るというよりは、見た目の美しさを競うコンテストになるかもしれない。
   また、コンペに勝てなかった場合でも、あなたのデザインの一部が勝手に使われる可能性もある。

7. 潜在的顧客が、彼らの持ってきたプロジェクトにいくつの代理店が興味を示しているかを言わない場合。
   この場合、非常に多くの代理店にメールでコンタクトを取っている可能性があり、選ばれるのは一番安い代理店だったりする。

8. 非常に多くの代理店とコンペをすることがあるかもしれない。こういう場合は顧客はあまり下準備をしていないことがありうる。もしこのコンペが重い金銭的負担を代理店に期待している場合、勝利の可能性は制限されるだろう

9. 焦点の見えない打ち合わせ。大企業のプロジェクトには多くの投資家が絡んでいる。もし顧客の側でそのあたりをまとめられる人間がいなかった場合、こちらがわがそれをやらないといけない。このことは、プロジェクトをとても複雑なものにし、さらに間接的な費用の増大につながる。
   一つの納入業者なので、あなたにはその組織での発言権など無いため、それはとても難しいものになる。また、組織内の政争に巻きこまれる危険性もあるのだ。

10. 潜在的顧客が、プロジェクトに関してあなたに大した要求も伝えず、またこちらが出したデザインについての質問を満足させてくれるような時間すら与えてくれないことがある。
    もし顧客が、プロジェクトにこちらが提示した時間をかけることに、あまり乗り気でなかく、そのプロジェクトにあまり真剣ではなかったら、顧客はたくさんの代理店に声をかけていて、あなたと話す時間があまり無いか、あるいはただウィンドウショッピング感覚なのかもしれない。

原文は10 Bad Project Warning Signsから。
---------------------

確かに、顧客があまり制作に乗り気でない、また、顧客がWebサイトにあまり価値を感じていない場合は、いかに顧客に「こんなものに何でお金を払わないといけないんだ」と思われないようにするかに、凄く気を使います。

どういう風に受注してきたかに関わらず、なんとか顧客のモチベーションを上げていかないと、効果のでるWebサイトって出来ないですし。

しかし元記事にはコメントたくさんついてますね。まだ読んでませんが、面白いこと書いてありそうな予感。

また、Top Tips For Freelancers という記事では、ついこの間からフリーに鞍替えした筆者が、読者からTipsを募っています。現在52個のコメントがついてます。こっちも面白そうですねぇ。
というか52個もつくというのが凄い。

※エントリー作りました。フリーランスでやる時に知っておきたいTips集：：[7korobi8oki.com]

• 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のドラフトを議論中ですね。

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とか。

HTMLだと、例えばIEのみ対応していないもので、"abbr"要素なんてあったんですな。略語としてマークアップさせるもののようです。
　＃参照：強調,引用,グループ化,画像などの要素 -- ごく簡単なHTMLの説明

<abbr title="Golden Week">GW</abbr>

こんな感じらしいです。IEだとabb要素を認識してくれないらしく、色々と対策が講じられてるみたいです。
　＃参照：WinIEでabbr要素を何とかする - 徒書

bdo要素

また、CSSの"direction: rtl"のようなもので、bdo要素なんてものもあったのか…。これはばけらさんによると、

異なる書字方向の言語を併用するようなケースでなければ活躍の機会は全くありません。

とのこと。

kbd要素、samp要素

キーボードで入力された部分だと示すために、kbdという要素が用意されているとのこと。また、samp要素は、プログラムやスクリプトのサンプルコードを表しています。

シチュエーションとしては、プログラミングの教科書などでしょうか。この辺りになると、必要ならXMLで書いた方が良い気がしますね。HTML4.01にはこんなものまであったとは。

Aural Cascading Style Sheets

CSSも,ちらほら知らんかったものがあるのですが、その対応状況はともかく、音声関係のスタイルがこんなにもあるとは知りませんでした。

音声系のスタイルはAural Cascading Style Sheetsと呼ばれて、略してACSS（アックス）と呼ぶそうです。（→IT用語辞典 e-Words ： ACSSとは 【Aural Cascading Style Sheets】　─　意味・解説）

W3Cの仕様書はAural style sheetsにあります。

日本語訳が、小町祐史氏のサイト（y-adagio）にある、CSS2の仕様書の翻訳「JIS/TR X 0032:2000, Cascading Style Sheets, level 2 CSS2 Specification」の中の[19 聴覚スタイルシート]のページにあります。
　　＃具体的にはAural style sheetsです。

これは、文書に音声に関する情報を盛り込んでおくことで、聴覚"表示"の品質を上昇させようというものです。例えば、文字サイズと同様に”音量”というプロパティがあって、これはVolumeという名前がついています。

例えば

div.giant { volume:x-loud }
div.ushmitsudoki { volume: silent }

というように使います。
これは相対的なものです、絶対単位でデシベルとかがあるわけではないです。カーオーディオのx-loudと、イヤホンのx-loudは絶対的な音量が同じだと、えらいことに。開いたらオーディオが壊れるページとかが。オーディオならいいですが、近所関係が大破する恐れも。

また、'play-during' というプロパティでは、BGMを指定することも出来ます。また、BGMではなく、効果音も'cue-before', 'cue-after'及び 'cue'プロパティで指定できます。
指定の方法は:before や :after疑似要素に似ていて、内容生成として、使用方法も同様のようです。
　＃擬似要素については：K@tsukun Page[:before および :after疑似要素]をどうぞ。

他にも、往年のText-Speechを思い出させるような、'voice-family' プロパティ。アクセントを指定するstressプロパティ、音声の豊かさ（？）をあらわす'richness' プロパティなど、多種多様な音声表現が用意されています。

これが実際に実用的になるには、長い年月が必要と思われますが、音声と言うものをどういった要素に分解するか、という点がとても面白いと思います。'richness' プロパティにはびっくり。
声色やテンション、話すスピード、間の取り方…プロパティがあるということは、重要だとみなされた、ということでしょう。

ところで、文字と音声だと、圧倒的に音声の方が情報量が多いですよね。文化人類学なんかでは、情報量が多くなる順に、文字→口承→踊り、である、なんていう話も聞きます。文字をはるかにしのぐ、言外の要素が音声や動作には含まれているというわけです。その辺りが、例えばネットでの純粋な情報収集手段としては、微妙なところです。

例えば、声色なんかは、余計な印象や先入観を与えてしまうこともあると思うので、本来の「純粋な情報」としては不必要なものだと思います。利用者の方で、好みの声を選べればそれでよいと思います。
フォントサイズなど以上に、音声の種類や、いわく豊かさなどは作り手は指定すべきではないです。

でないと、TV番組のように画面の印象だけで押し切ってしまえたりするのでは。ましてや情報を発する本人の声でも無いですし。

そんな感じで、Aural Cascading Style Sheets　音声スタイルシートネタでした。
DOMの方は、知らないこと多数なので割愛…('A`)

ちなみに、CSS関係の不具合はやはり『CSSバグ辞典スレッド』の要約
でしょうか。

CSS自体については、海外ではCascading Style Cheatsheet
が有名の様ですが、自分としてはCascading Style Sheets Reference
が最高に上質だと思います。

何度このページにお世話になったことか…。

ColorPic

紹介されているのは、まずカラーピッカーのColorPic。今まで他のカラーピッカーを使っていてそれなりに満足していたのですが、こっちもなかなか。

まず、基本的なカラーをピックする機能はもちろん一通り網羅。拡大率も変えられる、画面下の拡大鏡で対象に合わせて、Ctrl+Gでピックします。一度に複数の色をピックできます。デフォルトで16個と十分。また、ここでこのソフトのよさげなポイントの一つがあらわになるのですが、ショートカット完備で、慣れればかなりサクサクと色が取れます。

起動して取りたい色のところに持っていって「Ctrl+G」
さらに、上のパレットは、ファンクションキーにそれぞれ対応していますので、F2を押せば、ワンタッチで2つ目のスペースに移動できます。そこでまた「Ctrl+G」でピック…そしてF3…Ctrl+G…F4…Ctrl+G…

こうして好きなだけ色をとった後、ファンクションキーでカラーを選んで、Ctrl+Cを押せば、カラーコードをクリップボードにコピーできます。これはかなり楽そう。特にキーボード派には良いのでは。

MWSnap

続いてのMWSnapは、いわゆるスクリーンキャプチャ。BMP, JPG, TIFF, PNG GIFで保存できたりするのがよさげ。しかし、標準のスクリーンキャプチャの、ボタン一発の楽さもすてがたし。結局すぐにPhotoshopにペーストしてトリミングしてしまうので('A`)

TopStyle"Lite"

つづいて、http://www.bradsoft.com/topstyle/の、フリーの方のTopStyle"Lite"。こいつは以前から使っていましたが、リアルタイムにスタイルを表示してくれるので便利です。ただ、日本語に対応していないこと、そしてCSSを書き換えるたびに、下のプレビューウィンドウが一番上に戻ってしまうことがかなり個人的に面倒です。いちいちさっき見ていたスタイルまでスクロールしないといけないという罠。これが改善されれば悪くなさげ。特にピクセル単位での調整やら微妙なカラー調整に良いと思います。

Web Developer Extension

そして、FireFoxとMozillaの拡張ツールバーWeb Developer Extension

こいつは文句なしに便利です。ツールバーから画像の非表示をしたり、スタイルの非表示をしたり、画像サイズを表示したり、JavaScript切ったり、おまけに一発でValidateに持っていってくれたりで、Webサイトを作っていて追加のツールバーに抵抗がない人には是非お勧めです。ちなみに後発類似品でWeb Accessibility Toolbarもあります。こっちはIE用。

最後のひとつは、accessify.comの、Accessibility Toolbox 。これは、アクセシビリティに優れたFormを自動的に作ってくれるもののようです。お腹がえらく痛いので未使用('A`)

寝る前に牛乳をパック半分のみ干したのが良くなかったのだろうか…。週明けの忙しいときにやる気が右肩下がりです。

おや？と思ってカラーピッカーで取ってみると、やっぱり違う。何だ何だと思っていると、不意に右下のプルダウンメニューに目が。

「Protanopy (1 % of men)」

いつの間にかデフォルトの「Normal Vision」から変えてしまっていたようです。
しかしこれはどういう意味だろうか…というわけで調べてみると、以下のような意味でした。

Protanopyとはいわゆる「赤色が見えない」状態
Deuteranopyとはいわゆる「赤色が見えない」状態
Tritanopyとはいわゆる「赤色が見えない」状態
Protanomalyは、「赤色の見え方がおかしい」状態
Deuteranomalyは、「緑色の見え方がおかしい」状態
Tritanomalyは、「青色の見え方がおかしい」状態
Full colorblindnessはいわゆる「全色盲」で、
Atypical monochromatismは世界が「モノトーンに見える」ということらしいです。
　＃参照：http://www.drallanpanzer.com/color_vision_diagnosis.htm

つまりこのカラージェネレータは、なんと、色盲の人達の見え方をシミュレートしてくれるものなのです。

いじっていて、こんな風に見えるのかと言う驚きと共に、ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0を不意に読み返したりと、いいきっかけになりました。自分にとっては、視覚で示されると下手な文章より説得力が大きいようです。

また、Vischeck: VischeckImageでは、手持ちの画像をアップロードして、色盲の人の見え方をシミュレートすることが出来ます。こちらもどうぞ。また、色盲の人にもわかるバリアフリープレゼンテーション法にある、神奈川県の 『色使いのガイドライン（PDF版）』も良い感じだと思います。

【追記】
大変ありがたいコメントを頂きました。誤訳を指摘していただきました。多謝多謝です。
誠に勝手ながら、有用な情報ですので、転載させていただきます。ご了承下さいませ。

---------------------------------------------------
凄く惜しい翻訳です。
全ては「色覚異常者の見え方」です。
日本には、赤緑色覚異常の第１色覚異常と第２色覚異常と青黄色覚異常と言います。
色覚異常を分けた「中波長領域＝色弱（弱め）〜色盲」が下記のようになります。

Protanopyとは「赤色色盲」
Deuteranopyとは「緑色色盲」
Tritanopyとは「青色色盲」
Protanomalyとは「赤色色弱（弱め）」
Deuteranomalyは、「緑色色弱（弱め）」
Tritanomalyは、「青色色弱（弱め）」
Full colorblindnessとは「全色盲（モノクロ）」
Atypical monochromatismとは「単色色盲（単色明度・モノトーン）」
です。
参考：色覚異常（色盲・色弱）http://www.wakaba-hp.or.jp/eye/eyesick_f/eyesick_13.html
参考：Wikipedia（色覚異常）　http://ja.wikipedia.org/wiki/%E8%89%B2%E8%A6%9A%E7%95%B0%E5%B8%B8

---------------------------------------------------