とっぷぺーじ
ねこめしにっき
2003/05/中旬
2003/06/上旬
大須にいったついでに、携帯電話を変えてきた。前のやつはもう 3 年以上使っててバッテリが完全にヘタレておりまして、 3 分以上の連続通話が不能という状況だった。
んで、ぼく的には携帯電話ごときにコダワリは無いので、 0 円で機種変更できるヤツからテキトに選んでオシマイ。カメラとか付いてませんが何か？ i-Mode なんぞも全力で不要だし、携帯でメールなんかできなくてもいいんだけどなぁ…。
iBook 買っちまいますた。わーい。前モデルの一番下の G3/700MHz で CD-ROM なやつ。アポーの呼称でいえば iBook (Opaque 16 VRAM) ていうやつ。新モデル発売につき絶賛値下げ中だったヨ。…しかし、またしてもひみつ資金（謎）が…。
とりあえず AirMac カードも中古のやつをゲトしてケーブルひも付きから逃れ、ベッドに寝っ転がり IRC しながら Rendezvous で iTunes でお気楽ジュークボックス端末状態♪♪ とかしてみた。
いやー Rendezvous すごいですね、とか今更言ってみたりして。 iTunes のこないだのウプデータンで、 Rendezvous のプレイリスト共有（ほぼ音楽ファイルの自動共有システムそのもの）できるのは「同サブネット内に限る」となったらすぃのだけど、自分的には別に問題ないわけで。
ウチには前から、オカーチャンの VAIO のネト接続のためだけに無線 LAN があった次第。アクセスポイントは I-O DATA の WN-B11/AXP 。 AirMac なマクからでも問題なく繋がるわけなのだけど、ただ、 WEP 暗号化すると繋げられないのがちと。不正接続対策は従来どおり MAC アドレスによる接続制限でいいとしても、空中を漂ってる電波をキャプチャされたらイヤンだなぁ。うーむむ。
実は WEP 有効時でも AirMac から繋ぐ事はできるっぽいス。そのへんは「AirMac で WEP 有効な無線 LAN ネトワクに繋ぐ件」にて。
しかしやっぱし、 JIS キーボードがどうにも嫌だ。ほんとにいやだ。憎んでさえいます。わらい。それに加えて、世の中の多くのマカとちがってボクは、 Ctrl キーは SHIFT キーの下じゃないとイヤなのだ。それについては uControl で Ctrl と Caps lock を入れ替える設定で逃れるとして、記号系の配置が違うのも耐え難きを耐えるとしても、 Return がクソ遠いとか、かなだの英数だのジャマなキーが多いだの、 US 配列キーボードならほぼ全アプリで有効なウィンドウ切り替えショートカット (Cmd + ~) が使えない、などなどの強い不満はどうにもならず…。しかし交換用の US キーボードはなぜか 2 万円近くするという…。うーむむ。
あ、モバイル接続のアレコレをどうにかする資金までは無いので、外を持ち歩いたとしても相変わらず外出中はほぼ IP Unreachable という。
「CSSでイケてるデザインサイトリンク集 (Gecko サムネイル版)」のサムネール画像について、ラクガキgarden の結城美夜さんから、苦情というか問い合わせを頂いた次第。
今回のはありみかさとみさん作成の、Gecko版。これでちょっとした疑問が。このサムネイル、バナーが新しいオレンジのやつになってるので、Orange*Loungeに改装後のもののはずなんですが、ここでのスタイルは何故かYIN YANGのまま。改装後、推奨CSSはOrange*Loungeで(ちなみに固定CSSはカラ)、YIN YANGは代替に回っているので、何故こういう事になっているのか疑問。
[ 謎サムネイル - DIARY - ラクガキgarden (2003/05/25) より ]
スタイル切り替えスクリプトの動作をトレースしてみてください。
ねこめしにっきヘッドラインmain() 関数内 window.onload=fInit; によって、ページの読み込みが完了した際に
fInit() 関数が呼ばれる。fInit() 内で、処理は fGetStyleTitles() 関数へ飛ぶ。これは、ページに適用されているスタイルシート群のタイトルを配列として、グローバル変数 sfTitle へ格納する関数。insertform 変数（スクリプト利用者が自分で設定しておくフラグ）が true であれば、 fAddForm() 関数へ飛び、targetelement 変数に設定した要素名の要素位置に選択メニューが挿入されるわけだけど、insertform は false のままなのでそれは行われない。body 要素内から changess2.js が呼ばれてる。この外部スクリプトファイルの中身は fWriteForm(); の一行のみ。JavaScript においては、グローバルな関数や変数は「ページ (HTML) に対してのグローバル」な扱いであるので、これは changess.js 内の fWriteForm() 関数を呼ぶ事となる。fWriteForm() 関数は、標準 DOM 的処理 (←非標準の innerHTML を使用してる故に「的」と表現）で選択フォームを「追加」する fAddForm() 関数とは違い、 document.write で「タグをベタに書くレガシーな方法」で選択フォームを表示する物。ところが、この changess2.js の実行タイミングは、それを呼び出してる HTML 部分 (script 要素が記述されてるあたり) の読み込みがなされた時。つまり：
sfTitle の取得はページロード完了後
sfTitle を参照しながら選択メニューを表示する fWriteForm() の処理実行はページロード完了前
よって、 fWriteForm() の処理が行われるその時には、 sfTitle 変数はまだ定義されていない。値がカラなのではなくて、変数自体が未定義。ゆえに 150 行目、sfTitle[i] のループを行おうとした瞬間にスクリプトエラー発生、 Gecko ブラウザではスタイル選択メニューが表示される事は永遠に無い。
fInit() 内の処理、クッキーの呼び出しとそれによるスタイルの動的変更処理部分は、ドッコイまだ生きてる。以前食べた（とおぼしき） "YIN YANG" スタイル選択状態のクッキーが効いてたようで、新スタイル提供開始後も依然として "YIN YANG" スタイルへ自動切り替えが行われていたらしい。…と、このような案配でして。スタイル選択メニューが見あたらないし、何事もなく普段通りの（というか実際は「以前通りの」であるのだけど）スタイルで表示されている事、などなどによって、新作がデフォスタイルになっていた事にまったく気づいてませんでした（笑）…という。
てなわけでクッキーを捨ててから、サムネイルをゲット＆作成し直したです。
このスタイル切り替えスクリプトは結構よく見掛ける物なのだけど、どこで配布されてる物か実は知らないという。これ、 Gecko 系ブラウザでページ内容がまったく表示されなくなる時がある、っていう例のスクリプトですよね。なんというか、それ以外にもスクリプトソースに一言二言言いたい箇所があるような、無いような（笑）。 innerHTML や document.write を使ってる件については、 Opera 対策で致し方無いのだろうから、それはいいのだけど。
「OSX の Script Editor はデータフォーク保存型だった事にいまさら気づくの巻」で述べた、 mi で作成したコンパイル済み AppleScript ファイルに対して AmScriptFileCMX で「旧 OS 互換形式に変換」を行うとファイルが壊れる問題が、修正された模様ー。
- バグ修正：mi で編集・保存したスクリプトファイルに適用するとスクリプトが壊れる
- リソース 'scpt' を持つファイルを操作対象から除外する。
という事です。良き哉。
実は先日、首後ろのデキモノがまたぞろ腫れやがりまして、またしても禁錮約 3 日の実刑判決が下っていたのでした。いあ、入院のことなんですが。てなわけで、今日からニコニコ楽しい服役生活でっす！やったね。ガクリ。
なんつーか前回の入院生活で痛感したのは、身柄を拘束された上に日がなすることが無くてとても苦しくって、これはもう刑罰以外の何物でも無いゾとか思った次第でありましたユエ。
しかしこのまま手をこまねいていては、また「すること無し地獄」になるだけなので、友達から古いノーパソを借りましたというか、もらいましたというか。わはは。バッテリーが死んでるのでコンセントひも付きじゃないと生きられないし、ネット接続環境も無いのだけど、これさえあればニヤリ。今、暇つぶし用の遊び道具を貯め込んでる所。
こないだの入院＆手術のときに切開し忘れられてたというオチ。たのむよマッタク。で今回はさほど大事ではないのだけど、やっぱ首ってことで、家に帰して「傷口からまさかの大流血」とかの惨事が起きたらヤベェ！医療過誤だ！みたいな罠にハマりたくは無いセンセイ的には、病院に身柄を拘束しておくほうが何かと安心ということで、禁錮刑という。あーあ。
ちなみにWeblogとは英辞郎によると、
一つのWebサイトに一定期間記録されていく、ある特定の話題に関する日記形式の投稿です。秀逸な訳だと思います。特定のツールによるある特定の機能をもっていないものをWeblogに非ずとしている阿呆（あほう）がいますが（日本）、まあこの程度の意味なのでその辺一つ宜しくお願いします。
[ リンク集 - XSL Transformations（XSLT） - - Personnel より ]
笑った。
なんつーか、そのツールで何をヤるかではなくて、ツールを使ってることそれ自体が大事なんだろなーとか。要するに、ファッションってやつ？なんかマカーにも「ファッションマカー」な人々が古くから根強くいますが、たぶん似た傾向の持ち主なんだろな。
「ウェブヘルパー v1.0 に対する所感」の続き。
β版の間にもっとつっこんでおけばよかったなあ、と言っても私には役に立つ的確なツッコミをする能力は今も昔もないわなぁ、と振り返りつつ、皆さんの検証ぶりを集めて参考にしてみる。
なんつーか、やっぱ、「アドホックに能書き説明を大量に添えたり、その場で可能な選択肢を全て提示することで、ユーザビリティは向上する」なんて考えてるのが嫌だ。みんなのウェブ自体も、ウェブヘルパーアプレット自体も。
それは一番簡単に出来ることだけど、ただゴチャゴチャになるだけ。即効性は多少あるにしても、そこには持続性や発展性が無い。
中長期的に一番効果があるのは、要素を整理してシンプルにし、そのシツコイ繰り返しをユザに提示することで、体系を字面で説明するのではなく概念として掴ませ、可能選択肢をユザ自身が適切に見つけられるようにする事。
アクセシビリティに関しては、その向上ための説明や能書きをいくらクドクド大量に添えたとしても、その情報にたどり着けない限り意味が無いぞと。「線形化して意味が通るテーブルならレイアウトテーブルを使っても良い」とされてるにしても、政府のアクセシビリティ推進サイトが率先してそーゆー安易な逃げ道をひた走るってのは、どうなのよ。
例によって BS も CS も無いわが家では TV 中継を見れなかったわけだが。のこり 7 分までリードしてたのかよー。もったいねー。
んでもまぁ、本来ならラストゲームになるはずだったイヴォ王子と、地味ながら頼りになる中村が出場停止、そのうえケガ人病人がやたらと出てた状況で、首位ズビロ相手のアウエー戦。どうかんがえてもグラハチ超不利の状況だったし、引き分けできただけでオッケー。で、いまだ負け無しってスゲェなオイ。… 6 引き分けだけど（ワラ
この最高の状態で 1 ヶ月の中断か。グラハチて好調がホントに長続きしないのが伝統で、こういう長いブランク開けの頃にはヘタレに戻っているのが毎度のパタン。うぐ。
ちうか、 2 ステージ制っていつまで続けるんだろ。ひとステージ短すぎ。優勝の重みなさすぎ。なんだかなぁ感が。
「Webnail AppleScript」の続き。
ちうわけで。
ハードコアでストリクターな CSS スタイラーサイトの製作者に、いくら WinIE の表示具合を不愉快に思う人も多いとはいえ、わざわざ Gecko でのサムネール一覧を作らんでもいいでわないか、という意見多数。そもそもサイトのサムネイル一覧なんて、二回三回見ようってもんじゃない
わけだし。これも手段の目的化の産物で。あのーそのー。
拙作 Webnail AS は、 288 ページのサムネール取得処理に 1 時間以上かかりますが、何か。
「CSS なサイトをサムネールでドババ (2)」の続き。 Camino とグラフィックツールを連携制御して、たくさんの Web ページの画面サムネイルを撮る AppleScript アプレット、とりあえず完成ということで。
配布ページの文書自体は明日以降に書くとゆー。もう眠いしー。だいたいのところは同梱の README に書いておいたからいいっしょ。
キャプチャしたスクリーンショットの切り抜きと縮小と JPEG/PNG 保存に、超定番シェアウエア GraphicConverter を使ってるわけなのだけど、それ以外に、国産のフリーウェアな OSAX、GraphicsImporter も使えるようにしたです。…した、というか、アプレットをそれぞれに分けてるんだけど。
じゃあ Camino じゃなくて Safari を使う版も用意すればいいじゃん、とか言われそうな。しかしー、これを作る経緯的に、それはちとあり得ないってゆーか、自分のメインブラウザは依然カミーノたんなのでして。 AppleScript 対応度は、そこはアポー純正である Safari に分がありそうなのは承知なのだけど。
ちうかこんな、ほとんど実用にならんお戯れアプレットなんか、どうでもいいか（笑） 本来の用途目的よりも、そーいうアプレットを仕上げるんだーとかいう手段の目的化というか、趣味的活動のほうが比重が大きくなったという。
「CSS なサイトをサムネールでドババ (3)」に続く。
[ アクセスログの誤爆リファラ（笑） 経由 ]
…か、かわうい。いかにも萌えるあかぬけない髪型とか服とか、萌えー萌えー。雪菜たん（誰）もこんなおにゃのこに育たないかなぁ（謎）。いや将棋は指さんでいい。ちうか駒の動きかたさえろくに知りませんが何か。
香奈たんの視線を独り占めしてやがる手前の小汚いクソオヤジ、そこをどかないとブチコロスゾ（笑顔
We've decided to stay and fight on the Mac platform,Opera Software representative Pal Hvistendahl wrote in an e-mail.Tomorrow we are releasing a new version for the Mac.
[ Mac Opera escapes limbo | CNET News.com より ]
てなわけで、「負け犬の遠吠えカコワルイ」とかさんざ言われたあのマクからの撤退宣言は無かったことにして、やっぱしマクプラットフォームに留まって戦うって決めたヨ
だそうな。ニガワラしつつとりあえずその決定を歓迎する次第ではありまする。で、見てろよ明日新バージョンだすからな！
の明日
は今日なのでして。
…早急に 7 をキボンヌ。…数字だけ 7 ってのじゃだめよ？もちろん。とりあえず 6.02 を速攻ゲットしてきて使ってみたけど、 6.0 よりすこしパフォーマンスが上がってた。 他は特筆するところは無いかな。
AmScriptFileCMX は、Mac OS X の Script Editor で保存した「コンパイル済みスクリプト」ファイルを、Mac OS 9 互換の保存フォーマットに変換します。１つのスクリプトファイルを旧 Mac OS および Mac OS X 双方で共用したい場合などにお使い下さい。
Mac OS X の Script Editor は、コンパイル済みスクリプトをデータフォークに保存します。Mac OS 9 まではリソースフォークでした。このため、旧 Mac OS の Script Editor (スクリプト編集プログラム) やクラシックアプリケーションが提供するスクリプトメニューでは、Mac OS X の Script Editor で保存したスクリプトを開いたり、実行することができません。
AmScriptFileCMX は、データフォークに記録されている「コンパイル済みスクリプト」データをリソースフォークにコピーした後、データフォークから削除します。
これを読むまで気づいてなかった。いつのまにか Script Editor は、コンパイル済みスクリプトの実行用バイナリデータをデータフォークに保存する仕様になってたのねん。ただこれは、新規に書いた時に限られてるらしく、従来のリソースフォーク保存型のコンパイル済みスクリプトを Script Editor で編集保存した場合は、依然としてリソースフォークへ保存するようになってるっぽい。
OSX の Script Editor で新規に書いたスクリプトファイルを、 mi で開くと何故かカラッポになってたり、 mi の AppleScript ツールとして使っても動作しなかったり、何より OS9 時代以前からずっと使用できていた AppleScript ツールであっても、一度でも Script Editor で編集保存してしまうととたんに動作しなくなったりする理由は、ココにあったのかー。つまり、 mi は Carbon 化によって OSX ネイティブアプリとなってはいても、その AppleScript 方面の取り扱い部分は旧 MacOS 時代のままなのだなぁ…。
mi の AppleScript モードは旧「スクリプト編集プログラム」同様に、コンパイル済みスクリプトの実行用バイナリデータをリソースフォークに保存する。それと同時に、スクリプトファイルを純粋なプレーンテキストファイルとしても扱えるように（推測）、生のスクリプトソースをそのままデータフォークに転写してる。 mi 以外で作成して、 mi で開く前にはリソースフォークしか無かったとしても、保存時にその処理がなされる。これは OSX 用の現行最新バージョンでも同じ。
ところで、この AmScriptFileCMX は、データフォークに 1byte でも容量のあるスクリプトファイルを「OS9 非互換の OSX 専用スクリプトである」と見なしてる模様でして。上記のように、 mi で編集したスクリプトファイルのデータフォークには、プレーンテキストな生スクリプトトソースが入っているだけなので、これに対して AmScriptFileCMX による「互換形式に変換」を発動すると、確実にスクリプトファイルが壊れます。復旧は不可能。注意。
この件、AmScriptFileCMX 1.0.1 で修正されてます。
望みは薄いけど、CaminoがMacIE並みにAppleScript対応してくれたら、面白いことがいっぱいできるんですよね。ああ勿体ない。
[ AS対応 - 日これ (2003/05/21) より ]
Camino の本体を Script Editor にドロップしても、スクリプティングに対応していません
云々てなダイアログが出て、 AppleScript の用語辞書が出てこないんで、一見 AppleScript 未実装の様に見えるですが、実は、チョー基本的な部分だけですけど、一応対応してたりしてます。
スクリプトエディタから Camino の AppleScript 辞書を開こうとするとエラーが出ます。これに対処するには Camino アプリケーションのパッケージを開き
Contents/Resources/English.lprojの中の "Localized.rsrc" ファイルを取り除きます。しかし、これによって Shockwave Director のコンテンツが読み込まれなくなるので、これはアプリケーションの複製に対して行うことをおすすめします。
[ Camino™ リリースノート（和訳） より ]
"Localized.rsrc" を取り除きます
というか、リネームでもいいんですけど、ともかくこの状態にして Camino 本体を Script Editor にドロップすれば、 AppleScript 用語辞書が出てくるです。
その用語辞書を見ればすぐ分かりますけど、 AppleScript から JavaScript を投げつける do javascript なるモノが Camino Suite のトコにあったりして。本家 Mozilla や Firebird には無いコマンドだし、 Camino が独自に用意しようとしてる模様。ただし、まだ未実装なんで何も動作しないんですけど、一応期待はできます。
- do javascript : Execute the supplied JS in the context of the frontmost window. (Not yet implemented)
do javascript reference-- the object for the command
「ウェブヘルパーでアクセシビリティチェキ」の続き。
んでわウェブヘルパー v1.0自体に対する評価、所感など。
GUI がダサイ。いや使いづらい。いちおう Win 版 Mac 版と分けられているのに、画面内の操作説明やその背景にある操作概念体系がまるきり Win のソレのままというのもムカツク。
複数行に渡る段落の行同士が重なってそこかしこ文字が欠けてたり、画面内の文字表示全体がグチャグチャになりやすい。これも OSX の JavaVM 自体の問題かもしんないけど、前述のようにプラットフォームで分けてるんだから、対処してくれておいてもいいじゃん。
ボタン類の配置等も Mac の Human Interface Guidelines にまったく準拠していない。アプリの操作体系の設計は、その動作環境（プラットフォーム・ OS ）共通の概念、あるいは既定のルールに従うべきで、それはツールのアクセシビリティやユーザビリティを向上させる最短最良の道。それがわからんツールがアクセシビリティを検証するこの滑稽やいかに。
いや単に、配布ファイルのアーカイブ形式を Win と Mac で分けたかっただけ？不毛だなぁそれ。
どんなものか見てやろうと思ったのですが…Mac OS X向けのファイルが私の環境(Mac OS X 10.2.6)ではうまく展開できませんでした。どおして？ちなみにWindowsの方は未確認です。
[ みんなのウェブ：アクセシビリティ実証実験ホームページ - 林檎つまみぐい (2003/05/20) より ]
どうやら StuffIt Expander だと解凍できないっぽいような…。仕方ないので、 Terminal.app にて tar zxvf webhelper_v1.tar.gz とヤって解凍したです。
画面内の操作説明や能書きがくどい。雑然としたまま整理されてない冗長な説明やノウガキの氾濫は、アクセシビリティやユーザビリティにとってむしろ逆効果と考える次第。これはみんなのウェブのサイト自体にも言える感じ。操作説明がクドクド必要な Web サイトも、アプリケーションも、出来が悪いからゆえにそうなるわけで。
特に、画面内容が切り替わるたびにクドい操作説明ダイアログが出現して煩わしい。これはスクリーンリーダーなどではこのポップアップを読み上げ、目の不自由な方へ画面の内容を伝えることを第一目的
としての事らしいし、設定で OFF に出来るからいいんだけど、それにしたって同じ操作説明文言を毎度毎度見せとかないと操作できるか不安、という UI 設計への自信のなさが問題。
table 要素の存在確認」を常に経由しないとチェキできないしくみは、どうしようもなくダサイ。そんなもん、table 要素を見つけた時だけ「テーブル使用目的指定」画面を出して経由させれば済むのに。項目数 36とか出てると、とてもじゃないけどやってらんない。 OSX 上だと動作が激重なことと相まって。
非適合箇所の「該当箇所表示」などで表示される検証結果 HTML 。検証したオリジナルの HTML に XML 宣言があってもおかまいなしにそれより前にタグを追加するというか、 XML 宣言を中途半端に破壊した上、 DOCTYPE 宣言も削除されてる。すげぇイイカゲン。
で、その「該当箇所」を示すために img 要素を使っていて、該当セクション番号を alt 属性に入れてる。確かに alt 属性の使い方として間違ってはいないのだけど、多くの真っ当なブラウザでは、WinIE みたく alt 属性値をツールチップにポップアップしたりはしないわけで。つまり、画像表示 ON 設定の多くのブラウザでは、ソースを読まない限り該当セクション番号を知ることができない。特定ブラウザの実装に依存してるコレ、アクセシビリティはいずこ？という話。 title 属性にも併記すべき。
難癖としか言い様のない所感、しかもユーザビリティ系なモノばかり並べてしもた。確かにアプリの使用感といったユーザビリティ論は、アクセシビリティ論とは概念的にベツモノ。…ではあるけど、相互に影響を与え合うものでもあるから、 Web アクセシビリティの事しかぼくたちワカリマセン、みたいに受け取れるこのツールの出来はどうかと思った次第。
もちろん、政府機関（総務省）が音頭を取ってこのような実験を行い、ウェブアクセシビリティに関心を持ってもらおうとしていること
それ自体は評価したいと思います
ヨ。ゆえに理想は高く。
「ウェブヘルパー v1.0 使用所感リンク集」に続く。
WAI WCAG への適合検証はこれまで人力でやったことは何度かあったのだけど、結果の詳細というか非適合のイイワケを詳細に書いた事はたしか無かったと思うので、つらつら書いておく次第。今回はウェブヘルパー v1.0 を使用してみたゆえ、それによる検証結果を元に。
検証したのはトップページのみ。適合度 Triple-A を前提のチェック。 OSX 上におけるウェブヘルパーの動作は死ぬほど重いんで、たくさんのページをチェキるのはムリ。ムリムリ。人力検証もホネが折れるのでしない。
スクリプトの代わりとなるテキストが用意されていません。
このアクセシビリティチェック項目は、インタラクティブな UI を提供する系統か、くだらないノウガキや視覚効果を垂れ流す系統のスクリプトに対してのモノ。（「にっきのジャンル別見出し一覧ページの絞り込みマシーン」はコレに抵触してます。いまのとこ。でも今回はトップページに対するチェキなのでスルー。）
トップページ他で動作させてるスクリプトはそういう類のモノじゃなくて、CSS の実装に難のある UA に対する代替措置とか、取れなくても構わないアクセス解析 CGI の呼び出しをしてるだけのモノ（参考：「力技の多いサイトなのでして」）。このバヤイ、同等の役割を果たすテキスト
を用意するのはちとナンセンス。ムリヤリ用意しても「カクカクシカジカの代替処置が行われています」とかの文面になるだけで、「だからどうした」って感じ。蛇足の極み。
レイアウトや体裁にスタイルシートが使用されていません。
どっからどう見ても、レイアウトや体裁
はスタイルシートのみで行ってるんだけど。検証動作のほうがおかしい。バグですかい。
サイズや位置が、固定の単位（絶対単位）で指定されています。
CSS2 仕様書における値の種類の項によれば、絶対単位には in, cm, mm, pt, pc が、相対単位には em, ex, px, % が挙げられてる。説明画面によればウェブヘルパーもそのとおりに区分してるっぽい。この区分における絶対単位
は一切使ってないハズなのに、なぜか引っかかった。謎。バグかいな。
（px は絶対単位じゃないのか？という引っかかりを覚えやすいのだけど、 CSS 仕様上これは閲覧しているデバイス（多くの場合はコンピュータの画面）の解像度を参照する
相対値扱い。ビットマップ画像の背景上に文字を置く場合などには、ビットマップ画像がピクセルで構成されている以上、文字の配置関係プロパティも px 単位で指定するほうが安全。おなじ相対軸上にある単位で揃えたほうが何かと安心て事。やみくもに px 単位を忌避するのは賢くない。（関連：「pt 単位についてノベノベ」）
リンクを示すテキスト（リンクテキスト名）が明確になっていません。
これはどうやら、 img 要素しか含まないリンクアンカーに対して問答無用で出るくさい。実際には、問題アリと出た箇所の img 要素にも、 alt 属性で適切な代替テキストを与えてあるワケで、問題無いハズ。検証動作があんまりにも表面的すぎると思う。
コンテンツやサイト全体についての情報がありません。
文書タイトルを示す title 要素、文書間の結びつきを示す link 要素、文書制作者情報を示す address 要素といった「順当な項目」の他にも、ウェブヘルパー ver1.0 のこの項の説明によると、meta 要素の author, keyword, description といったあたりも記述しろ、となってて、たぶんそこに引っかかってる。（この方法でメタデータを提供すべしとの明示的言及は WCAG1.0 には無い）
過去にこれらは、嘘キーワード記載等の悪徳 SEO 手法でさんざ濫用された挙げ句、現在は形骸化の果てに利用価値ゼロな状態。それに author, keyword, description 等の meta 要素 name 属性値は、 HTML 仕様書等で定められ規格化されてるモノじゃない。よって記述するのは何だかアホくさい。…ビバ屁理屈！（w
たとえば、文書の制作者や内容のタイプなどを示すためには、RDF を使用してください
と WCAG 1.0 にあるように、今後は RDF でメタデータを記述する流れかと。まぁそういう RDF もウチは用意してないわけなのですが（笑）。
（余談だけど、こんどは RDF メタデータが悪徳 SEO 手法の餌食になって、嘘まみれのメタデータで氾濫する Web 世界になるという危惧も。世の中おしなべて、悪貨は良貨を駆逐する）
文書内で基本として使用されている言語（日本語や英語など）が指定されていません。
HTML4 / XHTML1.0 までは存在した lang 属性は XHTML1.1 にはすでに無く、ウチのサイトはほぼ全文書が XHTML1.1 なので、見ての通り xml:lang 属性のみで言語指定してるワケです。しかしこのウェブヘルパー v1.0 は lang 属性の有無しかチェックしてないらすぃ。
ショートカットキーが用意されていません。
ページ上端下端のナビリンク項目にはショートカットキーを用意してるけど、アンカーやフォームアイテム何でもかんでもショートカットキーを用意したりはしませぬ。理由は「「データ」「表示」「操作」」の通り。トップページ他のコンテンツメニュー項目も重要なリンク
だけども、そういうモノまでいちいちショートカットキーを用意すると、アクセシビリティやユーザビリティにとって却ってデメリットとなる、と考えてる次第。
結局、トップページには accesskey 属性の設定されたアンカーはひとつも無いのでそのせいか、自動検証段階でイキナリ×印がつけられてちゃってる次第。というかそもそも、重要なリンク
が何なのかを機械的に判断することは出来ないハズだから、自動検証後に人間が人力で評価する「確認必要項目」とすべきかと。
とりあえず形式的に適合度 Triple-A をゲットしたいだけなら、 HTML 文法チェッカを騙すのと同じ要領で小細工すればいいだけ。しかしそんなん意味ないってか、別に WCAG 適合バナーを自慢げに貼りたいが為じゃないのだし。
ウェブヘルパーは、あくまでアクセシビリティ点検のための補助ツールです。
（略）WCAG1.0の14項目のガイドラインにしたがって、それを完全かつ自動的にシステムが点検することは不可能です。ウェブヘルパーが行う点検は、WCAG1.0のガイドラインが意図するところの一部分を点検しているに過ぎません。かつ、利用者の判断に委ねられている点検項目も多数存在します。
したがって、最終的にアクセシビリティの確保が実現されているかは、WCAG1.0に照らし合わせて、ご自身で判定していただく必要があります。
[ ウェブヘルパーの点検の仕組み - ウェブヘルパーとは - 「みんなのウェブ」 より ]
機械的な適合チェックが比較的しやすい HTML でさえ、最終的な適合判断は人間の脳みそじゃないと不可能。逆に、人間様の脳みそは、機械を騙すことぐらい朝飯前。バリデータ自体を崇め奉る宗教ほどしょーもないモノは無い。ツールに頼らずとも自分で正しい判断を行えるだけの知識を蓄えて、それこそを崇めなくてわ。
「ウェブヘルパー v1.0 に対する所感」に続く。
Mail to Alimika Satomi
Site search
About copyrights