アカウント名:
パスワード:
Web閲覧者の増加に伴う老眼な閲覧者の増加を考えると、Webページのアクセシビリティはビジネスに際しても重要な特性となると思えます。
それはWCAGであって、UAAGではないのでは?
#もっとも、ブラウザ自体がレンダリング結果を拡大/縮小できると(Operaのように)、Author側は、絶対単位で固めたレイアウトなページ作っても問題ないというかになるので、UAAG準拠になってくれると嬉しいけど。
こっち [srad.jp]にも書いたけど、それを望むのならば UAAGではなくて WCAG の方です。
Opera の拡大縮小もレイアウトは維持されるのかも知れないけど、 文字で大きさを合わせると画像が見苦しくなるのが嫌で 使わなくなってしまいました。レイアウトは美観には影響するのでしょうが、読み取れる情報量を優先する私にとっては嫌な方式に写ります。
てなことで、外観構造が重要なら、フォントサイズなんぞに影響されない (フォントサイズが変わっても崩れない) ように作るのが、おしゃれと思う私です。
>なんでですか? >WCAGでは相対単位を求めているけれど、絶対単位のほうが作り >やすいから、UAAGによってOpera式?の拡大/縮小をブラウザが >実装して欲しいという話なのですが。 からは全く逆ともいえる「絶対単位が楽なんで UA が頑張ってよ」 という意味に読めました。
>なんでですか? >WCAGでは相対単位を求めているけれど、絶対単位のほうが作り >やすいから、UAAGによってOpera式?の拡大/縮小をブラウザが >実装して欲しいという話なのですが。
からは全く逆ともいえる「絶対単位が楽なんで UA が頑張ってよ」 という意味に読めました。
>#もっとも、ブラウザ自体がレンダリング結果を拡大/縮小 >できると(Operaのように)、Author側は、絶対単位で固めた >レイアウトなページ作っても問題ないというかになるので、 >UAAG準拠になってくれると嬉しいけど。
外観構造は大事なのですが、それが意図した通りに再現されるとは 限らないのが Webコンテンツの世界なんです。
意図した通りのメディアタイプで、意図というか仕様で定められたとおりのCSSを適用する分には、(ブラウザの謳い文句に嘘偽りがなければ)同じように再現されるはずなのではないでしょうか。
現実的にうまくいってないのは、各ブラウザがバグってたり、おのおのが違う解釈を行っていたりするからだと思いますが。
で、当然ながらHTMLは文書構造を提供しているわけですから、CSSが有効でない環境であれば、外観構造は破棄され、ブラウザ側の表示に完全に依存するでしょう。しかしそれは、意図したとおりのことだと思います。
とあるブラウザは、横幅の広いページを狭い表示画面で表示する ために、ページレイアウトを変換して縦方向に並べるように 表示します。 そうすると、ページ全体を閲覧するに必要な スクロールの方向が上下左右の４方向から上下方向の２方向に 減ります。 これは一部の環境やユーザにおける操作感にとって 非常に有効な効果をもたらします。
というか、それはそれで、全く問題ないと思いますが。そのようなブラウザでは、どう表示されようが、ブラウザ側に依存で、それでいいんじゃないでしょうか。見ている人はそのブラウザがそういう挙動をしていることがわかっているという前提が必要だと思いますけど。
CSS(とメディアタイプ)による外観構造の制御は、それが有効な環境である場合にのみ効力が発揮されれば良いわけで、そうでない場合も制御されてしまうと、逆に困りますというか。そのためにも、もともと意味づけとして妥当なマークアップを施した文書を提供していれば良いわけですし。
スラッシュドットに集まるような人は Web を「情報と機能」で解釈している人が多いんじゃないかと思いますが（少なくとも私はそうです）、世の大半の人は「一風変わったテレビ」的な感覚で捉えていて、実際「XGA 全画面表示が標準」だったりするわけです。
そういうフツーの人が制作者だったり、あるいはサイト制作の裁量
ざくっと。
というか、それはそれで、全く問題ないと思いますが。そのようなブラウザでは、どう表示されようが、ブラウザ側に依存で、それでいいんじゃないでしょうか。見ている人はそのブラウザがそういう挙動をしていることがわかっているという前提が必要だと思いますけど。 CSS(とメディアタイプ)による外観構造の制御は、それが有効な環境である場合にのみ効力が発揮されれば良いわけで、そうでない場合も制御されてしまうと、逆に困りますというか。そのためにも、もともと意味づけとして妥当なマークアップを施した文書を提供していれば良いわけですし。
総じて同意ですが、そういうことをみんなが（少なくとも一つのサイトを例に取れば、制作に関わる人と読み手の両方が）了解するという事態に至らなければ、サイト運営的にはむつかいんじゃないかな、と思います。たぶんそこがいちばん難しい。
えーと、#224174 [srad.jp]で、ある意味極端な例が挙げられたので、そんなこと関係ないでしょうと返事したつもりです。
通常であれば、CSSとメディアタイプがどーよなんてことは考えずに、いわゆるscreenメディアでIE6的に問題のないサイトってのを提供して、それを前提として掲げることには閲覧側も概ね了解してもらえるんじゃないかと思いますが、そういうことではなく?
読み手が受け取るのはただの情報じゃなくて、イメージ、レイアウトを含めた雰囲気だし、発信者もただ情報を発信したいわけじゃない、ってのが現実でしょう。（聴いている人を含む）閲覧者を幅広く想定しながら、なおかつ自分の目指すレイアウトを実現するってのは、現在のブラウザの使い勝手と制作者の平均的なレベルに対して高すぎる要求だと、個人的には思います。
そうです。僕もそう考えます。しかしまず、文書構造として妥当なHTML、正しい文法によるHTMLという時点だけで、その他の試みをおこなわかったとしても、そうでないものに比べると格段に、あらゆるブラウザを通してのアクセシビリティ(近づきやすさ)は高まるはずです。ここまではそれほど難しくはないのではと思います。
次にここからが難しいことと思うのですが、フォントサイズのみが可変というような状況は、レイアウトが容易に崩れることが想定されますので、ここにどう対応するかという点です。CSSで相対単位を基準としたレイアウトを試みるサイトを作る労力は計り知れないことがあります。ですので、絶対単位を前提とした外観構造を提供しても、ブラウザ側がそれでも問題なく読めるようにサイズの拡大/縮小などを行えばよい、と思うわけです。
読み上げに対応するのが難しいのは、日本でよく使われているといわれる、或いは、読み上げ対応の際の基準として取り上げられやすい、ホームページリーダーというソフトウェアが、auralメディアではなくscreenメディアで動いているために、尚難しくなっているのではないかと考えられます。
いえ、そういうことであれば。ただ、そのときにIE が数ある選択肢のうちの一つだという認識がされていることは少ないんじゃないかと思っています。これは個人的な経験と推測だけですのですべての現場がそうだとはもちろん言えないんですけど。
そこが認識されないと、HTML で構造とか、アクセ
そこが認識されないと、HTML で構造とか、アクセシビリティとか、そういうものへとステップアップできないんじゃないかな、と思うんですよ。悲観しすぎならいいんですが。
御意、そうですね。しかし、(僕のようなWebで飯喰っている人たちは別として)フツーの人がフツーにということで、仰るようにオーサリングツールのほうが発達して、(フツーの)Athor自体はたとえIEのことしか知らなくても、少なくともHTMLの文法的にはしっかりしたものが提供できるようになることが望まれます。まあ、文書構造的に妥当というのは、ツールレベルでどうこうというのは難しいとは思いますが……。
#↓以下は余談に近いのですが…
読み上げに対応するのが難しいのは、日本でよく使われているといわれる、或いは、読み上げ対応の際の基準として取り上げられやすい、ホームページリーダーというソフトウェアが、auralメディアではなくscreenメディアで動いているために、尚難しくなっているのではないかと考えられます。 これは不勉強で知りませんでした。参考になります。
これは不勉強で知りませんでした。参考になります。
といっても、ホームページリーダー自体はそんなこと意識していないというか、ようはIEに寄生するようなソフトウェアなので、IEがレンダリングしたものしか読み上げることが出来ないという話です(ホームページリーダー3の場合。ホームページリーダー2まではNetscape4のプロキシみたいな感じで動作してました)。
たとえば、過去にkanzaki.com [kanzaki.com]を見ていたら、display:noneしてある要素に「読み上げの人はメニューを飛ばしてコンテンツ本文へ」というページ内リンクが、ページの先頭にあり、それは@media auralの時はdisplay:inlineしてあるのですが、これを見て「おお!」と思ったものです。確かにそうしておけば、ブラウザの実装に合わせて、いわゆる上にヘッダエリア、左メニュー(ナビゲーション)エリアのような逆L字型レイアウトにしても、読み上げ時に本文部分に到達するのが楽になるよね、と。
しかし実際にその手法を取り入れて、ホームページリーダー3で読み上げさせて気づいたのですが、IEがdisplay:noneと認識しているのだから、ホームページリーダー3でもdisplay:noneされちゃうよね、という。
結局、今はタグの直下に近いところに、サイズ1x1の透明GIFを置いて、そのALT属性に「すぐに本文へ」というのを書いて、こいつをページ内リンクにしてやる、という、ややトリッキーな手法で対応するというのが、視覚的に違和感ない範囲で読み上げブラウザ向け、のやり方になるかなとか、思ってます。
#もっとも、ブラウザ自体がレンダリング結果を拡大/縮小できると(Operaのように)、 Author側は、絶対単位で固めたレイアウトなページ作っても問題ないというかになるので、 UAAG準拠になってくれると嬉しいけど。
そうですね。 表示画面というのは文字と画像の組合せですから、 画像が絶対単位であるピクセル単位で取り扱われている以上、 閲覧者の希望に応じた表示画面の拡大縮小は絶対単位の取り扱いを正しく行うべきです。 ということは、 文字が絶対単位であるピクセル単位で指定されていても 画像と同様に問題なく拡大縮小に対応すべきなんで
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
Webページのアクセシビリティ (スコア:1)
それはWCAGであって、UAAGではないのでは?
Re:Webページのアクセシビリティ (スコア:1)
> 4.1 ユーザーがテキストのサイズを構成できるようにします。[優先度 1]
だってさ。
ブラウザがフォントの拡大機能持ってなかったら困る、
ってことで UAAG に含まれてるわけね。
それにしても、
> 開発者は、オープンでアクセス可能な仕様を実装するべきです。
とか
> 標準API（例、W3C DOMなどのプラットフォームに依存しないAPI、オペレーティング・システムに関する標準API、プログラミング言語、プラグイン、仮想マシン環境に関する規定など）を使ったユーザー・エージェントのユーザー・インターフェース・コントロールに対するプログラマティックな読み込みおよび書き込みアクセスを提供します。
とか、オープンや標準を非常に意識した文書だな。
アクセシビリティについて考えれば、
ブラウザが囲い込みの道具として使われることを避けるのも当然だけど。
# mishimaは本田透先生を熱烈に応援しています
Re:Webページのアクセシビリティ (スコア:1)
そういうことじゃなくてというか、ビジネス的に重要な要素というなら、Author側がWCAGをよく考えて、という意味合いのつもりでした。
ブラウザ自体がビジネスの道具となられてもどうかと思うので。
#もっとも、ブラウザ自体がレンダリング結果を拡大/縮小できると(Operaのように)、Author側は、絶対単位で固めたレイアウトなページ作っても問題ないというかになるので、UAAG準拠になってくれると嬉しいけど。
Re:Webページのアクセシビリティ (スコア:0)
こっち [srad.jp]にも書いたけど、それを望むのならば UAAGではなくて WCAG の方です。
Re:Webページのアクセシビリティ (スコア:1)
WCAGでは相対単位を求めているけれど、絶対単位のほうが作りやすいから、UAAGによってOpera式?の拡大/縮小をブラウザが実装して欲しいという話なのですが。
Re:Webページのアクセシビリティ (スコア:0)
「作りやすいから絶対単位がいい」という発想は変ですってば。
Re:Webページのアクセシビリティ (スコア:2, 興味深い)
Opera式? とクドクド書いているのにはワケがあって、フォントサイズだけが可変というのがおかしいと思っているわけです。
画像などのオブジェクトはピクセル単位で表示されて配置されるわけですから、テキスト部分もピクセル単位で表示されるほうがきっちり配置されます。なんで、まるごと拡大/縮小できればそれで済むというか。IEなどでも、画像のwidth/heightをem指定とかすれば、そうなりますけど、ピクセルで切られたものをemに変換するというような作業が強いられるのは、それはそれでおかしいし。
テレビだって大きな画面で見れば、文字も絵もみんな大きくなるでしょう。絵だけとか文字だけとかが大きくなったら外観構造が崩れてしまいますし、外観構造は情報伝達の一端を担っているものですから、崩れてもいいということはありません。
Re:Webページのアクセシビリティ (スコア:0)
ページの幅を可変させる（可変させても追従出来る）選択肢も与えられるべきである。
文字は大きく出来るのにページはブラウザを広げても変わらないと言うのは
ユーザビリティとしてバランスがとれているとは言えません。
と言う事ですよね。
Re:Webページのアクセシビリティ (スコア:0)
http://srad.jp/comments.pl?sid=64293&cid=224074
>#もっとも、ブラウザ自体がレンダリング結果を拡大/縮小
>できると(Operaのように)、Author側は、絶対単位で固めた
>レイアウトなページ作っても問題ないというかになるので、
>UAAG準拠になってくれると嬉しいけど。
からは「絶対単位が安易に使われることへの危惧」は
感じたのですが
http://srad.jp/comments.pl?sid=64293&cid=224126
>なんでですか?
>WCAGでは相対単位を求めているけれど、絶対単位のほうが作り
>やすいから、UAAGによってOpera式?の拡大/縮小をブラウザが
>実装して欲しいとい
Re:Webページのアクセシビリティ (スコア:0)
画像サイズも追従するかどうかを選択できるのがより良いですね。
さて、
>画像などのオブジェクトはピクセル単位で表示されて配置される
>わけですから、テキスト部分もピクセル単位で表示されるほうが
>きっちり配置されます。
BODY要素直下における 1em のサイズは、多くの場合ブラウザに
設定されたデフォルトのフォントサイズなので、そういうブラウザ
ではフォントサイズを em で指定してあったとしてもピクセル単位
です。
> なんで、まるごと拡大/縮小できれば
>それで済むというか
Re:Webページのアクセシビリティ (スコア:2, すばらしい洞察)
Opera の拡大縮小もレイアウトは維持されるのかも知れないけど、 文字で大きさを合わせると画像が見苦しくなるのが嫌で 使わなくなってしまいました。レイアウトは美観には影響するのでしょうが、読み取れる情報量を優先する私にとっては嫌な方式に写ります。
てなことで、外観構造が重要なら、フォントサイズなんぞに影響されない (フォントサイズが変わっても崩れない) ように作るのが、おしゃれと思う私です。
の
Re:Webページのアクセシビリティ (スコア:2, 興味深い)
画像サイズが追随してくれない状態で、フォントサイズの拡大/縮小がユーザー本位で行なえるということを前提として、外観構造をデザインするというのは、非常に難しいことだと思っています。ひとつの段落の隣にひとつの画像がある、という外観構造は、それ自体にも意味があるわけです。それがフォントサイズのみが可変であることで、その構造がいたずらに壊れることは、良いことであるとは思いません。
もちろん、画像は別個に表示されるだとか、そもそも表示されないだとか、そういったインターフェースを経由して情報にアクセスすること自体は全く問題ないし、そういった環境でも可能な限り同等な情報を提供する必要があるわけですが、「崩れる」というのと「違った表示になる」というのとは全然ワケが違うと考えているといった次第です。
それで、話を戻しますがというか、
これも別に「全く逆のこと」なんではなくて、提供側にとって、たとえそれが悪しき慣習であったとしても、そうでなくても、いずれにしても絶対単位でガチガチに固めたようなデザインでサイト/ページを提供することのほうがやりやすいデザイナーというのは多いでしょうし、実際そうだと思います。
#僕は違いますけど、とか言いません。
#やりやすさはどっちもどっちなんで。
現状だと、相対単位じゃないから情報がうまく得られないということが往々にしてあったとしても、ブラウザがUAAG準拠して、絶対単位で提供された情報も、あたかも相対単位で提供されているかのような、とか、ページ全体が自由に拡大/縮小できるようなUIが、わかりやすく使いやすく実装されているだとか、そうなれば、あらゆるサイト/ページが、多くの利用者にとって近づきやすくなるのではないか、ということに期待しているわけです。そういう意味で、「嬉しい」と。
もちろんサイト/ページのほうが、もともとWCAG準拠を踏まえたかたちで情報が提供されていれば尚良いことは間違いないのですが、それはまあ、過渡期というか。いつまで過渡期なんだという話もありますが。
それと、ここでは主に延々とサイズの可変のことばかり言ってますが、色であるとか提供される情報の内容そのものであるとかを軽視しているわけでは微塵もないことを、自己フォロー的にしておいてみる。
僕の書いている話というか対象というかの前提とかが、明瞭でないまま、勢いだけで書いてしまって(先の書き込み)すみません。
Re:Webページのアクセシビリティ (スコア:0)
おっしゃる事、たぶん理解できたと思います。
話を進めれば互いに理解できるように思います。
こちらこそ、ちょっと乱暴な書き込みでスミマセンでした。
Re:Webページのアクセシビリティ (スコア:1)
意図した通りのメディアタイプで、意図というか仕様で定められたとおりのCSSを適用する分には、(ブラウザの謳い文句に嘘偽りがなければ)同じように再現されるはずなのではないでしょうか。
現実的にうまくいってないのは、各ブラウザがバグってたり、おのおのが違う解釈を行っていたりするからだと思いますが。
で、当然ながらHTMLは文書構造を提供しているわけですから、CSSが有効でない環境であれば、外観構造は破棄され、ブラウザ側の表示に完全に依存するでしょう。しかしそれは、意図したとおりのことだと思います。
というか、それはそれで、全く問題ないと思いますが。そのようなブラウザでは、どう表示されようが、ブラウザ側に依存で、それでいいんじゃないでしょうか。見ている人はそのブラウザがそういう挙動をしていることがわかっているという前提が必要だと思いますけど。
CSS(とメディアタイプ)による外観構造の制御は、それが有効な環境である場合にのみ効力が発揮されれば良いわけで、そうでない場合も制御されてしまうと、逆に困りますというか。そのためにも、もともと意味づけとして妥当なマークアップを施した文書を提供していれば良いわけですし。
Re:Webページのアクセシビリティ (スコア:1, 参考になる)
とかいうのはもう勘弁してほしい。
ちょっとした見出し程度なら
固定ピッチ/プロポーショナルどちらでも
気にならないんだけど、
ある程度以上の長さの日本語の文章は
固定ピッチのフォントが読みやすい、
複数行にまたがる文章だとゴチャゴチャ
していて文章に集中できない
...というわけでブラウザの標準フォント指定で
日本語 を 固定ピッチのフォントにしていたり
するんだけど、
> フォントのサイズが変わったくらいで崩れて
> 読みにくくなる痛いページって結構ありますね。
> 万人が同じメトリクスのフォントを持ってる
> わけじゃないのが判ってないんでしょうけど
フォントサイズの変更どころか、
固定ピッチ/プロポーショナルの差程度で
レイアウトが崩れるページも多いんだもん。
なんか「美観の基準自体が古い」(*)気がするんだ。
*もちろんこれはnobuhiro氏のことではないので、
とりちがえないでね
Re:Webページのアクセシビリティ (スコア:0)
スラッシュドットに集まるような人は Web を「情報と機能」で解釈している人が多いんじゃないかと思いますが（少なくとも私はそうです）、世の大半の人は「一風変わったテレビ」的な感覚で捉えていて、実際「XGA 全画面表示が標準」だったりするわけです。
そういうフツーの人が制作者だったり、あるいはサイト制作の裁量
Re:Webページのアクセシビリティ (スコア:0)
ざくっと。
Re:Webページのアクセシビリティ (スコア:1)
えーと、#224174 [srad.jp]で、ある意味極端な例が挙げられたので、そんなこと関係ないでしょうと返事したつもりです。
通常であれば、CSSとメディアタイプがどーよなんてことは考えずに、いわゆるscreenメディアでIE6的に問題のないサイトってのを提供して、それを前提として掲げることには閲覧側も概ね了解してもらえるんじゃないかと思いますが、そういうことではなく?
そうです。僕もそう考えます。しかしまず、文書構造として妥当なHTML、正しい文法によるHTMLという時点だけで、その他の試みをおこなわかったとしても、そうでないものに比べると格段に、あらゆるブラウザを通してのアクセシビリティ(近づきやすさ)は高まるはずです。ここまではそれほど難しくはないのではと思います。
次にここからが難しいことと思うのですが、フォントサイズのみが可変というような状況は、レイアウトが容易に崩れることが想定されますので、ここにどう対応するかという点です。CSSで相対単位を基準としたレイアウトを試みるサイトを作る労力は計り知れないことがあります。ですので、絶対単位を前提とした外観構造を提供しても、ブラウザ側がそれでも問題なく読めるようにサイズの拡大/縮小などを行えばよい、と思うわけです。
読み上げに対応するのが難しいのは、日本でよく使われているといわれる、或いは、読み上げ対応の際の基準として取り上げられやすい、ホームページリーダーというソフトウェアが、auralメディアではなくscreenメディアで動いているために、尚難しくなっているのではないかと考えられます。
Re:Webページのアクセシビリティ (スコア:0)
いえ、そういうことであれば。ただ、そのときにIE が数ある選択肢のうちの一つだという認識がされていることは少ないんじゃないかと思っています。これは個人的な経験と推測だけですのですべての現場がそうだとはもちろん言えないんですけど。
そこが認識されないと、HTML で構造とか、アクセ
Re:Webページのアクセシビリティ (スコア:1)
御意、そうですね。しかし、(僕のようなWebで飯喰っている人たちは別として)フツーの人がフツーにということで、仰るようにオーサリングツールのほうが発達して、(フツーの)Athor自体はたとえIEのことしか知らなくても、少なくともHTMLの文法的にはしっかりしたものが提供できるようになることが望まれます。まあ、文書構造的に妥当というのは、ツールレベルでどうこうというのは難しいとは思いますが……。
#↓以下は余談に近いのですが…
といっても、ホームページリーダー自体はそんなこと意識していないというか、ようはIEに寄生するようなソフトウェアなので、IEがレンダリングしたものしか読み上げることが出来ないという話です(ホームページリーダー3の場合。ホームページリーダー2まではNetscape4のプロキシみたいな感じで動作してました)。
たとえば、過去にkanzaki.com [kanzaki.com]を見ていたら、display:noneしてある要素に「読み上げの人はメニューを飛ばしてコンテンツ本文へ」というページ内リンクが、ページの先頭にあり、それは@media auralの時はdisplay:inlineしてあるのですが、これを見て「おお!」と思ったものです。確かにそうしておけば、ブラウザの実装に合わせて、いわゆる上にヘッダエリア、左メニュー(ナビゲーション)エリアのような逆L字型レイアウトにしても、読み上げ時に本文部分に到達するのが楽になるよね、と。
しかし実際にその手法を取り入れて、ホームページリーダー3で読み上げさせて気づいたのですが、IEがdisplay:noneと認識しているのだから、ホームページリーダー3でもdisplay:noneされちゃうよね、という。
結局、今はタグの直下に近いところに、サイズ1x1の透明GIFを置いて、そのALT属性に「すぐに本文へ」というのを書いて、こいつをページ内リンクにしてやる、という、ややトリッキーな手法で対応するというのが、視覚的に違和感ない範囲で読み上げブラウザ向け、のやり方になるかなとか、思ってます。
相対指定の文字と画像 (スコア:0)
そうですね。 表示画面というのは文字と画像の組合せですから、 画像が絶対単位であるピクセル単位で取り扱われている以上、 閲覧者の希望に応じた表示画面の拡大縮小は絶対単位の取り扱いを正しく行うべきです。 ということは、 文字が絶対単位であるピクセル単位で指定されていても 画像と同様に問題なく拡大縮小に対応すべきなんで