第1回WebコンテンツJIS(JIS X 8341-3)研究会
開催案内
JIS X 8341-3:2004 「高齢者・障害者等配慮設計指針−情報通信における機器、ソフトウェア及びサービス−第三部: ウェブコンテンツ」 (いわゆる WebコンテンツJIS)が、去る 6月20日に公示されました。Network Accessibility Project (NAP)は、規格制定の過程からこの規格に注目しており、昨年 7月と 11月には、この規格の素案に関する研究会をITRC(日本学術振興会産学協力インターネット技術第163委員会)のUAI分科会と共催しました。
NAPおよび UAI分科会では、この規格が公示された今、JIS X 8341-3 の精神や内容を理解するとともに、Webアクセシビリティの現状を考慮した上でのこの規格内容の吟味や不足点の指摘などを進めていくことが重要だと考えています。そこでUAI分科会と NAPでは、今後 JIS X 8341-3の研究会を開催していくこととなり、下記のとおり第1回の研究会を開催することになりました。第1回となる今回は、JIS X8341-3を正しく理解し、今後の議論を進めていくために必要な共通理解をすることを目的とします。
今回の研究会では、まず今年度のJIS X 8341-3研究部会の体制について、UAI分科会主査で、平成16年度の「ウェブアクセシビリティ国際規格調査研究部会(WG2)」主査でもある渡辺隆行氏からお話しいただきます。次に、 WG2 副査で、JIS X 8341-3 を策定した昨年度までの研究部会の副査でもある梅垣まさひろ氏に、刊行されたJIS X 8341-3の概略を説明していただき、それに対する質疑応答のかたちで議論を進めていきます。JISの内容は多岐に渡り、議論すべきことも多いと思われますので、今回はあまり細部に立ち入った議論は行わず、JIS X8341-3全体を検討し、今後どのようなことを議論すべきかを検討します。その上で、下記メーリングリストや新たな研究会などでの議論を重ね、2004年中を目処により広い視野から議論を深めていきたいと考えています。
なお、渡辺、梅垣両氏には、個人的な立場で本研究会にご参加いただくものです。
記
- 日時
- 2004年7月31日(土)13時〜17時
- 主催
- 場所
- 東京女子大学
善福寺キャンパス
24101号室(24号館1階)
〒167-8585 東京都杉並区善福寺2−6−1
中央線西荻窪駅または吉祥寺駅からバスで15分あるいは徒歩20分。
- 定員
- 100名 (先着順に受け付けます。参加の可否は後日メールにてお知らせします。)
- 参加費
- 無料
- お問い合わせ先
- jis-workshop@accessibility.org
プログラム
- 今回の研究会開催の経緯(渡辺隆行氏)
- 今年度のJIS WGの体制 (渡辺隆行氏)
- JIS X 8341-3に関する説明 (梅垣まさひろ氏)
- JIS X 8341-3に関する意見交換
- 今後の予定について
参考資料
参加を予定されている方は、JIS X 8341-3を熟読の上、ご参加ください。JIS文書は、下記Webサイトで閲覧・入手可能です。
- オンライン閲覧:
- 日本工業標準調査会の「JIS検索」で「X8341-3」と入力して検索すると、JISのPDF文書を閲覧できます。ただし、ここでは保存や印刷はできません。
- オンライン購入(3,045円、カラー印刷56ページ):
- 日本規格協会のJSA Web Storeで「X8341-3」と入力して検索すると、規格票のPDFや冊子を購入できるページが表示されます。
また、以下に挙げる文書も本件に関連が深いものですので、なるべくその内容を理解した上でご参加ください。
- W3C Web Content Accessibility Guidelines 1.0
- Web Content Accessibility Guidelines 2.0 Working Draft
- アメリカ、リハビリテーション法 508条施行規則
Electronic and Information Technology Accessibility Standards
なお、これらの文書に関する日本語の情報としては、以下のようなものがありますので、参考にしてください。
メーリング・リストについて
JIS X 8341-3に関連する事項を中心に、 Webに関連する技術的な話題をとり扱うことを主な目的として、 NAPにWebアクセシビリティに関する話題を取り扱うメーリング・リストが開設されています。 今後の情報などもこのメーリングリストを中心に流していきますので、研究会に参加される方はもちろん、当日の参加はできないがこの問題に関心があるという方もぜひ登録してください。登録方法など詳しくは、
web@accessibility.orgメーリング・リストに関する情報ページ
をご覧ください。なお、このメーリング・リストへの投稿は、
<URL: http://lists.accessibility.org/web/>
で逐次公開されています。
研究会記録
発表資料
今回の研究会開催の経緯(渡辺隆行氏)
- 6月20日に発行された JISに関する研究会
- NAPとITRCのUAI分科会の共催
WebコンテンツJISに対する取り組みの経緯
- 昨年6月1日: JISのウェブアクセシビリティ指針策定部会(WG2)の中村広幸先生と植木 真氏、さらにW3Cの石川 雅康氏と萩野達也先生を講師にお迎えして、JIS原案に対するパブリックコメント提出のための勉強会を、「Webアクセシビリティに関するJIS化パブリックコメント研究会」として開催
- 諸般の事情でパブリックコメント募集は延期
- 梅垣、渡辺両氏がJIS策定部会に参加
- 2003年10月24日から11月24日まで公開レビューが実施された
- 11月9日に第2回の研究会を開催
- 今回は、新たに第1回として、JIS X 8341-3の研究会を開催
- 今回は、JIS X8341-3を正しく理解し、今後の議論を進めていくために必要な共通理解を深めることが目的
NAP中根氏、W3C石川氏の紹介.
今回の内容
- 梅垣氏のプレゼンテーション
- それを踏まえた議論
- 最後に30分ほどWCAG 2.0について
JIS X8341-3に関連した今年度のJIS研究部会の体制 (渡辺隆行氏)
- JISを策定した委員会は2003年度ですでに解散
- 2004年度からは新たに「情報アクセシビリティの国際標準化に関する調査研究開発」委員会が開始
- この委員会の下に「ウェブアクセシビリティ国際規格調査研究部会」が設置され、渡辺が主査、梅垣氏が副査を務めている
新しいWGの役割
- ウェブアクセシビリティ規格の国際協調を目指した、W3C/WAIとの協調作業
- X8341-3はISO/IECガイド71に基づいて作られている
- セクターガイドライン自体も国際提案中
- X8341-3そのものを直接国際提案する気はない
- WCAG 2.0と協調しつつ、漢字文化圏固有の問題点などの足りないところは改善を働きかける
- JIS X 8341-3:2004の国内普及活動と改善 -- これが今回の研究会の主目的
JIS X 8341-3に関する説明と意見交換 (梅垣まさひろ氏)
- どんな方が参加されているか?
- 大学等で研究している関係者: わずか
- 企業の担当者: 半数くらい
- 個人で興味がある方: 1/3位
- 随時チャチャを入れていただいて構わない
- 前回のパブリックコメントのときにも研究会を行った
- 当初の予定からパブリックコメントまでの3ヶ月に多くの変更があった
- 書き足りなかったところも多くある
- すぐに改訂はできないが、正誤表などは出せるはず
- JISにはこう書いてあるが技術の発展によりこうした方がいい、といったことが出てくることもある
- 国際協調として発展させることも
- 今日はJIS関係者でない立場で発言する
- 渡辺氏と共に1年ほどJISの委員会にかかわった
- 立場としては障害者団体の代表として参加した
- 支援技術の開発会社にいたこともある
- 原稿を書く立場でもある
- 今月のインターネットマガジンに記事が載っている; 来月も記事が載る予定
- チェッカーのホットレーティング
適用範囲(1)
- 厳密に書く必要がある
- 「一時的な障害」とは?
- セクターガイドで議論になった
- 解釈が分かれている
- 「障害のある人」...障害者手帳を持っている制度上の「障害者」では必ずしもない
- 「障害」とアクセシビリティをどう理解するか
- 障害=WHOが定めた概念がある
- ICF国際生活機能分類
- 社会的な部分と医学的な部分のどちらを重視するか
- 心身機能・身体構造のレベル
- 身体機能、身体構造、認知機能
- 医学的impairmentがある
- 活動のレベル -- 手が欠損=箸が使えない.
- 参加のレベル -- 車椅子だから旅行に行けない.
- 体に実際にある障害と、社会的な意味での障害との複合された有り様が「障害」
- 一時的な障害 - 身体的、社会的、医療的な障害の複合でないと言えないのではないか
- 一方で暗いところで操作する場合や片手が塞がっている場合など、医学的な障害は無いが操作が不自由な場合も含むと捉える人はいる
- 広く捉えるとアクセシビリティの適用範囲を広く主張できアクセシビリティを売り込むには有利だが、強引な説明でもある
- 本当に怪我をしている人を考えている?
- 医学的レベルは前提にしてよい
- 音声が出れば、障害がなくても便利
- 応用可能性を示すには強引な説明もOK
適用範囲(2)
- 「ブラウザ」とは?
- ちゃんとした定義がない
- Netscape, Mozilla, Lynx
- あるアプリに組み込まれたIEコンポーネント?
- HTML, XHTML, CSS, XMLなどを使ったコンテンツが対象?
- XHTMLはJISになっていない - 対象にしにくい
一般的原則
基本方針(a)
可能な限り高齢者・障害者が操作または利用できるように配慮する
- 「高齢者・障害者」 -- 障害のある人、一時的な障害のある人
- 「可能な限り」- そのサイトの社会的な位置づけやポリシーといった点から見て技術的な制限の範囲内で実施する
- 政府のサイトやユニバーサルサービスを提供する企業のサイトなどはそれなりの責任がある
- 一方、個人のサイトなどはJISに準拠する義務はない
- 求められているのは確かだが、要求レベルが違う
- もちろん自主的にやるのは一向に構わない
- 技術的な制約 -- 非常に重い障害に対応できないのは仕方ないかも.
- コスト的な観点は入っていない (個人的な見解)
- 「操作」
- 物理的に操作 (例: フォームから入力)
- 「利用」
- 操作の結果としてサービスとして利用できる
- 操作ができない場合は代替手段を用意することで「利用」はできる場合もある
- 例:アカウント登録がうまくできないので、電話やファックスで対応した
基本方針(b)
いろんなブラウザに対応せよ
- これは「アクセシビリティ」か?
- 支援技術の中には古い技術に依存したものがまだ存在する
- 新しい技術に対応するのに時間がかかる
- ブラウザへの依存を避けてほしい
- IE, Netscape(Gecko), PDA, テキストブラウザ - どこまで対応すべきか?
- CSSに「中途半端に」対応したブラウザが厄介
- 画面解像度はどこまで求めるか?
- 個人的見解
- 使いやすい使いにくいは問わない
- 使えるか使えないか=多様なブラウザに対応可能
- 最終的にはそれぞれ考えてほしい
- 古いものを引きずるのは得策ではない
- できるだけ新しい技術をアクセシブルにするべき
- 支援技術が頑張るべき
基本方針(c)
企画から運用に至るプロセスで情報アクセシビリティを常に確保し、更に向上するように配慮する
- blogはテキストなのでアクセシブル
- CMSは難しい
- SQL, PHP:画像のaltフィールドが用意されていないと困る
- 設計者と保守運用者の分離
- デザイン会社とコンテンツ作者の分離
- 作り人だけでなく発注する人も保守する人も考慮する必要がある
基本的要件
「身体機能および構造の制約への対応」
推奨要件
a)認知及び記憶への過度な負荷をかけずに、ウェブコンテンツを操作又は利用できるユーザビリティの高いページを。
b)利用する情報通信機器、及び利用環境を限定せずに、多様な環境でウェブコンテンツを操作又は利用できる。
c)不慣れな人でも利用できる。
- セクターガイドを併読せよ
- 推奨要件とユーザビリティは深く関わっている
必須と推奨と、合わせワザ
JISの読み方 -- ソシオメディアの植木さんの整理:
- 必須
- しなければならない
- 推奨
- することが望ましい
- 合わせワザ
- することが望ましいが、できない場合は ... しなければならない
5.1 規格及び仕様への準拠(a)
a) ウェブコンテンツは、関連する技術の規格及び仕様、並びに文法に準拠して作成しなければならない
- DTDを明示してvalidかどうかチェックする
- HTML/XHTML/CSSだけでなくその他のものも(RDFなども)チェック
- なぜvalidにするのか?
- validでなくても表示できるブラウザが普及
- おかしいHTMLがちゃんと表示される
- へんな解釈が必要になる
- (変な解釈ができる) 賢いブラウザに支援技術が組み合わさると、支援技術が混乱する
- HTMLの解釈方法はひとつであってほしい
- 現実としてvalidなサイトは少ない
- validにするのはけっこう大変
- オーサリングツールのメーカにもっと頑張ってもらいたい
- Strictを要求すべきか?
- できればStrictにしたい
- 問題はブラウザがちゃんと扱えるかどうか
- ブラウザ依存 (ブラウザのバグ対応) は?
- 最新のHTML/XHTML/CSSを使うべきか?
- WCAGは最新のものを使え、とある
- JISでは必ずしもそれを要求していない
- できるだけ最新技術を使うべきだが、ブラウザが問題
5.1 規格及び仕様への準拠(b)
b)ウェブコンテンツには、アクセス可能なオブジェクトなどの技術を使うことが望ましい
- アクセス可能かどうかを誰が判断できるのか?
- PDFはアクセシブルか?
- アクセシブルに作ればいいのか?
- 保障できるのか?
- 「アクセス可能」は現時点ではJIS X8341-2で評価
- JIS X8341-2にソフトウェアも含まれる
- ソフトウェア業界にもアクセシビリティJISを作ってほしい
- Accessible objectの定義がまだできないために「望ましい」になっている
- 個人的には必須要件と考えたい
- 最近はFlash/PDFもアクセシブルにするための技術が出てきた
- スクリーンリーダーで音が出るようになった
- アクセス可能なオブジェクトには代替情報の付与は「推奨」
- アクセス可能でないオブジェクトには代替情報の付与は「必須」
- 例: Flashが表示できない場合に代替情報は必要か?
- 例: 97%の対応実績は十分か?
- 従来のFlashの使い方 - プルダウンメニューを表示したり、アニメーションを表示したりが主
- 最近はフォーム入力を使いやすくしたりといったこともできる
- ウィザードのような機能
- データベースとの連携
- 使いやすくなるのは間違いないが、代替手段は?
- HTMLで「代替」手段を提供するのはもはや不可能なのではないか?
- ブラウザがネイティブにFlashに対応したら? -- それはもはやアプリケーションなのでは?
- ブラウザとアプリケーションの区別がなくなっていく
- PDF, Flashはアクセシビリティ技術が一応確立している
- Macromediaがアクセシビリティ関連のフォーラムを開催したら700人以上の申し込みがあった
- こんなに来たのは世界でも初めて
- 会場ではJISが結構売れたらしい
- マクロメディアの担当者も驚いていた
- 時代は変わってきた
- 1年後にはすごいことになる? 忘れられている?
- アクセシブルでクールなサイトは日本から?
- Javaはアクセシビリティ技術が確立している
- 日本のスクリーンリーダーはほとんど未対応
- Jawsは一部対応しているが、サポートはされていない
- 日本では難しい
- ActiveXはMSAAに対応する必要がある (LonghornではMSAAはなくなるらしい)
- JavaScript, VBSは? noscriptは必要
質疑
Q: Javaでアクセシビリティが確立されている、というのはアプリケーション
での話は?
A: 梅垣:
- ややこしいので詳しくはJavaのサイトで確認して欲しい
- Windowsで使うにはブリッジが必要
- IBMがaDesginerというツールを出している
Q: Java でアクセシブルに書くことができる、という話か?
A:梅垣: それ用のクラスライブラリが用意されているのでそれを使えばよい
Q: 適用範囲について、社内のグループウェアの開発をしている。
ある程度適用範囲がわかるがパッケージとしても販売している。
基本的にはJISに対応しなければならないと思っているがそういった製品についてはどうか。
A: 梅垣:
- できれば対応していただきたい
- 障害者の社会参加などを考えたとき、ツールが対応しているかどうかは重要
- いったん導入すると入れ替えられないものはアクセシブルに
- 社内システムだとログイン管理など技術的に難しいかもしれないが
- JISはそういったものも対象と考えている
- JIS対応を売りにして商品価値を高めて欲しい
A: 渡辺:
- 利用者が利用しようと思ったときに利用できればよい
- 公共性の高いサイトほどJISに準拠することが求められる
その他の発言:
- 社員の男性の5%は色覚障害
- 企業側でも頑張っている
- HTMLの文法でStrictで書くと支援技術で対応できない? という話を聞いたことがあるが...
- 「Strictは難しい」とおっしゃったがそんなことはない
- 常にStrictで書くべき
- CSSとの併用にはStrictがよい
- 「最新」を明記して欲しかった
- HTMLは4.01が最新で、3.2は日本語が使えない
梅垣:
- Strictかどうかではなくvalidかどうかの問題
- ブラウザの切替にはvalidにならない裏ワザがある
- 何でもかんでもコンテンツで解決するのは間違い
- 支援技術やブラウザもコンテンツと同じくらい努力するべき
その他の発言
- Strictで全部済ませられるのが望ましいが現実にはなかなか難しい場合もある
- Transitionalで何が悪い?
Webアクセシビリティを構成する要素 (渡辺)
- Webのアクセシビリティ問題の研究、理解
- Web技術がアクセシビリティに配慮
- Webコンテンツ作成側がアクセシビリティに配慮して作成
- Web利用ソフトウェアがアクセシビリティ機能を利用できる
- Webの利用者に配慮が適合している
- Webの製作者と利用者の規範
- Web作者への配慮
- Webの自由を損なわない
- 作成者の負担を軽減するべき
- お互いに足を引っ張らないようにしたい
5.2 構造と表示スタイル(a)
ウェブコンテンツは見出し、段落、リストなどの要素を用いて文書の構造を記述しなければならない
- 「表示スタイル」- スタイルシートなどを使った場合 --- CSSのJIS規格の中にこういう言葉があった
- h, p, div, dl, ol, ul, address, blockquoteなどを使って構造的に書く
- h はツリー構造ではない - XHTML 2.0ではsectionがある
- デザインのきれいなページにはheadingがほとんどない
- 視覚障害者用スクリーンリーダーは、ウェブページを細長い巻物にして読むようなイメージ
- Tabキーでリンクをたどる
- シリアライズされた情報
- リンクが100個あるページだとどこに何があるかわからない
- 構造的に書くと、ページの構造が持つツリー構造を使ってアクセスできる
- スクリーンリーダでは仮想カーソルを適当な位置に移動して目的の位置にすばやくアクセスできる
- IBM A-Designerでうまくチェックできる
- headingは見出しなので本当の意味での構造化ではない
- XHTML 2.0で意味的構造が導入される
- 意味的にも構造化されているとサイトの中身を理解しやすい (SEO効果も上がる?)
- 最近はRSSを出すとSEO効果があるらしい
5.2 構造と表示スタイル(b)
表示スタイルは文書の構造と分離。
見た目はスタイルシートを用いて記述。
ただしスタイルシートを使用できない場合、意図的に使用しない場合でも支障が生じてはならない。
- レンダリングはCSSで、構造はHTML/XHTMLで
- ユーザが積極的に変更できる
- 優先順位を設定できる
- ブラウザがスタイルシートを簡単にON/OFFしたり、自分のスタイルシートを適用できるといい
- 開発者のニーズと利用者のニーズをコントロール
- もっと簡単にできるべき
- 現在はその準備としてHTMLとCSSを分離
- pre, code, sup は使っていいのか?意味的構造ととらえてよい
- font, i, b は使わない
- Strict を使えば意識しなくて済む
- NS4は捨てましょう
5.2 構造と表示スタイル(c)
表はわかりやすい表題を明示し、できる限り単純な構造にして、適切なマーク付けによりその構造を明示しなければならない
- data table の話
- 実際に表であるもの
- 2次元の構造
- ヘッダがあるもの
- caption, th が必ずある
- summary で説明する
- 縦方向か横方向か --- th scope="row/col"
- id, headers属性を用いた関連付け
- colgroup, rowgroup を用いた複雑な表
- できるだけ表を単純にすることを考えた方がよい
- 支援技術の方もこれらに完全に対応できているわけではない
5.2 構造と表示スタイル(d)
d) 表組みの要素をレイアウトのために使わないことが望ましい
- テーブルレイアウトは非常に蔓延している -- 絶滅させるべきか?
- 使うときには注意が必要
- HTMLのソースの記述順に読み上げられることを考え、読み上げ順に注意する
- caption, th要素などを用いて、ありもしない構造を明示しない
- リニアライズすると問題がわかる
Web Accessibility toolbarのデモ
(渡辺氏)
- TH があるのがデータテーブル
- TH がないのがレイアウトテーブル
- 支援技術が見分けるてがかりにしている
5.2 構造と表示スタイル(e)
e)ページのタイトルには、利用者がページの内容を識別できる名称を付けなければならない
- 他のページと区別できるタイトルを
- 検索結果やDBクエリー結果を識別できるタイトル?
- ある程度ユニークであれば凝った中身である必要はない
5.2 構造と表示スタイル(f)
f) フレームは必要以上に用いないことが望ましい
- たくさんのフレームで分けるのはやめよう
- せいぜい3つまで.できれば2つ.ないのがよい
- フレームは絶滅させるべき?
- XHTML 1.1では使えない
- 役割の明確化は必要
- 役割が title属性に書いてあれば支援技術で使える
5.2 構造と表示スタイル(g)
g) 閲覧しているページがサイトの構造のどこに位置しているか把握できるように、階層などの構造を示した情報を提供することが望ましい
- パンくずリストの有用性
- サイトマップもほしい
- 現在の位置を示す情報とそれを用いた簡単なナビゲーションを提供
質疑
Q: 構造と表示スタイルの分離が挙げられているのに「単語の中にスペースを入れない」といった表示の話が入っていたりする。こういったことは議論にならなかったのか?
A: 渡辺: 完全に分離することは難しい; 読む人にわかりやすいところに入れた
梅垣: 前者はタグの話。後者は文字の話。
- JISに従うのなら letter-spacing などを使ってやるのでは?
- ちょっとスコープが違うのではという印象が否めない
- どちらかというと項目が少ない方が利用者としてはわかりやすいが、少なくしすぎても抽象的過ぎてわからなくなる
- にわかには判断できないが今後多くの人が対応を考えていく上でこれらも考慮されるべき
Q: 見た目に綺麗なページにはヘディングが使われていないという話があったが、HTMLでは綺麗にしようとするとヘディングは使いにくいのか?
A: 梅垣:
- ヘディングを使ったからといって綺麗にならないということはないと思う
- レイアウトを頑張っている人はheadingのスタイルをそのまま使わない
- 視覚的にはきちんと構造化されている
- 視覚的な部分だけで満足している
- オーサリングツールの問題が大きいのではないか
- WYSIWYGで作っていると明示的にヘディング等を指定しないとヘディングにならない
- そもそも意識していないのでは
Web製作会社の立場から名誉のために言わせてもらうと構造もちゃんと考えて作っているし、見た目にも綺麗になるようにしている。コニカミノルタのサイトなど。
中根 (NAP):
- オーサリングツールの問題は極めて大きい
- WCAGの作成段階ではオーサリングツールを使うこと自体が悪、といった印象があった
- DreamWeaver なども最近はだいぶ良くなってきている
- CSSを使ったビジュアルレイアウトが、かなりのレベルで実現できる
- NAPでオーサリングツールの勉強会をやってはどうかと考えている
DreamWeaver は良くできているがCSSを知らないと使いにくい
ヘディングが使われなかった理由 (デザイナーの立場から):
- 昔は確かにあまり構造を考えていなかった
- 数年前はNetscape 4等が主流でヘディング等を使うとマージンができてしまうので避けていた; 制御したくてもできなかった
- 最近はNN4は捨てている
現場の人の意識の話:
- アクセシビリティの意識があまりない人が制作をやっている場合
- 私自身はある程度そういった意識があるが、私一人で作るわけではなく他の人と共同でやる
- 他の人はあまり意識がない
- 従来ホームページビルダーなどを使っていてヘディング等をあまり意識していなかったが、説明すればわかってくれる
- しかしDreamWeaverの解説本などを与えるとできることに気を取られてしまってそちらに意識が回らなくなる
- 教育の段階でアクセシビリティの話を盛り込むべき
- そういった意識がない人に構造を意識したページ作成を呼びかけても難しい
- CMSなどを使って、構造は自動的に反映するなどした方がいい場合もある
- きちんと意識させてCSSまで理解できるようになるには6ヶ月くらいかかる
- 将来有用なツールになったとしても価格が高くて企業でどんどん導入できるかというとなかなか難しい
- オープンソースのいいツールがあるといいのだが
Q: パンくずリストはインターネットを使い慣れていない人にはわからないのでは?
音声ブラウザに読ませる場合などに関する議論もあったのか?
A: 梅垣:
- 音声ブラウザの議論はあまりなかったと思う
- ナビゲーションバーの使い方の解説ページを用意したりする
- エキスパートな視覚障害者には便利かもしれないが高齢者や初心者にはちょっと難しいかもしれない
- でもユーザビリティの観点からは有用だとわかっている
- ウェブサイトの使い方を知るとき
- 視覚障害者=免許なしに運転するようなもの
- たとえばWindowsの使い方を覚えるときにいろいろな部品の解説などがある
- 結局は教育の問題ではないか
湊氏 (ソシオメディア): Web Accessibility Toolbar 日本語版作者
- もともと開発は95%日本で行なっている
- 来月日本語版を出す予定
Wrong HTML
で公開
- 日本語ドキュメントを作成中
- すでに8ヶ国語に翻訳されている
- 来月には中国語版、韓国語版も公開される
梅垣:
- オーサリングツールと評価ツールの一体化も期待できる
- LIFTもDreamWeaverもお試し版がある
5.3 操作及び入力(a)
a) ウェブコンテンツは特定の単一のデバイスによる操作に依存せず、少なくともキーボードによってすべての操作が可能でなければならない
- JavaScriptのマウス依存イベントハンドラは使わない
- ドロップダウンリスト
- キーボードだと選んでいる途中で決定されてしまう
- Flashなど特殊なオブジェクトで配慮が必要
- TAB/Enter/矢印キーで操作可能であること
- 視覚障害者はマウスを使えない、多くの支援技術はキーボードナビゲーションを用いている
- 音声認識はキー操作の方が便利
- Macではツールバーが常に画面上部にあるのでマウス操作でできるものも多い
- マウスをうまく動かすための支援技術も多かった
- 徐々に変化している
- TigerのSpoken Interface:キーボードだけで操作
- 本当にキーボードで操作できればいいのか?
- ドラッグ&ドロップはキーボード代替困難
5.3 操作及び入力(b)
b)入力欄を使用するときは、何を入力すれば良いかを理解しやすく示し、操作しやすいよう配慮しなければならない
- label でテキストと関連付けておく
- HTML の側にも問題あり?
- XForms では解決?
- formは分かりやすく(理解しやすく)作るべき
- 何をいれたらいいか困ることは多い
- 「理解しやすい」の測定は難しい
- 議論されたこと
- 半角全角、電話番号のハイフン
- できるだけ自動処理するのがよいかも
5.3 操作及び入力(c/d)
c) 入力に時間制限は設けないことが望ましい制限時間があるときは事前に知らせなければならない
d) 制限時間があるときは、利用者によって時間制限を延長もしくは解除できることが望ましい
- ある操作をしたら電子メールが来る
- その情報を10分以内に入力せよ
- 支援技術を使っていると間に合わない
- 時間延長、解除を可能にする
5.3 操作及び入力(e)
e) 利用者の意思に反して、又は利用者が認識もしくは予期することが困難な形で、ページの全部もしくは一部を自動的に更新したり、別のページに移動したり、又は新しいページを開いたりしてはならない
- 「利用者の意図に反して」という点がカギ
- 更新や新しいページを開く操作は本来ブラウザ側で制御すれば済む話かもしれない --- タブブラウザのタブで開きたいなど
- ページの自動更新 --- できるだけ一つのページの中で完結させる
- 別フレームの内容をJavaScriptで更新 --- 更新に気づかないことがある
- 意図しないページに勝手にリダイレクト --- URLが変わった場合の転送はOK (厳密には正しくないかも)
- どのように対応するか
- お伺いを立てる
- 新しいページに移動することを警告する
5.3 操作及び入力(f)
f) サイト内においては、位置、表示スタイル及び表記に一貫性のある基本操作部分を提供することが望ましい
- 基本操作部分=ナビゲーション、あるいはメニューの提供
- それらに一貫性を持たせると使いやすい
- サイト共通のメニューやナビゲーション
- ユーザビリティに近い話
- ページによって見栄えが違うことがない
- 一貫性の尺度が曖昧
- スクリーンリーダでも使いやすい
5.3 操作及び入力(g)
g) ハイパーリンク及びボタンは、識別しやすく、操作しやすくすることが望ましい
- ボタンやリンクが識別しやすい
- 意味の識別 --- リンクが張ってあるテキストが分かりやすいか。 (「ここ」だけでは分からない)
- 視覚的な識別 --- 見た目でどこをクリックすればよいかわかる
- ボタンやリンクが操作しやすい
- マウスを8ドットずつしか動かせない支援技術がある
- スタイルシートの切り替えで回避できればいいか?
- リンクの境目がわからないものは避けるべき
- WCAGには書いてある
5.3 操作及び入力(h)
h) 共通に使われるナビゲーションなどのためのハイパーリンク又はメニューは、読み飛ばせるようにすることが望ましい
- ナビゲーションスキップ
- HTMLとして提供されている仕組みではない
- 508条に入っているので入った
- XHTML的な定義があるべき
- 構造をきちんと明示できればいいのでは?
- HTML的にきちんと定義すべきかもしれない
5.3 操作及び入力(i)
i) 利用者がウェブコンテンツにおいて誤った操作をしたときでも、元の状態に戻すことができる手段を提供しなければならない
- X8341-1に書かれている「操作の取り消し」
- 動的なページで「戻る」が駄目な場合がある
- ブラウザのボタンの他にページ内に「戻る」ボタン
- ユーザビリティ的にもありがたい
質疑
Q: 5.3(i)について、利用者が操作を誤ったときにそのことをちゃんと明示して欲しい。フィードバックが得られないと不安になる。
A: 渡辺:
- ユーザビリティの問題
- 今どういう状態にあるかが利用者にわかること
- エラーが起こっても元に戻せること
Q: JISで日付の入力について年月日でするように、という規定があると話で聞いたが...「しなければいけない」の要件ではない?
A: 梅垣:
- なかなか難しい問題
- 年月日の入力は3つに分ける?
- 月は選択肢にする?
- 対象ユーザによる
- 必須要件ではない
Q: 5.3(f)について、定義をはっきりして欲しい。
「メインメニュー」「本文へ」「ナビゲーション」など、
製作者によって言い方がばらばらだと効果が薄れる。
また、表記の内容についての議論はあったか?
A: 梅垣: 表記の中身の標準化までは議論しなかった。一般論としてはユーザビリティはユーザの経験を大切にする。だんだんとサイト間で統一されていくといいのでは?
A: 渡辺: 普遍的なサイトの共通機能はHTMLが持つべき
Q: 5.3(e)について、サイト管理者が異なる場合に新しいウィンドウを開いた方がいい、という意見の者もかなりいるが、策定過程でそういった議論はあったか?
A: 梅垣: 策定段階ではそういう議論はなかった。
「予期せずに」という点がキー; あらかじめその点を明記してあれば良いのではないか
A: 渡辺: 予期しなくてわからないことが混乱を招く
Q: 例えばスタイルシートで新しいウィンドウを開く場合には色を変える、といった方法はどうか
A: 梅垣: 色だけに依存しない、という項目もあるのでそれだけではまずい
画像を用意して alt でその点を明記している例もある (富士通など)
5.4 非テキスト情報(a)
a) 画像には、利用者が画像の内容を的確に理解できるようにテキストなどの代替情報を提供しなければならない
- alt をつける。 必要ならlongdesc もつける
- しかしそれだけが代替情報とは限らない
- 無意味な画像は alt="" などとする
- ビュレット、スペーサー画像:DreamWeaverは賢く管理する
- ロゴ画像:画像化する前の文字。 (隣にテキストがあれば省略)
- グラフやシンボル:ちゃんと説明する
- 雰囲気写真: 雰囲気がわかるような alt を
- コンテンツ写真: 内容が理解できるようにきちんと書く
- 画像の持つ役割により変わってくる; 単に画像の内容を説明する、というわけではない
5.4 非テキスト情報(b)
b) ハイパーリンク画像には、ハイパーリンク先の内容が予測できるテキストなどの代替情報を提供しなければならない
- どんなページに行くかを示す
- 行き先のページの中身を示す
- リンクにふさわしいaltを
5.4 非テキスト情報(c)
c) ウェブコンテンツの内容を理解・操作するのに必要な音声情報には、聴覚を用いなくても理解できるテキストなどの代替情報を提供しなければならない
- 映画の主題歌が流れるなど
- 歌詞を提供する必要があるか?
- 画像の alt 同様、「役割」を考える
- 音が出ているということはテキストで教えること
- 「雰囲気」を伝えた方がいい場合もある
5.4 非テキスト情報(d)
d) 動画など時間により変化する非テキスト情報には、字幕又は状況説明などの手段によって、同期した代替情報を提供することが望ましい
- 同期したキャプションをつける
- WCAGでは優先度1
- JISでは「望ましい」のレベル
- 同期しなくても最低限内容を説明すること
- リアルタイム配信は困難
- 日本では特に動画が多い、現実的ではない
- 聴覚障害者にとってはとても重要; 「必須」と考えて欲しい
- 現実問題としてはキャプションをつけたりするのはなかなか大変な作業なので、これに関してはツールの充実を期待したい
5.4 非テキスト情報(e)
e)アクセス可能でないオブジェクトには代替情報を提供する
- アクセシブルでない場合は代替HTMLも書くこと
- あらゆるブラウザに対応するときには疑問が残る
質疑
Q: (質問というより宣伝)森田: "Web Site Design" で「実践アクセシブルHTML」の連載をしていた。連載の第1回で、alt だけで12ページ書いた。
http://w3j.org/ で原稿を公開している。
Q: 音の情報について、トップページにアクセスした段階で音が出るサイトもあり、こういったサイトは良くないという議論もあるが、そういった話は策定段階であったか?
A: 梅垣: トップページでは事前に知らせられない。JISではそこまでは求めていないが個人的には止めた方がいいと思う
5.5 色及び形(a)
a) 色だけに依存しない
- 赤い色のところを…といわれても色が分からない人がいる
- JISでは形と位置を取り込んだ
- △や×など、記号を使うと使いづらいことが起きる
5.5 色及び形(b)
b) 形あるいは位置だけに依存しない
5.5 色及び形(c)
c) 背景色と前景色には十分なコントラストを取る
- 輝度のコントラストをとる
- 識別しやすい配色に
- 弱視、色覚障害への対応
- 富士通の ColorDoctor のデモ --- 色覚障害のシミュレーションができる
- ColorSelector --- 背景色と文字色の組み合わせの見やすさをチェック
- 詳しくはINTERNET magazineの記事参照
5.6 文字
a)文字のサイズ及びフォントは必要に応じ利用者が変更できるようにしなくてはならない
b)フォントを指定するとき、サイズ及び書体を考慮し読みやすいフォントを指定することが望ましい
- ユーザスタイルシートで変更できるようにする
- 構造と視覚表現の分離
- ブラウザの機能で文字を拡大できる
- ブラウザ側に機能があれば済む話かもしれない
- 将来はレイアウトを崩さないで拡大できる?
5.7 音
a) 自動的に音を再生しないことが望ましい。自動的に再生する場合は再生していることを明示しなければならない
b) 音は利用者が出力を制御できることが望ましい
- 聴覚障害者は気づかない
- 視覚障害者はスクリーンリーダーの音と混ざってしまい使いづらい
- 利用者が意図的に再生する場合は問題ない
5.8 速度
a) 変化又は移動する画像又はテキストは、その速度、色彩、輝度の変化などに注意して作成することが望ましい
b) 早い周期での画面の点滅を避けなければならない
- 早すぎると読み取れない
- 拡大しているとき
- marqueeはだめ
- Flashも注意
- てんかん発作の防止
5.9 言語
a) 言語が指定できるときは、自然言語に対応した言語コードを記述しなければならない
- 言語コードの指定
- 言語が変化するときも指定する
- そのうちバイリンガルスクリーンリーダーが出てくる
5.9 言語(b-d)
b)理解しづらいと考えられる外国語は多用しないことが望ましい.
c)理解しにくいと考えられる用語は多用しないことが望ましい.
d)読みの難しいと考えられる言葉は多用しないことが望ましい.
- 認知的配慮事項
- 「想定する利用者」が大事
- 外国語
- 省略語、専門用語など、読みの難しい言葉
- 公共サービスを提供する場合などは配慮すべき
5.9 言語(e)
e) 表現のために単語の途中にスペース又は改行を入れてはならない
- 「請 求 書」など
- スクリーンリーダーを意識した規定
- ただスタイルシートではなかなかうまくいかないときもままある
- 均等割付の技術をみんなで考えてほしい
5.9 言語(f)
f) ウェブコンテンツは文章だけではなく、わかりやすい図記号、イラストレーション、音声などを合わせて用いることが望ましい
- 知的障害への対処をやるべきだとコメントがあった
- 図記号、イラスト、音声の方がわかりやすい、という人もいる
- 認知的配慮
- ユーザビリティを高めることと認知的配慮は近いところにあるのかもしれない
WCAG 2.0 の WG の紹介 (渡辺)
- 詳細は配布資料参照
- 1999年に WCAG 1.0 が勧告に
- しかしこれも完璧ではない
- HTMLに依存している
- 内容が必ずしも適切でないものもある
- JIS策定段階ではWCAG 2.0はまだ策定途中
- JISでは1.0を基本に欠点を補正するとともに日本固有のガイドラインを追加
- WGメンバーは欧米中心; 日本などの事情はあまり考慮されていない
- 協調作業が必要
WCAG 2.0本文
- 大きく4つの指針がある
- 認識できる
- 操作できる
- 理解できる
- コンテンツ技術にそって作成されている
- 特定の技術に依存しないガイドラインが合計14個ある
- 優先度を廃止
- ガイドラインごとにレベルを3分類
- すべてのウェブサイトに適応できる
- 工夫が必要
- さらに高い要求
- 各技術ごとのチェックリストと例を示した文書が用意される
- これらをリンクするためのGateway文書も用意される
- しかし文書は全部英語なのでなかなかコメントするのが難しい
- W3Cに参加
- WCAG 2.0 WGに漢字文化圏固有の問題を書き込む作業
- JISの成果をW3Cに還元する
- ウェブアクセシビリティ国際規格調査研究部会で今回のWDを翻訳する予定
最後に
中根: NAPのもともとの活動原則としては、裾野を広げてより多くの人に理解してもらいたい。今回のような大人数の会も有益だが従来のような少人数での勉強会も開催していきたい。
梅垣: 今年度のJISの委員会は国際化が中心。皆さんも会社内などで啓蒙活動に励んで欲しい。必要ならJISの委員会にコンタクトしてもらえれば説明に行ったりもできると思う。
(17:03閉会)
jis-workshop@accessibility.org