ARIAの使用 ARIA

2.1 ARIA利用の第一ルール

必要なセマンティクスと動作がすでに組み込まれているネイティブHTML要素[HTML51]または属性を利用できる場合、要素を流用してARIAロール、ステート、プロパティを加えてアクセシブルにするのではなく、それを利用してください。

どのような状況でこれが不可能になるか？

• 機能自体はHTML[HTML51]で提供されているが、未実装または、アクセシビリティサポートが実装されていない場合。
• ビジュアルデザイン上の制約により特定のネイティブ要素が求めるスタイルにできず使えない場合。
• 機能が現時点でHTMLに存在しない場合。

2.2 ARIA利用の第二ルール

本当に必要でない限り、ネイティブのセマンティクスを変更しないでください。

例：開発者が見出しをタブにしたい場合。

次のようにしないでください：

<h2 role=tab>heading tab</h2>     

次のようにしてください：

<div role=tab><h2>heading tab</h2></div>

2.3 ARIA利用の第三ルール

すべてのインタラクティブなARIAコントロールはキーボードで操作できなければなりません。

クリック、タップ、ドラッグ、ドロップ、スライド、スクロールなどの操作ができるウィジェットを作った場合、ユーザーはキーボードでもそのウィジェットに移動し、同様の操作ができなければなりません。

すべてのインタラクティブウィジェットは、該当する場合には標準的なキー操作またはキー操作の組み合わせに応じてスクリプトが反応するようにしなければなりません。

例として、role=buttonを使う場合、要素がフォーカスを受け取ることができ、両方のOSでenter（WIN）、return（MAC）、さらにはspaceキーでアクションの実行ができなければいけません。

デザインパターンとウィジェットやキーボードインターフェイスの開発の各節（[wai-aria-practices-1.1]）も参照してください。

2.4 ARIA利用の第四ルール

フォーカス可能な要素ではrole="presentation"やaria-hidden="true"を使用しないでください。

これらいずれかをフォーカス可能な要素で使用すると、一部のユーザーが「何もない」状態にフォーカスしてしまいます。

次のようにしないでください：

<button role=presentation>press me</button>   

次のようにしないでください：

<button aria-hidden="true">press me</button>   

<div aria-hidden="true"> 
<button>press me</button>
</div>

 button {opacity:0}

<button tabindex="-1" aria-hidden="true">press me</button>

2.5 ARIA利用の第五ルール

すべてのインタラクティブ要素はアクセシブルネームを持たなければなりません。

インタラクティブ要素は、そのアクセシビリティAPIのアクセシブルネーム（または同等の）プロパティに値がある場合のみ、アクセシブルネームを持ちます。

たとえば、下記のinput type=textのコード例は、ラベル「user name」が可視ですが、アクセシブルネームがありません：

    user name <input type="text">

    または

    <span>user name</span> <input type="text">
    

コントロールのMSAA accNameプロパティは空です：

比較として、下記のinput type=textはラベル「user name」もアクセシブルネームも持っています。この例ではinput要素がラベル付け可能要素であり、label要素を正しく使ってラベルテキストと入力を関連付けています。

<!-- 注：for/idやラベルでテキストとコントロールを囲む方法によりアクセシブルネームになります -->

<input type="text" aria-label="User Name">

または

<span id="p1">user name</span> <input type="text" aria-labelledby="p1">

コントロールのMSAA accNameプロパティには「user name」という値があります：

HTML label要素とラベル付け可能要素

以下はHTMLのlabelの利用についてです。ARIAウィジェットを作る場合はARIA作成ガイド文書を参照してください。

label要素は、labelがネイティブHTMLのラベル付け可能要素を参照していない限り、カスタムコントロールのアクセシブルネームには使えません。

     <!-- HTML input要素にcomboboxロールを付けた例 -->

      <label>
      user name <input type="text" role="combobox">
      </label>
    

コントロールのMSAA accNameプロパティには「user name」という値があります：

div要素は、どのロールを割り当てても、HTMLのラベル付け可能要素ではありません。

     <!-- HTML div要素にcomboboxロールを付けた例 -->

      <label>
      user name <div  role="combobox"></div>
      </label>
    

コントロールのMSAA accNameプロパティは空です：

2.6 ロールを追加するとネイティブセマンティクスに何が起きるか？

ARIAロールを追加すると、アクセシビリティツリーにおいてネイティブロールのセマンティクスが上書きされ、これはアクセシビリティAPIを通じて報告され、結果としてARIAはスクリーンリーダーや他の支援技術に報告される内容に間接的に影響します。

たとえば、HTMLツリー内のこのコード：

<h1 role=button>text</h1>

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

ロールを追加しても起きないこと

ARIAロールを追加しても、支援技術以外を使っている人にとって要素の見た目や動作は変化しません。つまり、ホスト要素の動作や状態、プロパティは変わらず、ネイティブのロールセマンティクスだけが変化します。

たとえば、HTMLツリー内のこのコード：

<button role=heading aria-level=1>text</button>

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

ただし、このボタンは押すことができ、デフォルトのタブ順に入り、見た目はボタンのままで、押された時に割り当てられたアクションも引き続き動作します。これが、ボタンを見出しに変更することがHTML5適合性エラーとなる理由です。

注: 要素のroleを変えても、そのroleに新たな動作やプロパティ、状態が追加されることはありません。ARIAはブラウザでの見た目や動作自体は変えません。たとえば、リンクをボタンのように動作させたい場合、role=buttonを指定するだけでは不十分です。ネイティブボタンと同様にスペースキーで動作するようにキーイベントハンドラを追加する必要があります。なぜならネイティブボタンはenterキーやspacebarでもアクション実行ができるためです。

2.7 ARIAはインライン、それともスクリプトで？

ARIAロールやaria-*属性がスクリプトによるインタラクション動作に依存しない場合は、ARIAマークアップをインラインで記述しても安全です。たとえば、ARIAランドマークロールやARIAのラベル・説明付与属性はインラインで問題ありません。

コンテンツおよびインタラクションがスクリプトが有効なブラウジングコンテキストでのみサポートされている場合、例：Googleドキュメント（アプリはJavaScript必須）、この場合もARIAマークアップをインラインにしても安全です（なぜならJSなしでは誰も使えません）。

それ以外の場合は、ARIAの追加・変更・削除をスクリプトで行います。たとえば、ツリーウィジェットの折りたたみ部分はこのようになります：

<li role=treeitem aria-expanded=false ...

ユーザーが展開したとき、JavaScriptで以下のように変更します：

<li role=treeitem aria-expanded=true ...

2.8 ARIAのバリデーション

最も簡単なのは、ARIAマークアップ入りのHTML5 DOCTYPEを使い、W3C Nu Markup Checkerでバリデートする方法です。ARIAは他のDOCTYPEでも動作しますが、バリデーションツールがARIAマークアップを認識せずエラーになるのは、対応するDTDが更新されていないためです。将来的にも認識されることはなさそうです。

HTML5より前のバージョンでのこれらのバリデーションエラーは、本当のアクセシビリティ問題を生むわけではなく、ユーザー体験に悪影響を及ぼすものでもありません。これはARIAのアクセシビリティ注釈に対応していない古い自動テストの副産物に過ぎません。

注: W3C Nu Markup CheckerによるARIAチェックは開発中のため、100%信頼できるわけではありません（しかしかなり正確です）。ARIA仕様やHTML仕様の適合要件と矛盾する結果が出た場合は、Issueを上げてください。

2.9 role=presentationまたはrole=noneの利用

role=presentationまたは同義語のrole=noneは、その要素からセマンティクスを取り除きます。

たとえば、HTMLツリー内のこのコード：

<h1 role="presentation">text</h1>

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

つまり、単なるテキストとして報告され、セマンティクス的な意味はありません。

必須の子要素がない要素については、role=presentation/noneが指定された要素内に入れ子になった要素は自身のセマンティクスを保持します。

たとえば、HTMLツリー内のこのコード：

<h1 role="presentation"><abbr>API</abbr></h1>

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

必須の子を持つ要素（例：ulやtable）では、role=presentation/none内に入れ子になった必須子要素もセマンティクスを除去されます。

たとえば、HTMLツリー内のこのコード：

<table role="presentation">
  <tr>
    <td>
      <abbr>API</abbr>
    </td>
  </tr>
</table>

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

注: role=presentation/noneが付いた要素の必須子でない要素は自身のセマンティクスを維持します。これは、入れ子リストや入れ子テーブルなどを含みます。

たとえば、入れ子テーブルを含むこのコードは：

<table>
 <tr>
  <td>
    <table>
     <tr>
      <td>
       <abbr>API</abbr>
      </td>
     </tr>
    </table>
  </td>
 </tr>
</table>

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

外側のtableにrole=presentation/noneを追加すると、HTMLツリーは：

<table role="presentation">
 <tr>
  <td>
    <table>
     <tr>
      <td>
       <abbr>API</abbr>
      </td>
     </tr>
    </table>
  </td>
 </tr>
</table>

アクセシビリティツリーで、外側tableのセマンティクス（trやtd含む）はrole=presentation/noneによって除去されます：

role=presentation/none利用例

不正なテーブル構造の修正例

<div aria-readonly="true" role="grid">
    <table role="presentation">
    <tbody><tr role="row">
    <th role="columnheader">Dog Names</th>
    <th role="columnheader">Cat Names</th>
    <th role="columnheader">Cow names</th>
    </tr>
    </tbody></table>
    <table role="none">
    <tbody><tr role="row">
    <td role="gridcell">Fido</td>
    <td role="gridcell">Whiskers</td>
    <td role="gridcell">Clarabella</td>
    </tr>
    <tr role="row">
    <td role="gridcell">Woofie</td>
    <td role="gridcell">Claws</td>
    <td role="gridcell">Glenn</td>
    </tr>
    </tbody></table>
    </div>

2.10 実用的なサポート：aria-label、aria-labelledbyおよびaria-describedby

執筆時点でのまとめ：

• aria-labelledbyとaria-describedbyは、 インタラクティブコンテンツ要素（例：リンクや多くのinput型を含むフォームコントロール）で堅牢にサポートされています。
• 多くの支援技術では、<nav>および<main>要素にはaria-labelまたはaria-labelledbyを使用できますが、<footer>、<section>、<article>、<header>には使わないほうが良いです。
• <aside>へのaria-label・aria-labelledbyのサポートはまちまちです。
• AndroidのTalkbackは、ランドマーク全体の内容をaria-labelまたはaria-labelledbyで上書きします。
• role=navigation、role=search、role=mainのdivへのaria-labelやaria-labelledbyは問題ありませんが、JAWSはrole=banner、role=complementary、role=contentinfoではサポートしません。NVDA、VoiceOver、TalkbackならOKです。
• aria-label、aria-labelledby、aria-describedbyはtable、th、tdにもよく効きますが、NVDA、iOSのVoiceOver、Talkbackで一部例外があります。
• 見出し要素にはaria-labelやaria-labelledbyを使わないでください。NVDA、VoiceOver、Talkbackでは上書きになります。JAWSは無視します。
• 非インタラクティブコンテンツ（p、legend、li、ulなど）にも使わないでください。無視されます。
• spanやdivには、roleが割り当てられている場合を除いて、aria-labelやaria-labelledbyを使わないでください。linkやbuttonロール、imgロールの場合は内容を上書きします。それ以外のロール（上記ランドマーク以外）は無視されます。
• aria-describedbyをspanやdivに使っても、NVDAやVoiceOverではインタラクティブロールやイメージ、ランドマークロールがなければ無視されます。JAWSとTalkbackならOKです。
• 静的コンテンツのその他全般では、aria-describedbyはNVDAやVoiceOverで無視されます。JAWSとTalkbackはOKです。

上記はすべてiframe要素内でも同様に機能します。aria-labelとaria-labelledbyはスクリーンリーダーとアクセシビリティAPIで同じ挙動です。しかし、可視テキストの参照がない場合やid管理が困難な場合にのみaria-labelの利用を推奨します。

Internet Explorerにおけるaria-labelledby、aria-label、aria-describedbyの注意

Internet Explorerでは、aria-labelledby（複数id参照）やaria-describedbyを使う場合、参照先の要素はMicrosoftが定義するアクセシブルHTML要素でなければなりません。

複数参照するaria-labelledbyの例では、spanにtabindex=-1を付与しています。非アクセシブル要素をアクセシブルにする方法を参照。

また、要素にARIAロールがある場合もInternet ExplorerではアクセシブルHTML要素になります。たとえば：

非表示コンテンツはアクセシブルネーム・説明計算に影響しない

設計上、aria-labelledbyやaria-describedbyが参照する要素の内容が、CSSのdisplay:noneやvisibility:hidden、またはHTMLのhidden属性で隠されていても、ネームや説明付与の材料として使用されることに変わりはありません。

既定では支援技術は非表示情報を伝えませんが、著者が明示的にaria-labelledbyやaria-describedbyを介して非表示テキストをアクセシブルネームや説明の一部として含めることもできます。

以下の例では、どちらの状態でも記述情報は支援技術の利用者に提供されます：

エラーでない状態： メッセージは目視不可

<label>Name <input type="text"  aria-describedby="error-message"></label>
<span id="error-message" style="display:none">
You have provided an incorrect name</span>

注：参照先要素にaria-hidden=trueを指定しても影響ありません：

<span id="error-message" style="display:none" aria-hidden="true">
 You have provided an incorrect name</span>

エラー状態： メッセージが表示される

<span id="error-message" style="display:inline">
You have provided an incorrect name</span>

状況依存の名前・説明テキストを提供する方法

• エラー状態発生時に参照要素をDOMに追加する
• エラー状態発生時に参照要素の子としてエラーテキストをDOMに追加する
• エラー状態発生時にaria-labelledby/aria-describedby属性にid参照を追加する

2.11 ARIA role=applicationの利用

role="application"はスクリーンリーダーにどのような影響を与えるか？

現在多くの主要なスクリーンリーダーでは、ユーザーがブラウズモードのとき、ほとんどのキー操作はスクリーンリーダー側で受け取られ、ウェブページには渡りません。これはページを効率的に移動するために必要です。執筆時点では、アプリケーションモードが指定されていると、多くのスクリーンリーダーはキー操作を取得しなくなり、すべてのキー操作をブラウザに直接渡します。そのため、ユーザーはページ内を見出しごとに移動したり、静的なテキストを一行ずつ読んだりが簡単にできなくなります。ただし、いくつかのスクリーンリーダーは、アプリケーションロールが設定されても動作に違いがありません。

いつ使い、いつ使わないべきか

role=applicationをいつ使うかを判断する際は、スクリーンリーダーのキーボードショートカットの利点とそれが失われるデメリットなども考慮してください。一般的には使用すべきではなく、使う場合はスクリーンリーダーユーザーによるユーザビリティテストを行うべきです。

標準HTMLのウィジェットだけで構成されているコントロールセットの場合や、WAI-ARIAロールでマークアップし、標準HTMLウィジェットと同じインタラクションモデルを作っている場合は、role="application"を使いません。

注意： カスタムテキスト入力ウィジェットを独自実装するのは推奨されません。こうした場合はネイティブ入力を使うのがほとんど常に最善です。

• テキストボックス（パスワード、サーチ、telなどの新しいinput typeも含む）
• textarea
• チェックボックス
• ボタン
• ラジオボタン（通常はfieldset/legendのラッパー内）
• select + option
• リンク、段落、見出し、ウェブ文書にクラシック/ネイティブな他の要素

また、下記のようなより動的かつ非ネイティブなウィジェットの場合もapplicationロールは使いません。これらについては、スクリーンリーダーや支援技術側がデフォルトでブラウズモードとフォーカスモードの切り替えをサポートします：

• ツリービュー
• スライダー
• フォーカス可能項目があり矢印キーで操作するtable（例：メール一覧など。インタラクティブグリッド、ツリーグリッドなど）
• タブリスト（tab, tablist）。左・右矢印キーでタブを切り替え（キーボードナビゲーションの実装は開発者が行う必要あり）
• dialogやalertdialog。これらには、フォーカスが内部コントロールへ移ると多くのスクリーンリーダーが暗黙的にアプリケーションモードになります。なお、うまくいかせるにはrole="dialog"要素のaria-describedby属性へダイアログの説明テキストのidを指定し、オープン時に最初のインタラクティブコントロールにフォーカスを当てるとよい：
  

  <div role="dialog" aria-label="login" aria-describedby="log1">
  <div id="log1" tabindex="-1">ログインにはユーザー名とパスワードを入力してください。</div>
  ...
  ...
  </div>

• ツールバー、ツールバーボタン、メニュー、メニューアイテムなど

role=applicationの利用は、提供するコンテンツが完全にフォーカス可能なインタラクティブコントロールだけ、しかも主にデスクトップアプリのような高度なウィジェット群で構成されている場合のみです。なお、現在は多くのものが「ウェブアプリケーション」と呼ばれていますが、実際のところその多くはFacebookの投稿やコメント、ブログ、Twitterフィード、アコーディオンUIなど、今も文書ベースの情報です。「デスクトップっぽい」見た目であってもWeb上の本体は今も文書であることがほとんどです。

フォーム（フォーカス）モードでスクリーンリーダーユーザーが操作中にUI独自のキー割り当てをサポートしたい場合も、role=applicationでなくてかまいません。たとえばカスタムコントロールでARIAのrole=listboxを使えば、ユーザーが操作している間にすべてのキー入力（矢印キーなど）を簡単に取得できます。

要するに：role=applicationを本当に使いたい場面はおそらくごくまれです！

希に役立つ場合、どこにrole=applicationをつけるべきか

ウィジェットの一番外側（たとえば親div）のような、最も近い包含要素につけてください。もし外側divが必要なウィジェットしか包んでいなければ、ユーザーがwidgetからタブ移動して外に出たとき自動的にフォーカスモードが解除されます。

ページが完全にウィジェットだけでできている場合のみbody要素に指定してください。ウィジェット中心だが一部通常の文書も含む場合、その部分の外側要素にrole=documentを付与します。これはrole=applicationの対になるもので、その中のみブラウズモードを活用させられます。また、その要素にtabindex=0を設定し、キーボードでフォーカスできるようにしてください。

目安： ページの内容が9割または95%以上ウィジェットとなる場合、role=applicationの利用が適切かもしれません。それでも、本当に知識ある人に2バージョン（role=applicationあり/なし）でテストしてもらい、モデル選択を見極めてください。

絶対にやってはいけない： ページの大部分が従来型ウィジェットやページ要素（リンク等）で、フォーカスモード操作を要しないならbody等の広範な要素にrole=applicationを指定しないでください。支援技術ユーザーにはとてつもなく不便となります。

詳しくは WAI-ARIAロール"application"の賢明な使い方 を参照。

2.12 カスタムコントロール アクセシブル開発チェックリスト：

以下の設計観点をもとにカスタムコントロールをチェックしましょう。どれか1つでも「No」なら、リリース前に修正するか、最低限課題を文書化して他の開発者に案内し、そのカスタムコントロールは一部の人にとって十分使えないことを知らせましょう。

2.13 ARIA はほとんどのHTML要素のデフォルトセマンティクスに何も追加しない

大多数のケースにおいて、ARIA roleやaria-*属性を、デフォルト暗黙的ARIAセマンティクスと一致するものとして設定するのは不要であり推奨されません。これらのプロパティはすでにブラウザによって設定されているためです。

<button role="button">press me</button>   

<input type="text" required aria-required="true">

<div hidden aria-hidden="true">

<h1 role="heading" aria-level="1">heading text</h1>

2.14 HTMLで機能として提供されないARIAロールとプロパティ

2.15 ARIAデザインパターン・タッチデバイスサポート

2.16 推奨事項表：

HTMLでARIA属性を利用するための文書適合要件テーブルは、ARIA in HTML仕様をご覧ください。

2.17 ARIAロール・ステート・プロパティ簡易リファレンス

許可されているARIAロール・ステート・プロパティテーブルは、ARIA in HTML仕様をご覧ください。