パターン、コンポーネント、デザイン システム

多くのユーザーは、開発ワークフロー プロセスでパターン スタイルガイド、コンポーネント ライブラリ、または完全なデザイン システムを使用したコンポーネント ドリブン開発を使用しています。これらのツールを正式に使用していない場合でも、同様のプロセスを使用して、ウェブサイトやアプリ、その他のデジタル プロダクト用の大規模なデザインを管理しやすいように分割していることがよくあります。

物理的な構造物を構築する場合と同様に、1 つずつ構築することが重要です。1 つ目は基礎、構造、壁、 窓、屋根 その他すべてですコンポーネント駆動型の開発ツールにより、ウェブサイト、アプリ、その他のデジタル プロダクトでこれを実現しています。

コンポーネント主導の開発には、管理しやすい要素に分割できるため、再利用可能なコンポーネントを使用して開発時間を短縮できるという利点があります。デザイナー、フロントエンドとバックエンドのデベロッパー、QA が同時に作業できます。クライアント、デザイナー、PM などにとっては、ウェブサイトのリリース後にビルドプロセスをプレビューして、ライフスタイル ガイドを参考として使用できるためです。

しかし、アクセシビリティを念頭に置いてパターン、コンポーネント、デザイン システムについて検討すると、いくつかの疑問が生じます。ユーザー補助において最適なパターンを見つけるにはどうすればよいでしょうか。確立されたパターン / ライブラリを使用するか、新しいパターン / ライブラリを作成するかこれらのパターンが実際にユーザーに役立つかどうかを確認するには、どうすればよいでしょうか。

選択肢が無数にあるため、このトピックについてすぐに混乱しがちです。このモジュールの目的は、ユーザー補助のパターン、コンポーネント、デザイン システムを評価する方法に関する一般的な情報を提供することで、より利用しやすい選択を行うための出発点となります。

批判的思考を持つ

利用しやすいパターン、コンポーネント、デザイン システムの選択は、科学に即したものではありませんが、時間と批判的思考が必要です。実際、「1 つの完璧なパターン」などというものはありませんが、有効な選択肢は多数ある可能性があります。それは個々の状況に最適なオプションを選択することを学習することです。

以降のテスト モジュールでは、ユーザー補助のパターン、コンポーネント、デザイン システムを評価する手法と手法について詳しく説明します。しかし、そのステージを始める前に、次のような基本的な質問を自問する必要があります。

  • 確立されたアクセスしやすいパターン、コンポーネント、デザイン システムはすでに存在するか。
  • どのブラウザと支援技術(AT)に対応していますか?
  • 考慮しなければならないコードやフレームワークの制限、その他の統合 / 要素 / ユーザーのニーズはありますか?

開発環境やユーザーのニーズに応じて、これらの質問に対する追加の質問や異なる質問になる場合があります。ユーザー補助機能を評価する際の出発点として、以下の質問を検討してください。

リソースの確立

新しいものを構築する前に、デュー デリジェンスを行い、アクセス可能なパターン、コンポーネント、デザイン システムに関してすでに存在するものを確認します。ほんの少し調べただけで、お客様のニーズに合うソリューション(または複数のソリューション)が見つかることに驚くかもしれません。

利用できるパターン、コンポーネント、デザイン システムに関する優れたリソースには、次のようなものがあります。

JavaScript フレームワークの場合、次のリソースはすぐに利用できます。また、ユーザー補助のために簡単にカスタマイズすることもできます。

ただし、コードをコピーして貼り付けるだけでは環境内に収まり、ユーザーのニーズを自動的に満たすと仮定すべきではありません。これは十分に強調できません。これは、完全にアクセスできるとラベル付けされていても、すべてのパターン、コンポーネント、デザイン システムに当てはまります。

すべてのリソースを出発点と考えてください。あらゆる要素をテストするようにしてください。

ブラウザと支援技術(AT)のサポート

開発環境で機能しそうないくつかの基本パターン、コンポーネント、完全なデザイン システムを調査したら、支援技術のサポートに進むことができます。パターン、コンポーネント、設計システムを評価する際に重視する AT の主要なタイプの一つは、スクリーン リーダーです。

スクリーン リーダーは特定のブラウザを想定して開発されており、これらのブラウザと組み合わせると最適に動作します。このトピックについては、AT テストのモジュールで詳しく説明しますが、パターン評価の際には、これらの組み合わせが存在することを理解しておくと、サポートに関して必要なものを把握しやすくなります。

スクリーン リーダー OS ブラウザの互換性 費用
Speech によるジョブアクセス(JAWS) ウィンドウ Chrome、Firefox、Edge ライセンスが必要(40 分間の無料バージョンあり)
非ビジュアル デスクトップ アクセス(NVDA) ウィンドウ Chrome と Firefox 無料(ダウンロードが必要)
ナレーター ウィンドウ エッジ 無料(Windows マシンに組み込み)
VoiceOver macOS Safari 無料(macOS マシンに組み込み)
オルカ Linux Firefox 無料(Gnome ベースのディストリビューションに組み込まれています)
TalkBack Android Chrome と Firefox 無料(特定のバージョンの Android OS に組み込まれている)
VoiceOver iOS Safari 無料(iOS デバイスに搭載)

ブラウザ サポートは一般的に複雑なため、AT デバイスと ARIA 仕様を組み合わせると、さらに難しくなります。

でも、悪いニュースだけではありません。幸い、HTML5 ユーザー補助ユーザー補助サポート、WCAG のカスタム コントロールのユーザー補助開発チェックリストなどの優れたリソースを活用することで、現在のブラウザと AT デバイスのサポートについて理解を深めることができ、ARIA をどのような場合に使用すべきかについて理解を深めることができます。

以下のリソースでは、オープンソースのコミュニティ テストなど、利用可能なさまざまな HTML および ARIA パターンのサブ要素の概要について説明しています。 パソコンとモバイル ブラウザ/AT デバイス向けのパターンの例もご覧いただけます。そのため、これらのリソースは、使用するパターン、コンポーネント、デザイン システムに関して、よりアクセスしやすい決定を行うのに役立ちます。

その他の考慮事項

アクセス可能な基本パターンまたはコンポーネントをいくつか選択し、ブラウザと AT デバイスのサポートを考慮すると、パターン、コンポーネント、デザイン システム、開発環境に関する、より具体的なコンテキストの質問に進むことができます。

たとえば、管理システム(CMS)で作業している場合や、以前のコードを使用している場合、使用できるパターンにいくつかの制限があります。レビューすると、複数のパターンの選択肢がすぐに 1 つか 2 つの選択肢に分けられます。

多くの JavaScript フレームワークでは、デベロッパーはほぼすべてのパターンを自由に選択して使用できます。このような場合は、制限が少なくなり、最もアクセスしやすいパターン オプションを選択できます。

パターン、コンポーネント、デザイン システムを選択する際には、他にも次のような考慮事項があります。

  • パフォーマンス
  • セキュリティ
  • 検索エンジン最適化(SEO)
  • 言語翻訳サポート
  • サードパーティとの連携

間違いなく、これらの要素がパターンの選択に影響しますが、コンテンツとコードを作成する担当者も考慮する必要があります。選択するパターンは、エディタが生成したコンテンツやユーザー作成コンテンツに関する潜在的な制限に対応できる堅牢さを備え、ユーザー補助のあらゆる知識を持つデベロッパーが使いやすいように構築する必要があります。

理解度チェック

パターンに関する知識をテストする

アクセス可能なコンポーネントは常にユーザーがアクセスできるか?

はい、追加の作業なしでこれらのコンポーネントを使用できます。
ユーザー補助機能を考慮して作成されたリソースは、他のリソースよりも自動的に動作することが多くなりますが、それでもなお、ユーザー補助機能のテストを実行して、これらのコンポーネントがユーザーに対して機能していることを確認することは不可欠です。
いいえ。最初にコンポーネントをテストする必要があります。
アクセシビリティを考慮して設計されたコンポーネントやパターンもテストする必要があります。他の既存のコンポーネントと組み合わせるとアクセスできない可能性があります。