ほとんどのデベロッパーは、最新のウェブの標準マークアップ言語であるハイパーテキスト マークアップ言語(HTML)を使い慣れています。ただし、Accessible Rich Internet Applications(ARIA)(旧称 WAI-ARIA)については、ARIA とは何か、どのように使用するのか、いつどのような状況で使用するのかについてはあまり馴染みがないかもしれません。
HTML と ARIA は、特にスクリーン リーダーなどの支援技術(AT)において、デジタル プロダクトを利用しやすくするうえで重要な役割を果たします。どちらも、点字やテキスト読み上げ(TTS)などの代替形式に変換するために使用されます。
ARIA の歴史について簡単に振り返り、ARIA が重要な理由、最適な使い方とタイミングを確認しましょう。
ARIA の概要
ARIA は、インターネットを管理および規制する包括的な World Wide Web Consortium(W3C)のサブセットである Web Accessibility Initiative(WAI)グループによって 2008 年に初めて開発されました。
ARIA は真のプログラミング言語ではありませんが、HTML 要素に追加することでアクセシビリティを高めることができる属性のセットです。これらの属性は、最新のブラウザに搭載されているユーザー補助 API を介して支援技術に役割、状態、プロパティを伝えます。この伝達はユーザー補助ツリーを介して行われます。
Accessible Rich Internet Applications Suite の WAI-ARIA は、障がいのあるユーザーがウェブ コンテンツやウェブ アプリケーションを利用しやすくする方法を定義しています。特に、HTML、JavaScript、および関連技術を使用して開発された動的コンテンツや高度なユーザー インターフェース コントロールに役立ちます。」
WAI グループ
ユーザー補助ツリー
ARIA は、ユーザー補助ツリーの一部を変更、公開、拡張することで、誤ったコードや不完全なコードを修正し、AT を使用するユーザーの利便性を高めます。
ユーザー補助ツリーは、標準のドキュメント オブジェクト モデル(DOM)ツリーに基づいてブラウザによって作成されます。DOM ツリーと同様に、ユーザー補助ツリーには、すべてのマークアップ要素、属性、テキストノードを表すオブジェクトが含まれます。ユーザー補助ツリーは、支援技術が理解できる表現を提供するために、プラットフォーム固有のユーザー補助 API でも使用されます。
ARIA 自体は要素の機能や外観を変更しません。つまり、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 を実装していないホームページよりも、主に ARIA 属性の不適切な実装により検出されたエラーが平均 70% 多いことが判明しています。
このルールには例外があります。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" を追加できます。キーボードのフォーカスの順序に関する潜在的な問題を防ぐため、可能な限り正の整数でタブ インデックスを使用することは避けてください。
<span role="button" tabindex="1">Submit</span>
<span role="button" tabindex="0">Submit</span>
ルール 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/ブラウザのサポート、変換ニーズ、環境の制約、レガシーコード、ユーザー設定など、注意すべき点は数多くあります。コーディングに関する多少の知識は、誤って使用すると、デメリットとなるだけでなく、単に煩わしいものです。コードをシンプルにしておくことを忘れないでください。
これらの警告はさておき、デジタル アクセシビリティはオール オア ナッシング(オール オア ナッシング)という状況ではなく、このようなグレーの領域を許容する範囲です。状況によっては、複数のコーディング ソリューションが「正しい」と考えることができます。大切なのは、学習とテストを行い、すべての人に開かれたデジタル世界にするために努力し続けることです。
理解度チェック
ARIA と HTML に関する知識の確認
アクセス可能なボタンを作成するためのおすすめの方法は次のうちどれですか。
<div id="saveChanges" aria-role="button" aria-pressed="false" tabindex="0">Go to shop</div>
<a id="saveChanges" aria-label="Some awesome article title">Go to shop</a>
<button id="saveChanges" type="button">Go to shop</button>