血統の森+はてな

旧はてなダイアリーの自動インポートによるアーカイブです。

W3C HTML5仕様に見るアクセシビリティーに関する記述

この記事はWeb Accessibility Advent Calendar 2014 - Adventarの6日目のエントリーです。このエントリーのタイトルからは、やれW3Cだやれ仕様だとお堅いイメージがぷんぷん漂いますが、易しいめに書くことを心がけてみました。そのため、ガチ勢には物足りなさを感じるかもしれません。

ウェブ業界の人にとっては周知のことだと思いますが、去る10月28日付けでHTML5仕様（以下単に仕様と書きます）が勧告されました。この仕様の意義はさまざまな切り口で捉えることが考えられますが、アクセシビリティーという観点から1つ前のバージョンのHTMLであるHTML4と比較して、この仕様で特に目立って強化されたと思われる点を挙げるとすると、

  1. img要素のalt属性が大幅に拡充されている
  2. WAI-ARIA1.0を取り込んでいる
  3. 映像や音声のための要素（video要素、audio要素）にテキストトラックを与えることができる

の3つではないかと思います。ほかにも仕様自身がValidatorに言及していたりするといった細かい点を挙げ出すとキリがないですが、今回は前述の3つに絞りつつも、つまみ食いの形で雑多なものをひとくくりにした4つでお送りしたいと思います。
なお、仕様に関しては拙訳HTML5日本語訳をそのまま引用しています。

alt属性について

img要素のalt属性の値、つまり代替テキストに関して仕様は、代替テキストは、視覚情報をアクセシブルにするための最も重要な方法であって、画像のalt属性は非常に重要なアクセシビリティ属性である。とされています*1。


たとえば、次のようなねこ画像を貼ることを考えてみましょう。
砂利の地面に腹ばいになっている、茶白ののらねこ写真

<img src="http://pbs.twimg.com/media/B3rveVrCYAAtqeG.jpg" alt="ねこ画像" />

というようなHTMLコードを与えればとりあえずは良いわけですが、仕様の4.7.1.1.14 写真の画像によれば、代替テキストには簡単な説明を書くよう促しています。つまり上述のコードは、

<img src="http://pbs.twimg.com/media/B3rveVrCYAAtqeG.jpg" alt="砂利の地面に腹ばいになっている、茶白ののらねこ写真" />

とした方が代替テキストとしてより好ましい、ということになります（もちろん一例です）。これは、G100: 非テキストコンテンツの一般に認められた名前又は内容が分かる名前を提供する｜WCAG 2.0 実装方法集にも合致するでしょう。


とはいえ、この例はあくまで写真の場合であり、画像によって適切な代替テキストは当然変化します。では、画像に対する適切な代替テキストを決定するにはどうすればいいのでしょうか。仕様には、

適切な代替テキストを判断するには、画像がページに含まれている理由を考えることが重要である。その目的は何か？このように考えることは、読者に意図する画像に関して何が重要かを理解するのに役立つ。すべての画像は、有用な情報を提供する、機能を実行する、インタラクティブな要素を分類する、美意識を高めるまたは純粋に装飾的といったページ上に存在する理由を持つ。したがって、画像が何のために存在するのかを理解することは、適切な代替テキストの記述を容易にする。

4.7.1.1.2 一般的なガイドライン ― HTML5 日本語訳

というように、画像の目的を考えるよう促しています。W3CのWAIのリソースにAn alt Decision Tree • Images • WAI Web Accessibility Tutorials（英語）というようなデシジョンツリーもありますが、個人的には仕様で一番それっぽそうなものを見つけた方が早い気もします。


前述したように、画像に対して適切な代替テキストを付与することは人間の価値判断を伴うため、自動で付与するのは現在の技術ではおそらく困難でしょう。また、CMSで大量に画像を管理しているものの、これまで適切に代替テキストを付与してこなかった場合にどうするか、といったあたりも課題かもしれません。

WAI-ARIAについて

WAI-ARIAのWAIは、W3CのWeb Accessibility Initiative（ウェブアクセシビリティ・イニシアチブ）の略称です。ARIAというのはMDNの説明を引用すると、

Accessible Rich Internet Applications (ARIA) は Web コンテンツや Web アプリケーション (特に Ajax や JavaScript を伴って開発するもの) を、ハンディキャップを持つ人々にとってよりアクセシブルにする方法を定義するものです。例えば、ARIA はナビゲーションの目印、JavaScript ウィジェット、フォームのヒントやエラーメッセージ、動的なコンテンツ更新などをアクセシブルにできるようします。

ARIA - Accessibility | MDN

ということになります。これだとわかりにくいと思いますので、もっと具体的に考えてみましょう。


たとえば、前節であげたような画像ならば、img要素でマークアップするのが素直な方法でしょう。img要素は画像を表すわけです。ほかにはp要素ならば段落を表す…と言った具合に、要素は意味を持っているわけです。このHTML要素の意味をWAI-ARIAで表したのが、仕様でいうところの「デフォルトの暗黙のARIAセマンティック」となるわけです。また、WAI-ARIAにあって、仕様にない意味というものも当然存在します（たとえば、ツリー表示を意味するtreeロールといったものなど）。言い換えるならば、WAI-ARIAは仕様（WAI-ARIAから見て、厳密に表現するとホスト言語）の意味を明示化する、あるいは仕様にない意味を補完してくれると言えるでしょう。


次のコードは、WAI-ARIAを用いたアスキーアートのマークアップしている要素の意味をより明確にしている例です。WAI-ARIAを解釈してくれるユーザーエージェントであれば、figure要素を無意味なテキストの羅列ではなく画像と見なし、figcaption要素をfigure要素のキャプションとして解釈してくれるでしょう。

<figure role="img" aria-labelledby="fish-caption"> 
 <pre>
 o           .'`/
     '      /  (
   O    .-'` ` `'-._      .')
      _/ (o)        '.  .' /
      )       )))     ><  <
      `\  |_\      _.'  '. \
        '-._  _ .-'       '.)
         `\__\
 </pre>
 <figcaption id="fish-caption">
  Joan G. Stark, "<cite>fish</cite>".
  October 1997. ASCII on electrons. 28×8.
 </figcaption> 
</figure>
3.2.7.4 暗黙のARIAセマンティック ― HTML5 日本語訳


WAI-ARIAは意味を付け足すだけでなく、打ち消すこともできます。たとえば、一般にtable要素はレイアウトのために使うことを避けた方がよいとされますが、レイアウトに使う場合の記述が仕様にはあります。

テーブルをレイアウトに使用する場合、ユーザーエージェントに対して支援技術へテーブルを適切に表現するために、および文書からのテーブルデータの抽出を 望むツールへ著者の意図を適切に伝えるために、属性role="presentation"でマークしなければならない。

4.9.1 table要素 ― HTML5 日本語訳

「しなければならない」というのはもちろんRFC 2119*2の"must"です。この場合、table要素の持っている意味を打ち消して、単に見た目だけにしか存在しないという意味で上書きします（いわばdiv要素のようにしてしまう）。


そうはいうものの、わざわざ仕様にある意味を打ち消してまで単に見た目だけのために存在するんだ、なんてやたらと宣言するものでもないでしょうから、濫用するのは避けたいものです。


以下のリンクは筆者による翻訳物の宣伝です。

//momdo.github.io/WCAG20-TECHS_aria.html">ARIA Techniques | Techniques for WCAG 2.0 日本語訳:WAICの実装方法集では翻訳されていないセクションの翻訳物です。*3
//momdo.github.io/wai-aria/">Accessible Rich Internet Applications (WAI-ARIA) 1.0 日本語訳:WAI-ARIA 1.0 勧告の日本語訳で、翻訳進行中です（5.4節の途中まで）。

上記に限らず、筆者の訳した文章に関して、誤訳等のツッコミを歓迎します。

動画や音声のテキストトラックについて

video要素やaudio要素（仕様ではメディア要素としてひとくくりにされる）に関しては、track要素を記述することで、テキストトラックを用意することができます。とはいうものの、筆者自身が仕様の訳起こしをやっている割には理解が曖昧ですし、実際に動画や音声を用意して実装の動作を検証したというわけでもないので、ごく簡単な説明にとどめるだけにして、最後に他サイトへの記事への誘導という形にしたいと思います。

仕様によれば、track要素の取ることのできるテキストトラックの種類（kind属性の値）は次の5つです。以下の説明は筆者が改変しています。*4

subtitles
（日本人話者を前提として）音声情報がたとえば英語である場合の「翻訳」を主に意図します。
captions
（日本人話者を前提として）音声情報が日本語ではあるが、聞き取りにくいか聞き取れないことを前提とした「キャプション」。耳の不自由な人を意図しますが、ワンセグのキャプションのような利用の仕方もあるでしょう。
descriptions
映像情報が見ることができない（目の不自由な人、あるいは車を運転していて画面を見ることができない）ことを前提とした「音声ガイド」。
chapters
映像や音声の「章のタイトル」。
metadata
スクリプトとの連携を意図した「メタデータ」。

captionsやdescriptionsが身体などに障害を持っている人にも応用できることが示唆されますが、そういった人だけを意図しているわけではないことに十分注意すべきだと個人的には思います。たとえば、音が出せない環境で動画にキャプションがあれば、それはそれで使いどころが見いだせたり、ひらがなのみのキャプションを用意すれば漢字が分からない子どもにも使えるわけで、状況に応じてさまざまな人に恩威があるでしょう。

と、ざっくばらんな格好になりましたが、最後にWebsite Usability Infoの記事をいくつか紹介して、この節の締めに代えたいと思います。

動画のクローズドキャプションの作りかた (HTML5 の <video> 要素の場合)
http://website-usability.info/2013/01/entry_130126.html
動画のクローズドキャプションの作りかた (YouTube の場合)
http://website-usability.info/2013/01/entry_130121.html
動画コンテンツに対する「音声ガイド」
http://website-usability.info/2014/01/entry_140119.html
track 要素の基礎 - HTML5 Rocks
http://www.html5rocks.com/ja/tutorials/track/basics/

雑多なもの

アクセシビリティーに関連すると思われる仕様の記述を3つほどつまみ食いしてみました。

title属性を必要以上に使わない

title属性に依存することは、多くのユーザーエージェントがこの仕様で要求されるようなアクセス可能な方法で属性を公開しないため、現在推奨されない（たとえば、ツールチップを出現させるマウスなどのポインティングデバイスが必要になり、これはモダンな携帯端末やタブレットをもつ人のような、キーボードのみのユーザーとタッチのみのユーザーを締め出す）。

3.2.5.2 title属性 ― HTML5 日本語訳

引用に中にあるとおり、スマートフォンやタブレットのようなデバイスでtitle属性をマウスで操作するときのように動作させるのはおそらく困難でしょう。

バリデーターについて

著者は、よく目にする誤りを見つける適合性チェッカー（バリデータとも呼ばれる）を利用することが推奨される。W3Cは、Nu Markup Validation Serviceを含む、多くのオンライン検証サービスを提供する。

1.9.3 HTMLを記述する際に誤りを見つける方法：バリデータと適合性チェッカー ― HTML5 日本語訳

G134: ウェブページをバリデートする｜WCAG 2.0 実装方法集にも挙げられているような、バリデーターの案内が仕様にも記載されている、というお話です。WCAG 2.0を参照するまでもなく文法に沿ったHTMLが求められるわけですから、当然機械的なチェックをするべきです。ただし、バリデーターでエラーが検出されないから仕様に適合していると言える、とは限りません。たとえば、最初に挙げたalt属性の値は、文脈によって変化します。機械的なチェックの限界を頭の片隅におくことが必要でしょう。

意味を考える

最後に次の仕様の一節を引用したいと思います。

HTMLでの要素、属性、および属性値は、ある意味（セマンティック）を持つよう（この仕様によって）定義される。たとえば、ol要素は順序つきリストを表し、lang属性はコンテンツの言語を表す。

これら定義は、ウェブブラウザや検索エンジンなどのHTMLプロセッサに、著者が考えてないかもしれないさまざまな文脈で文書およびアプリケーションの提示と使用を許可する。

著者は、ソフトウェアがページを正しく処理するのを妨げるような、適切な意図されるセマンティック目的以外の要素、属性、または属性値を使用してはならない。

著者は、将来的に拡張される言語に対して拡張が著しく困難になるため、この仕様または他の適用可能な仕様で許可されない要素、属性、または属性値を使用してはならない。

3.2.1 セマンティック ― HTML5 日本語訳

アクセシビリティーという単語が1つも出てきていないにもかかわらず、締めが仕様のセマンティックの節からの引用なのはどういうことなのか、と疑問を持つ方もいるかもしれません。


たとえば、見出しに対してh1要素でマークアップすれば、HTMLコードを扱う人は見出しだと認識できますし、種々のブラウザーも見出しだと認識できます。しかし、p要素でマークアップした場合はどうでしょうか。p要素に対して見出しのスタイルを当てれば、HTMLをブラウザーで表示する結果は見出しとして人間が認識できるでしょうが、ブラウザーはそのまま段落として認識するでしょう。このような誤った要素（など）の使い方をしてはならない、と仕様は要求しているわけです。たとえバリデーターやアクセシビリティー・チェッカーでエラーが検出されなくとも、仕様違反になります。


つまるところ、アクセシビリティーを頑張らなきゃという前に、まず仕様どおりのHTMLを書くように心がけましょう、ということです。そして、このエントリーで示してきたようなアクセシビリティーに関する記述が仕様にはあります。もちろんそれだけでなく、HTMLを書く上で役立つだろうさまざまな記述もあります。筆者の個人的な意見として、仕様に反しないHTMLを書くことがアクセシビリティー向上の大きな一歩につながると思います。仕様を理解する上でHTML5日本語訳が役立てば幸いですというステマ（になってないただの宣伝）でこのエントリーの締めに代えさせていただきたいと思います（酷い）。最後までおつきあいありがとうございました。

謝辞

ねこ画像は@isajiさんから https://twitter.com/isaji/status/539006410013437952 をお借りしました。
Website Usability Infoのリソースは@kzakzaさんに紹介いただきました。
この場を借りてお礼申し上げます。

*1:仕様4.7.1.1 画像に対して代替として動作するテキストを提供に対する要件より

*2:参考日本語訳：RFC において要請の程度を示すために用いるキーワード https://www.ipa.go.jp/security/rfc/RFC2119JA.html

*3:さくっとWAICに引き取ってもらいたいんですがどうすればいいのでしょうか

*4:仕様は4.7.9 track要素 http://momdo.github.io/html5/embedded-content-0.html#the-track-element