読者です 読者をやめる 読者になる 読者になる

Techniques for WCAG 2.0にコメントを送る会

先日、Techniques for WCAG 2.0にコメントを送る会をやりましたので、イベント中、およびその後で思ったこと・感じたことを書きます。

この記事ではTechniques for WCAG 2.0について思ったことの後に、個別の実装方法について思ったことの順番に書きます。また、この記事ではTechniques for WCAG 2.0(2014年7月25日付Editor's Draft)をもとに話を進めます。このEditor's Draftへのコメントは2014年8月12日*1まで募集されています(Call for Review: WCAG 2.0 Techniques Draft Updates)。

他の参加者のレポートは次の通りです。

Techniques for WCAG 2.0について思ったこと

なんか違う

内容が間違っていることはないとまず思うのですが、議論している実装方法と関係ない話が突然始まったり、例をコピペしただけだと動かなかったり、「このまま使うと、別の問題を指摘されてしまうよなあ」と思うものも中にはあります。やはり他の人に安心して薦められるものになってほしいと思います。

重複している

実装方法が多いことは基本的には良いことだと思うのですが、中には同じことを言っているんじゃないのかな、と思うものもあります。ページを作る側ではなく、チェックする側の意見ですが、実装方法集は重複なく必要にして十分な数がそろっていたらな、と思うことがあります。

WAICが公開しているJIS X 8341-3:2010 試験実施ガイドライン 2012年11月版でも、「実装チェックリストの作成方法の例」として「Understanding WCAG 2.0日本語訳の「達成基準を満たすことのできる実装方法」」をもとにする話がでてきます。この実装方法はTechniques for WCAG 2.0のことですので、それが重複していると精査にも時間と手間がかかってしまいます。

適用範囲

Techniques for WCAG 2.0の中にはHTML5では使えないもの、HTML5でしか使えないものもあります。それ自体は問題ではないと思う(WCAG 2.0は特定の技術に依存していないので)のですが、HTML5に適用できる実装方法一覧を取り出したり、といったことは簡単ではありません。それぞれの実装方法に「適用(対象)」(Applicability)という欄があるのですが、この内容の揺れが結構あるので、結局は手作業でやるしかありません。

「適用」欄のばらつきを抑えて「検証」を充実させられないかなと思いました。

GitHub

Techniques for WCAG 2.0ではGitHubでPull Requestを受け付けていますが、正直わかりにくいです。

  • どのブランチに対してPull Requestを送れば良いのかわかりにくい
  • リポジトリのファイルからHTMLを生成する方法がわかりにくい(.travis.ymlを参照)
  • 行末に空白があったり、改行やインデントがそろっていなかったりと、きれいな差分を作ることが難しい

GitHubでのPull Requestを受け付ける前に、空白やインデントの問題を修正してほしかったです。…そういう修正こそPull Requestで送ってくれ、という話なのかもしれませんが。

個々の実装方法について思ったこと

ARIA1

誤植がひどいので直しましょう。

ARIA2

ARAI2はaria-requiredを使って、入力欄が必須であることをプログラム(含む支援技術)から判断できるようにしようという実装方法です。この実装方法集が視覚的な手がかりがあった場合に限定されていますが、音による手がかりがある場合などを考えると、視覚に限定するべきではありません。

また「WAI-ARIAは草案なので~」という注記はWAI-ARIA 1.0が勧告されていますので、削除すべきです。

ARAI4とARIA5

ARIA4はroleを支援技術に提供しよう、ARIA5はstateとpropertyを支援技術に提供しようという実装方法です。これは人によるのかもしれませんが、私はこういったあまりにも漠然とした実装方法は不要だと思います。WCAG 2.0自体が技術によらない抽象的な書き方をしているので、サポート文書はある程度明確に書かないと、関係者をサポートできないと思うからです。

また、ARIAを使う場合に、一般的に求められることはrole、state、propertyを提供すること(roleだけとかstateだけではなく)、および、フォーカス(キーボード)を管理することだと思っていますので、roleだけ、stateとpropertyだけという実装方法は正しいとは思えません(個別の議論ではroleだけで良い場合、stateとpropertyだけで良い場合というのはありえますが)。誤解をされるよりは削除した方が良いと思います。

ARIA7

ARIA7はaria-labelledbyを使って、リンクのアクセシブルな名前(支援技術から見えるオブジェクトの名前)を変更するという実装方法ですが、例1にアクセシビリティ上の大きな問題があります。

例1は、画面上では「Read more...」と書いてあるけど、それだけではスクリーン・リーダーユーザーにはリンク先が分かりにくいだろうから、直前の見出し「Storms hit east coast」と読み上げさせようというものです。この方法は全盲のユーザーがスクリーン・リーダーを使う場合には問題ないでしょうが、ほかの場合には問題が起こりえます。

ARIA 1.0には同じような問題が例として挙げられているので、引用してみます。

For example, a sighted, dexterity-impaired individual may use voice-controlled assistive technologies to access a visual interface. If an author hides visible link text "Go to checkout" and exposes similar, yet non-identical link text "Check out now" to the accessibility API, the user may be unable to access the interface they perceive using voice control.

日本語にすると次のようになるでしょうか。

例えば、目の見える上肢障害者は画面に表示される(visual)インタフェースにアクセスするために、音声制御による支援技術を使うだろう。もし制作者が画面に表示されているリンクテキスト「お支払いへ進む」を隠して、類似した、しかし同一ではない、リンクテキスト「今すぐお支払い」をアクセシビリティAPI通して提供したとしよう。この時、ユーザーは音声制御で認識しているインターフェースにアクセスできないだろう。

例1の場合には、「もっと読む」と表示されているものを音声で操作するために「嵐が東海岸を襲う」と入力しなくてはならなくなってしまいます。

例1以外の例も画面に表示されているテキストと支援技術から認識できるテキストが異なるので微妙なのですが、例1の問題ぶりは群を抜いています。問題のある例は削除すべきです。

なお、ARIA7以外にもリンクテキストとその直前の見出しを組み合わせてリンク先の情報を伝える実装方法(H80)があります。WAICが公開しているアクセシビリティ・サポーテッド情報(2014年6月版)によると、最近のスクリーン・リーダーの多くで、リンクからフォーカスを移動させることなく直前の見出しを読み上げることができます。見出しとリンクテキストを組み合わせてリンク先の情報を伝える場合に、無理にaria-labelledbyを使う必要はないと私は思います。

ところで、H80がSufficient Techniqueになっていない件はWAIC的にどうなのか、私、気になります。

H39とH73

H39はデータテーブルでcaption要素を使うという実装方法で、H73はデータテーブルでsummary属性を使う、という実装方法です。

どちらもデータテーブルの話をしているのに、「検証」(Tests)には、「レイアウトテーブルでcaption要素/summary属性が使われていないことをチェックする」云々という話がでてきます。レイアウトテーブルでcaption要素やsummary属性を使わないことはF46にまとめられていますので、H39とH73からはレイアウトテーブルの話は削除すべきです。なお、H63ではデータテーブルでscope属性を使う話がでていますが、「検証」では「それぞれのデータテーブルについて」と、シンプルにまとめられています。

H43のデータテーブルでheaders属性を使うという実装方法の「検証」でも、レイアウトテーブルかどうかのチェックがありますが、F46でのheaders属性の扱いがあいまいなので、こちらはF46を調整する必要があるように思います。

SCR2

SCR2はキーボードとマウスのイベントハンドラ―をそれぞれ指定しようという実装方法、SCR20はキーボードと他のデバイス固有の機能を使おうという実装方法です。

内容はどちらもキーボードと他のデバイス固有のイベントを両方使うというものですので、より一般的なSCR20を残してSCR2は削除すべきです。

似たような実装方法にSCR29があります。これは、div要素やspan要素にtabindex="0"を付与したうえで、clickとkeypressイベントを両方処理しようという実装方法です。こちらは独立した実装方法になっていても良いと私は思っています。というのも、a要素やbutton要素など(HTML5が言うところの「activation behavior」が定義された要素)ではclickイベントだけ処理すれば良いという話(SCR35)があり、場合分けすると3つの実装方法が必要だと思うためです。

  • activation behaviorが定義された要素(a要素やbutton要素)
    • activation behaviorを起こすイベントの処理:SCR35(clickイベントを処理すればOK)
    • activation behaviorを起こさないイベントの処理:SCR20(各デバイスのイベントを処理しなきゃ)
  • activation behaviorが定義されていない要素(div要素やspan要素)
    • activation behaviorが定義された要素だったら、activation behaviorを起こすイベントの処理:SCR29(各デバイスのイベントを処理しなきゃ…SCR35へ誘導)
    • activation behaviorが定義された要素だったとしても、activation behaviorを起こさないイベントの処理:SCR20(各デバイスのイベントを処理しなきゃ)

F17

F17は、F17以外にも同じことを言っている不適合事例が多い、不適合事例です。F17は例として3つの問題を挙げています。

  • id属性値がユニークではない問題
  • for属性などで、id属性値や他の識別子への参照が正しくない場合
  • accessskey属性がユニークでない問題

このうちid属性値がユニークでない場合はF62として既にありますし、識別子への参照が正しくない場合はF68として既にあります*2

なのでF17が存在している理由はほとんどないありませんが、accesskey属性がユニークではない話は他の不適合事例にはでてきません。F17はaccesskey属性がユニークかどうかの話に絞って書きなおすべきです。

F41

F40は<meta http-equiv="referesh">を使って別のページにリダイレクトする際の問題、F41は<meta http-equiv="referesh">を使って同じページを再読み込みされる際の問題です。

F41には例が2つありますが、2つ目の例はF40の問題(別ページにリダイレクトさせている)ですので、削除すべきです。関連する実装方法のSVR1もF40に関連し、F41には関連していないので削除すべきです。

また、F41の試験方法では、0秒で再読み込みさせている場合には不適合になりませんが、実際にはユーザーに再読み込みを停止させる方法を提供せずに、自動的に再読み込みしている時点で問題があります*3。なので、「0秒より長い」ではなく「0秒以上」にあたらめるべきですし、F41の名前からも「タイムアウト」を取るべきです。

F42

F42は、プログラムからリンクとして認識できない方法でリンクをエミュレートしている、という不適合事例です。div要素のclickイベントなどでlocation.hrefを書き換えているような場合が該当します。

この不適合事例には2つの観点があります。1つはdiv要素のclickイベントなどを使うとキーボードで操作できない、という話です。これはF54のポインティングディバイス固有のイベントハンドラ―しか使っていないという不適合事例と同じです。

もう1つは、たとえキーボードで操作できたとして、div要素などを使っているとブラウザーや支援技術からはリンクだと認識できない、という話です。これはF59のroleを提供せずにdiv要素やspan要素でユーザーインタフェースコンポーネントを作っている不適合事例と同じです。F59ではユーザーインタフェースコンポーネントの例としてリンクも挙げられています。

F42として独立させる理由はありませんので削除すべきです。

F48

F48はpre要素を使って表形式の情報をマークアップしている、という不適合事例です。確かにこういう実装は問題なのですが、F34(空白文字を使って表をフォーマットしている)との違いがわかりません。また、F33(空白文字を使って複数カラムを作っている)にはpre要素版はありません。F34とF48をそれぞれ立てる必要はありませんので、一般的なF34を残してF48は削除すべきです。

F55

F55は、onfocusでthis.blur()をしているという不適合事例です。

F55の例3は例2とほぼ同じです。この不適合事例ではblur()することが問題なので、その意味では例2と例3は変わりません。なので、例3は削除すべきです。

F68

F68はフォームコントロールに視覚的なラベルがあるのに、フォームコントロールと関連づけられていない、という不適合事例です。視覚的なラベルが使われている場合、と繰り返し述べているにも関わらず、F58には視覚的なラベルが使えない話がでてきます。視覚的なラベルが使えない場合の話はF68からは削除すべきです。

おわりに

Techniques for WCAG 2.0について感じたことの「重複している」に対するコメントが多くなってしまいました。実際にはARIAまわりなどは足りないように思いますので、今後実装方法が増えていくでしょうし、増えないと困ります。

また、今回は突っ込みをする会でしたのでネガティブな話が多いですが、私はTechniques for WCAG 2.0がより使われるようになってほしいと思っています。…そうすれば、人に訊かれた際にも「これを読んでおいて」で済みますから。

*1:日本時間の2014年8月13日に送っても大丈夫だと思いますが、保証はしません

*2:識別子への参照が正しくない問題については、for属性とheaders属性について、それぞれ独立した不適合事例があります(F68とF90)が、関連する達成基準が違うので独立していても良いと私は思います

*3:HTML5では、http-equivがrefreshの場合、content属性は非負整数を取るので0秒という指定もありえます。