オープンウェブが強力なのは、あらゆる人が同じ情報にアクセスできるからです。つまり、ウェブは、場所やハードウェアの好み、言語、能力によらず、誰が使っても動作するように設計する必要があります。AMP は、すべての AMP エクスペリエンスをデフォルトで WCAG AA 対応にすることを目指し、UI およびアクセシビリティ ワーキング グループがこの作業に注力しています。これは、AMP を使うとアクセシビリティが高いサイトを簡単に作れるだけでなく、デフォルトの状態でもアクセシビリティの低いエクスペリエンスが生成 されなくなる ことを意味します。
このブログでは、アクセシビリティの高いコンポーネントを作るために AMP Project が注力してきた作業と、デベロッパーがウェブ エクスペリエンスを作成する際に最優先すべきいくつかの重要な原則、そしてツールについて紹介します。
AMP コンポーネントを設計するとき、アクセシビリティは早い段階で検討すべき重要な内容です。私たちは、さまざまなアクセシビリティのニーズがある人々が、リリースされるコンポーネントを利用できないという事態が起こらないように、設計レビューや実装の意図のプロセスで徹底的な確認を行います。その結果、AMP で W3C WCAG 2.0 の Level A および AA ガイドラインを満たすページを作成できるようになりました。このガイドラインは、国際的に見ても、アクセシビリティに配慮した法律の重要な部分となっています。
しかし、AMP を使えばアクセシビリティが高いエクスペリエンスを作成でき、それを推奨する声もあがっているものの、AMP を使うすべてのウェブサイトが WCAG ガイダンスを満たすことを強制してはいません。この点は他のフレームワークも変わりません。たとえば、<amp-img> には代替テキストを指定できますが、すべてのイメージに代替テキストを指定することは強制しません。たとえ強制したとしても、提供された文字列が実際にそのイメージの説明になるように強制することはできません。それには、大規模な機械学習モデルの実行が必要になります。
以下に示すのは、よく使われる AMP のコンポーネントやアクションのデフォルトのアクセシビリティを向上させるため、私たちのチームが行った重労働の一部です。
アクセシビリティは UI およびアクセシビリティ ワーキング グループの最優先事項であるため、今後も AMP のデフォルト アクセシビリティの改善を続けることを計画しています。以下に、今後の計画の一部を示します。
皆さんのサイトが WCAG AA ガイドラインを満たせるようにするために、以下のツールを使ってテストを自動化することをおすすめします。
ただし、自動ツールですべての問題を認識できるとは限りません。最高のリソースは、WCAG ガイドラインを理解しているデベロッパーにマークアップや CSS をレビューしてもらい、確実にベスト プラクティスが反映されるようにすることです。
いつものように、問題や機能リクエスト、特にアクセシビリティ関連の内容がありましたら、遠慮なくお知らせください。
投稿者: AMP Project、プロダクト マネージャー、Naina Raisinghani
