「アクセシビリティ・サポーテッド」という考えかた

Webアクセシビリティの標準指針である、W3C(World Wide Web Consortium)の「WCAG 2.0(Web Content Accessibility Guidelines 2.0)」および日本の「JIS-X:8341-3:2009(2010年に改訂される予定の公開レビュー版)」では、「アクセシビリティ・サポーテッド(Accessibility Supported)」という用語が見られます。見慣れない用語なので読んでいて戸惑うかもしれませんが、アクセシビリティを実効的なものにするための重要な概念だと思いますので、簡単にご紹介したいと思います。

現状では、WCAG 2.0の中で記載されている「Accessibility Supported」という英語表現に対する簡潔な日本語訳が無く、JIS X8341-3:2009においてもカタカナで「アクセシビリティ・サポーテッド」と表記されています。このため、ちょっと理解しにくい印象を受けるかと思いますが、簡単に言ってしまうと「アクセシビリティ・サポーテッド」とは:

  • Webコンテンツ自体が、標準仕様 (WCAG 2.0 や JIS X8341-3:2010) で定められたアクセシビリティに優れた方法で制作されている。
  • ユーザーエージェント (Web ブラウザや支援技術など) がそのアクセシブルな制作物 (コンテンツ) を適切に理解、解釈、出力できる。

その結果、ユーザーが Web コンテンツをアクセシブルに利用することができる。

...ということを指します。つまり、コンテンツ側の実装技術と、ユーザーエージェント/支援技術側の対応状況の折り合いがついて、初めてアクセシビリティが実現する、という考えかたです。

この考えかたは、W3Cが定めるWeb制作の標準仕様に合わせてコンテンツを制作しても、実際にユーザーに使用されているユーザーエージェントや支援技術によって、アウトプット(出力結果)が異なるという現実を憂慮したものと考えられます。

たとえば、当サイトのコラム記事「ひとつのページに同じラベルのリンクが複数存在する場合」で触れたテクニックとして、「同じリンクラベルの<a>要素が複数ある場合には、各々にユニークなtitle属性を付ける」という手法があります。これが本当にアクセシブルであるためには、すべての支援技術(音声読み上げツール)において、[Tab]キー操作時にtitle属性が優先的に読み上げられる仕様になっている必要があります。

また、「Ruby要素は固有名詞の読み上げに寄与するか」で触れたように、特殊な読みかたをする語には<ruby>要素で読み仮名を表記するという手法がありますが、これも、すべてのユーザーエージェント/支援技術が<ruby>要素の内容を適切に出力する仕様になっている必要があるでしょう。

この他にもたとえば:

...など、細かいところで色々な問題が潜んでいたりします。

さらに、Flashの.swfファイルをWebページ(HTMLファイル)に埋め込んでいる場合、仮に.swfファイル内ではキーボード操作が可能だったり、.swf内の各オブジェクトに代替テキストが用意されていたり、とアクセシブルに制作されていても、ベースとなるWebページ(HTMLファイル)上をキーボード操作している限り、.swfファイル上にフォーカスは基本的に当たらないという問題もあります(IEでのみ通用するJavaScriptなど、いくつかハックがあったりしますが)。こういった状況も、「アクセシビリティ・サポーテッドではない」と言えるかもしれませんね。

なお、より厳密な「アクセシビリティ・サポーテッド」の定義については、WCAG 2.0の「イントロダクション」に「Important Terms in WCAG 2.0(WCAG 2.0 における重要な用語)」というセクションがありますので、そちらをご参照ください(下記に引用します)。

WCAG 2.0 英語版の「Important Terms in WCAG 2.0より引用)

Accessibility Supported

Using a technology in a way that is accessibility supported means that it works with assistive technologies (AT) and the accessibility features of operating systems, browsers, and other user agents. Technology features can only be relied upon to conform to WCAG 2.0 success criteria if they are used in a way that is "accessibility supported". Technology features can be used in ways that are not accessibility supported (do not work with assistive technologies, etc.) as long as they are not relied upon to conform to any success criterion (i.e., the same information or functionality is also available another way that is supported).

The definition of "accessibility supported" is provided in the Appendix A: Glossary section of these guidelines. For more information, see Understanding Accessibility Support.

WCAG 2.0 日本語訳版の「WCAG 2.0 における重要な用語より引用)

アクセシビリティ・サポーテッド

技術をアクセシビリティ・サポーテッドな方法で用いるというのは、支援技術(AT)および OS、ブラウザ、その他のユーザエージェントのアクセシビリティ機能と連携するということを意味する。技術は、アクセシビリティ・サポーテッドな方法で用いられている場合のみ、WCAG 2.0 の達成基準を満たすために依存することが可能である。ただし、何らかの達成基準を満たすために用いられていない(つまり、同じ情報あるいは機能が、アクセシビリティ・サポーテッドな他の方法でも利用可能である)かぎり、その技術をアクセシビリティ・サポーテッドではない(支援技術などと連携しない)方法で用いることができる。

アクセシビリティ・サポーテッドの用語定義は、このガイドラインの附録 A: 用語集で提供されている。より詳細な情報は、「アクセシビリティ・サポーテッド」を理解するを参照のこと。

現状では、アクセシブルなWebコンテンツを作ったつもりでも、ユーザー側のインターネット利用環境(ユーザーエージェントや支援技術の種類)の違いによって、受けることができるユーザーエクスペリエンスに差が出てしまう、という問題があります。W3Cがオフィシャルな指針(WCAG 2.0)を通じて「アクセシビリティ・サポーテッド」という概念を明確に掲げたことで、Webサイト/コンテンツの作り手側と、ユーザーエージェント/支援技術のベンダー側の双方に対して、アクセシビリティの意識の浸透と同時に「歩み寄り」を求めたことは、地味かもしれませんがとても意義のあることだと思います。

なお、日本語環境の場合、表記のバリエーションの広さや読み仮名の複雑さ、独自のネット文化(絵文字の使用など)、あるいはその他の側面から、日本固有の「アクセシビリティ・サポーテッド」のありかたも問われることになると思います。このたび改訂されるJIS X8341-3の中に、WCAG 2.0を踏襲する形で「アクセシビリティ・サポーテッド」の概念が持ち込まれたことは、こうした問題の解決に向けて進んでゆく契機となるかもしれませんね。

記事を共有

Twitter に投稿 Facebook に投稿 はてなブックマークに投稿 Pocket に追加