ほとんどのデベロッパーは、最新のウェブの標準マークアップ言語である ハイパーテキスト マークアップ言語（HTML）に精通しています。ただし、Accessible Rich Internet Applications（ARIA）（正式名称は WAI-ARIA）については、その概要、使用方法、使用するタイミング、使用しないタイミングなど、あまり詳しくないかもしれません。
HTML と ARIA は、デジタル プロダクトのアクセシビリティを高めるうえで重要な役割を果たします。特に、スクリーン リーダーなどの支援技術（AT）を使用する際には重要です。どちらも、コンテンツを点字やテキスト読み上げ（TTS）などの代替形式に変換するために使用されます。
ARIA の簡単な歴史、重要性、最適な使用方法とタイミングを確認します。
ARIA の概要
ARIA は、インターネットを統治し規制する包括的な World Wide Web Consortium（W3C）のサブセットである Web Accessibility Initiative（WAI）グループによって 2008 年に初めて開発されました。
ARIA は、真のプログラミング言語ではなく、HTML 要素に追加してアクセシビリティを高めることができる属性のセットです。これらの属性は、最新のブラウザにあるアクセシビリティ API を使用して、役割、状態、プロパティを支援技術に伝えます。この通信はユーザー補助ツリーを介して行われます。
「WAI-ARIA（Accessible Rich Internet Applications Suite）は、障がいのあるユーザーがウェブ コンテンツやウェブ アプリケーションを利用しやすくなる方法を定義しています。特に、HTML、JavaScript、関連技術で開発された動的コンテンツや高度なユーザー インターフェース コントロールに役立ちます。」
WAI グループ
ユーザー補助ツリー
ARIA は、アクセシビリティ ツリーの一部を変更、公開、拡張することで、AT を使用するユーザーの利便性を高めるために、誤ったコードや不完全なコードを修正します。
アクセシビリティ ツリーはブラウザによって作成され、標準のドキュメント オブジェクト モデル（DOM）ツリーに基づいています。DOM ツリーと同様に、アクセシビリティ ツリーには、すべてのマークアップ要素、属性、テキストノードを表すオブジェクトが含まれています。アクセシビリティ ツリーは、プラットフォーム固有のアクセシビリティ API が支援技術で理解できる表現を提供するためにも使用されます。
ARIA 単体では、要素の機能や外観は変更されません。つまり、ARIA があるデジタル プロダクトとないデジタル プロダクトの違いに気づくのは、AT ユーザーだけです。つまり、要素を可能な限りアクセシブルにするために適切なコードとスタイルの変更を行う責任は、デベロッパーのみが負うことになります。
ARIA の主な機能は、ロール、プロパティ、状態/値の 3 つです。
役割は、ページやアプリの要素が何であるか、または何をするかを定義します。
<div role="button">Self-destruct</div>
プロパティは、オブジェクトの特性や関係を表します。
<div role="button" aria-describedby="more-info">Self-destruct</div>
<div id="more-info">This page will self-destruct in 10 seconds.</div>
状態と値は、要素に関連付けられた現在の条件またはデータ値を定義します。
<div role="button" aria-describedby="more-info" aria-pressed="false">
Self-destruct
</div>
<div id="more-info">
This page will self-destruct in 10 seconds.
</div>
ARIA の 3 つの要素はすべて 1 行のコードで使用できますが、必須ではありません。代わりに、最終的なユーザー補助の目標を達成するまで、ARIA のロール、プロパティ、状態、値を重ねていきます。ARIA をコードベースに正しく組み込むことで、AT ユーザーはウェブサイト、アプリ、その他のデジタル プロダクトを成功裏に、かつ公平に利用するために必要なすべての情報を得ることができます。
最近、Chrome DevTools では、アクセシビリティ ツリー全体を表示する方法が作成され、デベロッパーがコードがアクセシビリティに与える影響を簡単に把握できるようになりました。
ARIA を使用する場面
2014 年には、W3C が HTML5 の推奨事項を正式に公開しました。このバージョンでは、<main>、<header>、<footer>、<aside>、<nav> などのランドマーク要素や、hidden、required などの属性が追加されるなど、大きな変更がいくつかありました。これらの新しい HTML5 要素と属性、およびブラウザのサポートの拡大により、ARIA の一部の重要性が低下しました。
ブラウザが ARIA と同等の暗黙的なロールを持つ HTML タグをサポートしている場合、通常は要素に ARIA を追加する必要はありません。ただし、ARIA には、HTML のどのバージョンでも利用できないロール、状態、プロパティがまだ多く含まれています。これらの属性は、現時点では引き続き有用です。
ここで、最終的な疑問が生じます。ARIA はいつ使用すべきでしょうか？幸いなことに、WAI グループは要素をアクセシブルにする方法を判断するのに役立つ ARIA の 5 つのルールを開発しました。
ルール 1: ARIA を使用しない
そのとおりです。要素に ARIA を追加しても、要素のアクセシビリティが本質的に向上するわけではありません。WebAIM Million の年次アクセシビリティ レポートによると、ARIA が存在するホームページでは、ARIA が存在しないホームページよりも検出されたエラーが平均 70% 多く、これは主に ARIA 属性の不適切な実装が原因です。
このルールには例外があります。HTML 要素がユーザー補助機能をサポートしていない場合は、ARIA が必要です。これは、特定の HTML 要素がデザインで許可されていない、または必要な機能や動作が HTML で利用できないことが原因である可能性があります。ただし、このような状況はまれにしか起こりません。
しないこと: ロールを割り当てない。
<a role="button">Submit</a>
推奨: セマンティック要素を使用します。
<button>Submit</button>
迷った場合は、セマンティック HTML 要素を使用してください。
ルール 2: HTML に（不要な）ARIA を追加しない
ほとんどの場合、HTML 要素はそのまま使用でき、追加の ARIA を追加する必要はありません。実際、ARIA を使用するデベロッパーは、インタラクティブな要素の場合に要素を機能させるために、追加のコードを追加しなければならないことがよくあります。
避けるべきこと: 誤解を招くロールを割り当てる。
<h2 role="tab">Heading tab</h2>
推奨: ロールを正しく割り当てます。
<div role="tab"><h2>Heading tab</h2></div>
HTML 要素を意図したとおりに使用すると、作業量が減り、コードのパフォーマンスが向上します。
ルール 3: キーボード ナビゲーションを常にサポートする
インタラクティブ（無効になっていない）なすべての ARIA コントロールは、キーボードでアクセスできる必要があります。通常はキーボード フォーカスを受け取らない要素にフォーカスが必要な場合は、その要素に tabindex= "0" を追加できます。キーボード フォーカスの順序に関する問題が発生する可能性を回避するため、可能な限り正の整数でタブ インデックスを使用することは避けてください。
しないこと: tabindex を追加します。
<span role="button" tabindex="1">Submit</span>
対応: tabindex を `0` に設定します。
<span role="button" tabindex="0">Submit</span>
もちろん、可能であれば、この場合は実際の <button> 要素を使用してください。
ルール 4: フォーカス可能な要素を非表示にしない
フォーカスが必要な要素（tabindex= "0" を含む要素など）に role= "presentation" や aria-hidden= "true" を追加しないでください。これらのロールと状態を要素に追加すると、これらの要素は重要ではないためスキップするように AT にメッセージが送信されます。これにより、ユーザーが要素を操作しようとしたときに混乱が生じたり、操作が中断されたりする可能性があります。
しない: フォーカス可能な要素を非表示にする
<div aria-hidden="true"> <button>Submit</button> </div>
行う: フォーカス可能な要素を公開する
<div> <button>Submit</button> </div>
ルール 5: インタラクティブ要素にアクセス可能な名前を使用する
インタラクティブな要素の目的は、ユーザーがその要素を操作する方法を知る前に伝達される必要があります。AT デバイスを使用するユーザーのために、すべての要素にユーザー補助機能用の名前があることを確認します。
アクセス可能な名前は、要素で囲まれたコンテンツ（<a> の場合）、代替テキスト、ラベルのいずれかです。
次の各コードサンプルのユーザー補助機能用の名前は「Red leather boots」です。
<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>
<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>
<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>
要素のユーザー補助機能用の名前を確認する方法はたくさんあります。たとえば、Chrome DevTools を使用してユーザー補助機能ツリーを検査したり、スクリーン リーダーでテストしたりする方法があります。
HTML での ARIA
HTML 要素を単独で使用することがベスト プラクティスですが、特定の状況では ARIA 要素を追加できます。たとえば、環境上の制約により AT のサポート レベルを上げる必要があるパターンで ARIA を HTML と組み合わせたり、すべてのブラウザで完全にサポートされていない HTML 要素のフォールバック メソッドとして使用したりすることがあります。
もちろん、HTML で ARIA を実装するための推奨事項もあります。最も重要なことは、デフォルトの HTML ロールをオーバーライドしないこと、冗長性を減らすこと、意図しない副作用に注意することです。
例をいくつか見てみましょう。
禁止事項: 誤ったロールを割り当てないでください。
<a role="heading">Read more</a>
推奨: 正しいロールと追加のリンクの説明を使用します。
<a aria-label="Read more about some awesome article title">Read More</a>
禁止事項: 冗長なロールを追加しないでください。
<ul role="list">...</ul>
推奨: 冗長性を減らします。
<ul>...</ul>
しないこと: 潜在的な副作用を見逃す。
<details> <summary role="button">more information</summary> ... </details>
行う: 副作用に対処します。
<details> <summary>more information</summary> ... </details>
ARIA の複雑さ
ARIA は複雑であるため、使用する際は常に注意が必要です。このレッスンで紹介するコード例はかなり単純ですが、アクセシビリティに配慮したカスタム パターンを作成するのは、すぐに複雑になる可能性があります。
キーボード操作、タッチ インターフェース、AT/ブラウザのサポート、翻訳の必要性、環境上の制約、レガシー コード、ユーザー設定など、注意すべき点は数多くあります。コーディングの知識が少しあると、誤った使い方をした場合に有害になったり、単に迷惑になったりする可能性があります。
このような警告はありますが、デジタル アクセシビリティは全か無かの状況ではなく、このようなグレーゾーンを許容するスペクトルです。状況によっては、複数のコーディング ソリューションが「正しい」と見なされることがあります。重要なのは、学び続け、テストし続け、すべての人が利用しやすいデジタル世界を構築しようと努力し続けることです。