水無月ばけらのえび日記

Remove the CAPTCHA Exception

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

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

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

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

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

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

Media Guidelines

Contrast at Level A

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

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

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

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

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

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

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

Decrease the 200% Text Resizing Requirement

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

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

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

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

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

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

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

Clarify Images of Text

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

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" (プログラムが解釈可能) という概念があります。

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

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

これは「こちら」「ここをクリック」「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には「視覚的に認識可能なフォーカス」という達成基準があります。

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

Remove Parsing Requirement

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

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

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

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