WCAG 2.0 の特徴
- 規定と参考で構成されたコンテンツ
- 非W3C技術および新技術のサポート
- テクニック
- テスト
規定と参考で構成されたコンテンツ
- 規定:
- WCAG 2.0に適合するためにすべきこと
- 適合, 原則, 達成基準, 用語定義
- 参考:
- 要件を満たすために推奨される方法
- ガイドラインを満たすのに必須ではない
“Normative” parts of the guidelines define what must be done to conform to WCAG 2.0.
Most of the materials available are “Advisory”, which explain the Working Group's intent and provide recommended ways to meet the requirements. However, it is not mandatory to follow the advice in advisory materials, if you have another way to meet the specific requirement of the Success Criteria.
Normative sections: Conformance, Principles, Success Criteria, Definitions.
非W3C技術および新技術のサポート
ベースラインにより、WCAGはより多くの技術をサポートできる
- WCAGは、W3C技術およびその他の技術に応用できる
- 達成基準は、新技術にも適用できる
- 技術がアクセシビリティを十分サポートしていないときの代替を提供する
- Technologies not under control of W3C can be used if they provide accessibility features that meet WCAG requirements
- New technologies can incorporate accessibility features, and WCAG will still be relevant
- If only some features are supported, use the technology for those features and provide fallback to meet other Success Criteria
Examples
- AJAX
- Techniques exist to support WCAG SC
- Like Flash, requires more author responsibility at this time
- W3C is developing new technology features to increase ability to create WCAG-conformant applications in AJAX
テクニック
テクニック文書で達成基準を満たす方法に関するアドバイスを提供。3つのタイプのテクニックがある:
- 十分なテクニック
- 参考テクニック
- よくある間違いのテクニック
- Sufficient techniques: following these techniques will meet the Success Criterion. Only one sufficient technique per success criterion must be followed.
- Advisory techniques: not required for WCAG conformance, but recommended by the WCAG Working Group.
- Failure techniques: describe known content authoring practices that fail the WCAG Success Criteria.
テクニック
テクニックの種類:
皆さんもワーキンググループにテクニックを提出することが可能。あるいは、非W3C技術における別のテクニックを提出することもできる。
- General techniques: describe practices that can be implemented in any technology
- Technology-specific techniques: code approaches for specific technologies
WCAG 2.0 currently provides technology-specific techniques for:
WCAG 2.0 テスト
十分なテクニックに従っているかを検証する
まだ不十分だが、最終的にはガイドライン関連文書の一部となる
WCAG 2.0 テスト: テストの手順
スクリプトのテクニック “キーボードおよび他のデバイス特有の機能を用いること”
手順
- インタラクティブな機能を全て見つける
- 全てのインタラクティブな機能をキーボードだけで操作可能であることをチェックする
期待される結果
WCAG 2.0 テスト: テストファイル
スクリプトのテクニック “キーボードおよび他のデバイス特有の機能を用いること”
<a href="menu.php" onmouseover="swapImageOn('menu')" onfocus="swapImageOn('menu')"
onmouseout="swapImageOff('menu')" onblur="swapImageOff('menu')">
<img id="menu" src="menu_off.gif" alt="メニュー" />
</a>
In this example of an image link, the image is changed when the user positions the pointer over the image. To provide keyboard users with a similar experience, the image is also changed when the user tabs to it.
WCAG 2.0 における要件の概要
- 重要なコンセプト
- 原則
- 原則 1: 知覚可能である(Perceivable)
- 原則 2: 操作可能である(Operable)
- 原則 3: 理解可能である(Understandable)
- 原則 4: 現在および将来の利用に耐えうる(Robust)
重要なコンセプト
- 支援技術
- 代替テキスト
- プログラム的に決められていること(Programatically determined)
- 状況の変化
- キーボード・インターフェース / 入力デバイス非依存
Assistive technology (AT): special tools used by people with disabilities to interact with Web content. AT can adapt the page to the user's requirements so the author doesn't have to anticipate every user need. Most AT are not tested by authors, and require the encoding of content to support standard practices and accessibility APIs so it can reliably access it.
Text alternatives: because not all forms of non-text content can be transformed into accessible formats, WCAG 2.0 commonly requires text alternatives. Although some richness is lost, text can be transformed in a variety of ways and therefore provides the widest interoperability with AT.
Programatically determined: AT can reliably determine a state or property of content. Normally this requires that explicit, standard coding practices be followed, but it is also possible to use design practices that support widely-implemented heuristics.
Change of context: a change in the current browser window, or a change in input focus that the user did not initiate.
Keyboard interface: pointing devices (like a mouse) provide continuous, graphical-based input that is difficult for many people with disabilities to use. Keyboards and devices that use keyboard interfaces provide discrete input that most people can use. WCAG 2.0 requires compatability with keyboard interfaces, which allow standard keyboards as well as a wide variety of keyboard emulation hardware and software.
原則 1: 知覚可能である(Perceivable)
感覚(視覚・聴覚など)の障害に対応する
- 代替テキスト:画像、マルチメディアおよびその他の非テキストコンテンツ
- コンテンツ構造に関するセマンテック情報:ユーザーが知覚可能な形態に変換可能となる
- コントラスト:ビジュアルおよび音声
事例: 輝度コントラスト
-
5
5
レベル 2 達成基準では、輝度コントラスト比は 5 : 1
-
10
10
レベル 3 達成基準では、輝度コントラスト比は 10 : 1
Visual contrast is specified in terms of a Luminosity Contrast Ratio, which is defined as a mathematical formula.
原則 2: 操作可能である(Operable)
入力デバイスの使用に影響を及ぼす、手あるいは感覚の障害の有無に関係なく、ユーザーはコンテンツを操作できるようにすべきである。
- コンテンツがキーボード・インターフェースをサポートしている
- 時間制限をユーザーに課さない、あるいはユーザーが時間制限を調整できる
- ユーザーによっては集中力を奪われることのある、点滅あるいは移動するコンテンツを静止させることができる
- 光過敏性の発作を誘発しうる、閃光を使用していない
- ナビゲーションおよび現在位置確認の機能がプログラム的に決められている
- 入力エラーからユーザーをリカバリーするサポートを提供している
- At Level 1, content supports keyboard interface unless it intrinsically requires analog input (e.g., a graphics drawing program).
- At Level 3, content must work with keyboard interfaces. Some types of content may not be able to meet this Level 3 requirement.
Description of examples:
- The link to the WCAG home page does not have
a description of where it goes. The description is in this
paragraph but the association is not programatically determined.
- The link has its destination directly associated.
- The link has its destination explained in the same
paragraph. AT could retrieve this information easily, although it
does not now. This is not programatically determined, but may be
if AT support evolves.
原則 3: 理解可能である
ユーザーがコンテンツを理解できなければならない。
- 支援技術が自然言語に適応できるように情報を提供する (例: 英語、日本語)
- それだけでは意味を成さない恐れのある単語や用語に補足情報を提供する
事例: テキストの読みがなを提供するルビ(ruby要素)
慶應義塾大学
Ruby is used to give the reading of Han characters (Kanji). The pronunciation information is rendered in parentheses immediately following the base text. (User agents that support Ruby do not show the parentheses.)
原則 4: 現在および将来の利用に耐えうる(Robust)
- コンテンツが意図した通りに構文分析されるようにする
- 名前、役割、状態およびプロパティを支援技術に提供する
- Parsing replaces full validation requirements. There has been a lot of discussion about this, but parsing into a predictable representation is the aspect of validation that is crucial for accessibility, as any user agent must be able to understand the content.
事例: 構文分析
<p>ここに <b>太字と<i>イタリックの</b>テキスト</i> がある。</p>
このHTMLソースコードは、ユーザーエージェントによって、さまざまな表現に構文解析される可能性がある。
- ここに 太字と
イタリックの
テキスト がある。
- ここに 太字と
イタリックのテキスト
がある。
- ここに 太字と
イタリックのテキスト がある。
- <ユーザーエージェントが構文解析不可能>