アカウント名:
パスワード:
Web閲覧者の増加に伴う老眼な閲覧者の増加を考えると、Webページのアクセシビリティはビジネスに際しても重要な特性となると思えます。
それはWCAGであって、UAAGではないのでは?
#もっとも、ブラウザ自体がレンダリング結果を拡大/縮小できると(Operaのように)、Author側は、絶対単位で固めたレイアウトなページ作っても問題ないというかになるので、UAAG準拠になってくれると嬉しいけど。
こっち [srad.jp]にも書いたけど、それを望むのならば UAAGではなくて WCAG の方です。
外観構造は大事なのですが、それが意図した通りに再現されるとは 限らないのが Webコンテンツの世界なんです。
意図した通りのメディアタイプで、意図というか仕様で定められたとおりのCSSを適用する分には、(ブラウザの謳い文句に嘘偽りがなければ)同じように再現されるはずなのではないでしょうか。
現実的にうまくいってないのは、各ブラウザがバグってたり、おのおのが違う解釈を行っていたりするからだと思いますが。
で、当然ながらHTMLは文書構造を提供しているわけですから、CSSが有効でない環境であれば、外観構造は破棄され、ブラウザ側の表示に完全に依存するでしょう。しかしそれは、意図し
ざくっと。
というか、それはそれで、全く問題ないと思いますが。そのようなブラウザでは、どう表示されようが、ブラウザ側に依存で、それでいいんじゃないでしょうか。見ている人はそのブラウザがそういう挙動をしていることがわかっているという前提が必要だと思いますけど。 CSS(とメディアタイプ)による外観構造の制御は、それが有効な環境である場合にのみ効力が発揮されれば良いわけで、そうでない場合も制御されてしまうと、逆に困りますというか。そのためにも、もともと意味づけとして妥当なマークアップを施した文書を提供していれば良いわけですし。
というか、それはそれで、全く問題ないと思いますが。そのようなブラウザでは、どう表示されようが、ブラウザ側に依存で、それでいいんじゃないでしょうか。見ている人はそのブラウザがそういう挙動をしていることがわかっているという前提が必要だと思いますけど。
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属性に「すぐに本文へ」というのを書いて、こいつをページ内リンクにしてやる、という、ややトリッキーな手法で対応するというのが、視覚的に違和感ない範囲で読み上げブラウザ向け、のやり方になるかなとか、思ってます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
Webページのアクセシビリティ (スコア:1)
それはWCAGであって、UAAGではないのでは?
Re:Webページのアクセシビリティ (スコア:1)
> 4.1 ユーザーがテキストのサイズを構成できるようにします。[優先度 1]
だってさ。
ブラウザがフォントの拡大機能持ってなかったら困る、
ってことで UAAG に含まれてるわけね。
それにしても、
> 開発者は、オープンでアクセス可能な仕様を実装するべきです。
とか
> 標準API（例、W3C DOMなどのプラットフォームに依存しないAPI、オペレーティング・システムに関する標準API、プログラミング言語、プラグイン、仮想マシ
# mishimaは本田透先生を熱烈に応援しています
Re:Webページのアクセシビリティ (スコア:1)
そういうことじゃなくてというか、ビジネス的に重要な要素というなら、Author側がWCAGをよく考えて、という意味合いのつもりでした。
ブラウザ自体がビジネスの道具となられてもどうかと思うので。
#もっとも、ブラウ
Re:Webページのアクセシビリティ (スコア:0)
こっち [srad.jp]にも書いたけど、それを望むのならば UAAGではなくて WCAG の方です。
Re:Webページのアクセシビリティ (スコア:1)
WCAGでは相対単位を求めているけれど、絶対単位のほうが作りやすいから、UAAGによってOpera式?の拡大/縮小をブラウザが実装して欲しいという話なのですが。
Re:Webページのアクセシビリティ (スコア:0)
「作りやすいから絶対単位がいい」という発想は変ですってば。
Re:Webページのアクセシビリティ (スコア:2, 興味深い)
Opera式? とクドクド書いているのにはワケがあって、フォントサイズだけが可変というのがおかしいと思っているわけです。
画像などのオブジェクトはピクセル単位で表示されて配置されるわけですから、テキスト部分もピクセル単位で表示されるほうがきっちり配置されます。なんで、まるごと拡大/縮小できればそれで済むというか。IEなどでも、画像のwidth/heightをem指定とかす
Re:Webページのアクセシビリティ (スコア:0)
画像サイズも追従するかどうかを選択できるのがより良いですね。
さて、
>画像などのオブジェクトはピクセル単位で表示されて配置される
>わけですから、テキスト部分もピクセル単位で表示されるほうが
>きっちり配置されます。
BODY要素直下における 1em のサイズは、多くの場合ブラウザに
設定されたデフォルトのフォントサイズなので、そういうブラウザ
ではフォントサイズを em で指定してあったとしてもピクセル単位
です。
> なんで、まるごと拡大/縮小できれば
>それで済むというか
Re:Webページのアクセシビリティ (スコア:1)
意図した通りのメディアタイプで、意図というか仕様で定められたとおりのCSSを適用する分には、(ブラウザの謳い文句に嘘偽りがなければ)同じように再現されるはずなのではないでしょうか。
現実的にうまくいってないのは、各ブラウザがバグってたり、おのおのが違う解釈を行っていたりするからだと思いますが。
で、当然ながらHTMLは文書構造を提供しているわけですから、CSSが有効でない環境であれば、外観構造は破棄され、ブラウザ側の表示に完全に依存するでしょう。しかしそれは、意図し
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属性に「すぐに本文へ」というのを書いて、こいつをページ内リンクにしてやる、という、ややトリッキーな手法で対応するというのが、視覚的に違和感ない範囲で読み上げブラウザ向け、のやり方になるかなとか、思ってます。