2009年2月 | Web標準Blog | ミツエーリンクス

Home > メソッド > Web標準Blog > 2009年2月

Web標準Blogでは、Web標準の利用に興味のあるWebサイト管理者、Webデザイナーの方向けに、Web標準を利用するための手法やノウハウ、参考になるリソース等を、国内外を問わずご紹介します。

なお当Blogでは、Web標準に関する疑問や質問を募集しています。Webコンテンツ実装プロセスにまつわるお悩みでも結構ですので、お気軽に電子メールでstandards@mitsue.co.jp宛にお送りください。

2009年2月27日

Progressive Enhancementの実践と普及にむけて

フロントエンド・エンジニア矢倉

前回は実装におけるGraceful DegradationとProgressice Enhancementの違いについて説明しました。もうひとつ、Progressive Enhancementな例をお見せして、このシリーズを終わらせたいと思います。

Flashの埋め込みもProgressive Enhancementなやり方で

Flashの埋め込みについても、JavaScriptを用いた方法が盛んに行われているように思います。しかし、このやり方ではスクリプトが無効な環境でFlashが表示されません。また代替内容があったとしても「Flashプレーヤーが必要です」というメッセージがでるものが多く、適切な使われ方がされていないように思います。

動きを与えるムービーや動画など、代替となるコンテンツがそもそも存在し得ないものであれば仕方が無いかもしれません。しかし、サイトのナビゲーションがFlashで構成されている場合などは、適切な代替情報を指定する必要があります。

ナビゲーションとしてFlashが使われる場合、最低限必要なのは代替となるナビゲーションです。

<ul>
  <li><a href="/">ホーム</a></li>
  <li><a href="/products">製品一覧</a></li>
  <li><a href="/ir">IR情報</a></li>
  <li><a href="/recruit">採用情報</a></li>
  <li><a href="/inquiry">お問い合わせ</a></li>
</ul>

ここでは単純なリンクのリストを書いていますが、もちろん画像などを利用することもできます。

さて、Flashなどの埋め込みコンテンツは、object要素で記述します。img要素と違い、中に代替情報を記述することができます。

<object type="application/x-shockwave-flash"
        data="flash.swf" width="780" height="250">
  <param name="movie" value="flash.swf" />
  <!-- 代替情報 -->
</object>

param要素でファイル名が重複していますが、これはInternet Explorerで認識させるための指定です。

Flashを利用できる環境ではFlashを読み込ませたいので、先ほど用意したナビゲーションリストを、このobject要素で囲ってしまいましょう。

<object class="flash" type="application/x-shockwave-flash"
        data="flash.swf" width="780" height="250">
  <param name="movie" value="flash.swf" />
  <ul>
    <li><a href="/">ホーム</a></li>
    <li><a href="/products">製品一覧</a></li>
    <li><a href="/ir">IR情報</a></li>
    <li><a href="/recruit">採用情報</a></li>
    <li><a href="/inquiry">お問い合わせ</a></li>
  </ul>
</object>

これで、JavaScriptに頼らず、またembedなど非標準なやり方ではないFlashの埋め込みを実現できます。

しかしながら、Flashファイルが何かの理由でロードできない場合などは、きちんとフォールバックされる保証がありません。構築前に、そもそもFlashにナビゲーションを含む必要があるか考えることも大切でしょう。

JavaScriptによる処理の重ね方

Flashの埋め込みにJavaScriptが使われる理由のひとつに、Internet Explorerのプラグイン特許問題によって起こった修正を回避するものがあります。しかしこの問題についてはパッチがWindows Updateで提供されたため、今日ではアクティベートを目的としてJavaScriptを利用する必要はありません。

もうひとつの理由は、Flash Playerのバージョンをコントロールしたいというものです。これはHTMLからでは制御できないため、JavaScriptを利用する必要があります。しかしながら、全てをJavaScriptで完結させる必要はありません。HTMLはそのままに、必要な部分をJavaScriptで補ってあげればよいのです。

昨年公開しましたMJLには、先ほど書いたマークアップを生かしつつも、Flashのバージョンを指定してロードさせる機能が備わっています。

MJL本体と実行ファイル (run.js) をscript要素より読み込み、実行ファイルに次のように記述してください。

MJL.event.add(window, "load", function(event) {
  MJL.enable.flash("flash", { version: 9 });
}, false);

バージョン8以下のFlash Playerを導入したコンテンツには、代替情報が提供されることになります。

param要素で指定することにより、Flashコンテンツごとに指定することも可能です。

<object type="application/x-shockwave-flash" data="...">
  <param name="movie" value="..." />
  <param name="version" value="9" />
  <!-- 代替情報 -->
</object>

対象外のバージョンを利用する環境に対して、メッセージを提供することも可能です。

MJL.enable.flash("flash", { version: 9, minVerMsg: '<p>（メッセージ）</p>' });

<object type="application/x-shockwave-flash" data="...">
  <param name="movie" value="..." />
  <param name="version" value="9" />
  <param name="minVerMsg" value="&amp;lt;p&amp;gt;（メッセージ）&amp;lt;/p&amp;gt;" />
  <!-- 代替情報 -->
</object>

今回はMJLを利用しましたが、広く利用されているSWFObject（バージョン2以降）でも同様に、Progressive Enhancementなやり方でFlashを埋め込むことができます。

Progressive Enhancementが受け入れられるためには

Graceful DegradationとProgressive Enhancementを比べると、Progressive Enhancementの方が考え方としては好まれるでしょう。

しかし、CSSなど見た目に関するEnhancementは、「どのブラウザーでも同じ見た目で」という要件や制作期間の制限により、Web制作業ではなかなか手を出しづらいかもしれません。少しずつ、閲覧環境が多様であることの周知をしていく必要があるように思います。

この点、DOMスクリプティングにおいては比較的容易に行うことができると思っています。MJLを例にとってみますと、策定中ですが既に実用段階にあるSelectors APIやgetElementsByClassNameメソッドを利用することで、APIを実装するブラウザーでのパフォーマンス向上を行っています。Progressive Enhancementといえるかどうかは分かりませんが、高速化や内部処理の簡略化においては、新しい機能を取り込むことへの抵抗は、CSSほどではないでしょう。

なかなか難しいと思われるのが、Webアプリケーションでの実践です。JavaScriptありきで開発されることが多いため、HTMLにJavaScriptを重ねるという開発手法はとられていないからです。

しかしながら、不可能ではないと考える人も大勢おり、その中の一人であるJeremy Keithは「Hijax」という手法を提唱しています。彼が2006年のXTechで発表したHijaxについてのスライドを読むと、“Plan for Ajax from the start. Implement Ajax at the end.”という考え方を核に、WebアプリケーションでのProgressive Enhancementの実践についてまとめられています。発展途上ではありますが、WAI-ARIAなどWebアプリケーションのアクセシビリティについて需要が高まるであろう今後を考え、取り組んでいくことが必要でしょう。

恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]

2009年2月25日

WAI-ARIAの最終草案とSafari 4

フロントエンド・エンジニア木達

2009年2月24日
Derek Featherstone著

（この記事はWeb Standards Project（WaSP）における投稿記事「WAI ARIA Last Call, and Safari 4」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）

W3CよりWAI-ARIAの最終草案が公開されました。いみじくも、同仕様のサポートを改善したSafari 4のベータ版がリリースされています。

2008年12月、Web Content Accessibility Guidelines（WCAG）2.0が正式に勧告されました。しかし、アクセシビリティという名の車輪はその回転を止めてはなりません！アクセシビリティに重大な影響を及ぼす別の領域もまた、W3Cによって前進し続けています。

本日、W3Cのプロトコルとフォーマット・ワーキンググループは、WAI-ARIAの最終草案を公開しました。これは同ワーキンググループが、仕様を次のステージへと進展させる準備ができたと確信していることを意味します。ここでは、W3Cの仕様策定プロセスの詳細は割愛します。皆さんが知っておくべきなのは、この草案に対してW3Cへフィードバックを送れるのが2009年3月24日までだということです。

WaSPアクセシビリティ・タスクフォースのJames Craigは、同ワーキンググループの一員としてWAI-ARIAの策定に従事してきました。本件に関して、Jamesの功績を讃えたいと思います！

WaSP国際リエゾングループの副リードであるHenny Swanは、皆さんが仕様に取り組むきっかけにと、WAI-ARIA仕様にまつわる質問をいくつか集めて公開しました。

もう一つ注目すべきは、Safari 4に対するコメントや批評が多く出始めていることです。皆さんは、Safari 4の新機能リストの先頭に何があるか、ご覧になりましたか？

そう、その通り。WAI-ARIAを含むアクセシビリティの項です。

これは何年も先のお話ではありません。今まさに目の前で起きていることであり、将来に向けてアクセシブルなWebアプリケーションを作成することは重要なのです。そういわけで、どうか仕様に取り組み、一読のうえフィードバックを送ってください。たとえそれが些細なことであろうとも！

恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]

2009年2月25日

Safari 4パブリックベータがリリース

フロントエンド・エンジニア矢倉

昨晩のことですが、Safari 4のパブリックベータがリリースされました。UIの大幅な刷新が図られたほか、昨年発表された高速なJavaScriptエンジンも搭載されています。

次世代を感じさせるUI

なんといっても、UIの変更に驚かれた方が多いのではないでしょうか。上部に移動したタブ、Top Sites、スマートロケーションバーなど、Google Chromeを強く意識したものとなっています。

また、Windows版はこれまでのAppleらしい、メタル調の概観からWindowsのネイティブウィジェットに近いものに変更されています（フォントスムージングもClearTypeが既定の設定になっています）。

SafariのUIは、他のモダンブラウザーと比べ「ベーシック」な印象が強かっただけに、この刷新はとても大きく感じました。

WebKitの進化

レンダリングエンジンですが、WebKitが新しいバージョンになり、WAI-ARIAのサポートや、Acid 3への対応など、各種Web標準への準拠度が高まっています。また、HTML5のオフラインデータベースや、CSS Animation/Transition/Transformsといった新しい仕様の実装も進んでおり、今後の広がりを期待させます。

パフォーマンスに関しても大きく向上しているように感じます。昨年に「Squirrelfish」というコードネームで呼ばれていたJavaScriptエンジンが組み込まれ、「Nitro」という名称で発表されています。

2009年2月20日

Graceful DegradationとProgressive Enhancementの実践

フロントエンド・エンジニア矢倉

Chris Heilmanによる“Graceful degradation versus progressive enhancement”という記事について、前回は概要とその意義について紹介しました。今回は後半にあるの例をもとに、どのように実践していくのかを考えてみたいと思います。

「印刷する」というリンク

オンラインショッピングの決済画面には、印刷して手元に保管したいというニーズがあるからか「印刷する」といったリンクやボタンが設けられています。クリックしたときに印刷用ページが現れるものもありますが、記事では印刷ダイアログが現れる簡単なものを取り上げています。

このようなリンクは、JavaScriptにより実現されています。

<p id="printthis">
  <a href="javascript:windowprint()">Print this page</a>
</p>

しかしながら、JavaScriptが無効な環境では、リンクが機能せず全く意味がなくなってしまいます。というわけで、noscript要素を利用して、利用できない環境に向けたメッセージを記述することにしましょう。

ただ、「JavaScriptが有効になっていません」といったものはあまり意味がありません。「その機能が何で実装されているか」という情報を、ユーザーが直接求めているわけではないからです。なので、ここではブラウザーの印刷機能について書くことにしましょう。

<p id="printthis">
  <a href="javascript:windowprint()">Print this page</a>
</p>
<noscript>
  <p class="scriptwarning">
    Print a copy of your confirmation. 
    Select the "Print" icon in your browser,
    or select "Print" from the "File" menu.
  </p>
</noscript>

「『印刷』アイコンまたは『ファイル』メニューより『印刷』を選択することで、印刷することができます。」といった文を書くことで、代替手段を直接提供はしないものの、ユーザーにその存在を伝えることができます。

起こってしまった問題への「対処」という側面が強いので、これはGraceful Degradation的なアプローチといえるでしょう。では、Progressive Enhancementでは、どのようなアプローチになるでしょうか。

Progressive Enhancementな印刷リンク

Progressive Enhancementは、最低限提供したい機能や目的を「ベースライン」として設定します。印刷リンクは「ページを印刷したいというユーザーのニーズに答える」ことが目的ですから、まず「ページの印刷について言及する」ことをベースラインとしましょう。

<p id="printthis">Thank you for your order.
 Please print this page for your records.</p>

まず「印刷して保管できます」ということを伝える文を書きます。もちろん、先ほどのように、ブラウザーの印刷手法について言及するのも悪くないでしょう。

さて、印刷リンクはどのように実装すればよいでしょうか。ここで登場するのが、「Unobtrusive JavaScript」という考え方です。「おせっかいではないJavaScript」という意味のこのキーワードですが、簡単に説明すると、不必要にUAやHTMLに干渉したり依存したりすることのないようにJavaScriptを書くことです。

「おせっかいなJavaScript」の例としては、リンク先を新規ウインドウやポップアップで開く、次のようなコードが該当します。

<a href="#" onclick="window.open('popup.html','_blank')">ポップアップ</a>

JavaScriptが無効な環境では、通常のページ遷移すら行われないため、情報にアクセスすることができなくなってしまいます。このようなおせっかいをせずに、印刷リンクを追加するコードを書くわけです。

記事の中で、Unobtrusive JavaScriptな印刷ボタンを追加するコードは、次のように実装されています（この例ではリンクではなく、ボタンになっています）。

(function(){
  if(document.getElementById){
    var pt = document.getElementById('printthis');
    if(pt && typeof window.print === 'function'){
      var but = document.createElement('input');
      but.setAttribute('type','button');
      but.setAttribute('value','Print this now');
      but.onclick = function(){
        window.print();
      };
      pt.appendChild(but);
    }
  }
})();

getElementByIdの存在や、window.print()が機能するかを確かめた上で、ボタンをDOMにより生成し、先ほどの段落に追加しています。

最終的なコードは、次のようになります。

<p id="printthis">Thank you for your order.
 Please print this page for your records.</p>
<script type="text/javascript">
(function(){
  if(document.getElementById){
    var pt = document.getElementById('printthis');
    if(pt && typeof window.print === 'function'){
      var but = document.createElement('input');
      but.setAttribute('type','button');
      but.setAttribute('value','Print this now');
      but.onclick = function(){
        window.print();
      };
      pt.appendChild(but);
    }
  }
})();
</script>

ブラウザーがJavaScriptコード中で必要な機能を満たすときのみ、印刷ボタンが現れます。

このやり方は、印刷リンク（ボタン）だけではなく、文字の拡大縮小インターフェースなどにも利用することができるでしょう。まずブラウザーの文字サイズ変更機能について言及し、インターフェースをあとからJavaScriptで組みこむのです。

今回の印刷ボタンは、window.print()というブラウザーのAPIにどうしても依存してしまうものなので、「実現したいもの」と「最低限必要なもの」の差が大きく開いている例です。次回は、漸進的なEnhancementの例をお見せしたいと思います。

恒久リンク | コメント [2件] | 関連情報（トラックバック） [0件]

2009年2月13日

Web Forms 2を統合した新しいHTML5の草案が公開

フロントエンド・エンジニア矢倉

新しいHTML5の草案が昨日、付属文書とともに公開されました。

前回の草案公開は去年の6月でしたので、8ヶ月ぶりのリリースとなります。数多くの更新が行われていますが、主要な変更点は“HTML 5 differences”の“Changes since 10 June 2008”というセクションにまとめられています。いくつか気になったものを抜粋してみます。

HTMLのフォームを拡張したWeb Forms 2.0がHTML5に統合されました。input type=dateやinput type=emailなどはOperaで実装されており、入力した内容の検証を行うことができます。また、HTML5への統合にあたり、新たにinput type=colorやinput type=searchなども追加されています。
a要素がflow content（ブロック要素に近い概念）を囲むことができるように、内容モデルが変更されました。これまではphrase content（インライン要素やテキスト）にとどまっていたことから、大きな変更となります。
双方向通信のためのWeb Socket APIが追加されました。しかし、プロトコルについてはIETFが、このAPIについては今後Web Applications WGが引き継ぐことになっています。
非規範的なレンダリングに関するセクションが追加されました。内容については引き続き作業中ですが、デフォルトスタイルシートのヒントなどもまとめられています。

そのほかについては、“HTML 5 differences”の日本語訳を行いましたので、そちらを読んでいただければと思います。

“HTML 5 ― HTML 4 からの変更点”

ブラウザーの実装もすこしずつ始まる中、HTML5は年内のLast Callを目指し引き続き策定されています。

恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]

2009年2月10日

Webデザインプロフェッショナルワークフロー・バイブル

フロントエンド・エンジニア木達

今月の下旬に、毎日コミュニケーションズより『Webデザインプロフェッショナルワークフロー・バイブル』と題した書籍が発売されます。本書は英国を拠点に活躍されているWebデザイナー、Andy Clarke氏の著書『Transcending CSS』の日本語翻訳版であり、私にとっては通算で7冊目の監訳書です。既に一部のオンライン書店では、予約の受付も始まっています。

原著のタイトルにこそCSSの3文字が含まれていますが、決してWeb標準にまつわる話題だけを取り扱ったものではありません。もちろん、CSS3のAdvanced Layout Moduleを用いたテクニックなど、技術的な解説も多分に含まれてはいますが、一般化した既存のワークフローに対する改善の提案だったり、デザイン上のインスピレーションをいかにして得るかなど、話題は多岐に渡ります。概してClarke氏ならではのWebデザイン論となっており、(X)HTMLやCSSをある程度ご存知の方はもちろん、ビジュアルデザイン領域を専門とされる方にも楽しんでいただけるのではと思います。

なお、Clarke氏については以前、ミツエーリンクスVideocastingにご出演いただいたことがあります。収録をしたのは2006年9月のことでしたが、原著の発売を2ヶ月後に控えた時期の内容であり、インタビューの後半で書籍に触れています。

原著の出版から日本語翻訳版の発売に至るまでには、たいへん長い時間がかかってしまいましたが、しかしその内容は「これからの」Webデザインを考えるうえで十分お役に立てるものと思います。機会があれば是非お手にとって、収録された美麗な写真の数々を含めチェックしていただければと思います。

恒久リンク | コメント [0件] | 関連情報（トラックバック） [1件]

2009年2月10日

Graceful DegradationとProgressive Enhancement

フロントエンド・エンジニア矢倉

以前「OperaがWeb標準のカリキュラムを公開」で取り上げたOpera Web Standards Curriculum。今回は“Graceful degradation versus progressive enhancement”について、すこし触れてみようと思います。

Graceful DegradationとProgressive Enhancementとは？

記事では、それぞれを次のように説明しています。

Graceful Degradation: Webサイトで表現したい機能を、特定の水準にあるモダンブラウザーに対して提供します。しかし、低水準の古いブラウザーに対しても、同等ではないもののそつのない、または理にかなったかたちで機能を提供します。
Progressive Enhancement: ターゲットとするすべてのブラウザーに対し、最低限伝えるべき機能を実装します。その上で、より高水準の環境（ブラウザー）では、高い機能を体験できるように機能強化をおこないます。

Graceful Degradationは後方互換や古い環境に対しての対処という考えを持ちますが、Progressive Enhancementは「できる環境ではよりよいものを」といった、前向きなアプローチを取っています。

多様性を受け入れる柔軟なWebへ

さて、このような手法がなぜ注目されているのでしょうか。これには、日々絶えず変化しするWebと、Webにアクセスする環境の多様化が背景にあるものと思われます。

携帯電話やスマートフォン、ネットブックなど、Webを閲覧する手段は増え続けています。また、Google Chromeなど新しいブラウザーの出現や既存ブラウザーのバージョンアップ、または古いブラウザーを使い続けるユーザー層など、ソフトウェア側においても多様化が進んでいます。

このような状況で、全てのユーザーに同じWebサイトを提供しようとすると、全ての利用環境を意識するあまり、実装できる機能はとても最小的なものとなってしまいます。かといって、特定の環境だけに最適化されてしまうと、その環境下にいないユーザーに不都合を与えてしまうこととなります。

柔軟な媒体としてのWebを最大限生かすために、多様性を受け入れること。これがGraceful DegradationやProgressive EnhancementによるWeb制作の根底にある考え方です。

新しい技術の取り込みだけが目的ではない

Progressive Enhancementについては、昨年11月に開かれたWeb Directions Eastでも、スピーカーの何人かが取り上げていました。また、策定途中のHTML5やCSS3、DOM APIを利用するときにも、この考えが取り上げられることが多く、目にする機会が今後増えていくものと思われます。

しかしながら、このように新しい技術を利用することに絡めてProgressive Enhancementが紹介されることが多く、その結果「IEで利用できないから……」といった反応も少なからずみられます。確かにそういった側面もあるのですが、それだけがProgressive Enhancementのすべてではありません。

ということで次回は、記事の後半にある例などをもとに、今のWeb制作とGraceful Degradation/Progressive Enhancementとの関わりについて紹介したいと思います。

恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]

2009年2月 6日

2009年1月のW3C

フロントエンド・エンジニア矢倉

CURIE Syntax 1.0が勧告候補に

RDFaやXHTML Role属性などで使われる短縮URI構文、CURIEの勧告候補が1月16日に公開されました。

最終草案より、いくつかのセクションが修正され、新しいデータ型が追加されています。

XHTML Media Types 第二版

すでに「XHTML Media Typesの第二版が公開」でもお伝えしましたが、XHTML Media Types 第二版が公開されました。

XML Base (Second Edition)の勧告

XMLで基底URIをひもづけるxml:base属性を定義したXML Baseが改訂され、XML Base (Second Edition)として1月28日に勧告されました。

エラッタの修正や、属性がとる値に関する変更が行われています。

恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]

2009年2月 4日

OperaのWeb標準カリキュラムに複数の翻訳版が登場

フロントエンド・エンジニア木達

2009年2月3日
Henny Swan著

（この記事はWeb Standards Project（WaSP）における投稿記事「Opera Web Standards Curriculum translations available」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）

いつも私は、複数の言語に翻訳された有用なリソースを探し求めています。ですから、OperaのWeb標準カリキュラムがブラジル系ポルトガル語、中国語、ハンガリー語、イタリア語、ロシア語に翻訳され始めているのは、素晴らしいことだと思いました。

同カリキュラムは、じきにWaSPが提供する予定のWeb標準フレームワークと並行して利用されることになると思いますが、55の記事から成ります。その内容には、Web標準の歴史からHTMLやCSS、JavaScript、アクセシビリティが重要である理由などが含まれます。

国際リエゾングループに属する私たちにとって最も重要なことの一つに、優れたリソースの複数の言語での翻訳をサポートすることがあります。もしあなたが翻訳版を読むことや翻訳を手助けすること自体に興味があるなら、Web Standards Curriculum translationsのページをご覧ください。

釈明：私がWebエバンジェリストとしてOperaに勤めていながらこの記事を投稿したのは、Web標準カリキュラムが業界内の優れた人々によってもたらされた専門的知識からなる、本当に素晴らしいリソースだと思っているからです。

お楽しみください！

恒久リンク | コメント [1件] | 関連情報（トラックバック） [0件]

2009年2月 2日

WebAIMの実施したスクリーンリーダーに関する調査結果が公開

フロントエンド・エンジニア木達

2009年1月31日
Patrick Lauke著

（この記事はWeb Standards Project（WaSP）における投稿記事「WebAIM screenreader survey…the results are in」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）

アクセシビリティ・タスクフォースのメンバーであるJared Smithから寄せられた情報です：

WebAIMは最近、スクリーンリーダーの利用者の嗜好を調査しました。1100を超える回答が寄せられ、今回の調査結果はスクリーンリーダー利用者の層や嗜好について、たいへん有用な情報をもたらしてくれます。結果の一部は、極めて驚くべき内容でした。今回のような広範に渡る調査は、スクリーンリーダーの利用者という多様なグループにとって、殊更に必要とされる見識を与えれくれます。

以下に、そのいくつかを挙げます：

最もよく使われているスクリーンリーダーはJAWS（74%）、Window-Eyes（23%）、NVDA（8%）、VoiceOver（6%）の順でした。

75%のスクリーンリーダー利用者が、1年以内に最新バージョンにアップグレードしています。

回答者の12%が、携帯電話上でスクリーンリーダーを利用しています。

76%の利用者が常に、もしくは頻繁に、見出しによるナビゲーションを利用しています。

36%の利用者は全く、もしくは滅多にテキスト版のWebページを利用しません。

72%のスクリーンリーダー利用者が、Flashがとても、もしくは少なからず難解であると報告しました。

調査結果のページには、もっとずっと多くの学ぶべきことがあります。

間接的な証拠だとか、デザイナーや開発者による汎用的な仮定ではなく、実際のスクリーンリーダー利用者からのデータやフィードバックを目にするのは、素晴らしいことです。免責事項にあるように、実際のサンプルは手を加えられていません。また質問のいくつかは過度に技術的だったかもしれず、回答の一部は酷いコードで制作された非アクセシブルなサイトでの経験から影響を受けている可能性があります。

これらの調査結果から得られるおそらく最も重要な結論とは、典型的なスクリーンリーダー利用者など存在しない、ということです。

将来またこの手の調査が行われるとして、私はより典型的な結果が得られるかもしれない、回答者が評価を行うテストケースを期待したいと思います。それまではWebAIMのチームに感謝をし、またこの調査によって収集されたデータのより詳細な分析を楽しみにしたいと思います。

恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]

2009年2月 2日

Antenna House Formatter

フロントエンド・エンジニア木達

少し前のお話になりますが、今月に出荷が開始される予定のAntenna House Formatter V5.0をアンテナハウス様よりご紹介いただき、先月20日に東京で催された「CSSによる文書レイアウト指定セミナー」に参加させていただきました。

アンテナハウスでは、以前からXML組版・印刷ソフトウェアとしてXSL Formatterを開発、販売してきました。バージョン5.0において、レイアウト指定方法に従来のXSL-FOに加えCSSが利用できるようになるのを機に、同製品をAntenna House Formatterに改名するそうです。

Antenna House FormatterはWeb標準に積極的に準拠しているようで、その一例としてAcid2 Testをパスしているとのこと。CSS3のドラフト仕様についても実装を進めています。

セミナーでは『CSSによるページデザイン入門』と題した小冊子が配布されたのですが、もともとは単一のXHTML文書として制作したものをCSSでレイアウト指定、Antenna House FormatterによりPDF化したものと伺いました。CSS 2.1、CSS3に加え独自拡張機能（-ah-接頭辞が必要）を利用することにより、多様なレイアウト指定、さらには高い印刷品質を実現できることを、セミナーや小冊子を通じて学ばせていただきました。

同製品の詳細につきましては、アンテナハウスのWebサイトをご覧ください。

恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]

当Blogの更新情報は、Twitter経由でも配信しています。興味のある方はぜひ、@mlcstandardsをフォローしてください。当Blogへのご意見・ご質問は、Twitter経由でも受け付けております。

2009年2月27日

Progressive Enhancementの実践と普及にむけて

Flashの埋め込みもProgressive Enhancementなやり方で

JavaScriptによる処理の重ね方

Progressive Enhancementが受け入れられるためには

2009年2月25日

WAI-ARIAの最終草案とSafari 4

2009年2月25日

Safari 4パブリックベータがリリース

次世代を感じさせるUI

WebKitの進化

最新技術の積極的な利用も

2009年2月20日

Graceful DegradationとProgressive Enhancementの実践

「印刷する」というリンク

Progressive Enhancementな印刷リンク

2009年2月13日

Web Forms 2を統合した新しいHTML5の草案が公開

2009年2月10日

Webデザイン プロフェッショナルワークフロー・バイブル

2009年2月10日

Graceful DegradationとProgressive Enhancement

Graceful DegradationとProgressive Enhancementとは？

多様性を受け入れる柔軟なWebへ

新しい技術の取り込みだけが目的ではない

2009年2月 6日

2009年1月のW3C

CURIE Syntax 1.0が勧告候補に

XHTML Media Types 第二版

XML Base (Second Edition)の勧告

2009年2月 4日

OperaのWeb標準カリキュラムに複数の翻訳版が登場

2009年2月 2日

WebAIMの実施したスクリーンリーダーに関する調査結果が公開

2009年2月 2日

Antenna House Formatter

Webデザインプロフェッショナルワークフロー・バイブル