多くの人が、開発ワークフロー プロセスで、パターン スタイルガイド、コンポーネント ライブラリ、または完全なデザイン システムを使用して、コンポーネント駆動型開発を行っています。これらのツールを正式に使用したことがない場合でも、ウェブサイト、アプリ、その他のデジタル プロダクトの大きなデザインを管理しやすい単位に分割する同様のプロセスを使用している可能性があります。
物理的な構造物を構築するのと同じように、一度に 1 つずつ構築することが重要です。 まず、基礎、構造、壁、窓、屋根、そしてその間のすべてです。コンポーネント駆動型開発ツールを使用すると、ウェブサイト、アプリ、その他のデジタル プロダクトでこれを行うことができます。
コンポーネント駆動型開発のメリットとしては、管理しやすい単位に分割できるため、再利用可能なコンポーネントを使用することで開発時間を短縮できることが挙げられます。デザイナー、フロントエンド デベロッパー、バックエンド デベロッパー、QA が同時に作業できます。また、クライアント、デザイナー、PM などは、ビルドプロセスをプレビューでき、ウェブサイトの公開後にライブ スタイルガイドを参照できるため、この方法を好んでいます。
ただし、アクセシビリティを考慮してパターン、コンポーネント、デザイン システムを見ると、いくつかの疑問が生じます。アクセシビリティに関して最適なパターンを判断するにはどうすればよいでしょうか。 確立されたパターンやライブラリを使用すべきか、それとも新しいパターンやライブラリを作成すべきでしょうか。これらのパターンが実際にユーザーの役に立つかどうかを判断するにはどうすればよいでしょうか。
選択肢が多すぎて、パターン、コンポーネント、デザイン システムについて混乱するかもしれません。このモジュールでは、アクセシビリティのためにパターン、コンポーネント、デザイン システムを評価する方法に関する一般的な情報を提供し、よりアクセシブルな選択を行うための出発点を提供します。
批判的に考える
アクセシブルなパターン、コンポーネント、デザイン システムの選択は難しいことではありませんが、時間と批判的思考が必要です。実際、「完璧なパターン」というものは存在しませんが、機能する可能性のあるオプションはたくさんあります。独自の状況に最適なオプションを選択する方法を学ぶことが重要です。
以降のテスト モジュールでは、アクセシビリティのためにパターン、コンポーネント、デザイン システムを評価する手法と方法について詳しく説明します。その前に、次のような基本的な質問を自問する必要があります。
- 確立されたアクセシブルなパターン、コンポーネント、デザイン システムはすでに存在しますか？
- サポートしているブラウザと支援技術（AT）は何ですか？
- コードやフレームワークに制限はありますか？考慮すべき他の統合、要素、ユーザー ニーズはありますか？
開発環境とユーザー ニーズによっては、これらとは異なる質問が必要になる場合があります。これらの質問をアクセシビリティ評価の出発点として考えてください。
確立されたリソース
まったく新しいものを構築する前に、デュー デリジェンスを実施し、アクセシブルなパターン、コンポーネント、デザイン システムに関してすでに存在するものを見直してください。少し調査するだけで、ニーズに合ったソリューション（または複数のソリューション）が見つかるかもしれません。
アクセシブルなパターン、コンポーネント、デザイン システムに関する優れたリソースには、次のようなものがあります。
- Accessible Components
- Deque University ARIA library
- Gov.UK Design System
- Inclusive Components
- MagentaA11y
- 米国ウェブ デザイン システム（USWDS）、 米国連邦政府向けに作成された
- Smashing Magazine のアクセシブルなパターンの一覧
JavaScript フレームワークの場合、次のリソースはデフォルトでかなりアクセシブルであるか、アクセシビリティに合わせてカスタマイズできます。
- When CSS Isn't Enough: JavaScript Requirements For Accessible Components
- React
- Angular: Material library
- Vue: Vuetensils
ただし、コードをコピーして貼り付けるだけで、環境に適合し、ユーザー ニーズを自動的に満たすと考えるべきではありません。これは、完全にアクセシブルとラベル付けされている場合でも、すべてのパターン、コンポーネント、デザイン システムに当てはまります。
すべてのリソースは出発点と見なす必要があります。必ずすべてをテストしてください。
ブラウザと支援技術（AT）のサポート
開発環境に適したベースパターン、コンポーネント、または完全なデザイン システムをいくつか調査したら、支援技術のサポートに進むことができます。パターン、コンポーネント、デザイン システムを評価する際に重視すべき AT の主なタイプは、スクリーン リーダーです。
スクリーン リーダーは特定のブラウザを念頭に置いて構築されており、これらのブラウザと組み合わせることで最適な動作を実現します。このトピックについては、AT テストのモジュールで詳しく説明しますが、パターン評価の目的では、これらの組み合わせが存在することを理解しておくと、サポートに必要な内容を把握するのに役立ちます。
| スクリーン リーダー | OS | ブラウザの互換性 | 費用 |
|---|---|---|---|
| Job Access with Speech（JAWS） | Windows | Chrome、Firefox、Edge | ライセンスが必要（40 分間の無料版あり） |
| Non-Visual Desktop Access（NVDA） | Windows | Chrome、Firefox | 無料（ダウンロードが必要） |
| ナレーター | Windows | Edge | 無料（Windows マシンに組み込み） |
| VoiceOver | macOS | Safari | 無料（macOS マシンに組み込み） |
| Orca | Linux | Firefox | 無料（Gnome ベースのディストリビューションに組み込み） |
| TalkBack | Android | Chrome、Firefox | 無料（特定のバージョンの Android OS に組み込み） |
| VoiceOver | iOS | Safari | 無料（iOS デバイスに組み込み） |
ブラウザのサポートは一般的に複雑であり、AT デバイスと ARIA 仕様を追加するとさらに複雑になります。
ただし、悪いことばかりではありません。幸いなことに、 HTML5 Accessibility、 Accessibility Support、WCAG の Custom Control Accessible Development Checklist などの優れたリソースを使用すると、現在のブラウザと AT デバイスのサポートについて理解を深めることができます。また、 ARIA をいつ使用すべきかについても理解を深めることができます。
これらのリソースでは、オープンソース コミュニティ テストなど、利用可能なさまざまな HTML および ARIA パターンのサブ要素について説明しています。パソコン、モバイル ブラウザ、AT デバイスのパターン例を確認することもできます。そのため、これらのリソースは、使用するパターン、コンポーネント、デザイン システムに関して、よりアクセシブルな決定を行うのに役立ちます。
その他の考慮事項
アクセシブルなベースパターンまたはコンポーネントをいくつか選択し、ブラウザと AT デバイスのサポートを考慮したら、パターン、コンポーネント、デザイン システム、開発環境に関するより具体的なコンテキスト上の質問に進むことができます。
たとえば、管理システム（CMS）で作業している場合や、レガシー コードがある場合は、使用できるパターンに制限がある可能性があります。確認すると、いくつかのパターンの選択肢がすぐに 1 つまたは 2 つのオプションに絞られることがあります。
多くの JavaScript フレームワークでは、デベロッパーは任意のパターンを使用できます。このような場合は、制限が少なく、最もアクセシブルなパターン オプションを選択できます。
パターン、コンポーネント、デザイン システムを選択する際には、次のような追加の考慮事項があります。
- パフォーマンス
- セキュリティ
- 検索エンジン最適化
- 言語翻訳のサポート
- サードパーティとの連携
これらの要素はパターンの選択に影響しますが、コンテンツとコード自体を作成するユーザーも考慮する必要があります。選択するパターンは、エディタで生成されたコンテンツやユーザー作成コンテンツに関する潜在的な制限に対処できるほど堅牢である必要があります。また、アクセシビリティに関する知識を持つすべてのデベロッパーが使用できるように構築する必要があります。