アクセシビリティ達成基準レベル「AA」について考える
最近、ある Web サイトの構築プロジェクトで、情報アーキテクチャ (IA)、ユーザーインターフェース (UI) 設計、アクセシビリティ、といった領域で関わらせていただく中で、アクセシビリティの達成基準レベル「AA」について、改めて考える機会がありました。そのサイトデザインが海外でも使われるということで、ある国の法制面からの要求で、W3C が勧告する「WCAG (Web Content Accessiblity Guidelines) 2.0」の達成基準レベル「AA」を満たすことを視野に入れておく必要に迫られたからです。
Web サイトがアクセシビリティ対応 (厳密に言うと「WCAG 2.0 (日本の場合は JIS X8341-3:2010)」への対応) を検討するとき、どのレベルの達成基準を満たすのかについては様々な事情を勘案したうえで決めるわけですが (開発リソースが十分か、スタッフのノウハウ/経験値はどのくらいか、継続的な運用が可能か、その他ビジネス上の判断によって)、今後は法制面からの要求、という側面も増えてきそうな気がします。
いくつか例を挙げてみますと :
- オーストラリアでは、すべての政府関連機関の Web サイトは、2014年12月31日までに WCAG 2.0 のレベル「AA」を満たさなければならない、としています (参考 : オーストラリア政府「Web Guide」サイトの「Accessibility」ページ)。
- ニュージーランドでも、政府関連機関 Web サイトのすべてのページは、2017年7月1日までに WCAG 2.0 のレベル「AA」を満たさなければならない、としています (参考 : ニュージーランド政府「Web Toolkit」サイトの「Web Accessibility Standard 1.0」ページ)
- カナダ (オンタリオ州) では、公的機関だけでなく民間企業/NPO (スタッフが50人以上) においても、2014年1月1日以降に新規公開される Web サイトは WCAG 2.0 のレベル「A」を満たさなければならず、さらに2021年1月1日以降は、(2012年1月1日以降に公開された既存コンテンツも含め) すべての Web サイト/コンテンツがレベル「AA」を満たさなければならない、としています。(参考 : オンタリオ州地域社会サービス省 (Ministry of Ministry of Community and Social Services) サイトの「Make your website accessible」ページ)
上記以外にも、法律によって Web アクセシビリティの確保が求められる国はいろいろあります。日本でも、法的規制ではありませんが、総務省の「みんなの公共サイト運用モデル (2010年改訂版)」によって、国および地方公共団体などの公的機関の Web サイト (既存サイトを含む) は2014年度末までに JIS X 8341-3:2010 の達成基準等級「AA」に準拠することが求められています。
達成基準レベル「AA」の法制面での要求はウェルカムなこと。ただし敷居が高いのも事実。
Web アクセシビリティの担保が法制面から求められることは、ユーザーにとって、とてもウェルカムなことだと思います。特に、WCAG 2.0 の達成基準レベル「AA」を満たすように規定されることで、基本的なアクセシビリティに加え、たとえば以下についてもきちんと実現されることにつながります。
- 文字色と背景色の適切なコントラストが確保されるようになる。レベル「AA」以上では、具体的な数値基準が設けられている。(達成基準 1.4.3)
- ユーザーの任意で文字サイズを拡大できるようになる。モバイル向けサイトも例外ではなく、必ずピンチ＆ズームができるようになる (<meta name="viewport"> で、user-scalable=no という指定ができなくなる)。(達成基準 1.4.4)
- ロゴマークなどを除き、基本的に文字は画像ではなくテキストで表現されるようになる。(達成基準 1.4.5)
- 見出しおよびラベルの表現が適切になる (主題/目的を的確に記述するようになる)。(達成基準 2.4.6)
- キーボード操作時のフォーカス移動が、視覚的にわかりやすくなる。(達成基準 2.4.7)
- ナビゲーションやユーザーインターフェース (UI) の一貫性がサイト内の隅々まで確保されるようになる。(達成基準 3.2.3 および 3.2.4)
その一方で、レベル「AA」を満たすこと (そしてそれを維持すること) は、実際問題として敷居が高い側面があるのも事実です。特に民間企業の Web サイトでは、公的機関に比べ、よりエモーショナルな訴求をするためのコンテンツが要件となることが多くなると思います (プロモーションやデモンストレーションのための動画など)。また、サイトを運営する企業規模がそれなりに大きくなると、更新担当者も (様々な部署にわたって) 多くなり、コンテンツ品質維持という課題も出てくるでしょう。
具体的には、下記の達成基準はかなりのハードルになるのではないか、と懸念しています。
- ライブ音声に対するキャプション (字幕) の提供。(達成基準 1.2.4)
- 動画コンテンツに対する音声ガイドの提供。 (達成基準 1.2.5)
- コンテンツの中で部分的に外国語などが用いられる箇所の言語設定 (<span> 要素などで lang 属性を記述)。(達成基準 3.1.2)
達成基準レベル「AA」をどう実現し、維持するか。
達成基準レベル「AA」をどう満たし、維持するか。現時点では、ある意味、対象サイトの制作/運営に関わるすべての人が (ガッツで、または細心の注意力でもって) 頑張るしかない状況だと思いますが、それではやはり限界があるでしょう。
WCAG 2.0 および JIS X8341-3:2010 には、「アクセシビリティ・サポーテッド (Accessibility Supported)」という考えかたがあります。
- Webコンテンツ自体が、標準仕様 (WCAG 2.0 や JIS X8341-3:2010) で定められたアクセシビリティに優れた方法で制作されている。
- ユーザーエージェント (Web ブラウザや支援技術など) がそのアクセシブルな制作物 (コンテンツ) を適切に理解、解釈、出力できる。
...その結果、ユーザーが Web コンテンツをアクセシブルに利用することができることを意味します。つまり、コンテンツ側の実装技術と、ユーザーエージェント/支援技術側の対応状況の折り合いがついて、初めてアクセシビリティが実現する、という考えかたです。
この「アクセシビリティ・サポーテッド」の範囲に、もしかしたら、Web コンテンツを制作/更新するためのツールも含まれるようになると、よいのかもしれません。たとえば「動画配信インフラとしての (各サイトのページに自社動画コンテンツを埋め込む手段としての) YouTube に、音声ガイドを付加する機能が用意されている」とか、「CMS でコンテンツを作成中に、外国語表記部分を自動的に検知して、しかるべき lang 属性を (理想的には自動的に) 入れてくれる」、といったイメージですが、要はなるべく「(特定のスキルや経験を持った) 人に依存する」状態にしないことが、持続的にアクセシビリティを確保するうえで大きいだろうな、と思っています。
願わくば、こうしたアクセシビリティ対応が「やらされてる」感で取り組まれるのではなく、ビジネスの機会損失を防ぐ格好の機会と捕えられることを希望します。そのためにも、作業ハードルを下げ、無理なく仕事できるようにすることは、重要と言えるかもしれません。
達成基準レベル「AA」を目指すことを (法制面などを通じて) 社会が求めることは、とても意義があることなので、それ自体は受け入れつつ、自分なりにサポートできることを考えてゆきたいな、と思います。