チーム向けのユーザー補助機能

チームのプロセスにユーザー補助を組み込む方法。

サイトのアクセシビリティを向上させるのは大変な作業です。ユーザー補助に初めて取り組む場合は、トピックが広範であるため、どこから手をつければよいかわからなくなるかもしれません。多様な能力に対応するには、それに応じて多様な問題を考慮する必要があります。

ユーザー補助機能はチームで取り組むものであることを覚えておいてください。すべての人に果たすべき役割があります。この記事では、各主要分野(プロジェクト マネージャー、UX デザイナー、デベロッパー)が、ユーザー補助のベスト プラクティスをプロセスに組み込むための基準について説明します。

プロジェクト マネージャー

すべてのプロジェクト マネージャーにとって最も重要な目標は、すべてのマイルストーンにユーザー補助作業を取り入れることです。パフォーマンスやユーザー エクスペリエンスなどの他のトピックと同様に、ユーザー補助作業を優先するようにします。プロセスを進める際に留意すべきチェックリスト項目を以下にいくつか示します。

  • チームがユーザー補助トレーニングを利用できるようにする。
  • サイトまたはアプリケーションにおけるクリティカル ユーザー ジャーニーを特定します。
  • チームのプロセスにユーザー補助のチェックリストを組み込みます。
  • 可能であれば、ユーザー調査によってサイトまたはアプリケーションを評価します。

ユーザー補助に関するトレーニング

ウェブ アクセシビリティの学習に役立つ無料のリソースは数多くあります。チームがトピックを学習する時間を確保しておくことで、プロセスの早い段階でユーザー補助を組み込むことができます。

Google が提供するリソースには、次のようなものがあります。

Web Accessibility by Google - 数週間にわたるインタラクティブなトレーニング コースです。

ユーザー補助の基礎 - 書面によるユーザー補助のガイドとベスト プラクティス

マテリアル ガイドライン: ユーザー補助 - インクルーシブなデザインのための UX に関するおすすめの方法。

クリティカル ユーザー ジャーニーの特定

どのアプリケーションにも、ユーザーが実行する必要のある主要なアクションがあります。たとえば、e コマースアプリを作成する場合、すべてのユーザーがショッピング カートにアイテムを追加できるようにする必要があります。

主なユーザー ジャーニー: ユーザーはショッピング カートに商品を追加できる。

アクションによっては、2 番目に重要なものがあり、まれにしか実行されないものもあります。たとえば、アバター写真の変更は便利な機能ですが、すべてのエクスペリエンスで重要というわけではありません。

アプリのプライマリ アクションとセカンダリ アクションを特定することで、ユーザー補助の取り組みに優先順位を付けることができます。後でこれらのアクションをユーザー補助チェックリストと組み合わせることで、進行状況を追跡し、回帰を回避できます。

ユーザー補助チェックリストを組み込む

ユーザー補助のトピックは非常に多岐にわたるため、検討すべき重要な領域のチェックリストを用意しておくと、すべての環境に対応できているか確認できます。

ユーザー補助のチェックリストは多数存在しますが、業界の例としては次のようなものがあります。

WebAIM WCAG チェックリスト Vox ユーザー補助ガイドライン

チェックリストが手にあれば、プライマリ アクションとセカンダリ アクションを確認して、まだ完了していない作業の優先順位付けを開始できます。このプロセスは非常に戦術的に行えます。また、プライマリ アクションとセカンダリ アクションのマトリックスを作成して、プロセスの各ステップでユーザー補助ビットの欠落の有無を判断することもできます。

行が主なユースケース、列がチェックリストの項目を含むテーブル。

ユーザー調査による評価

実際のユーザーと一緒にアプリを使用するのを観察するのが一番です。ユーザー補助機能を既存のエクスペリエンスに改良する場合、このプロセスは、改善が必要な領域をすばやく特定するのに役立ちます。また、新しいプロジェクトを開始する場合、使いにくい機能の開発に時間をかけすぎないように、初期のユーザー調査を実施できます。

可能な限り、多様なユーザー層からのフィードバックを取り入れるようにします。主にキーボードで操作しているユーザーや、スクリーン リーダーや拡大鏡などの支援技術を使用しているユーザーについて考えます。

UX デザイナー

人は自分のバイアスを使ってデザインする傾向があるため、ご自身に障がいがなく、障がいのある同僚がいない場合は、意図せず一部のユーザーだけを対象にデザインしている可能性があります。作業を進めながら、「このデザインに依存するタイプのユーザーはどのようなものになるか」を考えてみましょう。ここでは、プロセスをよりインクルーシブなものにするために試すことができる手法をいくつか紹介します。

  • コンテンツの色のコントラストが十分である。
  • タブ順序が定義されます。
  • コントロールにアクセス可能なラベルがあります。
  • UI を操作するには複数の方法があります。

コンテンツの色のコントラストが十分である

ほとんどのサイトは、文字または画像を通じてなんらかの情報をユーザーに伝えることを主な目標としています。ただし、このコンテンツのコントラストが低いと、一部のユーザー(特に視覚障がいのあるユーザー)にとって読みにくい可能性があります。これにより、ユーザー エクスペリエンスに悪影響が及ぶ可能性があります。この問題に対処するには、すべてのテキストと画像の色のコントラストが十分になるようにします。

コントラストは、前景色と背景色の輝度を比較することで測定されます。小さいテキスト(18 pt または 14 pt 未満の太字)の場合は、最小比率を 4.5:1 にすることをおすすめします。大きい文字の場合は、この比率を 3:1 に調整できます。

下の画像では、左側のテキストはコントラストの最小値を満たしていますが、右側のテキストはコントラストが低いです。

横並びのテキストのサンプル。1 つはコントラストが十分で、もう 1 つは低コントラストです。

色のコントラストを測定するためのツールは、Google の Material Color ToolLea Verou の Contrast Ratio アプリ、Deque の aXe など、数多くあります。

タブの順序を定義

タブ順序とは、ユーザーが Tab キーを押すと、要素がフォーカスを受け取る順序です。主にキーボードで移動しているユーザーの場合、Tab キーは画面上のすべての項目に移動する主な手段となります。これはマウスのカーソルのようなものです

理想的には、タブの順序は読む順序に従って、ページの上部から下部に流れ、より重要な項目が順序の上の方に現れるようにする必要があります。これにより、キーボードを使用するすべてのユーザーが、これらのアイテムにすばやくアクセスできます。

インタラクティブなコントロールが番号付きでデザインされています。

上記のモック インターフェースには、タブオーダーを示す番号が付けられています。このようなモックを作成すると、目的のタブ順序を特定できます。これをデベロッパーと QA テスターと共有し、適切に実装およびテストされていることを確認します。

コントロールにアクセス可能なラベルがあります

スクリーン リーダーなどの支援技術を使用している場合、ラベルは本来は目に見える情報のみを提供します。たとえば、単なる虫メガネアイコンの検索ボタンに、ユーザー補助機能用の「Search」というラベルを付けて、不足しているビジュアル アフォーダンスを補完できます。

ユーザー補助ラベルを設計する際のおすすめの方法は次のとおりです。

  • 簡潔にする - 長い説明を聞くのは面倒です。
  • コントロールのタイプや状態は含めないようにしてください。コントロールが正しくコーディングされていれば、スクリーン リーダーが自動的に読み上げます。
  • 行動動詞に重点を置く - 「虫メガネ」ではなく「検索」を使用します。
アクセス可能なラベルでマークされたコントロールを備えたデザイン。

すべてのコントロールにラベルを付けたモックを作成することをおすすめします。これは、実装とテストのために開発チームや QA チームと共有できます。

UI を操作して理解するための複数の方法

すべてのユーザーが主にマウスを使用してページを操作すると想定するのは簡単です。設計する際は、ユーザーが代わりにキーボードを使用してコントロールを操作する方法を考慮してください。

フォーカス状態を計画するつまり、ユーザーが Tab キーでコントロールをフォーカスしたときや、矢印キーを押したときに、コントロールをどのように表示するかを決定します。後で設計に組み込もうとするのではなく、これらの状態を早期に計画しておくと便利です。

最後に、どのインタラクション ポイントでも、ユーザーが複数の方法でコンテンツを理解できるようにする必要があります。情報を伝えるのに色だけを使用しないようにします。色覚に障がいのあるユーザーはこうした微妙なヒントを見逃す可能性があります。典型的な例が無効なテキスト フィールドです。問題を示す赤の下線だけでなく、ヘルパー テキストを追加することも検討してください。これにより、より多くのベースをカバーし、ユーザーが問題に気づく可能性を高めることができます。

デベロッパー

デベロッパーの役割では、フォーカス管理とセマンティクスを組み合わせて、堅牢なユーザー エクスペリエンスを形成します。デベロッパーがサイトやアプリケーションに取り組む際、以下の点に留意してください。

  • タブの順序は論理的です。
  • フォーカスが適切に管理され、可視化されていること。
  • インタラクティブ要素はキーボードに対応しています。
  • ARIA ロールと属性は必要に応じて適用されます。
  • 要素に適切なラベルを付けます。
  • テストは自動化されています。

論理タブの順序

inputbuttonselect などのネイティブ要素はタブオーダーに無料でオプトインされ、キーボードで自動的にフォーカスできます。ただし、すべての要素に同じ動作が発生するわけではありません。特に、divspan などの汎用要素はタブオーダーで使用されません。つまり、div を使用してインタラクティブなコントロールを作成する場合は、キーボードにアクセスできるようにするために追加の作業が必要になります。

次の 2 つのオプションがあります。

  • コントロールに tabindex="0" を割り当てます。これにより、少なくともフォーカス可能となりますが、キー操作のサポートを追加するには追加の作業が必要になることがあります。
  • ボタンのようなコントロールには、可能であれば divspan ではなく button を使用することを検討してください。ネイティブの button 要素は簡単にスタイル設定でき、キーボードを無料で利用できます。

フォーカスの管理

ページのコンテンツを変更する場合は、フォーカスを動かしてユーザーの注意を引くことが重要です。この手法が役立つ典型的な例は、モーダル ダイアログを開くときです。キーボードを使用するユーザーがボタンを押してダイアログを開き、フォーカスがダイアログ要素に移動していない場合、ユーザーは最終的に新しいコントロールを見つけるまで、サイト全体をタブで移動します。新しいコンテンツが表示され次第、そのコンテンツにフォーカスを移動することで、ユーザー エクスペリエンスの効率を向上させることができます。

インタラクティブな要素のキーボード サポート

カルーセルやプルダウンなどのカスタム コントロールを作成する場合は、キーボード サポートを追加するために追加の作業を行う必要があります。ARIA オーサリング プラクティス ガイドは、さまざまな UI パターンと、サポートが想定されるキーボード アクションの種類を特定するための便利なリソースです。

ラジオ グループの作成方法を説明する、ARIA オーサリング プラクティス ガイドからの抜粋。

要素にキーボード サポートを追加する方法について詳しくは、Google のユーザー補助の基礎に関するドキュメントのタブインデックスの移動に関するセクションをご覧ください。

ARIA ロールと属性は必要に応じて適用される

カスタム コントロールは、適切なキーボードのサポートだけでなく、適切なセマンティクスも必要です。結局のところ、div は意味的には単なる汎用のグループ化コンテナです。プルダウン メニューのベースとして div を使用している場合は、ARIA を利用して追加のセマンティクスを階層化し、制御タイプをサポート技術に伝える必要があります。ここでも、ARIA オーサリング プラクティス ガイドは、使用すべきロール、状態、プロパティを特定するのに役立ちます。さらに、ARIA ガイドの説明の多くにはサンプルコードが付属しています。

要素のラベル付け

ネイティブ入力のラベル付けには、MDN で説明されているように、組み込みの <label> 要素を使用できます。これにより、画面上の視覚的な見栄えが良くなるだけでなく、ユーザー補助ツリー内で入力にアクセス可能な名前が付けられます。この名前は支援技術(スクリーン リーダーなど)によって取得され、ユーザーに通知されます。

残念ながら <label> では、カスタム コントロール(カスタム要素を使用して作成されたものや、単純な div とスパンから作成されたものなど)にわかりやすい名前を付けることはできません。このようなコントロールには、aria-label 属性と aria-labelledby 属性を使用する必要があります。

自動テスト

とりわけテストでは、怠け者になるのは良いことです。すべてを手動で行う必要がないように、可能な限りユーザー補助機能のテストを自動化してください。一般的なユーザー補助の問題を簡単かつ迅速にチェックできる、業界向けの優れたテストツールが多数用意されています。

Deque システムによって作成された aXe は、Chrome 拡張機能Node モジュール(継続的インテグレーション環境に適しています)として利用できます。この短い A11ycast では、aXe を開発プロセスに組み込むいくつかの方法について説明します。

Lighthouse は、プログレッシブ ウェブアプリのパフォーマンスを監査するための Google のオープンソース プロジェクトです。Lighthouse では、PWA が Service Workerウェブアプリ マニフェストなどをサポートしているかどうかを確認するだけでなく、ユーザー補助の問題に関するテストなどの一連のベスト プラクティス テストも実施します。

おわりに

ユーザー補助はチームの取り組みです。誰にでも果たすべき役割があります。このガイドでは、各チームメンバーが短時間で学習を進め、アプリの全体的なエクスペリエンスを向上させるために使用できる重要な項目をいくつか紹介します。

ユーザー補助について詳しくは、無料の Udacity コースや、web.dev にあるユーザー補助に関するドキュメントをご覧ください。