2006年6月アーカイブ

イベントハンドラは装置に依存しないよう論理イベントをあわせて指定する。

WCAG1.0 の ガイドライン9.　装置に依存しないように設計する 件について。

以前のエントリーではウェブ・アクセシビリティについての問題提起を少々「煽った」ような文章で書いてみたわけだが、コメントにも2chのエントリーにも「はてブ」のコメントにも「マイノリティ」がどうというような指摘が結構あった（Old Macユーザーであることを指して）。そもそもアクセシビリティに関する議論においては「少数派」と「開発コスト」みたいな話題がついてまわるものであるが、例えばマウスを使わずに他のデバイス（ボタン装置やキーボード等）を使っているケースというのはどういうケースだろう。

• 上肢体不自由の人 (注1)
• 音声ブラウザを使っている人
• テレビでウェブを閲覧（リモコン操作）している人
• 携帯電話でウェブを閲覧している人 (注2)

そもそもノートPCでマウスを使えない時、トラックパッドが扱いづらくてキーボード操作する時が（僕の場合は）ある。TabキーとEnterキーでリンクを移動するのだ。

(注1)

IBMのパソコンのキーボードの真ん中にある（何と言う名前かは知らないが）赤いボタン（マウスポインタを移動させることができる）を口にくわえたペンのようなもので操作しているところを見学させていただいたことがある。この場合はキーボードやボタン装置ではなく、マウス前提のイベントハンドラでの操作となる。

(注2)

WCAG2.0（ワーキング・ドラフト） にあるように、将来のことも見据えておかねばならない。

• Principle 4: Content should be robust enough to work with current and future user agents (including assistive technologies)

ということで mouseover 等の物理イベントには onfocus 等の論理イベントをあわせて指定する必要がある。

併記すべきイベントハンドラの例

物理イベント	論理イベント
onmousedown	onkeydown
onmouseup	onkeyup
onclick	onkeypress (注3)
onmouseover	onfocus
onmouseout	onblur

(注3)

Mozilla系のブラウザでは、フォーカスされた状態で Tabキーを押すと onkeypress イベントが発生してしまう。最近のブラウザではフォーカスされた状態で Enter（Return）キーを押すとマウスクリックと同等の動作をするから（MacIEでは動作しない）onkeypress は敢えて指定しないか Tabキーが押された時を例外として処理する等の検討が必要。

具体的には以下のようになる。

<a href="example.html" onmouseover="focusin()" onfocus="focusin()" onmouseout="focusout()" onblur="focusout()">サンプル</a>

長い、美しくない、面倒くさいとかいう話も出るだろうし、ここで「JavaScript and Accessibirity (1). - JavaScriptが前提の機能はJavaScriptで提供する」の考え方を適用する。

JavaScriptで実行したいイベント属性自体をJavaScriptでセットする方向で検討する。

参考：IE の getAttribute / setAttribute: Days on the Moon

JavaScript:

var isIE = (document.documentElement.getAttribute("style")
==document.documentElement.style);
// ブラウザ判別
function focusin(){
document.getElementById("status").innerHTML="Focus In";
}
function focusout(){
document.getElementById("status").innerHTML="Focus Out";
}

HTML:

<a href="example.html" id="tgtElement">サンプル</a>
<div id="status"></div>

bodyのonloadイベントでも良いし、適当な箇所でも良いので、イベント属性をセットするJavaScriptを追加。

JavaScript:

var tgt=document.getElementById('tgtElement');
if (isIE){
tgt.setAttribute("onmouseover", new Function("focusin()"));
tgt.setAttribute("onfocus", new Function("focusin()"));
tgt.setAttribute("onmouseout", new Function("focusout()"));
tgt.setAttribute("onblur", new Function("focusout"));
}else{
tgt.setAttribute("onmouseover", "focusin()");
tgt.setAttribute("onfocus", "focusin()");
tgt.setAttribute("onmouseout", "focusout()");
tgt.setAttribute("onblur", "focusout()");
}

function eventSet(tgt,fnction1,fnction2,fnction3,fnction4,ev1,ev2) として関数を作っておくとか、function eventSet(tgt,fnction,ev1,ev2) として、mouseover指定したら mouseout,　onfocus, onblur を自動的に併せて指定するようなものを用意しておくとシンプルになるだろう。

別にイベント指定をXHTMLの中に直接書いても良いのだが、物理イベントと論理イベント両方を指定するのは面倒だという場合は、ページ内の全てのリンク（document.anchors）をチェックして、マウス前提の mouseover / mouseout 等だけが指定されているリンクに論理イベントを追加するものを作ってやれば、特に意識しなくても気配りできるようになる。

どうせマウス前提のコードをゴリゴリ書いているのだから、こういったスクリプトを一つ書いておけば実装のコストは殆どかからないだろう?

Posted by Junnama (I'm in the Minority)

---

さて、レガシーなブラウザに対する配慮について書いてみよう。

今回の例はMac IE5について。

※MacIE5の話としてだけ見るかどうかはお任せする。言いたいのはそういったことではない。考え方である。

XHTML:

<div id="canvas"><!--Ajax実行結果を挿入する場所--></div>
<noscript><p>代替要素</p></noscript>

JavaScript:
try{
 //XMLHttpRequest対応ブラウザ向けの処理
 }catch(exception){
 //エラーが発生した時の処理
 var UA=navigator.userAgent;
 var UAName=navigator.appName;
 if((UA.indexOf('Mac') !=-1) && (UA.indexOf('MSIE 5')!=-1) && (UAName=='Microsoft  Internet Explorer')){
 //MacIEの処理。この例では noscript要素の内容をそのまま id="canvas" の中に放り込む
 var alt=document.getElementsByTagName("noscript");
 document.getElementById('canvas').innerHTML=alt[0].innerHTML;
 }
}

IE/Firefoxの場合はこの方法でnoscript要素にアクセスできるが、Safari/Operaではアクセスできない。そのあたりの配慮は必要。また、IE以外ではinnnerHTMLをそのまま放り込んでもタグを認識してくれないケースがある。

そもそもnoscriptである必要はなくて、非対応UAに対しては「普通に」その機能を提供しつつ、Ajax対応UAではリッチに、という考え方をする方が望ましいと思う。

<div id="canvas"><p>代替要素</p><!--Ajaxが正しく実行されたら実行結果と置換する--></div>

ちなみに、MacIEの場合 IFRAME を使ってそれっぽい処理を作ることもできる。OBJECT要素ではなく IFRAME を使うのが良いかどうかはともかくとして。

この点については以下のページにサンプルがある。 http://developer.apple.com/internet/webcontent/iframe.html

簡単な例で説明する。以下のようなIFRAMEを用意しておくか、動的に生成する。

<iframe id="RSIFrame"
name="RSIFrame"
style="width:0px; height:0px; border: 0px"
src="server.html"></iframe>

フレームのドキュメントへは document.frames['RSIFrame'] のようにしてアクセスできる。

IFRAME内のソースがロードされたかどうかはフレーム内文書の onload イベントで判別できるから、 Ajaxライクな実装だって可能である。

まぁ、ここまでするかどうかはどもかく (というかやらなくても良いと思う)。

エラーに対して寛容であることが大切なのだ。

---

「続きはまた」とか書いたことだし、少しずつ書くことにする。

Web2.0でもITベンチャーでも何でもいいけどさ、もう少しレベル上げろよ。
http://junnama.tea-nifty.com/online/2006/06/web20it_8b3b.html

イベントハンドラあたりに関する話は2年半程前にKOFで話をしてサイトにも上げたので、そのあたりも見ていただけるとありがたい。

アクセシブルなHTML作成の実際
http://alfasado.net/udon/accesible_html20/index.html

さて、まず最初はこれ。

「JavaScriptが前提の機能はJavaScriptで提供する」

分かりやすい話題だと思うので、最初はこのテーマから。

例えば、

<a href="javascript:window.close()">閉じる</a>

みたいな「機能」を提供する場合、これをそのままHTMLの中に書いてはいけない。

では、どう書くかの例。

(X)HTML:

<script type="text/javascript">
insertCloseBtn();
</script>

JavaScript:

function insertCloseBtn(){
document.write('<a href="javascript:window.close()">閉じる</a>
');
}

別に document.write でなくとも createChild とか innnerHTML とかでも良くて、とにかくJavaScriptが前提の機能はJavaScriptで提供するわけだ。

<a href="javascript:window.close()">閉じる</a>

とか書くと、JavaScriptがOffだと「閉じる」とか表示されるのに「閉じない」という間抜けな状態になる。そもそも「閉じる」ボタンが必要かどうか、という議論があるのかないのか知らないが（僕だったら「やめましょう、必要ないですよ」とか言うと思うけど）、『ここに「閉じる」ボタンを付けてね」とかいうことになったなら、このような実装をする（させる）。

例えばこのページの「閉じる」の実装を見て欲しい。
http://ndl.go.jp/nature/img_r/011/011-03-001r.html

「閉じる」だけじゃなくて、例えばプルダウンメニュー(Selectメニュー) ＋ 「移動」ボタンとかでも、JavaScript が On でなければ動かない機能なのであれば、そいつは JavaScript で提供する（表示させる）。

例えばこのページの プルダウン選択、「移動」ボタンで移動。
http://ndl.go.jp/constitution/shiryo/01/008/008_001r.html

ね、別に難しくないよな。これが「コスト」なのか? Scriptは外部ファイルで一箇所関数を定義するだけだし、かえって楽な気がしない?

続く...かも

# あ、一つ忘れてた。良かったら検討してみてください。「コスト」かけてもいいから、良いもの作ろうぜ。

---

みなさん、さようなら。ブログ連載から降ります。:烏賀陽（うがや）弘道の音楽コラム
http://www.actiblog.com/ugaya/7007

これははっきり言って「原稿料の価格破壊」です

（中略）

ぼくはだいたい2000字はきっちり書いていましたので、400字詰め原稿用紙に換算すると、5枚。一枚あたり何と1000円を切っていた。これはもう、ジャスコ夏のクリアランスセールも真っ青の超御奉仕価格であります。

ＡＦＰＢＢといえば、フランス国営通信社であるＡＦＰと、日本のＩＴ産業の覇者・ソフトバンクがタッグを組んだ、言うなれば日本のインターネットニュースメディアのフラッグシップになりうる存在なのです。

ネットのニュースメディアに「紙」の論理を持ち込むこと自体が間違っているとは思わないのだろうか。

雑誌が一冊出版される。そこには、あるライターが書いた記事が掲載されているが、同時にグラビアアイドルの水着写真が掲載されているかもしれない。アイドルの水着写真だけを目的に雑誌を購入した人にすれば、ライターの書いた記事は無意味である。ある購入者にとってはライターへの原稿料は単に払わされている余分なコストなのかもしれない。

ネットの場合はそうでは無い。少なくともアイドルの水着写真が見たい人はライターであるあなたの原稿を見ないで済むのだ。リンクだって今どき「当ニュースサイトへのリンクはトップページにのみこれを許可」とか書いてあるかどうかは別としてみんな該当のページをブクマしたりリンクしたりしているわけである。

逆に、ライターであるあなたの原稿も、水着写真の有無にかかわらず評価されるのだ。あなたのページには直接リンクが貼られ、言及され、トラックバックされ、ブックマークされる。

本当はあなたの原稿が読みたいのに、水着写真のモデルやカメラマンへのギャラを払わされている購読者にすれば、あなたの原稿だけを切り取って読めればそれに越したことはない。本屋であなたの書いた原稿が掲載されたページを切り取って買うことはできないが、ネットではそれができるのである。

印刷代（ネットメディアにしても　『わずかな』インフラコストが必要だが）、物流コスト、宣伝費、編集者のコストや出版社の利益等がかからないことを考えると、いわゆる「マージン」が不要になり、読者へ直接届けるためのメディアを持てるのだから、別に（本当にあるかどうかわからないような）「メディア」の権威等に中間マージンを払うこと無く、自分でメディアを持てばよいのではないかと思う。

原稿料なんてAdSenseでもアフェリエイトでも何でも稼げるではないか。

例えば雑誌メディアに製品のレビューを書いてくれって言われて執筆するのと、自分のBlogに製品レビューを書くのにどんな違いがあるっていうのだ。自分は文章で食っている人間なのだし、文章のクオリティに自信を持っているプロのライターなのであれば、それがどれほどの稼ぎにつながるかについて情報を集めることくらい簡単ではないか。
（「AdSenseやアフェリエイトでどのくらい稼げるのか取材対象を見つけて、取材記事書いてくれませんかねぇ」とか言われたら、それなりに調べるでしょう?）

例えば以下のエントリーあたりを参考に、必要ならば取材をしてみるとか。ネットでの情報収集、真偽の判断、必要ならば取材、ウラ取り。ライターの方の得意な分野ではないだろうか。

表現者と「ウェブ進化論」：住 太陽（スミ モトハル）のブログ。
http://www.motoharusumi.com/jobs/clarifying_the_web/communicator_and_the_evolutionism_of_web.html

この結果、僕がこの種の広告収入で得るお金は、2005年9月に既存のサイトにAdsenseを貼り付け、その当月にいきなり980ドル程度の報酬を得たところから始まり、その後のアフィリエイトへの参加などで報酬は増え続け、今では月間70万円程度に達し、今も増え続けています。

しかし、そもそも掲載されている媒体で媒体のギャラが尋常じゃないから降りるなんて記事がよく掲載されたなぁ。確かにアクセスは稼げるかもしれないけど、この原稿の掲載を許可したメディアの担当者は何を感じたのだろうか。

たけくまメモ：フリーにとって原稿料とは何か（１）
http://takekuma.cocolog-nifty.com/blog/2006/06/http.html

でもまあ、フリーライターがこういった「組織の内情」を、当の組織が運営しているメディアで暴露するのは、相当な決意が要ったでしょうし、その覚悟には敬意を表するにやぶさかではありませんが

「決意が要った」のは掲載したメディアの側じゃないかと思う。

---

『プロな人』と『アマな人』の違い：Web2.0ナビ
http://sengoku.blog.klab.org/archives/50318048.html

『プロ』と『アマ』ではまったく考え方が違う。プロ野球選手とアマの野球選手では野球の能力は確かに違うだろうが、それ以上に野球に対する精神的な考え方が違う。

このエントリーへのトラックバックやはてなブックマークでも肯定・否定色々なわけですが。

シンプルに「プロ」と「アマ」を分別するなら「カネを稼ぐための行動を一貫してとれるか否か」というのは前提にならないのだろうか。
僕は「プロ」「アマ」の違いってその一言で片付くと思っているのだが。

• できない言い訳をする（アマ）出来る方法を考える（プロ）
• 現状に満足する（アマ）チャレンジする（プロ）

出来ない言い訳をしても「カネを稼げない」、出来る方法を考えることで「カネを稼げる」。
現状に満足しても「稼げるカネは増えない」、チャレンジにより「稼げるカネが増える」。

拝金主義みたいに思われてしまうと心外だが、このようにシンプルに考えることで「プロ」の行動というものがはっきりするのだと思う。もちろん人によっては「プロ」の行動を無意識にやっている人がいるのだが、客観的に「何故あの人がプロなのか」を評価する時、「カネ（成果と言い換えても良い）」に責任をもち、成果をあげる行動を取っているかどうかが一つの基準になる。

• 仕事を楽しめない（アマ）仕事を楽しむ（プロ）

これはちょっとどうかと思うが、楽しむかどうかは付加的な問題であり「プロ」は楽しかろうが楽しくなかろうが結果に向けて最適なアプローチをとるものだ。

• 批判をする（アマ）行動を起こす（プロ）
• 時間を浪費する（アマ）時間を効率的に使う（プロ）

同じく、批判をしようがどうしようが関係ない。行動を起こさない（アマ）行動を起こす（プロ）、なわけだが、これでは確かに面白くも何ともないわな。
時間にしてもそう。時間を浪費するより効率的に使った方が、より成果をあげられる。あたりまえ。

• 約束を守らない（アマ）約束を必ず守る（プロ）

約束を守らない人間に次の仕事はない。だから「継続して成果を出し続ける、継続して稼げる」人は約束を守れる人だ。これもあたりまえ。

ビジネスの現場では「アマ」は「退場!」である。

だから、「アマ」のことなんかどうでも良いではないか。
シンプルに考えよう。「プロ」として行動し、「プロ」に相応しい待遇を得よう。

---

MacBookを買ってから、まずはメールのデータを移行して仕事ができる状態にし、二週間程が経過。Webとメール、MS Officeが使えれば取り敢えず仕事になるのだが、この週末にようやくあれこれと触ったり環境整えたり。

アプリケーションはMacOS9からの移行なのでPhotoshopは7はそのまま（Universal Binary対応になったらアップデートすることにして）、Illustratorはバージョン10がインストールできなかったので（インストーラが落ちる）、CS2のアップグレード版を購入してインストール、MS Officeは新規購入（Virtual PC が Intel Macで動作しないのをチェックし忘れていたのでPro版を買ってしまった。Win XP ProをParallelsかBoot Campに放り込むのはありなのだろうか(ライセンス的には駄目なんだろう)）。
Apple Works と REALbasic4.5は旧マシンからそのまま移行。

• Microsoft Office 2004 for Mac
• Adobe Photoshop
• Adobe Illustrator
• Apple Works
• REALbasic

MS Officeをはじめとして、インストールしたアプリケーションは僕の知っている旧来のMacintoshのアプリケーションである。仕事のためにはそれはそれで必要なのだが、MacをMacたらしめているのはMacBookに付属しているAppleのアプリケーション群である。まだ使い方もわからないのだが何となくダブルクリックして立ち上げてみて（AppleのWebサイトなんかを見たりして）、これはもはや僕の知っているパーソナルコンピューターではないのだという実感が。

自分自身、コンピューター（Mac）を使うことに関してリテラシーは高い方だとは思うのだが、ちょっと見る限りこいつら（iLife '06 - iPhoto, iMovie HD, iDVD, GarageBand, iWeb）は全然分からない。異文化である。この歳になって新しくアプリケーションを覚えるにはエネルギーも時間もないけれど、若い頃に出会っていたら全然違っていただろうな、と思わせるものがある。その昔、Avid Cinema で映像編集したり MIDIGraphy でサウンド作ったりしたもんである。あの頃のエネルギーを今かけられたら面白いだろうなと思う。

むしろこいつを小学生くらいの子供に与えてみると面白いのではないかと考えている。iLife等のアプリ群だけじゃなくて、TerminalからCUIで使わせてみたりアプリの開発とかさせてみたりしたら面白いだろうし、すぐ覚えていくんだろうなぁ。

MacOS X自身もそうだが、現在のMacっぽさと旧来アプリのデザインの違いが良く分かるのが iCal と Microsoft Entourageを比べた時である。

MS OfficeやIllustrator等の旧来型のアプリケーションは外観はOS Xになってはいてもやっぱりひきずってしまっている感を拭えない（仕方がないんだが）。

Appleのソフトを参考にして、またデスクトップアプリを作ってみたいと思う今日この頃である。

世間的にはワールドカップなわけですが。

「古館さん」（ドイツと中継がつながっている）

（2.5秒程間があって）

「はい...」

呼びかける方を2秒程遅らせたら（映像と音声を）自然な会話になるのに。簡単なことだろう? 2秒の差が気になるくらいのリアルタイム性を求めているわけでは無いのだ。これこそが「ユーザー体験」ではなかろうか。

もう一点。『映像を見る』対象デバイスはすごく広がっている。50インチのハイビジョンディスプレイと数センチ×数センチの「ワンセグ」と、同じ映像で良いのか?

以前から思っていたことだけど、野球中継とかサッカー中継っていかんよな。スタジアムで見るスポーツの美しさってね、例えば外野の間を白球が抜けていく瞬間にプレイヤーたちが一糸乱れぬ動きを見せる（フォーメーションの美しさ）、中継プレーのために自分のいるべき場所にポジショニングするっていう「引いた映像」でこそ得られる美しさってのがあるわけで。

いいかい? 選手の顔のアップなんて現場ではどうでも良いわけだ。あり得ない。

テレビも結局職人の世界なんだなと思うのはこういう時である。時代が変わっているんだから、変わろうよ。

テレビはWebに学ぶべきだよ。もっと。

『制約と変化に適応する美しさ』がWebデザインにはあるのだ。

技術をウリにする会社に必要な人種について。

アイディアを出す人、その実現を技術で支える人、作ったものを売る人：仙石浩明CTO の日記
http://sengoku.blog.klab.org/archives/50318048.html

技術をウリにする会社は、 その立ち上げメンバに三種類の人種が含まれていることが必須なのだと思います。 すなわち、

1. 湯水のように新しい事業アイディアを思いつくアイディアマン
2. アイディアを実際の製品として実現する技術者
3. 完成した製品を売る戦略を立案し実行するマーケッタ

さて、一方でGoogle。

街のスケッチ: アイディアだけでは評価されない会社
http://www.ooba-office.jp/sketch/post_84.php

アイディアの起案自身というのはほとんど評価されない。アイディアっていうのは当然、難しい問題を含むものだ。その問題を解決して、動く形にして初めて評価される。

• 売れるか売れないかのマーケティングが十分に出来ないアイデアマンなんて価値のかけらもないし、「素晴らしい」アイデアがあっても技術的に実装できない人は役に立たない。
• マーケットに対して理屈をこねるだけで、マーケットにアピールするためのアイデアも無く製品化する技術も持たない人は役に立たない。
• 「俺は製品を作る技術は持っているぜ」と言ってはいるが、どんなアウトプットが市場に受け入れられ（結果）製品が売れるかをイメージできない技術者も役に立たない。少なくとも会社を立ち上げるにあたっては。

必要なのは「バランス感覚」「客観的に自社（技術・製品）を見つめる厳しい"目"」である。
本当に優秀な技術者は顧客の前でいとも簡単に自分たちの製品を売ってしまうものであるから、場合によっては専門のマーケッタなんてものは不要なのだ（もちろん、単なる「アイデアマン」も単なる「技術者」も不要だ）。

---

わたくしごとで恐縮だがね(blogってそういうもんだよな)、この間MacBookを買ったんだ。もちろん黒い奴さ。メモリは目一杯。2.0GBだよ。この間の土曜日、銀座のAppleストアで買ったのだ。

で、言いたいのはそういうことではない。別に自慢する訳じゃねぇぜ。言いたいのはMacBook、というより新しいマシンを購入した理由なのだ。

オッサンはね、今や化石のようになったMacOS9のユーザーだった。DTPやってるわけじゃなくてWeb屋なんだが、エディタをはじめとして色んなツールを自作で作っていてそいつをOS Xに移行できなかったから、今のいままで移行に踏み切れなかったんだ。

ところが数ヶ月前からPowerBook G4(867Mhz)をOS9、OS 10.4のデュアルブートで利用するようになった。

Webが使えなくなったからだ。

レイアウトが崩れるくらいならまだいい。ブラウザがJavaScriptエラーを吐いてフリーズするのだ(JavaScriptオフにすると今度はウンともスンともいわねぇし)。

ちなみにそいつは有料のサービス(求人系サイト、某SNSの会社のサイト、ね)で、こっちは一応まがりなりにもお金を払ってるクライアントユーザーなのだ。先月は20万円強、年間にしたら結構な額を払っていると思うがね。

で、その使えねぇ求人サイトのオプションに、某SNSでも告知するよってなオプションがあって、そいつに申し込んだのだ。で、OS 9のIEじゃ固まるわけだから、OS10.4でSafariでアクセスしたら、駄目なんだよ。途中で求人広告が切れちまう。で、問い合わせしたわけ。「対象外です」だと、見事だね。

MacIEについては、もちろんそのサイトだけじゃない。他のサイトでも Ajax使ってる系は全滅。そーしゃるぶっくまーくとか、りっちなちずさーびすだって、大抵は駄目である。Ajax の「http_request」がMacIEで駄目だから、まず確実にここでエラーになる。エラーはともかく、固まるなんて反則ではないか?

MacIEがタコだからとかサポートがどうこうだとかそういう問題ではない。断じてない。
Web屋は例えばNetscapeNavigator 4.x のCSSのバグがひでぇから、みんな media="all" とか書いてNetscapeNavigator 4.x にはCSSを読ませないようにしているんだ。これは「切り捨て」なんかじゃないぜ、断じて違う。CSS読ませたらブラウザ落ちたりフリーズしたり平気なんだから、問題なく伝えるためにそうするんだ。

じゃぁ、MacIEに Ajax 解釈させないようにするには? ちょっと書き足せば済むじゃねぇか。

だいたいさぁ、配慮が足りないわ。話は変わるけど、例えばホームページリーダーってものもあるんだよ、世の中にはね。知ってる? 気にしたこととかあるかい?

ちょっとだけさ、正しい対処法を教えてやるよ。若いキミたちに。

この間、Ajaxの案件でね、MacIEどうしましょう? ってウチのスタッフに聞かれたから、「http_request」のところでエラーがでたらそいつを拾って、非対応ブラウザには noscriptの中身を放り込んでおいてくれ。エラー? try ,catch で拾えるだろ? っていったんだ。それで? 全然問題なし。MacIE使ってても、「あ、こうなんだ」ってなもんさ。最初からそれが普通に見えるし、別に差をつけられたなんて思わない。

まちがっても、

「このページは Ajax対応のブラウザでご利用ください」
「このページは　最新のブラウザに最適化されています」

とか書くなよ、いいな。
動きはどうあれ、見ている人が気にしないで同じ情報が得られるように設計するんだ。気にさせてどうする。

それって、

「音声ブラウザのユーザーの方はこちらから本文へジャンプすることができます」

って書くのと同じだぜ。え、どこがいけないんだって? 本当にわかんねぇのかい?

話変えるぜ。ホームページリーダーではAjaxとかどうかって?
ホームページリーダーはさ、Win IEのエンジンを使ってるし、JavaScript(JScript)はきちんと評価され反映されたものを読み上げるからね、動的に画面の一部とか切り替える場合とか下手な実装やったら理解できない可能性あるぜ。気にしたことあるかい?

じゃぁどうすればいいって? 自分で考えろよ。一回読み上げて使ってみろよ、な。

持ってねぇしわかんねぇ? いちいち世話焼けるな、まったく。どっかWebに情報落ちてねぇかって? 横着いっちゃいけねぇけどさ、仕方ねぇし、今度オッサンが教えてやるからちゃんと耳かっぽじって聞きな。ってか、「Webに情報落ちてねぇか」とか言う前に、

まず考えることだな。
あなたの作ったサービスをどんな人がどんな気持ちで使っているか、を。

# 続きはまた...

追記：NiftyのWebメールが2.0になってる...さて、最新のMacBookだし、今まで駄目で悔しかったけどこれでって...あ、駄目ですか、Mac。

※6月17日追記：
少しずつですが、具体的に書くことにしました。
http://junnama.tea-nifty.com/online/2006/06/javascript_and_.html

---