« 2007年04月 | メイン | 2007年06月 »

2007年05月 アーカイブ

2007年05月31日

常に自分のせいにする習慣。

教えてくれる人が側にいない環境とか、職場の空気が良くないとか、とかく周囲のせいにしがちな私たちだけど、こと自分の成長のためを思ったら「それは俺自身のせい」と思うようにしてみたら?

何が自分を成長させてくれるかは考え方次第。

これは「職場」を「社会」に置き変えてもそう。

自分が「そこ」を構成している一員である以上、自分に出来ることはある筈だ。

カテゴリー: 駄文・雑文

投稿者: Junnama Noda 日時: 2007年05月31日 23:12 | | コメント[ID:1445] (0) | トラックバック[ID:1445] (0)

大学に。

広告をスキップ

「大手」ってあるんだ。

「一流」ってのはわかるけど、規模の問題かね? まぁどうでもよい突っ込みだが。

カテゴリー: 駄文・雑文

投稿者: Junnama Noda 日時: 2007年05月31日 02:36 | | コメント[ID:1442] (0) | トラックバック[ID:1442] (0)

2007年05月30日

不満でとどまるか、行動するか。

広告をスキップ

Webアクセシビリティの議論とかで「2007/05/30」はちゃんと読み上げられないから「2007年5月30日」って書こう、みたいな話が必ず出てくる。

これは、読み上げる側が改善されれば良い話であるわけで(本来は支援技術側の仕事)、究極の答えは「じゃぁ、読み上げられる音声ブラウザを作れ」というものになる。

僕にはその力が無いから、「アクセシブルなHTMLはこうやって書くんだよ」といったドキュメントを作成して公開したりブログに書いたりする。

同種の話では、「何でMTですか? 再構築とか、重くないですか」とかも同じ。

そこで思考を止めてしまわずに、「読み上げやすく変換するフィルターを作ろう」とか「どう設計したら再構築のストレスなくなるだろう」とか考えて実際にやってみる。

出来ることから実際に行動していくことが大切。そこから見えてくるものが色々ある。

そこをクリアすると、新しい世界が見えてくるのだ。

カテゴリー: 駄文・雑文

タグ:

投稿者: Junnama Noda 日時: 2007年05月30日 01:53 | | コメント[ID:1440] (0) | トラックバック[ID:1440] (0)

2007年05月28日

音声ブラウザと相性の良いHTMLを作る(5)。

関連エントリー

広告をスキップ

PDFをどうするか

ホームページ・リーダーは3.04からPDFの読み上げに対応している。それ以前のバージョンでは未対応だった。PC-Talker XP Version1.14, 95 Reader Version 6.0, JAWS for Windows Professional Version 6.2 ではPDFを読み上げることができるようだ。

参考: 日本の視覚障害者用ウェブ利用ソフトの機能調査

とはいえ、まだまだ問題は多そうだ。

日本の視覚障害者用ウェブ利用ソフトの機能調査 > 5.3 ユーザエージェントによって差があった機能 > 5.3.2 PDFとFlash より引用

PDFに関しては，

  • 95 Reader以外は，表示行ごとに区切って読むので，読み上げが不自然だった．
  • JAWS以外は，PDFのテーブルを表として読み上げることができなかった．
  • グラフの読み上げに関しては，PC-Talkerはグラフの表題しか読み上げなかった，
  • HPR 3.04は見出しを読まなかった．
  • 画像の代替テキストは，95 ReaderとJAWSは読み上げるが，PC-TalkerはPDF上では読み上げることができなかった．HPR 3.04は読み上げる画像と読み上げない画像があった．

日本の視覚障害者用ウェブ利用ソフトの機能調査 > 6.9 PDFはどの程度利用できるかより引用

調査の結果，PDFの利用にはかなりの制約があることがわかった．全ユーザエージェントが共通してできたのは，本文と表を上から順に読み上げることだけである(以下略)

広告をスキップ

ゲートウェイへの実装

これまでNaked(Beta) (音声ブラウザができるだけ読み上げやすいページに変換しようと試みるゲートウェイ) では、Content-Type が text で始まらないものは無条件にリダイレクトしていたのだが、Xpdf をインストールするついでがあったので変換を試みることにした。

見出しが読めるわけでもなく、表が読めるわけでもないが (JAWSでは表がうまく読み上げられるようだ)、文章が途中で分割されてしまう (95 Reader以外は，表示行ごとに区切って読むので，読み上げが不自然だった．) 部分に関しては、改行(文章や単語の中で改行されたと思われる部分)を削除することで対応させた(つもり)。

この部分はXpdfの解釈もGoogleやYahoo!の検索結果から参照出来るHTML(もどき)も共通していて、PDFをテキスト化した時に「各行毎に改行されてしまう」傾向がある。スクリーンリーダーや音声ブラウザの多くが各行毎に読み上げてしまうことから、おそらくPDFの仕様なんだろう (このあたりは見出しの抽出方法とあわせて今後調べてみようと思う)。

これは想像なのだが、これが仕様であるならばおそらく縦書きのPDFの読み上げ状況が悪いのではないかと思う(誰か分かる人教えてください)。

現状の変換についてはちょっと(まだまだ実用的じゃないと思うけど)以下の通り

変換方針

  • PDFはテキスト化する。
  • タイトルの取得を試みるが取得に失敗した場合は最初の1行をタイトルとみなす。
  • テキスト化の際に分割された(であろう)行をつなげる。

今後の対応課題

  • 見出し等の文書構造のサポート(見出しを抽出してページ内リンクでナビゲーションを作る)。

表は...ちょっと僕の力量では難しいかもしれないが。

以下、変換結果。元にしたのは (特に意味はありません)「京都府ウェブアクセシビリティガイドラインのPDF版」。

ベタ読みになってしまうのが何とも辛いところだけど、テキスト変換するだけでもこうして携帯版が出来たりルビを振れたりするし、やはりHTMLやプレーンテキストで情報が伝わるように作成することが大切なのだと思う。

カテゴリー: アクセシビリティ

タグ:

投稿者: Junnama Noda 日時: 2007年05月28日 20:37 | | コメント[ID:1438] (0) | トラックバック[ID:1438] (5)

2007年05月27日

音声ブラウザに最適化された検索エンジンについて考えてみる(だけじゃなくて作成してみる)。

以前のエントリー (Naked(beta)のこれから。) で書いたもののうち、検索からのアクセスについて。

URLからのアクセスの他に「検索」から利用スタートできるように(Yahoo! のAPIを使おうかと目論んでいる)

Yahoo!検索WebサービスのAPIについてちょっと調べて2〜3時間くらいあ〜だこ〜だして原型ができた。シンプルで良いです、これ。Yahoo! Japan Good Job! ですよ (反応遅い?) 。

作ってみたもの↓

基本的な考え方

  • (削除)とりあえずは検索対象はHTMLのみとする (PDFとかは現状では対象外とする)。(追記)Xpdfを使ってPDFも変換するように変更
  • できるだけシンプルな結果を返す (URLとかは読み上げてもおそらく意味不明ではないだろうか)。
  • 無駄な情報をできるだけ排除して検索結果主体にシンプルに返す。
  • (削除)更新日はひらがなで返す。(追記)年月日はひらがなにする必要はないか...参考:日本の視覚障害者用ウェブ利用ソフトの機能調査ということで修正
  • 要約の「...」は削除する。
  • できるだけ直感的に理解出来る日本語表現とする (例:フィードバックの受付のためのmailtoリンクのリンクテキストは「ご意見、不具合のご指摘（サイトの作成者 野田純生宛のメールを作成する」) 。問い合わせフォーム用意してません、すいませんっ!
  • 冗長で恩着せがましい? 表現はできるだけしない (ナビゲーションスキップ、とか書かない)。
  • 「もう一度検索」や「次の検索結果への移動」は検索結果の後に。但し見出し(h2)はつける。
  • 検索結果の先頭への移動やナビゲーションへの移動にはアクセスキーを指定する。
  • 検索結果の表示数はデフォルトで20件とする (おそらく多い方が探しやすいと思う。ページ内検索も使えるし。ただ、重くなっては本末転倒なのでとりあえず20件単位で表示)。
  • 検索結果からのリンクについては「音声ブラウザ向けテキスト変換ゲートウェイ (Naked(Beta), スキンは「音声ブラウザ」)を通す。

カテゴリー: アクセシビリティ

投稿者: Junnama Noda 日時: 2007年05月27日 00:13 | | コメント[ID:1437] (0) | トラックバック[ID:1437] (0)

2007年05月25日

MeCab (和布蕪)でルビ振り。

MeCab (和布蕪)を使ってルビ振りを実装してみた。

弾さんのコードを参考にして。

弾さんのやつはXHTMLの空要素が /="/" とかになっちゃうのと、英語の単語間の空白が飛んでしまうのでまぁごにょごにょと。
HTMLパーサでの実装は参考になるなぁ。こうするんだ。

どっちかと言えばインストールの方が大変だったけどね。

小学生向けCSSとか、色々楽しそうだ。

読み上げの簡易的な確認にも使えそう。

※しかし... 「和布蕪」を「和布蕪」を使ってルビを振ると「わかめかぶら」...

カテゴリー: アクセシビリティ, プログラミング

投稿者: Junnama Noda 日時: 2007年05月25日 01:02 | | コメント[ID:1436] (0) | トラックバック[ID:1436] (0)

2007年05月23日

AdSense広告のマッチング。

こんなのを作ったもんだから (なのか?）AdSenseの広告が「豊 胸」とか「ペ○ス増○」とか「か つ ら」とかが増えてきたような気が...

※Naked=裸

あんまり感じよくないなぁ。フィルタとか使ってみるかな。

Googleもまだまだ...だな! なんて言ってみるのはいいけど、こんなエントリーを上げるとますます「そっち系」に最適化される罠。

関連する (かもしれない) 話題

カテゴリー: 駄文・雑文

投稿者: Junnama Noda 日時: 2007年05月23日 20:57 | | コメント[ID:1435] (0) | トラックバック[ID:1435] (0)

見下してたの?

HTML書きたちを、プログラマーたちが「下に見ていた」ということは否定できない。そのHTML書きたちの、「私たちにも少しはプログラムさせてよ」という声に他の言語屋たちが耳を充分傾けてこなかったことこそ、猛省すべき課題だろう。

HTML書きはプログラマを「腫れ物に触るように」見ていたのかもしれない。ただ、HTML書きは今やその領域でプログラマが出来ないことを成し遂げてしまった。

デザインについても然り。

結果、プログラマたちはデザインテンプレートサイトや素材ジェネレーターに群がっているし。

結局、大切なのは「何を生み出せるか」なのだ。パートナーは誰だって良い。ただ、相手にも選ぶ権利はある。

カテゴリー: 駄文・雑文

投稿者: Junnama Noda 日時: 2007年05月23日 01:24 | | コメント[ID:1434] (2) | トラックバック[ID:1434] (0)

2007年05月22日

そろそろThinkITに一言いっとくか。

この記事を、えぇ、1〜3まで読んだ時にね、「くだらねぇ記事読んで時間を無駄にしたなぁ」って思ったわけで。

まぁ、流せば良いわけですが、この記事が「はてブ」で大量に「ブクマ」されてるわけですよ。

「多くのオープンソースソフトウェアがPHPで書かれているからPHPを覚えよう」ってのがこの記事の主題なわけで(小学校の国語のテストならこれで正解ではないか?)。

  • PHPは習得しやすいか
  • 開発スタイルを変化させたC言語

とかいうパラグラフは、はっきり言ってどーでもいいブロックじゃないか。この記事においては。

※別に、「多くのオープンソースソフトウェアがPerlで書かれているからPerlを覚えよう」でも全然成立するわけだし。

PHPがどうとかPerlがどうとかではなく、「今だからこその「PHPのすすめ」というタイトルの記事でこの内容、且つ大量のブクマってあたりがちょっとひとこといいたくなる原因なわけです。読み終わった後で「時間を返せ」をいう気持ちになったのではないかと推測するのです。

それで(僕ですら切れかけたのだから) こうなるわけですよ。きっと。

だから、言語としてのPHPに対するツッコミではなく、記事、あるいは記事に大量にブクマされているという現実に対する何だ、その、まぁhogehogeなわけだ。と推測してみる。

※つまりね、こんな記事に反応してブクマなんかしないでくれ! ということが言いたい。

カテゴリー: 駄文・雑文

投稿者: Junnama Noda 日時: 2007年05月22日 00:01 | | コメント[ID:1433] (0) | トラックバック[ID:1433] (0)

2007年05月21日

Naked(beta)のこれから。

さて、2週間でつくったβ版(レベルはまだまだα版) Webサービス、Naked(仮称) の仕様と今後について(考えていることを)簡単に。

これは何?

音声ブラウザ (に限らず様々なデバイス) に対してできるだけ最適化されたコンテンツに自動変換してページのデータを返すゲートウェイ。

名前 (Naked) の意味は「裸」。CSS Naked Dayとか? 意識? してますよ。もちろん。

コンセプト

現状の音声ブラウザ, 携帯ブラウザ等の仕様や制限によってユーザーに「伝わらない」「伝わりにくい」情報を出来る限り伝わりやすく変換する技術を開発することで、ユーザーが利益が恩恵を受けるだけでなく、制作者の負担を軽くし、様々なUAに対して最適化されたウェブコンテンツを制作しやすくする。

また、旧来の作成手法(テーブルレイアウト、透明GIFでのレイアウト調整)からWeb標準に則ったサイトへの移行をしやすくし、以下のような用途への技術の転用を予定。

  • テーブルレイアウトのサイトをCSSベースで自動リニューアルするエンジンの開発
  • アクセシブルなテキストバージョンの自動生成
  • 携帯電話用コンテンツの自動生成
  • 既存ウェブサイトの自動CMS化
  • CMSによるサイト運用におけるウェブアクセシビリティの継続(CMSプラグイン等)

※まぁ、これくらいぶち上げておくのも良いか、と。

主な仕様

  • JavaScriptやCSSをカットしてプレーンなHTMLに変換する
  • いくつかの非推薦の要素を代替要素に置き換える
  • レイアウトのためのテーブル関連要素(TABLE,TR,TD等)を削除または変換する
  • 画像やイメージマップをテキストベースの情報に変換する
  • 変更を表す要素(INS,DEL)の前後にテキストを挿入する
  • 日付や数式のフォーマットを日本語環境でできるだけ読み上げやすいように変換する
  • 記号を(一部)よみがなに変換する
  • メディアタイプがSPEECH, AURALのCSSを「擬似的に」有効にする

現状の制限事項・今後の改良点

  • 処理と変換の一層の安定化
  • ゲートウェイであるが故の匿名性の問題(UA情報に接続元IPを加える、等)
  • 現状アクセスできないページ(Basic認証, HTTPS通信)のサポート
  • Cookieのサポート(←これは検討中。プライバシーの問題もあるし)
  • URLからのアクセスの他に「検索」から利用スタートできるように(Yahoo! のAPIを使おうかと目論んでいる) →作ってみた

以下、雑記 (というかこのエントリ自体雑記だけど)

来週あたりちゃんとデザインしてドメインも取って引っ越ししたい。

今は何かと話題? のオンライン「ロゴジェネレーター」で作成したロゴをペタっと貼っているだけなので。

雑記の余談

FizzBuzz問題が面白かったのでやってみた。あくまでも「アマグラマ」の余興のレベルですよ、ええ。

全然短くならないや。まぁ、プログラマ面接受ける予定ないからいいけど...って違う違う、今度面接する時に参考にしよう。

※でもまぁ言うだけだと卑怯? なので貼っておく。
短けりゃいいってもんでもないしまぁいいか。

perl -e 'for(1..100){print$_ if$_%3&&$_%5;print"Fizz"unless$_%3;print"Buzz"unless$_%5;print"\n"}'

エレガントにサクっと書ける方と面接でお会いできる日を楽しみにしていますから!

カテゴリー: プログラミング, 駄文・雑文

タグ:

投稿者: Junnama Noda 日時: 2007年05月21日 17:43 | | コメント[ID:1432] (0) | トラックバック[ID:1432] (1)

2007年05月20日

サラリーマンが会社を辞めて自分の会社を始めるために必要な8つのステップ。

この5月、ブログに1日1エントリー、毎週何かのアウトプット(WebサービスとかMTプラグインとか)を自分のノルマ化してあれこれ書いたり作ったりしている。
1日1エントリーはさすがにしんどいか。

それでも「本当に好きなこと」「本当にやりたいこと」「儲からない? けどやりたいこと」を今月あたりはあれこれやっている気がする(本当は儲からないわけではなく、それなりの打算もあるわけだが)。

間もなく会社をはじめて4期目の期末。ようやくここまでたどり着いたという感じだ。

さて、それ(自分のやりたいことがやれる会社)が出来る状況に自分を置くためのいくつかの約束事について書く。結局『会社』をつくるってのは「やりたいことを納得いくようにやる」ための手段なのだ(僕にとっては)。

1.儲かるところで結果を出そう

何はともあれ、殆どの人はサラリーマンであったりフリーランスであっても日々の生活の糧に追われる身である。色んな意味で「バブリー」な人たち (アルファな人たちもね) のことはひとまず考えず、まずは目の前の仕事で成果を出そう。「堅実な成果」は裏切らないから。

これは周囲から「文句を言わせない」ための何よりの特効薬でもある。

2.「やりたいこと」と「儲け」の接点を考えよう

あなたの上司や会社は常に数字や結果、つまり成果を求めることだろう。
であれば、あなたのやりたいことで成果を出せるのがベストである。成果さえ生み出せれば誰にも文句は言われない。

だから、あなたのやりたいことは社会にどれだけニーズがあって、それはこんな可能性を秘めているんだということを考えてあなたの阻害要因(例えば上司とか) を取り除くこをを考えよう。

3.あなたの「時間」をコントロールする権限のある人を洗脳しよう

自分がやっていることの意義、上記項目と重なるが「私がやりたいこと、やっていること」は「あなたの利益(例えば「儲け」)につながることなのですよ。ということを繰り返し繰り返し話し続けよう。

4.「接点」が無ければ「接点」を持てそうな場所を探そう

安易な転職はお勧めしないが、どう考えても接点を持てない場合がある。
今からかれこれ7〜8年くらい前のことだったか、広告制作会社に在籍、「Webアクセシビリティ」が自分のテーマになってしまったことがある。色んなアプローチをとったが根本のところでは結局は理解してもらえなかった。だって、Web系の会社でもないんだし。

※今は少し状況が違う。JIS X 8341-3のこともあるが、何より企業のCSRやコンプライアンスへの意識が高まっている影響で、(あるいはウェブの業界も進んで来たこともあって)、結果的には状況は変わって来たわけだ。
ただ、その時は難しかったな。今となっては理解できるのだが、「接点」が無いところでいくら頑張っても限界はあるのだ。

そういった場合は転職も視野にいれよう。「会社はわかってくれない」のではなくて「その会社には接点がない」のだ。

5.「20％ルール」を自分でつくろう

Googleとか20％は自分の好きな分野の研究がどうのって、与えられることを前提に考えるから時間を作れないのだ。

仕事ができる人は20％の時間なんぞ結果を出しながらひねり出せる。だから、「出来る人を採用して20％好きなことをやらせる」も「出来る人は勝手に時間をひねり出して20％程度は好きなことをやっている」は結果的には同義だ。

あなたの会社が古めかしくて、好きなことやっていたらまわりとの軋轢がうまれるとか、周りが残業続きなのに自分はさっさと片付けて周りから浮いてしまっている...のならば、周囲と同じく「しんどい」演出をしつつ、8割の時間でノルマをこなしてしまえ。で、残りの2割の時間は「難しい顔」をしつつ、同僚を励まし励まされつつ、好きなことをやっていたまえ。

それもまた「大人」のやり方なんだ。

6.それでも、どうしても駄目なら、自分で会社をつくろう

あなたのやりたいことが社会的に意義があって「儲け」との接点も自信を持って説明出来て、それでも尚且つあなたが置かれている環境における周囲の人に理解されないことを気に病んでいるのであれば、(つまり、本当に会社はわかってくれない! のれあれば)『そんな場所はさっさと飛び出してしまえ』。

それでも、再び戻って自問してみるのだ。原点に立ち戻って、その上でそれでも...辞める覚悟があるのなら、

7.もう一度だけ洗脳・説得してみよう

結局独立してフリーランスになっても会社を作っても、最初の問題「儲かるところで結果を出す」に戻ってくる。
自分が立てた仮説通りに物事が進まないのであれば、結局は会社や上司が「わかてくれなかった」ことが「正しかった」ことになる。『あいつの口車に乗らずに良かった』てなもんだ。

結果を出せなければ、会社を辞めて職を失うわ、会社を作ったが借金ばかりが増えていくわ...という状態に陥るわけである。

だから徹底的に計画して、数字のシミュレーションも終わって、「さぁ、これで行けるぞ! 明日から俺も一国一城の主だ! 」と思ったら、その段階でもう一度『その数字を持って周りを洗脳しに動いてみる』のだ。一抹の不安もないのであればさっさと辞めてしまえば良い。迷いがあるなら尚のこと、その数字、計画を『会社向け、上司向けにリライトしてから』持って行けばよい。

さて、あなたは上司にそれを持っていった。そこで感じたこと、得られた反応を大切にしよう。

それで何かが変わるかもしれない。

それでも単なる『分からず屋!』という気持ちになって、『これでもこの計画の意味がわからんか!』という気持ちになったのであれば...

8.それでは、会社をはじめよう。

その時こそがキミが起つべき時である。『業を起こす』と書いて『起業』と言う。
そこが「社会」にとってはとても小さな、そして「自分」にとってはとても大きな一歩なのである。

そして、もう一つのステップ8。

当社では人材 (特にプログラマとサーバー系エンジニア) 募集中。我はという方はまずはメールで結構ですので連絡ください。

カテゴリー: 駄文・雑文

投稿者: Junnama Noda 日時: 2007年05月20日 00:58 | | コメント[ID:1431] (0) | トラックバック[ID:1431] (0)

2007年05月19日

音声ブラウザと相性の良いHTMLを作る(4)。

CSSメディアタイプによる分岐とINS, DEL要素の処理

関連エントリー

考察(?) の具体的成果物(進行中)

メディアタイプによる分岐とINS, DEL要素の処理を実装してみた。

  • 読み上げないテキスト
  • 読み上げるテキスト
  • 挿入されたテキスト(日付指定あり)
  • 削除されたテキスト(日付指定あり)
  • 挿入されたテキスト(日付指定なし)
  • 削除されたテキスト(日付指定なし)

今回のテスト用コード

<ul>
<li class="silent">読み上げないテキスト</li>
<li class="speech">読み上げるテキスト</li>
<li><ins datetime="2007-05-19T13:45+09:00">挿入されたテキスト(日付指定あり)</ins></li>
<li><del datetime="2007-05-18T13:45+09:00">削除されたテキスト(日付指定あり)</del></li>
<li><ins>挿入されたテキスト(日付指定なし)</ins></li>
<li><del>削除されたテキスト(日付指定なし)</del></li>
</ul>

Media Type (speech, aural) に対応させる

参考情報:

CSSのメディアタイプを指定することによって、対象のデバイスによってレンダリング結果 (視覚的なレンダリングとは限らない, 例えばサウンドとか）を分岐させることができる。多くのブラウザはメディアタイプ print に対応してきているため、既に以下のような使い方は日常的に行われるようになった。

  • 右側が用紙からはみ出してしまわないように幅を調整する
  • リンク先のアドレスが出力されるようにする
  • 全ページ共通のナビゲーションカラムなどをカットする

音声ブラウザのようなメディアの場合、メディアタイプ aural (※) を指定することができる。
出来るとは言っても、現状対応しているUAは (僕の知る限り) 殆ど無いのだが。

※CSS2.1からは aural の代わりに speech だそうである。aural メディアタイプに対応した読み上げ環境が殆ど無い現状で仕様も何も...てな思いがあったりなかったり...

メディア別のCSSは例えば以下のようにして適用させることができる。

  1. <link rel="stylesheet" href="aural.css" media="aural" type="text/css" />
  2. @import url("aural.css") aural;
  3. @media aural { /* style sheet for aural here */}

今回は上記の1番目の書き方に対応させた。このページにおいて以下の LINK要素を追加。

<link rel="stylesheet" href="styles-aural.css" media="aural" type="text/css" />

#beta { /*これはMTの初期のまんま、右側のサイド・バー部分*/
	display:none;
 /*隠すのがアクセシブルというわけではなくて, あくまでもテスト用*/
}
.speech { /*音声ブラウザに読ませたいところ*/
	display:inline;
}
.silent { /*音声ブラウザに読ませくないところ*/
	display:none;
}

普通にブラウザ(Safari)で見る限り何も変化がない。そりゃそうだ。メディアタイプで言うと「screen」にあたるのだから。
ところが、HPR (ホームページ・リーダー) だったら aural が適用されるかというと、そんなことはない。HPR は IE がレンダリングした結果を読み上げているので、今僕が Safari で見ているものと変わりないCSSが適用されているのだ。

処理としては、CSSを解釈してページ出力をするのではなく、相手(誰?) が screen メディアとして振る舞うのだったら騙してやれ、ということで「media="aural" , media="speech" 」を「media="all"」に変換することにした。

例えばウェブアクセシビリティにおけるライティング(コピーライティング)の役割は非常に重要なのだが、「ウェブページ」が「ウェブデザイン」というプロセスを経て作成される以上色んな意味で制約が出てくる (アクセシブルにしようとすると表現が冗長になったり)。

UAの特性に適した分岐が可能であることによって「読み上げてわかりやすい表現」の分岐も可能になると思う。

ただ、ソフトウェアが対応していない技術を使うということは自己満足のような面もあるから中々普及しないのだろう。
逆に普及しないからソフトウェアが対応しないのかどうかは僕にはよく分からないが。

変換方針

  • LINK要素のmedia属性が speech 又は aural を含む場合 media="all" に変換する。

INS, DEL要素の処理

INS要素は挿入された部分を、DEL要素は削除された部分を表すのに使う。
多くの視覚系UAは、INS要素は下線、DEL要素は打ち消し線で表現される。

これらの要素は視覚系のUAでも使い方によってしばしば問題になる。下線や打ち消し線を前提とした情報提供を行った場合 (下線は新製品、打ち消し線は売り切れ在庫無し、など) 、下線や打ち消し線が付かない環境では意味が通じなくなるからだ。

例えば僕の携帯電話(SH901iS)のブラウザでは打ち消し線も下線も表示されない。 検索エンジンが表示する「要約部分」にも、多くの場合下線や打ち消し線は付かないだろう。

音声ブラウザでも同じことが言える。削除されたもの、挿入されたもの、ということが音声で表現されなければ 意味が通らないことになる。

そこで、INS要素、DEL要素については以下のように前後にテキストを追加するようにした。

(追記) 挿入されたテキスト (追記ここまで)
(削除) 挿入されたテキスト (削除ここまで)

「挿入」よりは「追記」の方が読み上げとしては自然に理解できやすいかと思うがどうだろうか。

また、INS, DEL要素には datetime属性が指定できることになっていて、「2007-05-18T13:45+09:00」のようなフォーマットで挿入、削除されたタイムスタンプを追加できる。

よって、datetime属性が指定されている場合は、

(2007年05月19日 追記) 挿入されたテキスト(日付指定あり) (追記ここまで)

というように日付を (ちゃんと年月日形式に変換した上で) 付加するようにした。

逆に考えると実際のマークアップの際に、ちゃんと削除、挿入されたことをテキストで表現しておけばこのような処理は不要になるのだ。

変換方針

  • INS, DEL要素の前後に「追記」「削除」されたことが理解できるテキスト情報を入れる。
(※これはほんまの追記) S要素, STRIKE要素はDEL要素に置換した上で処理するようにしている

カテゴリー: アクセシビリティ

タグ:

投稿者: Junnama Noda 日時: 2007年05月19日 02:03 | | コメント[ID:1430] (0) | トラックバック[ID:1430] (7)

2007年05月18日

音声ブラウザと相性の良いHTMLを作る(3)。

さらに続き。
今回は、記号、日付、数式、そしてイメージマップについて考えてみる。

関連エントリー

記号、日付、数式について

(とある)音声ブラウザはデフォルトの設定で記号を読み上げない。

いちいち読み上げたら鬱陶しいというところもあるのだが、以下のような場合は問題になる。

例1 リンクが認識できないし、移動もできない。


<a href="http://example.com">◎</a>

例2 記号に意味を持たせている。例えば営業カレンダーなんかで良くある場合。

▲＝休館日
◎＝営業日
※＝イベント開催日

少々鬱陶しくなるかもしれないが、こういった記号はやはり読み上げられるようにテキストにしてあげた方が良いような気がする。

とはいえ、記号が何に使われているのかの判断は (これまた文脈解析でもしなければ) 不可能だ。※(あすたりすく)がイベント開催日を表しているのか注釈なのか、どう判断すりゃいいんだ?

判断できそうなものもある。例えば数式や日付など。

$str =~ s/((?:¥G|>)[^<]*?)(^0|[1-9])((?:[0-9]|(?:[¥+|＋|¥-|-|/|*|=])|¥s){10,}[0-9])(.*?)/$1.&math_to_str($2.$3).$4/eg;

0以外の数字で始まる(<-悩ましいところだけど電話番号を拾ってしまうので...いや逆に電話番号を識別すればいいのか?)数字と演算記号とスペースで構成される10文字(<-適当)以上の文字列で、且つ数字で終了しているものを置換対象とする。

あと、一応 &math_to_str の中で =(イコール) を含むかどうかチェック。住所の中に 1-2-3 とか出てくるので。

数式の場合は「ー」は「ひく」あるいは「まいなす」に変換してやれば良い（その他の場合は変換しない、とすれば良いか。

また、数式の中の「＝」は「いこーる」または「わ」(<-「は」ではなくて) とする。

日付フォーマットも年月日形式に変換する。
「ごぶんのにせんなな じゅうはち」とか読み上げられた日にゃぁ、何が何だか。

$str =~ s/((?:¥G|>)[^<]*?)(?<![0-9]|[a-z]|[A-Z]|"|'|¥/)([0-9]{4})¥/([0-9]{1,2})¥/([0-9]{1,2})(?![0-9]|[a-z]|[A-Z]|¥/)/$1.&checkdate($2,$3,$4,$6)/eg;

タグの中を置換すると /2007/5/18/post.html みたいな(MTとかで良くあるパターン)ものをひっかけてしまうので、タグの外であることと "/ あたりで始まる場合はURL等の可能性があるので除外する。

また、マッチした後に実在する日付かどうか一応チェック。2007/02/30 は日付じゃない! と判断することで精度を高める(ようにできるだけ努力)。

※このあたり実は強くないので添削求む!

変換方針

  • 記号は「よみ」に変換する。
  • 日付や数式など、フォーマットが特定可能なものは適切なフォーマット、適切な読み方に変換する。

記号を「よみ」に変換することで逆に今度は視覚的に理解しづらくなる。 「音声ブラウザでできるだけ読み上げやすいHTML」がコンセプトではあるけれども、文字を大きくしたり配色を変えてみたり色んな用途に使えるエンジンにしたい、という思いもあって (色んなスキンを適用できるってのも単純に楽しいし) 、この切り分けはCSSで行えるようにクラス名を振ることにした。

<span class="naked_sign">×</span><span class="naked_aural">かける</span>

現状はここまで。

▲ページの先頭へ -> さんかくぺーじの先頭へ

とかになってしまうが、回避する策はあるだろうか... 要素内容が「記号とスペース」のみの場合だけ変換する? う〜んいまひとつかもしれない。

イメージマップについて

イメージマップについても正しく記述していればちゃんと読み上げてくれる。 但し、AREA要素を使う場合はALT属性が必要。

ということで変換しなくても良いのだが画像を削除あるいは外部リンクに変換する関係でそのままではまずかろう。

単にAREA要素をリンクに変換すれば使えるのだが、一連のひとかたまりのリンクということでUL〜/ULの形式に変換する。

以下は Yahoo! Japan の例

Yahoo! Japanのイメージマップの画像 

<img src="http://i.yimg.jp/images/main13.gif" width=675 height="60" usemap="#Map" border=0 alt="Yahoo! JAPAN">
<map name="Map">
<area shape="rect" coords="194,1,430,57" href="/r/lg">
<area shape="rect" coords="626,1,670,16" href="/r/ht" alt="ヘルプ" title="ヘルプ">
<area shape="rect" coords="627,22,672,40" href="/r/et" alt="登録情報">
...
</map>

変換後のHTML


[画像:<a href="/naked.cgi/default/http://i.yimg.jp/images/main13.gif">Yahoo! JAPAN</a>]
<ul class="image_map">
<li><a href="/naked.cgi/default/http://yahoo.co.jp/r/lg">/r/lg</a></li>
<li><a href="/naked.cgi/default/http://yahoo.co.jp/r/ht">ヘルプ</a></li>
<li><a href="/naked.cgi/default/http://yahoo.co.jp/r/et">登録情報</a></li>
...
</ul>

問題は1つめのリンク。ALT属性がない。ALT属性がないものはぶった切ってしまえ! と思ったけれどイメージマップしか置いていないページ (ALT属性もないし) をこのあいだ目にしたので、仕方ない。リンク先のパスをALTの代用とすることにした。

現状はこのようにしているが一点問題があって、MAP要素はコード上のどこに置かれるかわからないのだ。


<map name="menu">
<area... />
<area... />
</map>

<p>以下のメニューから選択してください。<p>

<p><img src...usemap="#menu" /><p>

そのまま変換すると「以下のメニュー」じゃなくなるのだ。位置関係がおかしくなってしまう。

アンカーで飛ばすか、あるいはスマートなのはこんな感じか。

<dl>
<dt>[イメージマップ:<a href="/naked.cgi/default/http://i.yimg.jp/images/main13.gif">Yahoo! JAPAN</a>]</dt>
<dd>
<ul>
<li><a href="/naked.cgi/default/http://yahoo.co.jp/r/lg">/r/lg</a></li>
<li><a href="/naked.cgi/default/http://yahoo.co.jp/r/ht">ヘルプ</a></li>
<li><a href="/naked.cgi/default/http://yahoo.co.jp/r/et">登録情報</a></li>
...
</ul>
</dd>
</dl>

変換方針

  • イメージマップは、リスト＋リンクに変換する。
  • 画像とイメージマップの項目の関連付けについては要検討。

「イメージマップ」って言葉がわかりやすいかどうかが気にはなるが。

以下、テスト用

  • 読み上げないテキスト
  • 読み上げるテキスト
  • 挿入されたテキスト(日付指定あり)
  • 削除されたテキスト(日付指定あり)
  • 挿入されたテキスト(日付指定なし)
  • 削除されたテキスト(日付指定なし)

次は、↑この件について。

関連エントリー

カテゴリー: アクセシビリティ

タグ:

投稿者: Junnama Noda 日時: 2007年05月18日 14:37 |

2007年05月17日

音声ブラウザと相性の良いHTMLを作る(2)。

引き続きウェブアクセシビリティ関連の話題。

関連エントリー

このエントリーの続きだが、今回は単に音声ブラウザとの相性だけでなくレイアウトのためのテーブル関連要素を判別してカットする考え方について書く。

※実はこのエントリーを書く段階で、テーブルの良いサンプルを見つけようと思い「週間天気予報」で検索して「気象庁 週間天気予報」を見つけたのだが...うまく変換できなかったのでプログラムのロジックを変更させられた。ちょっとこれは無いんではないか、気象庁御中。


<table>
</p><br>
<b>全国主要地点の週間天気予報一覧</b>
<p>5月17日17時<br>
<table class="forecastlist" id="infotablefont">
...

HTMLにおけるテーブルの扱い

テーブル自体は正しくマークアップしてあれば (本来の) 2次元で表現できる情報をわかりやすく表現できるし、ホームページリーダー等でもテーブルの読み上げモードが用意されている。

※今ちょっと手元に環境ないので記憶曖昧だが、「表の先頭」とかちゃんと読み上げてくれる(はず)。

HTMLとテーブルについてはこちらを参照されたし。気象庁と戦ったおかげ? で解説まで書く気力もないし。

氏名 年齢 血液型
野田純生 40歳! A型

例えばこんな表を、

氏名→野田純生, 年齢→40歳(不惑? 厄年?), 血液型→A型

ってな具合に読み上げることも可能なのだ。

ところが「テーブルレイアウト」である。表に次ぐ表のオンパレード。どう読み上げれば良いのだろう。

ということでレイアウトのために用いられている「であろう」テーブルをぶった切ることにする。

※「テーブルをぶった切る」っていうと「ちゃぶ台をひっくり返す」みたいですな...

変換方針

  • TABLE要素の子要素に表の構造を表す「CAPTION要素, TH要素」を持たないもので、TABEL要素の「SUMMARY属性」が指定されていないTABLEをレイアウト目的のTABLEとみなす
  • レイアウト目的のTABLE要素については、
    • (レイアウト目的とみなした)TABLE要素自身→削除
    • TR要素→DIV要素に置換
    • TD要素→半角スペース(&nbsp;)に置換
    • THEAD,TBODY,TFOOT要素は削除

方針を書くところまでは早いのだけれど、実装となるとなかなかにコストのかかる処理になってしまった。

TD要素の中にはTABLE要素が置けるから、


<table>...<tr><td>...<table>...</table>...

というように「ネスト」できるのだ。だから単純に


$src =~ s/<table.*?</table>/ほにゃらら/igs;

みたいなことが出来ない。パーサ使う? ってのもどうかと思うし(何しろ、きちんとパース出来る保証はどこにもないのだから)...とにかく一応 split で切ってループで処理させてみた。段々重くなるような気がするぞ。

この方針に沿って変換したのがこれ(すっぴんバージョン)。

で「裸」にしたら服を着せてみたくなるのが人情, ということでCSSを充ててみたのがこれ。

ね、それなりにCSSベースのレイアウトになってるでしょう?

追伸:
頑張れ! 気象庁

引き続き、次回以降は「日付」「記号」「数式」などについて。

関連エントリー

カテゴリー: アクセシビリティ

タグ:

投稿者: Junnama Noda 日時: 2007年05月17日 19:58 | | コメント[ID:1428] (0) | トラックバック[ID:1428] (6)

プロトコルとTPO。

まともなメールのひとつも送れない学生...

色んな意見があるなぁ...と。

どなたかが「プロトコルの違い」と仰っていたように思うが、プロトコルとは約束事とか儀礼のことである

「プロトコルの違い」にはとどまらなくて『異なるプロトコルで違うポートに接続しにいくようなもの』ですかね。

POPサーバーだったら「HELLO」とかFTPだったら「USER」とかっていうのを何も考えずに「GET」とか、『いつもGETで通ってますから』ってなもんで。

だから、『今どきFTPサーバーないの!?』みたいな指摘は的外れだしね。

実際、僕が携帯から社内メーリングリストに送るメールには署名も入れないし「野田です」も入れないけど、顧客や取り引き先へメールを送る時にそんなことはあり得ない。

どうでも良いけど、「はてな」"※デフォルトではないのかな? ってか特定のサービスに限ったことじゃないけど。"とかで、 「このページをアンテナに追加」とか「RSSフィード」ってのが見出し (<h1>) の中にあるってのも UserAgent (例えば音声ブラウザ) に対する「プロトコル(謎)」を考えていない、ということなんだろうなぁ。

カテゴリー: 駄文・雑文

投稿者: Junnama Noda 日時: 2007年05月17日 02:58 | | コメント[ID:1427] (0) | トラックバック[ID:1427] (0)

2007年05月16日

音声ブラウザと相性の良いHTMLを作る(1)。

先週から「音声ブラウザ用にできるだけ読み上げやすいHTMLに変換するゲートウェイ」なるものを少しずつ書いている。

関連エントリー

毎日少しずつ修正しているのだけれど、どうやって読み上げやすいHTMLへ変換するかについての考え方を(これも少しずつ)書いてみよう。

画像に関する問題

画像には等価なaltテキストが指定されている筈、という前提に立たないで考えないといけないから、どんな条件の場合にはどんな画像が利用されるかについて考えて処理を行う必要がある。

画像には等価なaltテキストが指定されているのであれば画像はすべてaltテキストを展開すれば良いわけだが、続けて読み上げて意味の通る文章になるとは限らないのだ。

また、敢えて「画像」であることが分かったほうが良い場合もある。

画像がそこにあることを理解出来た方が良い画像


日本について。<img alt="富士山" src="fuji.jpg" />

というようなHTMLの場合、

日本について_[一拍置いて]_ 富士山

「富士山」が装飾のための画像だったら、何だかおかしくなってしまうだろう。

日本について_[一拍置いて]_[声を変えて]_富士山_についての写真があります

とすれば「そこに画像があるんだな!?」っていうのが分かる。音で読み上げているにしても「そこに写真があるんだな!?」ってなことが把握したいケースがある筈だ (例としてはあまり良くないかもしれないが)。

画像が「視覚的な」装飾のためでのものあれば以下のように書くべきだろうが、それが装飾のための画像かどうかの判断は (文脈でも理解しない限りは) 不可能である。

日本について。<img alt="" src="fuji.jpg" />

「画像＝コンテンツの一部」である場合、強制的にテキスト変換だと困るし (画像であることが理解できるようにして欲しいだろうし)、alt属性を空にすべきではないものもある。

例えば「地図」の場合

自分が「視覚的」に地図を見ることができなくても、印刷して (それを誰かに見せて) 人に説明を求めることだってできるし、現地で誰かに地図を見せて道を尋ねることもできる。

「何番出口を出てどういってこう行って」等のaltテキストを指定するとベストなのだろうが、現実的にそんなページは殆ど無い。

画像を画像へのリンクにしたら(イメージへの直接リンクは良くない、ということに注意は必要)読み上げ音声も(ホームページリーダー等の場合)変化するし、画像をプリントすることもできるだろう。ただし、その場合のリンクテキストについては

地図_についての写真があります

だと不自然だろうから、単純に

画像_地図

とかの方が良いのかもしれない。また、alt属性に「画像:地図」とか書いてあるページがあって、その場合は重なってしまう(画像_画像_地図)ので「画像」で始まるalt属性の場合は単純にalt属性をただ展開すれば良いだろう。

変換方針

  • 画像は画像へのリンクに変換し、リンクテキストは「画像」＋「altテキスト」とする (それが画像であることが理解できるようにするため)
  • リンクテキストの先頭部分が「画像」にマッチしたらリンクテキストは「altテキスト」とする (冒頭に「画像」を付加しない)
  • altテキストが空の画像は無視する(画像ごと切ってしまう)

画像が視覚的なアクセントや「機能」を表す場合

いわゆる「パンくずリスト」について、

<img alt="現在位置" src="you_are_here.gif" /> ホーム <img alt="の中の" src="arraw.gif" />...

のように音声読み上げ環境に配慮したHTMLがある。これを画像をリンクにして

画像_現在位置

ではちょっと困る。

画像_現在位置_ホーム_画像_の中の

せっかくの配慮が逆効果になってしまう。もちろん「現在位置_についての写真があります」ではもっと困る。

この場合は画像は画像でも、そこに画像がある/ないを意識させないのが親切だろう。

同じく、リストマーカーのような画像(例えば行頭の矢印)等の画像について、


<img alt="→" src="arraw.gif" />
<img alt="矢印" src="arraw.gif" />

とかいう指定をしているもの。これは alt="" にすべきケースが殆どなんだろうが、

画像_矢印

なんて読み上げたら鬱陶しいことこの上ないだろう。

そこで、小さな画像は概ね「写真」や「画像」そのものが意味を持つものではないという仮説を立てる。width属性とheight属性を見て一定サイズ以下だったら「画像_altテキスト」とせずに単にaltテキストを展開する。

変換方針

  • 一定サイズ以下の画像は altテキストをそのまま展開する

見出しやボタンのための文字の画像化

「見出し」文字を画像化しているケースも多いだろう。これはプロのウェブデザイナーでもやっている。CSSで画像置換 (Image Replacement) というテクニックも一時流行ったが、画像オフ/CSSオンだと何も見えなくなるということで最近は下火のようだ。


<h1><img src="product.png" alt="製品案内" /></h1>

これが、

[見出し強調された(且つリンクになっている)音声で] 画像_製品案内

これも"ちと"辛い。この場合は「画像であることイコール見栄えを良くしたい」わけだから、音声読み上げ環境のユーザーには関係のないことである。この場合は

[見出し強調された音声で] 製品案内

であるべきだろう。

見出しと似たケースでは「画像ボタン」があげられる。ボタンが「クリック」しやすいように画像にする。ユーザビリティ面でも「ボタンは一目でボタンとわかるように」とか「ボタンは"押せる"ように」とかの鉄則? があるし。この場合も、


<a href="product.html"><img src="product.png" alt="製品案内へ" /></a>

の読み上げは、単純に以下のようになるのが良いだろう。

[リンク用音声で] 製品案内へ

変換方針

  • 見出しとアンカーの中の画像は altテキストをそのまま展開する

まずは画像について書いたが、まだまだ考慮すべき問題はある。

例えば「日付」「記号」「通貨」「日本語の単語の空白文字での分割」等。これらについてもおいおい書いていこうと思う。

でも、何と言っても難しいのが「レイアウトのためのテーブルと構造を示すテーブルが混在しているHTML」である。これについても考え方はある程度固まっているけれども。

続きは以下のエントリーで

カテゴリー: アクセシビリティ

タグ:

投稿者: Junnama Noda 日時: 2007年05月16日 22:21 | | コメント[ID:1426] (0) | トラックバック[ID:1426] (5)

2007年05月15日

音声ブラウザができるだけ読み上げやすいページに変換しようと試みるゲートウェイ(続き)。

以前のエントリーでご紹介した「音声読み上げ向けページ変換ゲートウェイ」ですが、変換速度の向上といくつかの変換アプローチの見直しを行った上でいくつかのデザインスキンを適用出来るようにしました。

関連エントリー

簡単なデモページを用意しました。

オリジナルページ

音声ブラウザ向け

デザインを適用

以下の通り、記号は使っているわ、文字揃えのために地域名は分割しているわ、日付は「/」で区切っているわ、広告は入っているわ...というパターン。

※このエントリー上では数値参照化しています。

※5月16日少し修正, 記号、(何となく)数式対応にしました。



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>デモページ</title>
</head>
<body>
<pre>
⑴　2007/05/16㈬　北海道 &nbsp; 製 品 デ モ　¥10,000
⑵　2007/05/17㈭　東　北 &nbsp; 製 品 デ モ　¥10,000
⑶　2007/05/19㈯　関　東 &nbsp; セ ミ ナ ー　¥10,000
⑷　2007/05/20㈰　近　畿 &nbsp; セ ミ ナ ー　¥15,000
⑸　2007/05/21㈪　香　港 &nbsp; 懇　親　会　　 $200

主催：ＡＢＣ㍿
</pre>

<div style="float:right;padding-left:1.5em"><script type="text/javascript">
<!--
google_ad_client = "pub-1511440356861540";google_ad_width = 120;google_ad_height = 240;google_ad_format = "120x240_as";google_ad_type = "text_image";google_ad_channel = "";google_color_border = "FFFFFF";google_color_bg = "FFFFFF";google_color_link = "335C85";google_color_text = "555555";google_color_url = "555555";
//-->
</script><script type="text/javascript"  src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script></div>

</body>
</html>

カテゴリー: アクセシビリティ

投稿者: Junnama Noda 日時: 2007年05月15日 21:51 | | コメント[ID:1425] (0) | トラックバック[ID:1425] (2)

Google 対 Yahoo!

えーっと、検索の質とかそういう問題ではなくて。

Another HTML-lint gatewayでのチェック結果。

  • Google 日本
    80個のエラーがありました。このHTMLは -215点です。
  • Yahoo! Japan
    869個のエラーがありました。このHTMLは -443点です。

点数だけで比較は出来ないですね(っていうか、どっちもどっち)。タグが 29種類 1462組使われています(Yahoo!)、とタグが 28種類 62組(Google)だからね。

こうやって書く理由ですが単なるHTMLへの純粋な?ツッコミではなくて、ちょっと昨日