アカウント名:
パスワード:
仕様に沿った HTML 4 または CSS1 の範囲であれば、実はさほど問題がない (HTML 4 については abbr 要素の認識以外では HTML 回りはほぼ完璧で、CSS も CSS1 「のみ」であればやはり問題は起きない) のが実際ですよ。
IE6 は HTML4 + CSS1 までしか謳っておらず、XHTML 1.0/1.1 や CSS2 以降に関しては対応しているとは言ってません。CSS の問題は仕様上 CSS1 から外れる領域 (CSS2 以降) のセレクタの記法等、「未知のセレクタに遭遇したら無視する」という仕様を満たしていないため、CSS 回りにおいて IE hack が発生するというのが現実です。
むしろ IE6 じゃないと困るというのは、IE7 によりセキュリティが強化する目的で行われた仕様変更への追従に関する問題や、JavaScript 回りで厳密にバージョンチェックを行っていた事による (IE4/5.0/5.5/6.0 で処理を細かく振り分け等) IE7 用の分岐路がない、既存動作との互換性保証があるか、という問題とかです。
Firefox や SeaMonkey などでも security fix により 0.0.1 の差で動かなくなるスクリプトが発生するといった事はありますから、メジャーバージョンアップになる IE7 に関して、スクリプト回りを利用している場合の検証コストは常に発生する話です。
JavaScript はまともに仕様と言えるものが現状 ECMA-262 revision 3 程度しかありませんが、これは本当に言語仕様であって「ブラウザ (実装系) がどんなオブジェクトを持っているか」とかの仕様ではないのです。つまり document.write() とかも仕様外。C# の ECMA にある仕様と実際に書かれる .NET Framework を前提とした C# 2.0/3.0 とかみたいな乖離がある、という感じでしょうか。(後者の方は違いがヘビーすぎますが、まぁ極端な例ということで)
そういう世界なので、「このブラウザだとこのオブジェクトがあるから」とかいうのはよくある話ですし、「このプロパティが」「このメソッドが」というのも普通にあるという事でして。
だから、世に溢れる JavaScript 入門系の本などでもメソッド/プロパティ毎に「IE6 で使える」「Firefox で使える」といった記述が踊る事になるのです。
さらに、共通で使えるオブジェクト/メソッド/プロパティなど (さすがに w3m-js なんかは無視されますが……) だけでも実装差異等の問題もあり、処理内容によっては細やかな分岐が必要になったりします。
まぁ、その辺りは結局「Web 標準規格の範囲内」からがっつり外れてしまう物になりますけどね。
Flash 9 で作って携帯じゃ (略) とか、Java Applet にして w3m 憤死とか。
なので、結局アクセシビリティ的な観点からも、Web サービスは最初から HTML のみ、それも画像とかはできるだけ使わずにテキストのみで「そのサービスは実現可能なのか」という点を元に設計する必要があると思いますよ。
Java Applet や Flash、ActiveX といったプラグインを使うコンテンツによるサービス、HTML + JavaScript で構成、HTML のみで構成……と落ちていっても、とりあえず同等の「機能」は提供する (使いやすさは前者ほど高いでしょう) という複合型で。
# アクセシビリティ的再重視では、動画ですら「最終的にテキストに落とせ」という素敵なコンテンツ制作が待ってます。本気でやると泣けますよ。(笑)
"Web のプロ" が本当に Web のプロかどうかが問題であって……未だに W3C なんて見たことも聞いたこともありませんとか、そういうクラスがプロだと言っていたりしますから。
コンテンツにおいてはアクセシビリティでは text/plain 最強。WCAG (Web Contents Acceccibility Guidelines) なんかでは、HTML のコンテンツも最終的にはテキストに落とせ、とする程度にテキストは最強です。
ただ、ソフトウェア的に意味ベースで解釈するにはマークアップがあった方が負荷が低いといった、HTML の方が何かと便利という点から見ると HTML の方が扱いやすい、という程度でしょうね。
JavaScript の場合は、言語的な動作の仕様は当然ながら決まっています。決まっていないのは Web ブラウザ毎に固有となる実装の部分です。C# の仕様に .NET Framework のクラスライブラリが仕様に含まれている訳ではないのが状況として似ている、ということです。
つまり、実際に C#(JavaScript) を使う .NET(Web ブラウザ上) という環境を想定すると、たとえ C#(JavaScript) の仕様だけを知っていても、実際に使う場面となる .NET のクラスライブラリ (Web ブラウザが持っている各種オブジェクト) を理解していないと、事実上使いものにならないということです。
そして、この Web ブラウザが持っている各種オブジェクトに関しては標準化されたものはないし、W3C も UA に関する仕様を定義する組織ではないため、特に標準化しようという動きはありません。いいとこ DOM 程度です。
これらを踏まえた上で、ユーザビリティとアクセシビリティの両立を常に意識している人であれば、AJAX を使いつつアクセシビリティの確保を行うのは、特に大きな問題がある訳でもないですよ。
WCAG 的には、Web サービスを Flash 等で行う事は否定されていませんが、Flash プレーヤがない場合には「同等の Web サービスを HTML ベースで内容として持て」とあります。よくある「最新の Flash プレーヤをインストールしてください」なんてリンクがあるのは最悪のパターンなんですよね。
こうしたことを当たり前のようにやってくれる制作会社だったら「Web のプロ」だと呼んでいいと思いますよ。
ただし、Flash とかを使わないと実現できない機能を持っていて、HTML レベルではどうやっても不可能である場合にユーザを絞って提供することがダメだとは思いません。それは元々ターゲッティングの違いですから。
ユニバーサルサービスを標榜しつつ Flash のみです、なんてのは話になりませんけどね。
アクセシビリティに関しては、発注者側の意識も確かに大切です。が、Web 制作会社側が「そうした点に対する考慮はどうするのか」という確認を行ってくるかどうかというのも、クォリティに対する意識があるかどうかの点で判断基準になるかと思います。
# 幸いにして、以前いた会社では「それが当たり前」でしたが……。
JavaScript に関しては、基本的に昔は Netscape、今は Mozilla Foundation が仕様を作り、それを ECMA に提出という感じで国際規格化されています。ECMA-262 辺りを探してみると見つかります。これで Web アプリ向けのコードを書けたらすごいってレベルです。
Flash などでも、たとえば Flash でムービーを提供 (YouTube やニコニコ動画みたいな?) の場合、同等の情報というのが信じられないほど膨大なテキストになったりする (笑) ため、実はかなり非現実的な話なのですけどね。
装飾程度の位置付けで無くても問題ないというレベルであれば、そこまでの説明等は不要ですが、だったら最初から(ry とか。難しいところです。
皆が～というのは当然望ましい事ですが、金を取ってはいても冗談みたいなレベル (1 ページ数百円とか) で発注している業者とかもありますので、実際の作業者としてはこの単価でそこまで考えろというのは酷でしょうね。
# その業者側の意識が足りない、とは思ってます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
IEでしか動かないってのが (スコア:1, 興味深い)
どっちにしても数年内に企業PCもVistaになるんだから
覚悟きめて標準的なWebアプリを模索すべき。
それにしても、IE6でしか動かないシステムを提案をした
システム屋の責任は問われないのかな？
Re: (スコア:4, すばらしい洞察)
>システム屋の責任は問われないのかな？
よくこういう発言を目にしますけど、WWWというサービスが使われ始めて
すでに17年が経ってるわけで、その間いろいろと変わってきました。
「IE6でしか動かない」というよりも、
「その当時に最も使われているブラウザで動く」というものであって、
将来登場するであろうブラウザでの動作も保証することなんて困難です。
CookiesもJavaScriptも使わず、本当に昔のMosaicから最新のIE7や
Firefox2はもちろん、将来登場するはずの見たことも聞いたこともない
ブラウザでも動作する安全なWebアプリケーションを、顧客の要件を
満たして作ることの困難さを考えてみましょう。
システム屋に責任がありそうですか？
Re:IEでしか動かないってのが (スコア:1)
もっともHTMLに対応しているブラウザについての話で、HTML以外の何かにしか対応していないUAについてはなんともいえませんが。
ただ、今までもこれからもHTMLでは見た目は保証されませんので、見た目を保証したい場合はPDFをお勧めします。多分互換性もばっちしです。Flashでもいいかもしれません。
適切なリソースの作成を努力して、結果として完璧ではないというのであれば評価できます。
ですが、たまたま偶然レンダリング結果が意図通りになっただけの無茶苦茶なリソースが、将来的にブラウザの糞なソースを補完する機能の進化などにより、本来持っている無茶苦茶さを取り戻すのはむしろ必然でありますよ。
それをして無茶苦茶なソースを記述することに対して責任が無いとのたまうようなベンダーが在るなら、そのベンダーは恥を知るべきです。
◆IZUMI162i6 [mailto]
Re: (スコア:0)
Re:IEでしか動かないってのが (スコア:1)
仕様に沿った HTML 4 または CSS1 の範囲であれば、実はさほど問題がない (HTML 4 については abbr 要素の認識以外では HTML 回りはほぼ完璧で、CSS も CSS1 「のみ」であればやはり問題は起きない) のが実際ですよ。
IE6 は HTML4 + CSS1 までしか謳っておらず、XHTML 1.0/1.1 や CSS2 以降に関しては対応しているとは言ってません。CSS の問題は仕様上 CSS1 から外れる領域 (CSS2 以降) のセレクタの記法等、「未知のセレクタに遭遇したら無視する」という仕様を満たしていないため、CSS 回りにおいて IE hack が発生するというのが現実です。
むしろ IE6 じゃないと困るというのは、IE7 によりセキュリティが強化する目的で行われた仕様変更への追従に関する問題や、JavaScript 回りで厳密にバージョンチェックを行っていた事による (IE4/5.0/5.5/6.0 で処理を細かく振り分け等) IE7 用の分岐路がない、既存動作との互換性保証があるか、という問題とかです。
Firefox や SeaMonkey などでも security fix により 0.0.1 の差で動かなくなるスクリプトが発生するといった事はありますから、メジャーバージョンアップになる IE7 に関して、スクリプト回りを利用している場合の検証コストは常に発生する話です。
Re:IEでしか動かないってのが (スコア:1)
問題なのは「それっぽく見えるからいいじゃん」とやっつけで仕事をしているようにしか見えない方々で、更に問題なのは「IEで動くからいいじゃん」とか考えてる要件定義者も少なくないってとこなんでしょうか。
Java Scriptについては、そこまでローカルの実装に依存しなければならないようなとこまで使わずになんとかならないんかな？
いや、Java Script使ってないんで全然わかんないんですけどね
定期的に修正を発注させるためにわざとそういう設計をしてんじゃねーか？ってシステムが前の職場にあって萎えたりしてました・・。(^_^;;;
◆IZUMI162i6 [mailto]
Re:IEでしか動かないってのが (スコア:1)
JavaScript はまともに仕様と言えるものが現状 ECMA-262 revision 3 程度しかありませんが、これは本当に言語仕様であって「ブラウザ (実装系) がどんなオブジェクトを持っているか」とかの仕様ではないのです。つまり document.write() とかも仕様外。C# の ECMA にある仕様と実際に書かれる .NET Framework を前提とした C# 2.0/3.0 とかみたいな乖離がある、という感じでしょうか。(後者の方は違いがヘビーすぎますが、まぁ極端な例ということで)
そういう世界なので、「このブラウザだとこのオブジェクトがあるから」とかいうのはよくある話ですし、「このプロパティが」「このメソッドが」というのも普通にあるという事でして。
だから、世に溢れる JavaScript 入門系の本などでもメソッド/プロパティ毎に「IE6 で使える」「Firefox で使える」といった記述が踊る事になるのです。
さらに、共通で使えるオブジェクト/メソッド/プロパティなど (さすがに w3m-js なんかは無視されますが……) だけでも実装差異等の問題もあり、処理内容によっては細やかな分岐が必要になったりします。
Re:IEでしか動かないってのが (スコア:1)
というか、標準仕様が存在しないものを仕事で使うっつーのは自分なら絶対に避けたいところ。
フラッシュかJAVAアプレットの方がまだいいんじゃ・・・。
◆IZUMI162i6 [mailto]
Re:IEでしか動かないってのが (スコア:1)
まぁ、その辺りは結局「Web 標準規格の範囲内」からがっつり外れてしまう物になりますけどね。
Flash 9 で作って携帯じゃ (略) とか、Java Applet にして w3m 憤死とか。
なので、結局アクセシビリティ的な観点からも、Web サービスは最初から HTML のみ、それも画像とかはできるだけ使わずにテキストのみで「そのサービスは実現可能なのか」という点を元に設計する必要があると思いますよ。
Java Applet や Flash、ActiveX といったプラグインを使うコンテンツによるサービス、HTML + JavaScript で構成、HTML のみで構成……と落ちていっても、とりあえず同等の「機能」は提供する (使いやすさは前者ほど高いでしょう) という複合型で。
# アクセシビリティ的再重視では、動画ですら「最終的にテキストに落とせ」という素敵なコンテンツ制作が待ってます。本気でやると泣けますよ。(笑)
Re:IEでしか動かないってのが (スコア:1)
どうなんだろう？HTMLでの作成であれば当然理念としてアクセシビリティは要求されて当然な気がするんですが(というか、割とHTML自体がそういう言語設計になってるよね)、Webリソースを作成と言った時にHTML以外の選択肢を選ぶならアクセシビリティは捨てていいというかなんというか、そんな気がします。アクセシビリティが要求に入った時点で、HTMLくらいしか要件を満たせないってことの裏返しかもですが。
アクセシビリティを考慮するなら仕様が決まっているものを適切にしか使えない気がするんですよね。動作の仕様が決まっていないらしいJava Scriptでは代替情報の提供も困難でしょう。正確な代替情報を提供するには代替されるものが確実なものとしてある必要があるでしょうし。
なので、実際に仕事としてAjaxとかとアクセシビリティとを両立させようとすると眩暈がしてきますね。自分みたいに趣味で書く人間ならそもそもそうならないようにリソースを書きますが、顧客はそうはいかないでしょうし・・だからこそ自分はそれを仕事にしなかったんですけれども・・。
アクセシビリティというのは端末を選ばない必要がありますから、テキストでの代替、たとえばimg要素のalt属性とかは必須なのがわかりやすい例ですけれども、ぶっちゃけｉモードとかで見ても同じ情報(同じ見た目ではなく)が得られる必要があるというのは、そもそもの文書設計の段階でそういうことを考慮してなけりゃ困難に決まってるんじゃないかと。
そういう意味で、実は理解してる顧客がいないことの方が大きな問題なのかもしれません。解ってないけどJISの8341は満たしたいとかそういうなんつーか、アレなところで。あの辺の旗はそもそものところで企業とかが理念を理解して意識を変えて取り組むためのもののはずなんですが。
◆IZUMI162i6 [mailto]
Re:IEでしか動かないってのが (スコア:1)
"Web のプロ" が本当に Web のプロかどうかが問題であって……未だに W3C なんて見たことも聞いたこともありませんとか、そういうクラスがプロだと言っていたりしますから。
コンテンツにおいてはアクセシビリティでは text/plain 最強。WCAG (Web Contents Acceccibility Guidelines) なんかでは、HTML のコンテンツも最終的にはテキストに落とせ、とする程度にテキストは最強です。
ただ、ソフトウェア的に意味ベースで解釈するにはマークアップがあった方が負荷が低いといった、HTML の方が何かと便利という点から見ると HTML の方が扱いやすい、という程度でしょうね。
JavaScript の場合は、言語的な動作の仕様は当然ながら決まっています。決まっていないのは Web ブラウザ毎に固有となる実装の部分です。C# の仕様に .NET Framework のクラスライブラリが仕様に含まれている訳ではないのが状況として似ている、ということです。
つまり、実際に C#(JavaScript) を使う .NET(Web ブラウザ上) という環境を想定すると、たとえ C#(JavaScript) の仕様だけを知っていても、実際に使う場面となる .NET のクラスライブラリ (Web ブラウザが持っている各種オブジェクト) を理解していないと、事実上使いものにならないということです。
そして、この Web ブラウザが持っている各種オブジェクトに関しては標準化されたものはないし、W3C も UA に関する仕様を定義する組織ではないため、特に標準化しようという動きはありません。いいとこ DOM 程度です。
これらを踏まえた上で、ユーザビリティとアクセシビリティの両立を常に意識している人であれば、AJAX を使いつつアクセシビリティの確保を行うのは、特に大きな問題がある訳でもないですよ。
WCAG 的には、Web サービスを Flash 等で行う事は否定されていませんが、Flash プレーヤがない場合には「同等の Web サービスを HTML ベースで内容として持て」とあります。よくある「最新の Flash プレーヤをインストールしてください」なんてリンクがあるのは最悪のパターンなんですよね。
こうしたことを当たり前のようにやってくれる制作会社だったら「Web のプロ」だと呼んでいいと思いますよ。
ただし、Flash とかを使わないと実現できない機能を持っていて、HTML レベルではどうやっても不可能である場合にユーザを絞って提供することがダメだとは思いません。それは元々ターゲッティングの違いですから。
ユニバーサルサービスを標榜しつつ Flash のみです、なんてのは話になりませんけどね。
Re:IEでしか動かないってのが (スコア:1)
JavaScriptにもちゃんと言語仕様はあるんですね。誤解してました。
DOM1くらいしか使えないというのはしょんぼりですが、そもそもそれすらも知らずにトライアンドエラーだけで作ってる製作者も多いんでしょうね。
text/plainはリソース単体でのアクセシビリティは完璧ですが、複数リソースでサイト全体が構成されるとき、リソース同士の関連性などメタ情報が欠落することでサイトとしてみた時に若干アクセシビリティが低下する気がします。
Flashなどの代替の話だと、「同等のサービス」ではなく、「同等の情報へのアクセス性の確保」が重要なので、代替となるHTMLのリソースなんかへのリンクでもOKですよね。
Flashの代替で「Flashを入れろ」とかってのは確かに最悪ですな。noframeで「フレーム対応のブラウザで出直してこい」とか書いてあるのと同じくらい酷い話です。
>こうしたことを当たり前のようにやってくれる制作会社だったら「Web のプロ」だと呼んでいいと思いますよ。
逆に、Webのリソースを作って金を取ってるならその時点でプロなので、皆がそのくらいのレベルであって欲しいと思うんですが。
今の状態ではマレーシア製テレビ以下の信頼性しかないところがほとんどで。
しかし、彼らは顧客が満足するものを作るのが仕事であって顧客のサイトを見る人が満足するかどうかはどうでもいいので、やはりそこは要件定義でしっかりしないと駄目なのかと思われます。
◆IZUMI162i6 [mailto]
Re:IEでしか動かないってのが (スコア:1)
アクセシビリティに関しては、発注者側の意識も確かに大切です。が、Web 制作会社側が「そうした点に対する考慮はどうするのか」という確認を行ってくるかどうかというのも、クォリティに対する意識があるかどうかの点で判断基準になるかと思います。
# 幸いにして、以前いた会社では「それが当たり前」でしたが……。
JavaScript に関しては、基本的に昔は Netscape、今は Mozilla Foundation が仕様を作り、それを ECMA に提出という感じで国際規格化されています。ECMA-262 辺りを探してみると見つかります。これで Web アプリ向けのコードを書けたらすごいってレベルです。
Flash などでも、たとえば Flash でムービーを提供 (YouTube やニコニコ動画みたいな?) の場合、同等の情報というのが信じられないほど膨大なテキストになったりする (笑) ため、実はかなり非現実的な話なのですけどね。
装飾程度の位置付けで無くても問題ないというレベルであれば、そこまでの説明等は不要ですが、だったら最初から(ry とか。難しいところです。
皆が～というのは当然望ましい事ですが、金を取ってはいても冗談みたいなレベル (1 ページ数百円とか) で発注している業者とかもありますので、実際の作業者としてはこの単価でそこまで考えろというのは酷でしょうね。
# その業者側の意識が足りない、とは思ってます。