Webアクセシビリティに関するJIS素案研究会
開催案内
高齢者や障害者などのウェブ・アクセシビリティを向上させるためのガイドラインをJIS化する作業が進められていますが、このたび「高齢者・障害者等配慮設計指針-情報通信における機器・ソフトウェア・サービス- 第三部: ウェブコンテンツ(JIS素案)」が完成し、広く意見を求める公開レビューが、10月24日から11月24日まで実施されています。(公開レビューの詳細は、
「公開レビューのご案内」
をご覧ください。)そこで、下記のとおりこのJIS素案に関する研究会を開催することとなりました。本研究会は、より多くの方にこの問題に対する理解を深めていただき、このJIS素案に対する多くの有益な意見が提出されるようにすることを目的として開催するものです。研究会ではまず、JIS素案の説明をJISワーキング・グループ副査の梅垣まさひろ氏にしていただき、それに対する質疑応答のかたちで議論を進めていきます。
また、この問題に関する議論を行うことを主な目的として、 NAPでは新たに Webアクセシビリティに関する話題を取り扱うメーリング・リストを開設しました。研究会に参加される方はもちろん、当日の参加はできないがこの問題に関心があるという方もぜひ登録してください。登録方法など詳しくは、
web@accessibility.orgメーリング・リストに関する情報ページ
をご覧ください。なお、このメーリング・リストへの投稿は、
<URL: http://lists.accessibility.org/web/>
で逐次公開されています。
記
- 日時
- 2003年11月9日(日)14時-17時
- 主催
- 場所
- 筑波大学附属盲学校
〒112-8684 東京都文京区目白台 3-27-6
地下鉄有楽町線護国寺駅から徒歩8分
- 定員
- 50名 (先着順に受け付けます。参加の可否は後日メールにてお知らせします。)
- 参加費
- 無料
- お問い合わせ先
- jis-workshop@accessibility.org
プログラム
- 今回の研究会開催の経緯 (渡辺隆行氏)
- JIS素案に関する説明 (梅垣まさひろ氏)
- JIS素案に関する意見交換
参考資料
参加を予定されている方は、「公開レビューのご案内」で公開されている、JIS素案、付属書および解説書を熟読の上ご参加ください。
また、以下に挙げる文書も本件に関連が深いものですので、なるべくその内容を理解した上でご参加ください。
- W3C Web Content Accessibility Guidelines 1.0
- Web Content Accessibility Guidelines 2.0 public draft
- アメリカ、リハビリテーション法 508条施行規則
Electronic and Information Technology Accessibility Standards
なお、これらの文書に関する日本語の情報としては、以下のようなものがありますので、参考にしてください。
研究会記録
研究会開催の経緯 (渡辺隆行氏)
- NAPで千葉大市川先生が発言して、今年 5月に JISのことを知った。
- 6月1日に研究会を実施
- 当時のパブコメ用ドキュメントには問題があった
- JISは日本では法律に代わる大事なガイドラインとなるから、なんとか実現させたいと思った
- ドラフト作り直し
- 新たに渡辺氏らがJIS委員会に参加
- 10月にパブリックコメント開始
- 新たに新鮮な目で見て、自分の立場で自由に発言して欲しい
JIS素案の説明 (梅垣まさひろ氏)
発表資料
資料の中で、 WebJIS となっている部分があるかもしれないが、 WebJIS素案
というのが正しい。
はじめに
- WG2で公開した公式文書はパブリックコメント文書のみ
- 今日の話は個人的見解
WebJIS作成の背景
- JEITA指針、CIAJ指針(電話、ファクスなど)の統合
- ガイド71の具体化
- IT基本法
- eジャパン戦略でアクセシビリティの考慮が名言された
- 電子政府におけるアクセシビリティ確保
- ユニバーサルデザイン
- マルチアクセス環境
- 総務省 行政管理局が政府関係のウェブを統括している
2002年7月の文書:行政情報の電子的情報に関する基本的考え方(指針)
ほぼWAI WCAG1.0と等価
グループ規格の構造と位置づけ
- 第1階層:ガイド71
- 第2階層:セクター指針:パブコメ終了。 まもなく正式に発行される最終段階
- 第3階層:さまざまな機器やソフト・サービスで、共通指針の枠組みにある個別規格
- だからWebコンテンツは「第3部」である
- 現状見えているのは:セクター指針、JEITA、ウェブコンテンツ
ガイド71
- 日本からの提案によるISO国際規格
- 「規格作成配慮指針」=規格を作る人が参照する規格(規格の規格)
- 3500円でダウンロードできる
- この規格は、規格の作成に関わる人を対象
- 高齢者・障害を持つ人々のニーズに配慮する
- 非常に重度な人のニーズは、範囲を超えるかもしれない
- 軽度の障害を持つ多数の人々のための変更=市場の拡大
共通指針
この規格は主に高齢者・障害者および一時的な障害がある人が、
情報処理装置・・・サービス利用の際のアクセシビリティを高めるために、
ハード・ソフト・サービスについて規格策定の指針。
- 未知の分野に関する指針は共通指針でカバーする
- 具体化された場合はそちらでカバーする(WebJISなど)
策定経緯
- 第1回は2001年7月から
- これまでに全 42回。
- このころのWGでは梅垣は傍聴者
- 関係団体に照会されたドラフトに多くの意見が出た (2003/06)
- 親委員会 (6/27)が「作り直し」を決定
- 体制の強化・補充 7月10日から新しい案の検討開始 ここから梅垣責任あり
- 主査の濱田さんが新しい案を作った
- 絶対にこれで十分とはいえない
- 国の予算でやっている関係で、今年度の予算でJISを作るには1週間くらいしか遅れが許されない
- 具体的でない提案は反映することが難しいが、具体的でよい提案はどんどん取り入れたい
- 以上、厳しい日程で作ってきた言い訳
WebJISの策定方針
- 誰が使うのかを明確にしよう
- 当初の案は使いにくかった
- 作成者が「見ながら作る」ことが考慮されていなかった
- 作成者・保守者がどこを読めばいいのか、何を理解すればいいのか、わかるように
- ガイド71・共通指針と整合すること
- 特定の技術に依存しない
- インターネットの世界で1年先を予想するのは難しい
- HTML4.01に依存したくない
- 分かりやすさとは相反するが抽象度を上げた
- 明快で最低限の基準に
- 製作プロセスを意識する
- どのように企画・保守すればいいのか
- コンテンツのライフサイクルを考えて
- 公共分野での発注・調達基準として使えること
- eJapan:国の調達担当者が「使える」と思えること
- 総務省行政管理局の指針(WCAG1.0とほぼ同等)と互換性を持たせ、スムースに移行してもらえるように意識した
- 例示を豊富に分かりやすくした
- Webアクセシビリティを理解していない企業は多い
- 具体例を示し、何をどうすればいいのか示した
梅垣氏個人が考えたこと
- WCAG1および2との整合、違いを明確に
- WCAG2のドラフトはよいものになりそうなので、盗みたい
- ユーザエージェント、支援技術との切り口の意識
- Webのアクセシビリティを実現するために、コンテンツがやる
べきことと、ブラウザがやるべきことがある。
- 現在はUAが未熟なのでコンテンツが解決していることが多い
--- 本当はUAのJISを作るべき
- 本来コンテンツが解決すべきこと、のみを区別して分離すべき
- 何でもUAに押し付けるのも困るし、支援技術に押し付けられるのも困る
- 正しく切り分けて、何でもコンテンツに盛り込まない
WebJISの社会的役割
- 政府の「努力義務」
- JISに合致したものを調達する
- ただし守らないからといって処分されたりはしないので、その点は 508条と違う
- IT基本法・eJapan戦略を援用すれば、WebJISを守らせることはできる
- JISを守るべきである、という世論が熟成されることが必要
- WG参加企業が守ってくれることを期待する
- 日本規格協会のWebサイトも問題あり
- 最近はJISを軽視する風潮もある
- ADAのような法律が必要かも -- 障害者基本法の改正案も解散で廃案になってしまった
- いかに社会的に認めさせるか、使わせていくかも重要な視点
各章の構成と解説
序文
- 序文は規格ではなく、 あくまで参考
- 規格で重要なのは「何が本文か」である
1:適用範囲
- 同じ適用範囲を持つ規格が複数存在してはいけない
- ウェブブラウザでアクセスされるあらゆる情報・サービス
- イントラネット
- CD-ROMコンテンツ
- ブラウザを用いて操作する機器
- 明示はしていないが、以下も含まれると考えている
- iモードやPDA向けに提供されるサービス
- Lモード
2:引用規格
- 同時に読まれるべき・満たされるべき規格
- 「セクターガイド」を満たすこと
3:関連規格
4:言葉の定義
5:一般的原則
- 可能なかぎり高齢者障害者が利用できるようにしなさい
- 出来るだけ多くの機器や環境で利用できるようにしなさい
- 企画から運用に至るプロセスで常にアクセシビリティを確保しなさい
- 規格の思想 -- 実際にどのようなユーザがいて、どのような条件で守られるべきか
6:個別要件
あとで質疑応答
- おおむね書かれていることは間違っていないと思う
- 我々が何かを見落としていないかどうかをよく検討して欲しい
- 書いてあることをどう変えて欲しい、はあるが、「これを入れて欲
しい」というのがなかなか出てこない。
- 見落としの指摘に力をさいて欲しい
7:全般的要件
- コンテンツの自動生成プログラム
データベースサーバに表示する画像ファイルを突っ込むフィールドがあるとき、
ここにALTを入れるフィールドがないと後で困る
- 上流の工程で配慮が必要
- 追加・更新をする人が品質を維持することの必要性
- アクセシビリティ検証の必要性
たとえば、今のところいいaltと悪いaltの判断は機械的にはできので、
ユーザを交えて検証するしかない
- 利用者からのフィードバック、利用者のサポート
情報源
- 資料にリンク集をつけたので、読んだ上で吟味して欲しい
- 残された時間は短いが、少しでも良くしたいので、建設的な意見が
聞きたい
JIS素案に関する意見交換
本文を見ながらメー
リング・リストで出された指摘(64件ある)を検討
4章
- 非テキスト情報
- 文字以外のウェブコンテンツ。画像,音声,動画等のマークアップされたもの。
→文字以外のウェブコンテンツ。画像、音声動画等。
5.2 基本的要件
4)ウェブコンテンツを操作・利用することによって、身体の安全を害さない
ようにする。
→エラーを最小限に防ぎ、適切に回復するための手段が必要。
6.開発・制作に関する要件
- 非常に重要な部分
- 並べ方は工夫した 大枠から順番
- 画像や音声は要素でもあり非テキストでもある
- 重複するがなるべく適切な場所に分類したつもり
6.1 規格や仕様の準拠 a)
a)ウェブコンテンツは、原則として関連する文法、技術の規格や仕様に
準拠して作成しなければならない。
以下、「しなければならない」となっているのに、「原則として」となっている点に
ついて。
- コンテンツが正しく書かれているという前提条件を崩すと結局
アクセシビリティが守られない
- UAが対応し切れていない場合がある -- NN4.7はどうするのか、など
- アクセシビリティの観点から、「原則として」は削除するべき
- MUSTにする意味がなし崩しになり、志が消えてしまう
- 多様なユーザへの配慮と多様なブラウザへの配慮は違う --- NN4.7に配慮すべき理由は何もない
- 「原則として」はあるメーカが強く主張して入った
- 現場の人にとっては、完全な準拠はシビアである
- 問題は古いブラウザ
特定のブラウザ固有のローカルな要素はこのルールに反するのか。
- 6.1a)の2番目の参考に書いてある
- この「参考」については、「何が乱用なのか分からない」という意見もあるが、
正しい方向へ行くことを目指したコメント。
- 「原則として」を消した上で、この2番目の参考を残すというのはどうか。
- 「参考」や「例」は規格本文ではないので、これらを隠した状態のものが規格
- 「原則として」を取ると、参考の2つ目「あえて破らないとアクセシビリティを確保できない」が不適合になってしまう
以下、具体的に守るべき「規格や仕様」が不明確であるという指摘に対して。
- 例示のところに別記されている
- WCAGでは、「関連仕様の最新バージョン」と書いてある。
- 特定の仕様やバージョンを明記すると、アクセシビリティに配慮した新技術を
排除することにつながる。
- どの程度のブラウザを想定しているのか見えない
- 古いバージョンのブラウザをサポートしなくていいと JISに明記してあればい
いのかもしれないが…。
具体的にHTMLXXと書けない理由:
- JISはJISを参照しなくてはならない
- XHTMLは JISになっていない。
- HTML4.01はJIS-TRになっている
- XMLはJISである
- RUBYのJIS規格とW3CのRUBYは違う
1番目の参考の 「正しく書かれていないと支援技術が正しく動作しなかったり、利用
することができなかったりする可能性がある。」について、
- これを守って欲しい根拠がはっきりと書かれていない。
- あるブラウザでは、間違った入れ子構造になっているソースでも表示できてしまうが、そうでないものもある。
- どのブラウザでどんな支援技術が誤動作するのか明記すれば分かりやすい。
- 守って欲しいレベルを明記すればよい。
6.1 b)
【例】 コンテンツにJavaを埋め込む場合には、用意されているアクセシビリ
ティ機能を適切に実装する。
- 「用意されている機能を適切に用いたプログラムを実装する」ではないか。
- WCAG1.0では、埋め込みプログラムにアクセシビリティの高いIFを用意せよ、
となっている。
埋め込まれているもののアクセシビリティを確保することが重要ではないか。
- WCAG1.0では、「スクリプトやプログラム」となっている。 JISでもそのよう
にした方がいいのでは。
- WCAG1.0のころには、対象となるものが JavaScriptと Java Appletくらいしか
なかった。
- 今は、スクリプトともプログラムとも言えないものもある。 (Flash, SVG, 動
画コンテンツなど)
- 「プログラム」と言わずに「オブジェクト」として抽象化しておくべき。
- オブジェクトを使うならアクセシブルなオブジェクトを使えと書けばいい
- 「オブジェクトそのものをアクセシブルにしたい」という文章にしたい
- 現状支援技術が対応している例として、 JavaScriptのイベント・ハンドらを
挙げてはどうか。
6.2 構造と表現 a)
a) コンテンツは論理構造にしたがって記述する。
- なぜ文末が「する」で、「しなければならない」ではないのか。
- チェック漏れ。本来「しなければならない」か「望ましい」のどちらかは、今
は軽率には言えない。
- 「しなければならない」とするべきではないか。
【参考】音声ブラウザによっては論理構造の情報を音声化して利用者に提供し
ている。
- 論理構造は音声ブラウザがユーザに適切な音声情報を
提供する上で不可欠な情報である
などとしてはどうか。
- 論理構造とはなにかを明確にすべき。マークアップされていればなんでもよい、
と思われるかもしれない。
- W3C的には、 semanticsを記述する、という意味だが、適切な日本語はなにか
- 「情報の意味的構造」ではどうか。
6.2 b)
b) コンテンツの表現はスタイルシートを使うことが望ましい。加えて、スタ
イルシートを使用する場合は、未対応のウェブブラウザでも利用可能にする。
- 後半部分について、目的語がなく意味が分からない。
- この部分は削除すべきではないか。
- しかし、 WCAG 1.0には、「未対応のブラウザでも意味が分かるように」とい
う項目があるので、整合性を確保するためには必要ではないか。
【参考】音声ブラウザなど、スタイルシートに対応しないウェブブラウザもあ
る。
- 音声ブラウザに関しては、「現状では」とすべき。
- 一般のブラウザで非対応のものがあることは周知なので、削除してもよいのではないか。
- 意味構造と見た目を分離することを推奨する明確な記述がない。
5章あたりに書いておくべきではないか。
- もともと 6.2のタイトルは「構造と表現の分離」だったが、内容を整理するう
ちに、別の項目も入ってきたので「分離」がとれた。
- やや遠慮がちに「分離しなさい」と言っているのが現状
6.2c)
c) 表組みの要素をレイアウトのために使わないことが望ましい。レイアウト
のために表組みの要素を用いる場合は、音声での読み上げ順序を考慮して作成
しなければならない。
- 論理構造と表現の分離のポイントになる項目なので、表組みの要素はレイアウトのために使わない、と言い切るべき
- WCAGでも譲歩している。
- いかにアクセシビリティを損なわないかが重要ではないか
- 現場には「それなくしてデザインできない」という意見が強い
- ウェブを紙の置き換えだと思っている人も少なくない現状では、 tableによる
レイアウトが禁止されるとつらいだろう。
- レイアウトテーブルを禁止することで、JIS自体がそっぽを向かれるのは困る
6.2 f)
【例1】各frame要素のtitle属性に、内容にあったタイトルを入れる。
- 内容に合った、ではなく「役割に合った」であるべき
- フレームセットの中の各フレームの役割を明示することが必要。
- 議論を眺めていると、フレームに分かれていたときに、
各フレームの役割や変化のタイミングがわからないことが
アクセシビリティを損なうということだと思う
- この素案にはそういう項目はないと思うが、WCAG1.0には、そのサ
イトのアクセシビリティに関する説明を提供すべき、とある
- そのような説明ページの中で、このフレームセットがどういう構成か、という説明があれば問題は緩和できるのではないか。
6.3 操作や入力 b)
【例4】ラベル(名称) とチェックボックス等のコントロールを関連づけるこ
とで、ラベル部分をクリックしても、コントロールを選択できるようになる。
ラベルには2種類の機能があるが、素案ではその一方しか言及されて
いない。そこで、
例4の後半に追加:
また、ラベルを設定することによって音声ブラウザが
各コントロールの意味を誤らずにユーザに伝えることができるようになる
6.3 g)
【参考】高齢者や上肢に障害がありマウスの操作が困難な場合、認識できなかっ
たり、操作が困難になったりする。
- 高齢者という言葉が定義されていないのにこのような記述をすると、なぜ高齢
者だと難しいのかが分からない。
- 加齢により、上肢のコントロールが難しくなる、など具体的に示すべき。
- 高齢者をまとめて扱っていて、大雑把過ぎる印象。
- 「一時的障害」の例もいれられるのではないか。
6.4 非テキスト情報
- Hotmailの新規アカウント作成の際には、画像で表示される文字列を入力する
ことが求められる。このようなケースに関して
何らかの大体手段を用意するようなことを求める項目が必要。
- 画像の代わりに音声、ということでは、盲聾の人はアクセスできない。
- 大体手段としてメールなどでもよい。
- このようなケースをカバーするための項目は、あまり抽象的な書き方では何の
ことを言っているのか分からないので、具体的に分かるような文を考える必要
がある。
6.6 文字
- 文字サイズの指定について、印刷メディアに関しては、相対指定でなくてもよいのではないか。
- 本来はブラウザがユーザの都合のいいサイズに調整できるべきではないか。
6.7 音
- 音に加えて動画も対象にしては?
- 動画というとむやみに範囲が広がる
- 関連して、フォーカスが他に移るようなコンテンツも問題
- 連続的なメディア全般に関して適応すべきではないか
- フォーカスという概念はUAの実装に依存する
- フォーカスの話を6.3e)に入れたらどうか。-- ページの自動更新などと関連するのではないか
6.9 言語 d)
d) 表現のために単語の途中にスペースや改行を入れてはならない。
- 支援技術で対応することはできないか。
- 論理的でないスペースに対応するのはきわめて難しい。
- 縦書きではないような開業については問題ないはずなので、表現に工夫が必要。
- 「縦書きの実現」もCSS3の Writing Mode でできる
提案 (以下を参考などとして追加):
縦書きで表現したいという理由で一文字ごとに改行タグを入れると
音声ブラウザはばらばらの文字として認識するので正しく読み上げられない。
7.3 検証に関する要件
- 単に検証といわれても何を検証すればよいのかがはっきりしない。
- 支援技術の現状を考慮したコンテンツ作成を行うことが望ましい、というよう
な項目を追加してはどうか。
- 対応する支援技術がまったくないような状況では、さらなる配慮が
必要となる。したがって、広く使われている技術の状況を考慮してコンテンツ作成を行うべき。
- よく使われている環境について、実装状況など、現状を示すと分かりやすい。
- 音声環境は、時系列的な情報提示手段であり、記憶に頼る部分があるというこ
とを伝えたい。
- 各障害の人が情報取得をするときになにが難しいのか、どこにも書
いていない。-- たとえば、視覚障害者は鳥瞰図が得られないことがもっとも大きな問題であるなど。
- セクター・ガイドラインには書いてないのか?
- 鳥瞰図がないから、みたいなことはガイド71では無理。やはり特別に作る必要がある
- みんなをどう教育していくか、という話
その他
- 入力装置に依存しないというだけでは不足しているかもしれない。動的に画面
が変化するものは困る。
- textualな情報が変化するのが困るのであって、画像の変化は困らないと思う
ので、もう少し弱い言い方でもいいと思う。
- WCAGにはあるが JIS素案にないものとして、 lang属性を指定する、というの
がある。
- それは仕様に従う、というのでカバーされているのでは。
- langはオプショナルだからカバーされていないと思うし、「仕様に従う」でカ
バーされていると言ってしまえば 6章のほとんどはカバーされてしまうのでは
ないか?
- 明らかに視覚障害者が使わないと思われるアプリケーションのアクセシビ
リティはどうか。
- 企画準拠が調達基準になるということ。後は調達基準に適合させたいかど
うかという開発側の問題。
- iモード、デジタル放送のBMLによるアクセスなどはカバーするか。
- (梅垣): iモードは対象として考えている。データ放送やBMLについては放送と通信
の狭間である。BML自信が視覚障害にうまく対応できないのではないかという問
題もある。別の企画で対応できるといいと思う。
日本語に関して
WCAG 2.0の策定作業に対して、我々が貢献できる部分だと思う。
- 固有名詞 ・人名に振り仮名をつける。これはみんなにメリットが
ある。
- 本質的にそれ以外に日本語固有の問題はないのでは?
- 日付・単位の問題は、UAの問題で、一部のUAが変な読み方をするから、といって
コンテンツのガイドラインに盛り込むべき問題ではない。UAがこうあるべきだ、
という別の仕様が必要
- コンテンツの問題として捉えるのは的確ではない
- 日付の書き方に関する項目が WCAGの策定段階で入っていたことがあったが、
それは障害とは関係ない、文化の問題なので、削除された。
- ーと- 1とlなど、文字を見かけではなく論理的に正しく使うべき
- 日本語固有の問題という扱いはしない方がいい。
- 日本語固有ではないからこそWCAGに提案しうる項目である。
最後に
提出するコメントでは、
- 企画の必要性・重要性を伝えること
- こうしたらもっとよくなる、と言ってほしい
- コメントは「お褒めの言葉」もほしい