MT plugin Jaccessibility (続き).

近々公開しますが、ネーミングを考え直した方が良さげな気が。

MovableTypewoCMSとして使うにあたって...便利な機能が満載でございます。

MT plugin Jaccessibility (β3).

• 設定をBlog単位で行うように変更
• サムネイルを作成したときのリンクHTMLの生成が正しくなされるように修正
• アップロード関連のインターフェイスを便利に
• アップロードしたファイルへのリンクパスを置換できるように
• 管理画面のフォントサイズを拡大できるように(*)
• その他細かなチューンナップ

* BigPAPIがインストールされていると効かない。
* その他の機能についてはMT3.3であればコンフリクトしない筈。

MT Plugin Jaccessibility

設定はこんな感じ↓。

MT plugin Jaccessibility (β2).

アックゼロヨンの懇親会の時にも話してしまったし、当面こいつを使い物になるまで仕上げようかと思っている。前のエントリの続き。

MT Plugin Jaccessibility

眠い...ので、何が変わったかは明日にでも。

少しだけ告白? すると...

エントリの本文を選択→画像を選択→アップロードされ、タグが挿入される

※選択された本文のテキストが画像のAlt属性になる

アップロードがすごく楽になるのだが、保存場所がデフォルトだと何なので、プラグインの設定で保存場所を指定できるようにした。

ね、ねむい...ので続きは明日にでも。

MT plugin Jaccessibility (β).

10月30日23時追記：アーカイブに不具合がありました。
修正分をアップ済みです。

プラグイン作りました。お勉強がてら? くらいのレベルなのでテスト協力いただけると嬉しいです。

多分? UTF-8 でスタティックなファイルベースで運用している環境であれば問題なく動作すると思います。MT3.3限定です。

ダウンロードはこちら↓。MTの plugins フォルダに放り込めば使える筈です。

MT Plugin Jaccessibility

何が出来るの?

• ファイルアップロード時に画像のalt属性を指定できるようになります。 (画像参照 ＞ MTデフォルトだとaltにはファイル名入るんよね)
• アップロードしたファイルを編集中のエントリに埋め込めるようになります。
• エントリをW3C Markup Validation Service/Another HTML-lint で文法チェックできるようになります。
• 以下の設定ルールに従ってテキストや見栄えを変更することができます。
  • jaccessibility="1"=>通貨の書式を変換する（円,ドル,ユーロ）
  • jaccessibility="2"=>スペースによる日本語文章の分割をしない
  • jaccessibility="3"=>日付・時刻の書式を変換する (年,月,日形式)
  • jaccessibility="4"=>マウス依存のイベントをキーボードでも操作可能にする (つまり、onmouseover 等には onfocus等 を強制的に加える、っつーもの)
  • jaccessibility="5"=>文字を大きくする (200%)
  • jaccessibility="6"=>ハイコントラスト表示 (背景黒、文字を白) にする jaccessibility="0"=>1〜4の設定を有効にする
  • 属性はカンマ区切りで複数指定できます。全てを有効にするには例えば (<$MTEntryBody jaccessibility="0,5,6">) とします。

5,6 はおまけみたいなもんです。MTのテンプレート触れるなら直接CSS書いた方が早いですしね。

名前からすると「アップロードしたファイルを編集中のエントリに埋め込めるようになります」ってのもおまけですが、自分としてはこれが結構便利かなと思ってます。

ちなみに、管理画面いぢくりまくっててますが、BigPAPI入ってても動きます (ってことで、MT3.2対応も可能かな?) 。

以下、メモ。

Transfomer プラグイン書いていて BigPAPI とのコンフリクトが気になっていたのですが、
MT->add_callback('MT::AppTemplateSource は BigPAPI と衝突するんですが、
MT->add_callback('MT::App::CMS::AppTemplateOutput は衝突しない

ということで、基本 AppTemplateOutput に対して置換をかけています。

つまり、MT->add_callback('bigpapi::template::...に置き換えればMT3.2＋BigPAPIでも動くかも?

JavaScript and Accessibility (3).

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

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)

---

JavaScript and Accessibility (2).

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

今回の例は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ライクな実装だって可能である。

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

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

---

JavaScript and Accessibility (1).

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

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は外部ファイルで一箇所関数を定義するだけだし、かえって楽な気がしない?

続く...かも

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

---

Web2.0でもITベンチャーでも何でもいいけどさ、もう少しレベル上げろよ。

わたくしごとで恐縮だがね(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

---

それ、本当に赤色？

建築を学んでいるという学生さんからメールをいただいた。

CADやCGに課題で取り組んでいるそうなのだが、色盲のため「青だと思って選んだのが紫だったり、黄色だと思ったのが実は違っていたりして」色を使うことが段々減っていったそうだ。

以前に作成したソフトウェア（Color Quest＝ディスプレイ上の1点の色の名前をことばで表示するソフト）を見つけてくれて、メールの最後には「色に立ち向かっていきたい」と書いてあった。

ソフトを作っていて本当に嬉しいのはこういう時だ。

このソフトを作る時には、色々勉強もしたけれど、色んな人が知恵を貸してくれた。色の名前に著作権がある（らしい）という話しもあって（結局確かなところはわからなかったけれど）、表示を「系統色名」にした、とか。

そういえば、最近作ってない。もちろんWebサイトを作ったり、という形で仕事でモノづくりをしているわけだが、やはりユーザーの人からダイレクトに反応をもらえる喜びとか、本当に小さなことだけど人に喜んでもらう喜びってのは、何ものにも代えがたい。

まだ、時間ができたら再開したいと思う。

こんな感じで色の名前を表示します↓。Macユーザーで色の件で苦労している人には是非使って欲しいと思う。

ダウンロードはこちら。フリーウェアです。
→http://alfasado.net/udon/tools.html

ちょっと探してみたら、こちらのエントリーのコメントでもご紹介いただいていました。

色覚異常・色盲・色弱・色覚障害・色覚特性・・・についてのあれこれ
→お役立ち情報？<http://colorblind.exblog.jp/1276413/>

ミスをリカバリできるのも良いシステムの条件。

よく読まないと何のことだかわからないんだが、「単に入力ミスは怖い」という話ではなかったようだ。

東証 : 投資家及び関係の皆様へ -１２月８日のジェイコム(株)株式の注文取消処理に係る株式・CB売買システムの不具合について-
http://www.tse.or.jp/news/200512/051211_a.html

午前９時２７分、ジェイコム株式に対し、みずほ証券が６１万円で１株の売注文を、１円で６１万株として発注いたしました。その際、同銘柄は６７万２千円の特別買気配を表示中でしたが、当該売注文により約定成立要件が整い、売買が成立しました。ただし、今回の売注文が大量で初値成立後にも残っていたため、残存分は初値決定により設定された呼値の制限値幅の下限である５７万２千円の売注文として登録され（詳細は後述いたします）、大量の買注文と間断なく順次約定していくこととなりました。その過程で、みずほ証券から当該注文に対する取消注文が発注されましたが、そのような例外的状況において生ずる不具合が売買システムに存在したため、取消しができずにその後も連続対当により約定が順次成立することとなりました。

「不具合」と言い切っているのだから、これは「不具合」なのだろうが、とにかく「ユーザーはミスをおかすものである」前提で「ミスが致命的な影響につながる可能性がある」システムにおいては、あらゆる事態を想定しておかないといけない。

「こんな値が入力がされるわけがない」という凝り固まった考え方や「エラーは自動的に機械の側で修正し、ユーザーはそれを意識させないことがユーザビリティの法則なのだ」といった意識にとらわれること、また逆に「簡単に「警告」を出しすぎてユーザーがろくに読まない習慣がついてしまい、形骸化した「警告」になってしまう」ことなど、考えなければならないことは本当に色々ある。

人間はミスをする。

「ユニバーサルデザインの7原則」の5項目めにも「ミスに対して寛容」(Tolerance for error) という項目がある。何もユニバーサルデザインやアクセシビリティは障害者や高齢者の為だけはなく、あらゆる人間の助けになるのだということを改めて意識したい。

What is Universal Design- Principles of UD
http://www.design.ncsu.edu:8120/cud/univ_design/princ_overview.htm