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

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

物理的な構造物を建てる場合と同様に、一度に 1 つの部分を構築することが重要です。まず、基礎、構造、壁、窓、屋根など、すべてをコンポーネント ドリブンの開発ツールを使用すると、ウェブサイト、アプリ、その他のデジタル プロダクトでこの作業を行うことができます。

コンポーネント ドリブン開発のメリットには、管理可能な部分に分割できるため、再利用可能なコンポーネントの開発時間が短縮されることなどがあります。これにより、デザイナー、フロントエンド デベロッパー、バックエンド デベロッパー、QA が同時に作業できます。クライアント、デザイナー、PM などのユーザーは、ビルドプロセスをプレビューしたり、ウェブサイトのリリース後にライブスタイルガイドを参照したりできるため、この方法を好んでいます。

ただし、パターン、コンポーネント、設計システムをユーザー補助に配慮して検討すると、いくつかの疑問が生じます。ユーザー補助機能の観点から最適なパターンを判断するにはどうすればよいですか?既存のパターンやライブラリを使用するか、新しいものを作成するか。これらのパターンが実際にユーザーの役に立つのかどうかをどうやって判断すればよいでしょうか。

選択肢が豊富なため、パターン、コンポーネント、設計システムについて混乱しがちです。このモジュールでは、パターン、コンポーネント、設計システムをユーザー補助の観点から評価する方法に関する一般的な情報を提供します。また、ユーザー補助に配慮した選択を行うための出発点として活用できます。

批判的思考を持つ

アクセシブルなパターン、コンポーネント、デザイン システムを選択することは難しくありませんが、時間と批判的思考が必要です。実際、「完璧なパターン」というものはありませんが、機能するオプションは多数あります。独自の状況に最適なオプションを選択することを学ぶことです。

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

  • 既存のアクセシブルなパターン、コンポーネント、デザイン システムはありますか?
  • サポートされているブラウザと支援技術(AT)
  • コードやフレームワークに制限はありますか?他に考慮すべき統合、要因、ユーザーニーズはありますか?

開発環境やユーザーのニーズに応じて、追加の質問や、これらの質問とは異なる質問を受けることがあります。これらの質問は、アクセシビリティ評価の出発点として検討してください。

確立されたリソース

新しいものを構築する前に、デューデリジェンスを行い、アクセス可能なパターン、コンポーネント、設計システムに関して既存のものをご確認ください。少し調べてみると、ニーズに合ったソリューション(または複数のソリューション)が見つかることがあります。

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

JavaScript フレームワークの場合、次のリソースはデフォルトでアクセス可能であるか、ユーザー補助用にカスタマイズ可能です。

ただし、コードをコピーして貼り付けるだけで、それが環境に適合し、ユーザーのニーズを自動的に満たすと想定することは絶対に避けてください。これは、完全にアクセス可能とラベル付けされている場合でも、すべてのパターン、コンポーネント、デザイン システムに当てはまります。

すべてのリソースは出発点として見なす必要があります。必ずすべてをテストしてください。

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

デベロッパー環境で使用できるベースパターン、コンポーネント、または完全なデザイン システムをいくつか調べたら、支援技術のサポートに進みます。パターン、コンポーネント、設計システムを評価する際に注目すべき主要な AT の 1 つがスクリーン リーダーです。

スクリーン リーダーは特定のブラウザを念頭に作られており、これらのブラウザと組み合わせると最適に動作します。このトピックについては、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 のユーザー補助ユーザー補助のサポート、WCAG のカスタム コントロールのユーザー補助対応開発チェックリストなどの優れたリソースが、現在のブラウザと AT デバイスのサポートを理解するのに役立ちます。また、ARIA を使用するタイミングについても理解できます。

これらのリソースでは、オープンソース コミュニティ テストなど、利用可能なさまざまな HTML と ARIA パターンのサブ要素について概説しています。パソコン、モバイル ブラウザ、AT デバイスのパターン例も確認できます。そのため、これらのリソースは、使用するパターン、コンポーネント、設計システムについて、より簡単に判断するのに役立ちます。

その他の考慮事項

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

たとえば、管理システム(CMS)で作業している場合や、レガシー コードがある場合は、使用できるパターンに制限がある場合があります。確認すると、複数のパターンの選択肢が 1 ~ 2 つのオプションに絞られることがあります。

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

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

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

これらの要素はパターンの選択に影響することは間違いありませんが、コンテンツとコード自体を作成するユーザーも考慮する必要があります。選択するパターンは、エディタ生成コンテンツやユーザー作成コンテンツに関する潜在的な制限を処理できるほど堅牢で、すべてのユーザー補助に関する知識を持つデベロッパーが使用できる方法で構築されている必要があります。

理解度を確認する

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

ユーザーがアクセス可能なコンポーネントは常にアクセス可能である必要がありますか?

はい。追加の作業なしでこれらのコンポーネントを使用できます。
ユーザー補助用に作成されたリソースは、他のリソースよりも自動的に機能する可能性が高いですが、ユーザーにとってこれらのコンポーネントが機能することを確認するために、ユーザー補助テストを実施することは不可欠です。
いいえ。まずコンポーネントをテストする必要があります。
ユーザー補助向けに設計されたコンポーネントやパターンもテストする必要があります。他の既存のコンポーネントと組み合わせるとアクセスできない可能性があります。