新春特別企画

2017年のWebアクセシビリティ

この記事を読むのに必要な時間:およそ 3 分

あけましておめでとうございます。株式会社ミツエーリンクスの黒澤剛志です。本稿では,昨年に引き続いて,2017年のWebアクセシビリティの短期的な予測を寄稿させていただきます。

WCAG 2.1

WCAG 2.0は2008年にW3Cの勧告(Recommendation)となって以来,国際的なWebアクセシビリティのガイドラインとして使われています。2016年のJIS X 8341-3の改正(JIS X 8341-3:2016)においても,当該JIS規格はWCAG 2.0と一致した内容注1になりました。

注1
厳密にはJIS X 8341-3:2016はISO/IEC 40500:2012と一致した規格になっています。なお,ISO/IEC 40500:2012はWCAG 2.0をISO規格化したものです。

一方で,W3Cの中ではWCAG 2.0以降のガイドラインに関する議論がなされています。大きくはWCAG 2.0の枠組みを維持したまま更新するWCAG 2.1とWCAGなどの枠組みそのものを見直すAccessibility Guidelines 3.0の2つがあります。

まず,WCAG 2.1について見てみましょう。WCAG 2.1の要件として検討されている内容は,大きく次の2つがあります。

  • 2.1はWCAG 2.0を大きく変更するものではない
  • 2.1の変更は,WCAG 2.0の達成基準を厳しくするものか,WCAG 2.0に存在しなかった達成基準を追加するものである

この通りにWCAG 2.1が策定されると,例えば,WCAG 2.0のレベルAに適合していたコンテンツが2.1のレベルAに適合できるとは限りません(2.1の基準のほうが厳しいため)が,2.1のレベルAに適合していれば2.0のレベルAには適合します。このアプローチでは仕様同士の整合性は保つことができますが,既存の仕様の見直しに大きな制約があるため,各方面から吸い上げた要求事項を現実的な仕様に落とし込むのは容易ではないと考えています。

また,W3CはWCAG 2.1が策定されてもWCAG 2.0が廃止されるわけではなくガイドラインとして採用しつづけられると明言しています。つまり,WCAG 2.1が策定された後でも,基準とするガイドラインをWCAG 2.0とするか,WCAG 2.1とするかをサイトが選択できます。WCAG 2.0も選択肢として残る中でWCAG 2.1を選択する理由・メリットをどう打ち出すかもWCAG 2.1の標準化におけるポイントの1つと考えています。

W3CのAccessibility Guidelines Working Group(AG WG・注2プロジェクト計画の中でWCAG 2.1の最初の草案を2017年2月に公開することを掲げており,2017年はその内容・動向に注意が必要です。

注2
Web Content Accessibility Guidelines Working Group(WCAG WG)は行動憲章(charter)を更新中で,行動憲章の更新が承認されるとAG WGとなります。

一方,Accessibility Guidelines 3.0はウェブコンテンツ向け,オーサリングツール向け,ユーザーエージェント向けに分かれているアクセシビリティガイドライン注3の統合など,大がかりな更新を行うことが検討されていますが,本格的な議論はまだ先です。なお,AG WGのプロジェクト計画では2019年10月に最初の草案を公開することを掲げています。

注3
現在,W3CのアクセシビリティガイドラインはWeb Content Accessibility Guidelines,Authoring Tools Accessibility Guidelines,User Agent Accessibility Guidelinesと対象ごとに分かれています。

Accessible Rich Internet Applications(WAI-ARIA)

具体的な技術や仕様に目を向けると,2016年,WAI-ARIAでは1.1の勧告候補(Candidate Recommendation)が公開されました。WAI-ARIA 1.1は比較的小規模な更新ということになっていますが,WAI-ARIA 1.0と互換性のない変更もあります。例えば,WAI-ARIA 1.1ではランドマーク(landmark)に分類されるロールが1.0の定義から変更されました。1.1ではapplicationロールとarticleロールがランドマークから外れ,regionロールがランドマークとなります。本稿執筆時点ですでにiOSのVoiceOverやAndroidのTalkbackはWAI-ARIA 1.1の定義に基づいてランドマークかどうかを判断しています。

しかし,サイト制作者やアプリケーション開発者にとって,より影響が大きいのはWAI-ARIA Authoring Practicesの更新でしょう。WAI-ARIAの仕様を読んでもなかなか具体的な利用方法が分からないという声がありますが,W3Cも仕様そのものとは別にWAI-ARIA Authoring Practicesという制作者・開発者向けの文書を作成しています。この文書はWAI-ARIA 1.0に対するWAI-ARIA 1.0 Authoring Practicesとして作成されていましたが,1.1に合わせて大幅な見直し・書き換えがなされています。例えば,AccordionはWAI-ARIA 1.0 Authoring Practicesではタブとして実装することになっていましたが,WAI-ARIA Authoring Practices 1.1では単に見出し(heading)とボタン(button)を組み合わせて実装するように変更されました。WAI-ARIA Authoring Practicesは今後も更新される見込みであるため,2017年も定期的に見直すことが必要でしょう。

また,HTMLとの関係について見ると,モダンブラウザーではWAI-ARIAに頼らなくてもHTMLのセマンティクスが支援技術に伝わるようになってきています。2016年について見ると,例えば,MicrosoftはHTML5AccessibilityにおけるEdgeのスコアが100%になったことを発表しています。IE11以下を除けば,HTMLで表現可能なセマンティクスに対してWAI-ARIAを利用しなくてはならない状況はあまり残っていません。2017年以降,WAI-ARIAはもっぱらHTMLなどでは表現できないセマンティクスのために利用されていくでしょう。

一方,WAI-ARIAなどを利用していると使い方によってはセマンティクスが意図した通りに支援技術へ伝わらない場合があります。このような場合,制作者や開発者が原因の調査にブラウザー組み込みの開発者ツールを利用できるようになりつつあります。WebKitでは以前からWebインスペクタにアクセシビリティオブジェクトを調査する機能がありましたが,Edgeは2016年にF12開発者ツールにアクセシビリティオブジェクトを調査する機能を追加しました。また,制作者や開発者が設定を変更する必要がありますが,Google Chromeもデベロッパーツールにアクセシビリティオブジェクトを調査する機能があります。これらを含む開発者向けのサポートが,2017年,どのように広がるかにも注目しています。

Scalable Vector Graphics(SVG)

2016年はSVG 2の勧告候補も公開されました。SVG 2ではHTML5などと同じように,WAI-ARIAのrole属性やaria-*属性をほとんどの要素で利用することができます。また,要素がキーボードフォーカスを受け取るかどうかをtabindex属性で指定できるようになりました。インタラクティブなコンテンツをよりアクセシブルに作成しやすくなった仕様といえるでしょう。

また,画像ならではの代替テキストの指定方法も盛り込まれています。多言語対応を前提にしたサイトやアプリケーションでは,表示されるテキストは変わっても画像(特にアイコン)の見た目は言語によらず同じ場合があります。例えば,動画の「再生」を表すテキストは日本語では「再生」⁠英語では「Play」など言語によって異なりますが,アイコンでは言語によらず右向き三角(▶)を使うことが多くあります。しかし,画像ではなく代替テキストを利用しているユーザーは,ユーザーの理解できる言語で代替テキストが書かれていなければ内容を理解できません。例えば,英語圏のユーザーを対象にしているサイトでアイコンの代替テキストを「再生」のままにしてしまえば,ユーザーの多くは内容を理解できないでしょう。そこで,SVG 2は1つのSVGファイルの中に複数言語の代替テキストを記述できるようにし,ブラウザーや支援技術がユーザーの言語設定から自動的に代替テキストを選択する仕組みを設けました注4)⁠なお,この仕組みはWebKitですでに実装されています注5)⁠

注4
lang属性を指定したtitle要素やdesc要素を複数記述するとブラウザーや支援技術がユーザーの言語設定に基づいて適切なtitle要素やdesc要素を選択します。
注5
本稿執筆時点ではWebKit(Safari)は仕様に基づいて代替テキストを選択していますが,代替テキストの内容はVoiceOverでは読み上げられません。

Payments

2016年は,というよりも,2016年もオンラインショッピングにおいては,決済に必要な情報をユーザーがサイトごとに入力するのではなく,デバイスに記憶させた支払情報を呼び出して決済する流れが加速しました。例えば,iOS 10ではWebでもApple Payが利用できるようになりましたし,Android版Google ChromeやEdgeでもPayment Request APIの実装が進んでいます。これらの決済方法では,ユーザーはサイトの入力フォームに記入することなく,ブラウザーやOSが提供するインタフェースを数回操作するだけで決済できます。

この流れは支払情報を都度入力することが多くの人にとって時間と手間のかかる作業であることを反映しています。その一方で,入力フォームはWebアクセシビリティにおいては問題が特に起きやすい部分であり,ユーザーによっては入力や送信ができない場合も少なくありません。他方,事前にデバイスを記憶させた支払情報を使って決済する場合,ブラウザーやOSがアクセシブルなユーザーインタフェースを提供すればサイトによらず一定のアクセシビリティを確保できます。

このような状況下で,入力フォームのアクセシビリティを確保しないと何が起きるでしょうか。何を入力すれば良いのか分からない,自分のデバイスで操作できないといった問題のある入力フォームを使うよりも,類似のことが問題なくできるサービスやアプリ,仕組みにユーザーは移ってしまわないでしょうか。

定型的な情報は入力フォームを使わなくてもサイトに伝えられる時代である今,ユーザビリティの面もそうですが,何よりもまず一定のアクセシビリティを確保していなければユーザーに入力フォームを利用してもらえないと考えています。その意味で,2017年は入力フォームのアクセシビリティの確保がより重要になるでしょう。

著者プロフィール

黒澤剛志(くろさわたけし)

株式会社ミツエーリンクス 第一事業部アクセシビリティ部所属。近著にWEB+DB PRESS Vol.95の特集1[実装例でわかる!]実践アクセシビリティ(共著)。

コメント

コメントの記入