Smart Communication Design Company
ホーム > ナレッジ > Blog > アクセシビリティBlog > 2014年2月 > Using WAI-ARIA in HTMLのEditor's Draftに第4のルールが追加

Using WAI-ARIA in HTMLのEditor's Draftに第4のルールが追加

2014年2月6日
アクセシビリティ・エンジニア 黒澤

W3Cが策定をすすめているUsing WAI-ARIA in HTML（HTMLでWAI-ARIAを使う）のEditor's Draftに新しいルールが追加されました。Using WAI-ARIA in HTMLはThe Paciello GroupのSteve Faulknerさんを中心に編集されている、HTMLでARIAを使う際の実践的なガイドです（もともとはSteve Faulknerさんが「Unofficial Draft」として書いていました）。

Using WAI-ARIA in HTMLにおけるこれまでのルールは3つで、次のようなものでした。

（ルールが3つしかなかったことは2013年10月3日版のUsing WAI-ARIA in HTML草案などで確認できます。なお、以降特に断りが無い限り「Using WAI-ARIA in HTML」はEditor's Draftにリンクしています。）

今回、Editor's Draftに追加された第4のルールは「フォーカス可能な要素ではrole="presentation"やaria-hidden="true"を使ってはならない」です。本エントリーではこのルールに従わない場合、どういった問題が起こり得るのかを考えてみたいと思います。

role="presentation"

まず、presentationロールについてみてみましょう。このロールは要素のセマンティクスをはぎ取ります（ブラウザーがセマンティクスを支援技術に伝えなくなります）。

具体的にどのような効果があるのか、Using WAI-ARIA in HTMLの「Use of role=presentation（presentationロールの使用）」の例を見てみましょう（日本語訳は筆者）。

例えば、HTMLツリーにあるこのコードは、

 <h1 role=presentation>テキスト</h1>

アクセシビリティツリーではこうなります。

 <>テキスト</>

h1要素にrole="presentation"を指定すると、h1要素としてのセマンティクスがはぎ取られ、支援技術には要素の子孫（この場合はテキスト）のみが伝わります。

ですが、この効果には例外があります。WAI-ARIAのpresentationロールでは、フォーカス可能な要素にrole="presentation"が指定されても、ブラウザーはその指定を無視しなくてはならないと定義されています（日本語訳は筆者）。

もし、presentationロールを持った要素がフォーカス可能であるならば、ユーザー・エージェントは（訳注：presentation）ロールの通常の効果を無視して、暗黙のネイティブセマンティクス（訳注：簡単に言えば、要素がもともともっているセマンティクス）を支援技術に提供しなくてはならない。これは、その要素が理解可能かつ操作可能であることを保証するためである。

これだけではわかりにくいので、この例外が無かった場合どうなるのかを考えてみましょう。例えば、リンクにpresentationロールを指定したら、ブラウザーはリンクのセマンティクスを支援技術に伝えなくなるとします。

この場合、WAI-ARIAは要素のブラウザーでの見た目や機能を変えないため、支援技術を使っていないユーザーは、要素がリンクであると認識し、要素のクリックなどによってリンクを開くことができます。一方で、支援技術のユーザーは、リンクに移動しても、その要素がリンクとして機能しうることはわかりません（支援技術はその要素はリンクではないと認識しています）。

このように、ユーザーが操作する要素にpresentationロールが作用すると、支援技術を使っているユーザーは、その要素が操作可能か理解できなくなるおそれがあります。そして、「ユーザーはキーボードで操作が行えなくてはならない」というルールから、ユーザーが操作する要素はフォーカス可能になっているはずです。そのため、フォーカス可能な要素にpresentationロールが指定されてもブラウザーは無視しなくてはならないという例外がある、と筆者は理解しています。

aria-hidden="true"

一方のaria-hiddenはその要素がユーザーから認識できるかどうか（知覚可能かどうか）を表し、aria-hidden="true"はその要素と子孫がユーザーから隠されている（知覚不可能である）ことを意味します。DOM上に存在するもののユーザーからは隠されている要素にaria-hidden="true"を指定することで、ユーザーは隠されているコンテンツをスキップしてページを理解したり操作することができます。

ブラウザーはaria-hidden="true"が指定された要素とその子孫をアクセシビリティツリーに出さないか、支援技術が無視できるように専用のプロパティを設定しています（Marco Zehe氏による解説）。そのため、要素は支援技術のユーザーからも隠されます（スクリーン・リーダーでは読み上げられない、など）。

さて、このaria-hidden="true"は視覚的に表示されている要素に対しても指定することができます。視覚的に表示されている要素であっても、ブラウザーは支援技術に対して要素を隠すため、支援技術のユーザーからは隠されるでしょう。

ですが、WAI-ARIAは要素の機能を変えるわけではないため、aria-hidden="true"が指定されている要素がフォーカス可能な場合、Tabキーを押すとブラウザーはフォーカスをその要素に移動します。フォーカスの移動先がリンクなどであれば、Enterキーなどを押すとページ遷移が発生します。しかし、支援技術はその要素に関する情報をもっていないため、どこにフォーカスが移動したのか、何がおこったのかをユーザーに伝えることができなくなります。

フォーカス可能な要素にaria-hidden="true"を指定しても問題がおこるおそれがあります。

まとめ

筆者は「フォーカス可能な要素ではrole="presentation"やaria-hidden="true"を使ってはならない」というルールからは「WAI-ARIAを指定しても要素の見た目や動作が変わるわけではない」ことを気に留める必要があると感じました。もちろん、今回Editor's Draftに追加されたルールは今後の議論によって変更されたり、削除される可能性もあります。しかし、WAI-ARIAはセマンティクスを補うものだということを気に留め、ブラウザーでの見た目や動作との整合性にも注意する必要がある点は変わらないだろうと筆者は考えています。

皆さんはどんな点に注意してWAI-ARIAを使っていますか？

ミツエーリンクスでは、WCAG準拠やJIS X 8341-3対応をはじめ、さまざまなWebアクセシビリティ関連サービスをご提供しています。是非アクセシビリティのページをご覧いただき、お気軽にお問い合わせください。

Pick Up