ブラウザの開発ガイドライン User Agent Accessibility Guidelines 1.0 が勧告に 40
ストーリー by Oliver
すべての人に情報を 部門より
すべての人に情報を 部門より
Average曰く、"新もじら瓦版のこのページを書いた人がタレこんでいただければ良いのですが、未だ/.jpには出ていない様なのでタレコミます。
このページにあるように「W3C内にある Web Accessibility Initiative (WAI) の取り組みのひとつである User Agent Accessibility Guidelines 1.0 (UAAG 1.0) が勧告」となったようです。
Web閲覧者の増加に伴う老眼な閲覧者の増加を考えると、Webページのアクセシビリティはビジネスに際しても重要な特性となると思えます。現にワタシ、着実に小さいフォントが読めなくなってきてますモン（笑）
みんな笑っているけど、老眼になるのに後２０年しかないぞ！（ホントか）"
大きさだけじゃなく色も... (スコア:2, すばらしい洞察)
最も良いフォントと最も良い色（Re:大きさだけじゃな (スコア:2, 参考になる)
プラットフォームに設定した適切なフォントと色の情報を
引用できまして、それがある意味もっとも良い設定のはず
なんですが CSS1/2 を正しく実装した UA の普及という問題が。
18.2 User preferences for colors
http://www.w3.org/TR/REC-CSS2/ui.html#system-colors
http://www.y-adagio.com/public/standards/tr_css2/ui.html#system-colors
18.3 User preferences for fonts
http://www.w3.org/TR/REC-CSS2/ui.html#system-fonts
http://www.y-adagio.com/public/standards/tr_css2/ui.html#system-fonts
Re:大きさだけじゃなく色も... (スコア:1, 参考になる)
アクセシビリティを重視するなら、識別可能な色を使うのは当然だと思います。
Re:大きさだけじゃなく色も... (スコア:1)
どういう識別になるか固体差があるのでは？
いや、俺自身もそういうものなのかどうか自信は無いんですが。
Re:大きさだけじゃなく色も... (スコア:2, 参考になる)
自分は非色盲(しきもうで変換できない!!)なのですが， プレゼンテーション作るのに 色盲の人にもわかるバリアフリープレゼンテーション法 [nig.ac.jp] から辿れる 色覚バリアフリープレゼンテーション [nig.ac.jp]や 医学生物学者向き 色盲の人にもわかるバリアフリープレゼンテーション法 [nig.ac.jp] が，すごく参考になりました． 良くある風景(発光ダイオードでの表示など)が どんな風に見えるのかを色盲タイプ別に見せてくれています． 私は，このページを読んで以降赤色レーザーポインターに 頼らないプレゼンを心がけるようになりました．
# これの英語版もすごく評判良いです@職場
Koichi
Re:大きさだけじゃなく色も... (スコア:1, 参考になる)
なんて参考になると思うよ．
Re:大きさだけじゃなく色も... (スコア:3, 参考になる)
いや、別にケチつけるわけじゃありません。
私自身、軽い色覚異常(呼び名は軽度色盲でも何でもいいんですが）があるので
（アレゲ諸兄に分かりやすく説明すると、BASICの4(緑)と6(黄)の区別が付かない）
色使いには普段から気を付けているんですが、
関係する資料を当たっても 正常な例 の時点で既にバイアスかかって見えちゃうんですよね
もちろん 障碍のある人の例 だと2重に
まぁ、文章や周りとの兼ね合いで論理的に意味は取れるんですが
結果として、自分と同じタイプの見え方をする人には見やすいWebにはなりますが
それ以外の障碍の持つ人に見えるかどうかは分からないんですよ。
多分、正常な色覚の人には変な色使いに見えると思いますし
色覚障碍を持つ人に見せるためのガイドじゃなくて
色覚障碍を持つ人がデザインするためのガイドってないんですかねぇ。
# 小学校の頃受けた色盲検査は、精密検査で正常って診断されちゃった。
# 殆ど正常に近い異常らしい。
Re:大きさだけじゃなく色も... (スコア:1)
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)
そうですね。 表示画面というのは文字と画像の組合せですから、 画像が絶対単位であるピクセル単位で取り扱われている以上、 閲覧者の希望に応じた表示画面の拡大縮小は絶対単位の取り扱いを正しく行うべきです。 ということは、 文字が絶対単位であるピクセル単位で指定されていても 画像と同様に問題なく拡大縮小に対応すべきなんで
いいえ、UAAGです (スコア:0)
ユーザー・エージェントのアクセシビリティに関する指針(石川准監訳)の指針4. [u-shizuoka-ken.ac.jp]を参照。
両方なんでは？（Re:いいえ、UAAGです (スコア:0)
ある目的を果たすという事もあります。
たとえば文字の大きさですが、WCAG的には絶対単位ではなく相対単位を
使う事が求められています。 なぜならば絶対単位で指定された文字の
サイズは、必ずしも
Re:両方なんでは？（Re:いいえ、UAAGです (スコア:2, 興味深い)
Mozilla (Gecko) ではテキストのサイズを拡大縮小できるのは、
ちゃんとアクセサビリティを意識しているということなのですね。
Internet Explorer 6 では､ユーザー補助のプロパティに、
「Web ページで指定されたフォントスタイルを使用しない」
「Web ページで指定されたフォントサイズを使用しない」
という設定があります。これも、アクセサビリティに対する
取り組みの一つなのですね。
ユーザー定義のスタイルを指定できる辺り、良くできて
います。
Re:両方なんでは？（Re:いいえ、UAAGです (スコア:1)
取り組みや実際にそういう機能があるということ自体は良いことだと思うのですが、そのチェックを両方やっても、完全にCSSが切れるわけではないので、line-heightの値によっては字が重なってしまって、逆に読めなくなるといった事態に陥ることもあり、なんというか微妙に中途半端なんですよね。
フォントサイズを変更するボタンをデフォルトでツールバーに置いてないのもナンというか、ですし。まあ絶対単位が指定されている環境では役に立たないので、あっても紛らわしいだけなのかもしれませんが……。
Re:両方なんでは？（Re:いいえ、UAAGです (スコア:0)
ブラウザ → テレビ
と置き換えれば判りやすいんかな。
つまりは、良い映像と良いテレビが揃ってこそ
良い映像を見ることができる、みたいな。
一方が欠けるとダメ。
アクセシビリティ関連情報 (スコア:1, 参考になる)
http://www-6.ibm.com/jp/accessibility/ [ibm.com]
こころWeb
http://www.kokoroweb.org/ [kokoroweb.org]
U-Site(usability.gr.jp)
http://www.usability.gr.jp/index.html [usability.gr.jp]
2002年 ウェブ・デザインの間違いトップ10
http://www.usability.gr.jp/alertbox/20021223.html [usability.gr.jp]
これも追加 (スコア:1, 参考になる)
http://www.jwas.gr.jp/index.html [jwas.gr.jp]
障害者・高齢者がウェブを利用する時の問題
http://www.jwas.gr.jp/whatsacs/seni/index.html [jwas.gr.jp]
総務省 (スコア:0)
「高齢者・障害者によるＩＣＴ活用の推進に関する研究会」（ＩＣＴユニバーサル研）の開催
http://www.soumu.go.jp/s-news/2002/021205_2.html [soumu.go.jp]
webdesing (スコア:0)
Re:webdesing (スコア:0)
まぁwebdesingerを名乗っている方はひとりしか知りませんが。
Re:webdesing (スコア:0)
googleで探したところ2万件ほど発見されましたが
私の知らないヨーロッパの言語で記述されているページがほとんどで
それが何を意味するのか知ることができませんでした。