アクセシブルなコンポーネントの記述

学習の目的

この単元を完了すると、次のことができるようになります。

Lightning コンポーネントフレームワークに含まれるコンポーネントセットを特定する。
アクセシビリティ対応のコンポーネントを作成する手順を示す。
カスタム Web コンポーネントを作成する手順を示す。

はじめに

Lightning コンポーネントフレームワークには、完全に機能するコンポーネントセットが含まれています。そのすべてが、関連するアクセシビリティガイドラインに従った最新の SLDS コンポーネントブループリントに基づいています。可能な限り、これらの既存のコンポーネントを使用すれば、アクセシビリティが検証済みなので、多くの余分な作業を省くことができます。これらのコンポーネントについては、「Component Reference (コンポーネントリファレンス)」を参照してください。

コンポーネントの使用

「Component Reference (コンポーネントリファレンス)」には、Aura コンポーネントと Lightning Web コンポーネントの 2 種類のコンポーネントセットに関する情報が含まれています。リストされている Aura コンポーネントは多数の異なる名前空間に分類されます。ui 名前空間と force 名前空間のコンポーネントは古い ARIA 仕様を満たすように開発されたため、アクセシビリティが最も高いコンポーネントではなくなっています。

Lightning Web コンポーネント (LWC) は、Salesforce で UI を構築する場合に推奨される方法です。「Aura から Lightning Web コンポーネントへの移行」モジュールにアクセスして、LWC の使用方法を学習し、現在の Web 標準に準拠してください。Aura の詳しい情報が必要な場合は、『Lightning Aura コンポーネント開発者ガイド』または Aura コンポーネントのドキュメントを参照してください。

lightning- プレフィックスが付いた Lightning Web コンポーネントは、最新の ARIA 標準に対して記述され、最新の SLDS コンポーネントブループリントに従っています。可能な限り、旧式のコンポーネントではなく、このコンポーネントを使用してください。

Lightning コンポーネントを使用するときにも、アクセシビリティを念頭に置く必要があります。たとえば、<lightning-icon> を使用して情報アイコンを配置する場合でも、ユーザーにアイコンの目的がわかるように、適切な alternative-text 値を指定する必要があります。<lightning-input> を使用するときにも、label を指定して、プログラムによって結果の <input> を <label> に関連付ける必要があります。required="true" を設定すると、アクセシビリティに対応した方法で入力が必須になります。

[Input label (入力表示ラベル)] と、「This field is required (この項目は必須です)」というエラーメッセージが表示されたプレースホルダーテキスト。

多くの Lightning コンポーネントには ARIA プロパティを設定する属性もあります。これらの属性はアクセシビリティに必須ではないこともありますが、これらの値を設定する必要がある場合のために含まれています。

コンポーネントの作成

必要なコンポーネントがコンポーネントリファレンスになければ、独自の Lightning コンポーネントを作成する必要も出てくるでしょう。その場合は、アクセシビリティに対応するために次の手順に従ってください。

必ず、SLDS コンポーネントブループリントから始めます。マークアップと ARIA のロール、状態、プロパティを慎重に調べます。必須の属性と、ユーザーがコンポーネントを操作したときに変化する属性に注意します。
キーボード操作を実装します。ARIA ロールはユーザーに対する約束です。この約束には、指定したロールに対してユーザーが期待するキーボード機能を提供することが含まれます。コンポーネントブループリントには、キーボードナビゲーションの手順が含まれています。

ヒント: Tab キー押下イベントをリスンせず、フォーカスをリスンするようにします。スクリーンリーダーのユーザーがページの移動に Tab キーを使用することはほとんどありません。

ユーザーフォーカスを管理します。『Global Focus Guideline (グローバルフォーカスガイドライン)』に従って、インタラクティブ要素がフォーカス可能になるようにします。
オートメーションを記述し、コンポーネントを手動でテストします。
1. キーボード操作をテストするインテグレーションテストを記述します。キーボード操作をテストする唯一の信頼できる方法は実際のブラウザーを使用することです。手動の DOM 検査によって不具合を見つけようとしないでください。マークアップが正確であることを確認するテストを記述します。次のことなどを確認します。
  - 正しいセマンティックが正しいノードに設定されていること。
  - 正しい属性が正しいノードに設定されていること。
  - コンポーネントのライフサイクル中に正しい属性値が更新されること。
2. SLDS 仕様に従って、キーボードのみを使用してエンドツーエンド機能テストを手動で実行します。すべてキーボードで実行できることを確認します。

Web Components

Web Components は Web 用の標準コンポーネントモデルを提供するブラウザー機能です。このモデルは、異なる場所にある複数の要素で構成されます。構成要素は shadow DOM、カスタム要素、HTML テンプレート、CSS 変更です (出典)。実際には、Web Components にはルートとしてカスタム要素があります。これらのカスタム要素にはセマンティックな値はありませんが、支援技術にとって直系子孫の問題の原因となる場合があります。

直系子孫の問題

順序なしリスト <ul> を作成し、Web コンポーネントリスト項目 <lightning-example-list-item> を含めると、マークアップは次のようになります。

<ul>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
</ul>

ただしこれはアクセシビリティに対応していません。<ul> のすべての子は <li> 要素である必要があるためです。スクリーンリーダーは、これが 3 つの項目からなるリストであると認識できません。ここではセマンティック要素よりも ARIA ロールを使用する方が適しています。

<ul> の代わりに、role="list" を指定した別の Web コンポーネントを使用できます。その場合、リスト項目 Web コンポーネントには role="listitem" が必要で、<li> 要素は使用しません。下のコードを使用することで、スクリーンリーダーはこれを 3 つの項目からなるリストとして正しく識別できます。

<lightning-example-list>
<div role="list">
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item”>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
</div>
</lightning-example-list>

グローバル HTML 属性

内部要素の属性を設定するためにグローバル HTML 属性を使用しないでください。Lightning Web コンポーネントを使用してホスト上でグローバル HTML 属性を設定すると、フレームワークでは、それを渡す場合でもホスト上に設定すると想定されます。たとえば、入力 Web コンポーネントで子の属性を設定する API として aria-describedby 属性を使用すると、誤って 2 回設定することになります。

<lightning-example-input aria-describedby="foo">

これは次のように表示されます。

<lightning-example-input aria-describedby="foo">
  <input aria-describedby="foo" />
</lightning-example-input>

その代わりに、次のように Web コンポーネントの API 名をキャメルケースにします。

<lightning-example-input ariaDescribedby="foo">

これは適切に表示されます。

<lightning-example-input>
  <input aria-describedby="foo" />
</lightning-example-input>

キャメルケースの使用など、プロパティ名と属性名に関する詳細は、「リソース」セクションを確認してください。

Shadow DOM

Web Components で Shadow DOM が有効になっている場合は、また別のアクセシビリティに関する問題が発生します。Web アクセシビリティの多くの側面は、コンポーネント ID 参照がページ上の別の要素にリンクされていることに依存しています。その簡単な例は、フォーム入力のラベル付けです。

<label for="foo">First Name</label>
<input type="text" id="foo" />

上記の例では、ID "foo" によって表示ラベル「First Name」がテキスト入力に関連付けられます。その後、Shadow DOM のために表示ラベルと入力が別の Web コンポーネントに配置されると、ブラウザーのアクセシビリティツリー内にこのリレーションは存在しなくなります。

<lightning-example-label>
     <label for="foo">First Name</label>
</lightning-example-label>
<lightning-example-input>
     <input type="text" id="foo" />
</lightning-example-input>

この場合、表示ラベルと入力の関連付けがなくなり、フォームのアクセシビリティが失われます。ここでの解決策は、ID 参照関係が必要な場合に要素を異なるカスタム要素に分割しないことです。

<lightning-example-input>
     <label for="foo">First Name</label>
     <input type="text" id="foo">
</lightning-example-input>

独自のカスタム Web コンポーネントを作成するときには、SLDS ブループリントと ARIA 設計仕様を調べます。ID 参照に依存する HTML プロパティと ARIA プロパティを特定し、それらの要素を別個のシャドウルートに分割しないようにします。

W3C の 1 つのグループが Accessibility Object Model を開発中です。これは、HTML 属性と ID 参照に依存せずにロールとプロパティを割り当て、状態を更新し、リレーションを作成する手法です。このモデルはまだドラフト状態ですが、ブラウザー、支援技術、開発コミュニティによって採用されれば、Web コンポーネントのアクセシビリティをより詳細に制御できるようになります。

まとめ

ここでは、アクセシビリティ対応ユーザーインターフェースの作成の基本を学習しました。アクセシビリティのための設計とテストを開始する準備ができたときには、Trailhead でさらに多くのリソースを参照してください。また、Salesforce Trailblazer Community からシステム管理者や開発者の大規模なコミュニティに参加すれば、アイデアを交換したり、グループに参加したり、サクセスストーリーを読むことができます。

リソース

ドキュメント: W3C Standards and Drafts (W3C 標準とドラフト)
Salesforce 開発者リファレンス: Lightning Web Components (Lightning Web コンポーネント)
Salesforce 開発者リファレンス: プロパティ名と属性名
ドキュメント: Accessibility Object Model
Salesforce ヘルプ: Component Blueprints (コンポーネントブループリント)
ドキュメント: W3C Web Components Specifications (W3C Web Components の仕様)