パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

ブラウザの開発ガイドライン User Agent Accessibility Guidelines 1.0 が勧告に」記事へのコメント

  • Web閲覧者の増加に伴う老眼な閲覧者の増加を考えると、Webページのアクセシビリティはビジネスに際しても重要な特性となると思えます。

    それはWCAGであって、UAAGではないのでは?

    • UAAGでは [u-shizuoka-ken.ac.jp]

      > 4.1 ユーザーがテキストのサイズを構成できるようにします。[優先度 1]

      だってさ。
      ブラウザがフォントの拡大機能持ってなかったら困る、
      ってことで UAAG に含まれてるわけね。
      それにしても、

      > 開発者は、オープンでアクセス可能な仕様を実装するべきです。

      とか

      > 標準API(例、W3C DOMなどのプラットフォームに依存しないAPI、オペレーティング・システムに関する標準API、プログラミング言語、プラグイン、仮想マシ
      --
      # mishimaは本田透先生を熱烈に応援しています
      • あー。

        そういうことじゃなくてというか、ビジネス的に重要な要素というなら、Author側がWCAGをよく考えて、という意味合いのつもりでした。

        ブラウザ自体がビジネスの道具となられてもどうかと思うので。


        #もっとも、ブラウ
        • #もっとも、ブラウザ自体がレンダリング結果を拡大/縮小できると(Operaのように)、Author側は、絶対単位で固めたレイアウトなページ作っても問題ないというかになるので、UAAG準拠になってくれると嬉しいけど。

          こっち [srad.jp]にも書いたけど、それを望むのならば UAAGではなくて WCAG の方です。

          • なんでですか?
            WCAGでは相対単位を求めているけれど、絶対単位のほうが作りやすいから、UAAGによってOpera式?の拡大/縮小をブラウザが実装して欲しいという話なのですが。
            • UAAG準拠などというようにアクセシビリティを考えているならば
              「作りやすいから絶対単位がいい」という発想は変ですってば。
              • うーん。絶対単位が*いい*とは書いてないんだけども。

                Opera式? とクドクド書いているのにはワケがあって、フォントサイズだけが可変というのがおかしいと思っているわけです。

                画像などのオブジェクトはピクセル単位で表示されて配置されるわけですから、テキスト部分もピクセル単位で表示されるほうがきっちり配置されます。なんで、まるごと拡大/縮小できればそれで済むというか。IEなどでも、画像のwidth/heightをem指定とかす
              • Opera風に画像も拡縮できる方がよいというのは全く賛成ですが
                画像サイズも追従するかどうかを選択できるのがより良いですね。

                さて、

                >画像などのオブジェクトはピクセル単位で表示されて配置される
                >わけですから、テキスト部分もピクセル単位で表示されるほうが
                >きっちり配置されます。

                BODY要素直下における 1em のサイズは、多くの場合ブラウザに
                設定されたデフォルトのフォントサイズなので、そういうブラウザ
                ではフォントサイズを em で指定してあったとしてもピクセル単位
                です。

                >           なんで、まるごと拡大/縮小できれば
                >それで済むというか
              • 外観構造は大事なのですが、それが意図した通りに再現されるとは
                限らないのが Webコンテンツの世界なんです。

                意図した通りのメディアタイプで、意図というか仕様で定められたとおりのCSSを適用する分には、(ブラウザの謳い文句に嘘偽りがなければ)同じように再現されるはずなのではないでしょうか。

                現実的にうまくいってないのは、各ブラウザがバグってたり、おのおのが違う解釈を行っていたりするからだと思いますが。

                で、当然ながらHTMLは文書構造を提供しているわけですから、CSSが有効でない環境であれば、外観構造は破棄され、ブラウザ側の表示に完全に依存するでしょう。しかしそれは、意図し

              • ざくっと。

                というか、それはそれで、全く問題ないと思いますが。そのようなブラウザでは、どう表示されようが、ブラウザ側に依存で、それでいいんじゃないでしょうか。見ている人はそのブラウザがそういう挙動をしていることがわかっているという前提が必要だと思いますけど。

                CSS(とメディアタイプ)による外観構造の制御は、それが有効な環境である場合にのみ効力が発揮されれば良いわけで、そうでない場合も制御されてしまうと、逆に困りますというか。そのためにも、もともと意味づけとして妥当なマークアップを施した文書を提供していれば良いわけですし。

              • 総じて同意ですが、そういうことをみんなが(少なくとも一つのサイトを例に取れば、制作に関わる人と読み手の両方が)了解するという事態に至らなければ、サイト運営的にはむつかいんじゃないかな、と思います。たぶんそこがいちばん難しい。

                えーと、#224174 [srad.jp]で、ある意味極端な例が挙げられたので、そんなこと関係ないでしょうと返事したつもりです。

                通常であれば、CSSとメディアタイプがどーよなんてことは考えずに、いわゆるscreenメディアでIE6的に問題のないサイトってのを提供して、それを前提として掲げることには閲覧側も概ね了解してもらえるんじゃないかと思いますが、そうい

              • 通常であれば、CSSとメディアタイプがどーよなんてことは考えずに、いわゆるscreenメディアでIE6的に問題のないサイトってのを提供して、それを前提として掲げることには閲覧側も概ね了解してもらえるんじゃないかと思いますが、そういうことではなく?

                いえ、そういうことであれば。ただ、そのときに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属性に「すぐに本文へ」というのを書いて、こいつをページ内リンクにしてやる、という、ややトリッキーな手法で対応するというのが、視覚的に違和感ない範囲で読み上げブラウザ向け、のやり方になるかなとか、思ってます。

                親コメント

※ただしPHPを除く -- あるAdmin

処理中...