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

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

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

ユーザー補助はチームで取り組むべきものであることを忘れないでください。すべての人に役割があります。この記事では、主要な分野(プロジェクト マネージャー、UX デザイナー、デベロッパー)ごとに基準を概説し、各分野がアクセシビリティのベスト プラクティスをプロセスに組み込むための作業を進めることができるようにします。

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

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

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

ユーザー補助機能のトレーニング

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

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

Google のウェブ アクセシビリティ - 複数週間にわたるインタラクティブなトレーニング コース。

ユーザー補助の基礎 - ユーザー補助に関するガイドとベスト プラクティス。

マテリアル ガイドライン: ユーザー補助 - 包括的な設計に関する UX のベスト プラクティスのセット。

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

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

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

一部のアクションは重要度が低く、たまにしか実行されない場合があります。たとえば、アバター写真の変更は便利な機能ですが、すべてのエクスペリエンスで重要とは限りません。

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

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

ユーザー補助のトピックは非常に広範にわたるため、検討すべき重要な領域のチェックリストを用意しておくと、すべてのベースをカバーできます。

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

WebAIM WCAG チェックリスト Vox アクセシビリティ ガイドライン

チェックリストを手元に用意して、主なアクションと副次的なアクションを確認しながら、まだ行う必要がある作業を優先順位付けします。このプロセスを戦術的に進め、プライマリ アクションとセカンダリ アクションのマトリックスを作成して、それらのプロセスの各ステップで、不足しているユーザー補助ビットがあるかどうかを判断することもできます。

主なユースケースが行に、チェックリスト項目が列に表示された表。

ユーザー調査による評価

実際のユーザーに座ってもらい、アプリの使用を試してもらうのが一番です。既存のエクスペリエンスにユーザー補助機能を後付けする場合は、このプロセスで改善が必要な部分をすばやく特定できます。新しいプロジェクトを開始する場合は、早い段階でユーザー調査を行うと、使いにくい機能を開発するのに時間をかけすぎないようにできます。

できるだけ多様なユーザー層からのフィードバックを組み込むことを目指します。主にキーボードで操作するユーザーや、スクリーン リーダーや画面拡大などの支援技術に依存するユーザーを考慮してください。

UX デザイナー

人は自分のバイアスを使って設計する傾向があるため、障がいがなく、障がいのある同僚もいない場合は、意図せず一部のユーザーのみを対象に設計している可能性があります。作業中は、「このデザインを利用する可能性があるユーザーの種類はすべて何ですか?」と自問してください。プロセスをより包括的なものにする方法をいくつかご紹介します。

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

コンテンツの色のコントラストが良好である

ほとんどのサイトの主な目的は、テキストや画像でユーザーに情報を提供することです。ただし、このコンテンツのコントラストが低いと、一部のユーザー(特に視覚障がいのあるユーザー)が読みづらい場合があります。これにより、ユーザー エクスペリエンスに悪影響が及ぶ可能性があります。この懸念に対処するには、すべてのテキストと画像に十分な色のコントラストを持たせるようにします。

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

下の画像では、左側のテキストはこれらのコントラストの最小要件を満たしていますが、右側のテキストはコントラストが低くなっています。

テキストのサンプルを並べて表示します。1 つはコントラストが十分で、もう 1 つはコントラストが低い。

色のコントラストを測定するためのツールは多数あります。たとえば、Google の マテリアル カラーツールLea Verou のコントラスト比アプリ、Deque の aXe などです。

タブ順序が定義されている

タブ順序は、ユーザーが Tab キーを押すと要素がフォーカスを受け取る順序です。主にキーボードで操作するユーザーにとって、画面上のすべての項目にアクセスするための主な手段は Tab キーです。マウスカーソルのようなものです。

タブ順は、読み取り順に従ってページの上から下に流れ、重要度の高い項目が上位に表示されるのが理想的です。これにより、キーボードを使用しているユーザーがこれらのアイテムにすばやくアクセスできるようになります。

インタラクティブなコントロールに番号が付けられたデザイン コンプ。

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

コントロールにユーザー補助ラベルが設定されている

スクリーン リーダーなどの支援技術を使用しているユーザーにとって、ラベルは視覚的な情報のみを提供するものです。たとえば、虫メガネのアイコンのみの検索ボタンには、視覚的なアフォーダンスが不足しているため、アクセス可能なラベル「検索」を追加できます。

ユーザー補助対応のラベルを設計する際は、次の簡単なヒントを参考にしてください。

  • 簡潔に - 長い説明を聞くのは退屈です。
  • コントロールのタイプや状態を含めないようにしてください。コントロールが適切にコーディングされている場合、スクリーン リーダーはこれを自動的に読み上げます。
  • 動詞に重点を置く - 「拡大鏡」ではなく「検索」を使用します。
アクセス可能なラベルが付いたコントロールが示されたデザイン コンプ。

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

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

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

フォーカス状態を計画しましょう。つまり、ユーザーがタブキーでフォーカスを合わせたり、矢印キーを押したりしたときに、コントロールがどのように表示されるかを決定します。後でデザインに無理やり組み込むのではなく、これらの状態を早い段階で計画しておくと便利です。

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

デベロッパー

デベロッパーの役割は、フォーカス管理とセマンティクスを組み合わせて堅牢なユーザー エクスペリエンスを構築することです。以下に、サイトやアプリの開発時にデベロッパーが留意すべき点をいくつか示します。

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

論理的なタブ順序

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

次の 2 つの方法があります。

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

フォーカスの管理

ページのコンテンツを変更する場合は、フォーカスを移動してユーザーの注意を引くことが重要です。この手法が役立つ典型的な例として、モーダル ダイアログを開く場合が挙げられます。キーボードに依存しているユーザーがボタンを押してダイアログを開き、フォーカスがダイアログ要素に移動しない場合、ユーザーが取れる唯一の操作は、新しいコントロールを見つけるまでサイト全体をタブで移動することです。新しいコンテンツが表示されたらすぐにフォーカスを移動することで、ユーザー エクスペリエンスの効率性を高めることができます。

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

カルーセルやプルダウンなどのカスタム コントロールを作成する場合は、キーボード サポートを追加するために追加の作業が必要になります。ARIA 作成手法ガイドは、さまざまな UI パターンと、それらがサポートすることが期待されるキーボード操作の種類を特定できる便利なリソースです。

ラジオ グループを作成する方法を説明した ARIA 作成ガイドからの抜粋。

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

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

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

要素にラベルを付ける

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

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

自動テスト

特にテストの場合は、遅延を許容することもできます。可能であれば、ユーザー補助テストを自動化して、すべて手動で行う必要がないようにします。一般的なユーザー補助に関する問題を簡単にすばやく確認できる、優れた業界向けテストツールが数多く存在します。

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

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

まとめ

ユーザー補助はチームの取り組みです。全員に担うべき役割があります。このガイドでは、各チームメンバーがこのトピックを迅速に習得し、アプリの全体的なエクスペリエンスを改善するために使用できる重要な項目をいくつか説明します。

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