水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > WCAG2.0の次のステップへ

WCAG2.0の次のステップへ

2012年2月21日(火曜日)

WCAG2.0の次のステップへ

公開: 2012年3月4日0時55分頃

こんな記事が話題になっていました……「WCAG Next (webaim.org)」。WebAIMによる、WCAG2.0の問題点の指摘と改善策の提案ですね。

詳しくはお読みくださいというところですが、わかりにくいところもありそうなので、内容について私なりに解説しながら紹介してみたいと思います。

ただし、かなり長いので注意してください。

Remove the CAPTCHA Exception

1.1.1では、非テキストコンテンツに対して代替テキストを指定するように求めています。しかし、CAPTCHAは明示的に例外として扱われています。

CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.

以上、WCAG2.0 1.1.1 Non-text Content より

これを見ると、画像以外にも音声のCAPTCHAを用意すれば良いように読めます。そして実際、そのようにしているサイトがあります。しかし、視覚と聴覚の両方が使えない利用者の場合、画像と音声の両方があっても、CAPTCHAをクリアすることができません。

すべての利用者にとってアクセシブルにするためには、マシン・リーダブルな形で情報を提供する必要がありますが、CAPTCHAの目的はそのマシンを排除することです。マシン・リーダブルにしてしまうと、その時点でCAPTCHAとしては機能しなくなってしまいます。

WebAIMは、CAPTCHAを利用しているサイトはアクセシブルではないので、CAPTCHAの利用を認めるべきではないという立場です。具体的には以下のような提言をしています。

  • CAPTCHAの例外を削除するべき (CAPTCHAを使用したら等級Aも満たせないとする)。
  • あるいは、等級Aでは視覚+音声のCAPTCHAを許容したとしても、等級AAではすべてのCAPTCHAを禁止するべき。

後者はまあ、妥協案というところでしょう。

Media Guidelines
Media alternative for text

WCAG2.0には "Media alternative for text" という表現が出てきます。たとえば1.2.1には以下のような達成基準があります。

1.2.1 Audio-only and Video-only (Prerecorded): For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such: (Level A)

以上、WCAG2.0 1.2.1 Audio-only and Video-only (Prerecorded) より

これは定義された用語で、定義は以下のようになっています。

media alternative for text

media that presents no more information than is already presented in text (directly or via text alternatives)

Note: A media alternative for text is provided for those who benefit from alternate representations of text. Media alternatives for text may be audio-only, video-only (including sign-language video), or audio-video.

以上、WCAG2.0 Appendix A: Glossary - media alternative for text より

この "Media alternative for text" は、「テキストの代替であるメディア」です。たとえば、市役所のサイトなどで、たまに「このページを読み上げる」というボタンを見かけることがあります。そのボタンで提供されるのは、コンテンツ内のテキストと同じ内容を音声の形にしたものです。WCAG2.0では、テキストを手話に翻訳したビデオのようなものも例に挙げられています。

このように、メインの情報が元々テキストで提供されていて、その代替として音声や映像などが提供されている場合があります。この場合、代替として提供された音声や映像に対する代替テキストを用意する必要はありません。テキストが必要なら、元々あるメインのテキストを読めば良いからです。except when... というのはそういう意味です。

しかし、これを「動画に字幕がついていれば代替テキストはいらない」という意味に解釈する人が多い、というお話のようです。多くの人は「テキストの代替であるメディア」というものをあまり見かけないでしょうし、そう誤解されるのは分かる気がします。

というわけで、表現の見直しが提案されています。

Alternative for time-based media

WCAG2.0には、"Alternative for time-based media" という表現が出てきます。

Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.

以上、WCAG2.0 1.2.1 Audio-only and Video-only (Prerecorded) より

これも定義された用語です。

alternative for time-based media

document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction

Note: A screenplay used to create the synchronized media content would meet this definition only if it was corrected to accurately represent the final synchronized media after editing.

以上、WCAG2.0 Appendix A: Glossary - alternative for time-based media より

これも混乱を招いてわかりにくいので、単に "descriptive transcript" と言えば良いのではないか、という提案です。

Recommended restructuring

メディア関連のガイドラインの構造と等級の設定が適切でないので、再構築したいという提案です。

このあたりは複雑怪奇で、たとえば、映像コンテンツに対してどの等級でどういう代替を用意すれば良いかというと、こんな感じです。

  • 等級A …… 代替コンテンツ (alternative for time-based media)、もしくは音声トラック (audio track) のどちらかがあれば良い (1.2.1)
  • 等級AA …… 音声ガイド (audio description) が必須 (1.2.5)
  • 等級AAA …… 代替コンテンツ (alternative for time-based media) が必須 (1.2.8)

一見すると、代替コンテンツが等級AとAAAの両方にあって、しかもAAにはないという不可解な構成に見えます。実際には、等級AAAを達成するためにははAとAAも満たす必要がありますし、等級Aではor条件のひとつなので必須ではない、という話で理屈は通るのですが、非常にわかりにくいです。

また、等級Aでは「代替コンテンツ」を利用せずに「音声トラック」をつける選択をしても良いことになっています。代替コンテンツが必須になるのは等級AAAです。代替コンテンツがなくても、映像に音声トラックと音声ガイドをつければ、等級AAまで満たすことができます。

しかしこの場合、映像と音声が提供されているものの、マシン・リーダブルなテキストは提供されていません。そのため、視覚と聴覚が両方とも利用できない利用者は、このコンテンツに全くアクセスできない可能性があります。

全くアクセスできない可能性があるのに等級AAになってしまうのは、やはりまずいでしょう。

Contrast at Level A

文字色と背景色とのコントラストの規定は2つあります。達成基準1.4.3は等級AAで、4.5:1のコントラストを求めています。

1.4.3 Contrast (Minimum):The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

以上、WCAG2.0 1.4.3 Contrast (Minimum) より

達成基準1.4.6は等級AAAで、7:1のコントラストを求めています。

1.4.6 Contrast (Enhanced):The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following: (Level AAA)

以上、WCAG2.0 1.4.6 Contrast (Enhanced) より

コントラストの要求はこれだけです。等級Aではコントラストの規定は一切ありません。つまり、ほとんど誰も読めないような薄い色や、あるいは背景と完全に同色であっても、等級Aを達成できてしまうことになります。

それではまずいので、等級Aにも緩やかなコントラストの規定を作るべき、というのがここでの主張です。

ただ、WAIは「これはアクセシビリティの問題ではない」という立場をとるかもしれません。あまりにもコントラストが低い場合、特定の障害のある人だけが不利になるわけではなく、誰が見ても読めません。そのような場合は、アクセシビリティの問題とはみなさないというのが基本的なスタンスです。

たとえば、リンクの目的に関する達成基準では、「リンクの目的が一般的にみて利用者にとって曖昧な場合は除く」とされています。こういったところを見ると、「色の区別のつきにくい人には読めない」というのはアクセシビリティの問題ですが、「誰にも読めない」となるとアクセシビリティの問題ではなく、そのための基準を新たに設ける必要もない、というスタンスになりそうです。

ちなみに実務上は、等級Aを目標にしていても、色だけは1.4.3の基準(等級AA)を満たすようにすることが多いです。この基準の達成はそれほど難しくもないので、いっそこのまま等級Aにしてしまうのもありなのではないか、と個人的には思います。

Decrease the 200% Text Resizing Requirement

支援技術なしでテキストを200%まで拡大できるように、という等級AAの規定があります。

1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)

以上、WCAG2.0 1.4.4 Resize text より

これをサポートするのは難しいので150%で良いのではないか、200%はAAAで良いのではないか、という主張です。

Designing modern web interfaces to support 200% text resizing is very difficult と言われているのですが、個人的には何がそんなに難しいのかよく分かりません。最近のブラウザはズーム機能で200%以上の拡大ができますので、特に何かをしなくても達成できるはずです。

あえて言うと、IE6の問題はあります。IE6にはズーム機能がなく、テキストのサイズを「最大」にしても200%の拡大はできません。IE6をターゲットにする場合、200%は厳しいでしょう。実際、富士通のサイトがこの理由でAAを達成できていません。以下は富士通のサイトにある試験結果からの引用です。

テキストのサイズ変更(達成基準 7.1.4.4)

Internet Explorer 6をお使いの場合には、ページ内のテキストを200%まで拡大することができません。本サイトのテキストを拡大して閲覧されたい方は、ズーム機能を搭載しているブラウザをご利用されること(Internet Explorerならば、Internet Explorer 7以上にバージョンアップされること)を推奨いたします。

以上、JIS X 8341-3に対応したアクセシビリティ確保の取り組み より

150%で良いとなれば、IE6でも問題ないことになります。

ただ、いまさらIE6を意識して基準を緩和するというのもどうかと思いますし、WebAIMもそういう話をしているわけではないと思うのですが……。

※あと、日本語だと問題ないが、英語では単語中の改行がうまくできないのでレイアウトが崩れやすく、だから200%は厳しいと言っているのではないか、という説も。

Clarify Images of Text

1.4.5と1.4.9には、テキストはできるだけ画像化しないようにという規定があります。

1.4.5 Images of Text: If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: (Level AA)

以上、WCAG2.0 1.4.5 Images of Text より

1.4.9 Images of Text (No Exception): Images of text are only used for pure decoration or where a particular presentation of text is essential to the information being conveyed. (Level AAA)

以上、WCAG2.0 1.4.9 Images of Text (No Exception) より

1.4.9のほうは等級AAAの基準で、ロゴなどのわずかな例外を除いてテキストを画像化してはならない、という規定です。1.4.5は等級AAなので若干緩く、「使用しているウェブコンテンツ技術で意図した視覚的な表現が可能である場合は」、という条件がついています。つまり、テキストでは意図した視覚表現が再現できない場合、画像化することが許されています。

そして、この条件が曖昧だというのがWebAIMの主張です。CSSやJavaScriptを駆使すれば、テキストにかなり凝ったスタイルを適用することができます。「高い技術力のある人ががんばればテキストでも表現できる」という場合でも、「使用しているウェブコンテンツ技術で意図した視覚的な表現が可能」に該当するのか、判断が難しいところです。アクセシビリティのテストをする人がそんな判断をしなければならない、というのも変な話です。

提案としては、等級AAではそこまで頑張らなくても良く、フォントを変えるだけのような場合は画像にしないように、という程度で良いのではないか、ということのようです。基準を変えるというよりも、表現を変えて基準を分かりやすくしたいという話のように思えます。

Specify Mechanisms to Bypass Blocks

ブロックスキップの話。

実装方法が多岐にわたっていてどうすれば良いのかわかりにくいので、具体的に以下のうち2つ以上を実装すれば良いことにしてはどうか、という提案。

  • スキップリンクを設ける
  • 見出しを使う (メインコンテンツは常にh1見出しで始まる、など)
  • ページ内のナビゲーションリンクを設ける
  • WAI-ARIAのLandmark Roles (www.w3.org)を使う
  • HTML5の構造化要素を使う

しかし、WCAG2.0は特定の技術や実装方法に依存しないという方針です。この提案は実装方法の話なので、ガイドライン本体ではなく、実装方法集 (Techniques for WCAG 2.0 (www.w3.org)) の方に入るべきものでしょう。

ただ、実装方法が分離されていること自体が分かりにくさの原因だ、という議論もあります。そこを根本的に見直すというのも、それはそれでありだと思います。

Can Be Programmatically Determined

WCAG2.0には、"Can Be Programmatically Determined" (プログラムが解釈可能) という概念があります。

programmatically determined (programmatically determinable)

determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities

Example 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.

Example 2: Determined from technology-specific data structures in a non-markup language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

以上、WCAG2.0 Appendix A: Glossary - programmatically determined (programmatically determinable) より

しかしこれは、「理論上、プログラムで解釈しようと思えばできるはずだ」という話でしかなく、実際に解釈できるプログラムがあるかどうかはまた別の話です。

たとえば、2.4.4には「文脈におけるリンクの目的」という基準があります。

2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)

以上、2.4.4 Link Purpose (In Context) より

これは「こちら」「ここをクリック」「more」のような、単独ではリンク先が何か分からないようなリンクの話です。

等級Aでは、リンクテキスト単独では理解できない場合でも、「プログラムが解釈可能なリンクの文脈」(programmatically determined link context) から理解できれば良いことになっています。スクリーンリーダーでリンク項目だけを読み上げていったとき、「こちら」というリンクが出てきても全く意味が分かりません。しかし、段落や見出し、リストなどが適切にマークアップされていれば、同じ段落にあるテキスト、対応する見出しなどを読み上げることができるはずで、そのテキストと合わせて意味が分かれば良い、というわけです。

しかし、理屈の上で「読み上げられるはず」と言っても、実際にはそんな機能がない場合があります。

WCAG2.0の考え方としては、実際にブラウザや支援技術がアクセシビリティ機能を実装しているかどうかを調べて、「アクセシビリティ・サポーテッド情報」をまとめるべし、という立場です。そして日本では、ウェブアクセシビリティ基盤委員会 (waic.jp)Techniques for WCAG 2.0 (www.w3.org)で挙げられている実装例をテストして、アクセシビリティ・サポーテッド情報 (waic.jp)を公開しています。

2.4.4の実装方法についても検証しているのですが、残念なことに、リンクの文脈を読み上げられるスクリーンリーダーはほとんどないと言って良い状況でした。

WCAG2.0が出てからかなり経つのですが、等級Aの達成基準で前提とされている機能が実装されていない、というのはかなり深刻な状況です。実装されないのには何か理由があるはずで、それを踏まえてガイドラインを見直す必要があるのではないかと感じます。

Require Keyboard Focus Indicators at Level A

2.4.7には「視覚的に認識可能なフォーカス」という達成基準があります。

2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)

以上、WCAG2.0 2.4.4 2.4.7 Focus Visible より

これは等級AAなのですが、フォーカスが見えないと、事実上キーボード操作が不可能な状態になります。これを等級Aにすべきではないか、という提案です。

Remove Parsing Requirement

4.1.1にはこういう達成基準があります。

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

以上、WCAG2.0 4.1.1 Parsing より

要は、マークアップがwell-formedになっていなければならないという話です。タグの対応関係がしっかりしていれば良く、validであることまでは求められていません。

WebAIMでは、この基準は不要、もしくはAAAで良いのではないか、としています。実際にマークアップの不備が支援技術に致命的な悪影響を与えることはほとんどなく、ほかの達成基準と比べても重要性が低い、という話のようです。

ただ、ここはロバスト性に関する基準です。前方互換性を保証したり、今後開発されるであろうさまざまなプログラムからアクセスしやすくする、ということも目的にしているはずです。「今の実装で悪影響が出ていないからOK」というのは違うのではないか、と個人的には思います。

……と、以上が今回の話の大まかな解説です。賛同できるところもあり、やや疑問に思うところもありますが、いずれにしても、WCAG2.0にうまく行っていない部分があるのは確かだと思います。

特に、最大の問題は「分かりにくい」という点。特定の技術に依存しない汎用的なものに、というポリシーは理解できるのですが、達成基準を一般化したため、抽象的で分かりにくいものになっている面が否めません。具体的な実装方法はTechniquesのほうに書かれているのですが、そのクオリティも正直、今ひとつです。次を考え始める時期に来ているのかな、という印象はありますね。

※Techniquesは特にJavaScriptの実装サンプルが低品質で、IEで動かない (そして、ちょっと実装の仕方を変えるだけで動くようになる) とかしょっちゅうです。

関連する話題: Web / アクセシビリティ

最近の日記

関わった本など

インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンデザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチ体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)

その他サイト