ウェブコンテンツ・テキストバージョン・ジェネレーター(Naked Beta)。

Naked (Beta)について

「音声ブラウザと相性の良いHTMLをつくる」というコンセプトで開発を始めた「ウェブコンテンツ・テキストバージョン・ジェネレーター(ゲートウェイ)」です。

• Naked (ウェブコンテンツ・テキストバージョン・ジェネレーター)

以前にも紹介しましたが、その後色々と調整を行い実用レベルになったと思うので、このブログの各ページに各モード(スキン)変換のためのリンクを設置したついでにブックマークレットを作りました。宜しければご利用ください。

これは何?

• HTMLからCSSや装飾部分, JavaScript等を削除します。
• 一定サイズ以下の画像はALT属性の文字列に置き換え、一定サイズ以上の画像は外部リンクに変換します。*
• 音声読み上げの際に問題になることの多いいくつかの問題 (日付のフォーマット、機種依存文字、DEL要素,INS要素、スペースによる日本語の分割等) の解決 (読み上げやすい、あるいは読み上げて意味の通りやすいフォーマットへの変換) を試みます。
• レイアウト用のテーブル要素 (らしきもの) を削除してできるだけプレーンなHTMLに変換します。
• PDFをテキスト化します。
• 上記の変換を行った上で、各スキンの適用やルビ振り処理を行います。

* 画像については実際はもう少しインテリジェントな? 処理を行っています。見出し要素の中の画像は「テキストが画像化されたものだろう」、とかアンカーの中の画像は「ボタン」だろうとか。詳しく知りたい方は関連エントリーをご覧ください。

ブックマークレット

• =>読み上げ用
• =>ルビ付き
• =>配色反転
• =>文字拡大

サイト貼付け用JavaScript

このブログに貼っているJavaScript↓そのまま使っていただいても構いません。

<script type="text/javascript" src="/online/naked.js"></script>

H3要素で「スタイル：」というラベル、各リンクはUL, LI要素によるリストです(このブログではCSSで一行に並べています)。

より詳細な仕様について

関連エントリーをご覧ください。実装の課程で書いたものです。どういうコンセプトでどのような処理を行っているかを書き連ねています。

関連エントリー

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

制限事項

• httpsからはじまるURLのページには対応していません。
• クッキーが必要なページやログインが必要なページには対応していません (ブログのコメント程度であれば問題ないと思います)。
• HTMLやPDF文書の容量は4MBまで対応しています (実際に視覚障害者の方に要望をいただいたため、1MBから4MBに制限をゆるめましたが、サーバー負荷の問題もありますので暫く様子を見たいと思います)。
• サービスは予告なく停止する場合があります。

プライバシーについて

• フォームからポストされたデータ等は運営側では一切保持しません。
• ゲートウェイから実際のサーバーへのHTTPリクエストヘッダ (UserAgent情報) にIPアドレスが付加されます(匿名プロキシとしての利用対策)。
• IPアドレスと閲覧ページのURLについてはログに保存しています。

ちょっと宣伝

CMS製品への組み込みや企業や自治体様のサイトへの導入やカスタマイズについてはご相談ください。

また、Nakedと共通(一部のみ)のテキスト変換ルーチンを組み込んだMovable Typeのプラグイン(Movable Type Jaccessibilityプラグイン)を提供しています。

---

ウェブ制作に携わるデザイナー、コーダー、エンジニアの方へ僕が伝えたいこと

僕の立ち位置はどちらかといえば実装系であったりアクセシビリティ系のコンサルティングだったりする (と思われているのかも) わけですが、別にデザイナーでもプログラマーでもどっちでもえーやん! って思ってます。良いものを作るためには立ち位置や自分の職種なんてどうでも良い。最近はHTMLやCSSよりももっぱらPerl書いている方が多かったりするけれど、それは他の人とは違ったアプローチで物事を解決するのが楽しいからに過ぎません(仕事でもあるけれど)。

だから「どっちが上」とか「どっちが下」と言わないまでも心のどこかで他方を軽蔑したり逆に自分たちを卑下したりするなんて非生産的なことはやめて、それぞれの立場でを理解したり物事を考えると理解も深まるし協力して良いものが出来るよ、ということが言いたい(これは常々思っていた)。

例えばこのプログラムを作る過程で「XHTMLはどう書くべきか」っていうのがすごく見えてきた。これはプログラマやUA開発者の目線で「どう渡されたら読み上げやすいよね」というのを徹底的に考えたからです(もちろんその先にはユーザーがいます)。

逆に、僕は最近MTを良く触るわけですが (アクセシビリティの人じゃなくてすっかりMTの人になっちゃったね、って最近言われる(苦笑))、MTベースで開発をするプログラマ的立場の時は実装系のウェブデザイナーに分かりやすいテンプレートタグとリファレンスを用意して渡す (何より自分が楽になる)。

だからそういう選択でMovable Typeになった。MTタグだったらデザイナーとプログラマーが共通言語で話せる。

エンジニア目線で作ったテンプレートエンジンの記法はウェブデザイナーに理解しにくいものが多いと思う。それは「あいつらが分かってねぇ」のではなく真面目に協業する気がないのである。

というようにいつもプログラマと実装者の協業やコミュニケーションについて考えている今日この頃。

いつか「Web業界のウッドストック」が出来るといいね!(＜古!)