ウェブ デベロッパー向けのユーザー補助機能

ユーザー補助機能を改善することで、あらゆるユーザーにとって使いやすくなります。

Addy Osmani
Addy Osmani
X GitHub

インクルーシブで、誰もがアクセスしやすいサイトを構築することは重要です。 少なくとも次の 6 つの主要な障がいについて、最適化の対象にできます。 画像、聴覚、可動性、認知、音声、ニューラルです。 ここで役立つツールやリソースは数多くありますが、 ウェブユーザー補助にまったく詳しくない方にも有効です。

10 億人以上 なんらかの障がいを抱えて生きている人のことです。

サイトがアクセスできるようにするには、複数のデバイスで機能する必要があります スクリーン リーダーなどのさまざまな画面サイズと入力の種類に対応できます。 さらに、サイトは最も幅広いユーザー グループ、 支援しています

ユーザーは次のような障がいを抱えている可能性があります。

Vision 聴覚 モビリティ
  • ロービジョン
  • 視覚障害
  • 色覚異常
  • 白内障
  • 日光の反射
  • 難聴
  • 聴覚障害
  • ノイズ
  • 耳感染
  • 脊髄損傷
  • 緻密さが欠けている
  • 手がふさがっています
認知 音声 Neural
  • 学習障がい
  • 眠気または注意散漫
  • 片頭痛
  • 自閉症
  • 発作
  • 周囲のノイズ
  • 喉の痛み
  • 発話障害
  • 話せません
  • うつ病
  • PTSD
  • 双極性障害
  • 不安症

視覚的な問題は、色を識別できないから目がまったく見えないまで、多岐にわたります。

  • テキスト コンテンツが次の基準を満たすようにする コントラスト比のしきい値。
  • 情報のやり取りを避ける 色のみを使用して すべてのテキストが サイズ変更可能である。
  • すべてのユーザー インターフェース コンポーネントが支援技術で使用できることを確認する スクリーン リーダー、拡大鏡、点字ディスプレイなどです。 これにより、UI コンポーネントが確実にマークアップされ、 ユーザー補助 API がプログラムによって 要素の role、state、value、title。
で確認できます。

Chrome DevTools の [要素を検証] ツールチップのスクリーンショット。

私は個人的にロービジョンで暮らし、サイトをズームインして ターミナルで実行します。 ズームをサポートすることは、開発者がToDo リスト 私のようなユーザーに大きな変化をもたらすことができます。

難聴とは、ページから発せられる音が聞こえないという問題です。

  • 提供 代替テキスト テキスト以外のすべてのコンテンツに適用されます。
  • UI コンポーネントが引き続き機能することをテストする 音声なしで接続できます。

ChromeVox スクリーン リーダーがウェブページを読んでいるスクリーンショット

モビリティの問題では、マウス、キーボード、またはデバイスを操作できない タッチスクリーン。

  • UI コンポーネントのコンテンツを作成する キーボードから機能的にアクセス可能 マウスで操作する操作をすべて実行できます
  • 以下のような支援技術について、ページを正しくマークアップしてください。 スクリーン リーダー、音声操作ソフトウェア、物理的なスイッチ コントロールなど、 同じ API を使用する傾向があります

認知に関する問題は、ユーザーが支援技術を必要とする可能性があることを意味します。 テキストが読みやすくなるため テキストの代替機能を用意しておくことが重要です

  • アニメーションを使用する際は注意が必要です。次のような動画やアニメーションは使用しないでください。 リピート またはフラッシュが、問題の原因となる 一部のユーザーに対して

    prefers-reduced-motion CSS メディアクエリを使用すると、アニメーションを制限できます 動画の自動再生は、モーションの軽減を好むユーザーに適しています。

    /*
If the user expresses a preference for reduced motion, don't use animations on buttons.
*/
@media (prefers-reduced-motion: reduce) {
  button {
    animation: none;
  }
}

  • 不適切なやり取りを避ける タイミングベース。

カバーしきれないほど多いように思えるかもしれませんが それでは診断用の問題に UI コンポーネントのユーザー補助機能を改善します

映像サポートをさらに充実させるために、GOV.UK のユーザー補助チームは ユーザー補助の推奨事項と禁止事項のデジタルポスター ベスト プラクティスをチームと共有するために使用できます。

<ph type="x-smartling-placeholder">
</ph> ユーザー補助の推奨事項と禁止事項を示すデジタルポスター。
ユーザー補助のベスト プラクティスを列挙した 6 人のポスター。詳しくは、 全文。

UI コンポーネントのユーザー補助機能を測定する

ページの UI コンポーネントのアクセシビリティを監査する際は、次の点を確認してください。

  • UI コンポーネントはキーボードだけでも使用できますか？

    コンポーネントはフォーカスを管理し、フォーカス トラップを回避しますか？ 適切なキーボード イベントに応答できるか。

  • UI コンポーネントでスクリーン リーダーを使用できますか？

    視覚的に表示される情報について代替テキストを用意しましたか？ ARIA を使用してセマンティック情報を追加しましたか？

  • UI コンポーネントは音声がなくても動作しますか？

    スピーカーをオフにして、ユースケースを確認します。

  • UI コンポーネントは色がなくても機能しますか？

    色を確認できない人でも UI コンポーネントを使用できるようにします。 色覚異常をシミュレートする便利なツールは、 Colorblindly。 （4 種類の色覚異常シミュレーションを試してみましょう）。 こちらもいかがですか ダルトナイズ これは同様に有用です。

  • 高コントラスト モードを有効にして UI コンポーネントは動作しますか？

    最新のオペレーティング システムはすべて、高コントラスト モードをサポートしています。 高コントラスト 便利な Chrome 拡張機能です。

標準化されたコントロール（<button> や <select> など）にユーザー補助機能がある 組み込まれています。Tab キーを使用してフォーカス可能です。 キーボード イベント（Enter、Space、矢印キーなど）に反応します。 ユーザー補助ツールで使用されるセマンティックなロール、状態、プロパティを持ちます。 デフォルトのスタイルも、記載されているユーザー補助の要件を満たしている必要があります。

カスタム UI コンポーネント（標準 <button> のような要素）には次のような機能が組み込まれていません。 提供する必要があります。クラウド移行の出発点として コンポーネントを同等の標準と比較することが 要素（または、複雑さによってはいくつかの標準要素の組み合わせ） 行います。

ほとんどのブラウザ デベロッパー ツールは、ページのユーザー補助ツリーの検査をサポートしています。 Chrome DevTools の [要素] パネルの [ユーザー補助機能] タブで、この設定を使用できます。

Chrome DevTools のユーザー補助ツリービューのスクリーンショット。

Firefox には [ユーザー補助機能] パネルもあります。

FireFox DevTools のユーザー補助ツリービューのスクリーンショット。

Safari では、[Elements] パネルの [Elements] タブにユーザー補助情報が表示されます。

UI コンポーネントのアクセシビリティを向上させる際の検討事項を以下にまとめました。

キーボードのフォーカスを改善する

UI コンポーネントのすべての機能にアクセスできることが理想的です できます。ユーザーエクスペリエンスを 設計する際には キーボードだけで要素を使用する方法を考えます キーボード操作の一貫したセットを見つけます

まず、各コンポーネントに適切な重点目標があることを確認します。 たとえば、メニューなどの複雑なコンポーネントは、 そのページ内でフォーカスを管理して、アクティブなメニュー項目が 常にフォーカスを合わせます

<ph type="x-smartling-placeholder">
</ph> フォーカス管理が必要なメニューとサブメニューのスクリーンショット。
複雑な要素内のフォーカスの管理。

tabindex を使用する

tabindex を使用すると、要素と UI コンポーネントのキーボード フォーカスを追加できます。 属性です。キーボードのみを使用する 支援技術では 操作対象の要素にキーボードでフォーカスできます。

組み込みのインタラクティブ要素（<button> など）は暗黙的にフォーカス可能であるため、 位置を変更する必要がない限り、tabindex 属性は必要ありません。 選択します。

tabindex 値には次の 3 種類があります。

  • tabindex="0" は最も一般的で、要素をナチュラルタブに配置します。 順序（DOM の順序により定義されます）となります。
  • tabindex 値が -1 の場合、要素はプログラムによって処理されます。 フォーカス可能ですが、タブオーダーでは利用できません。
  • tabindex 値が 0 より大きい場合、要素は手動タブオーダーに配置されます。 正の tabindex 値を持つページ内のすべての要素がアクセスされました 通常のタブオーダーの要素の前の番号順。
で確認できます。

こちらの記事で tabindex のユースケースをご覧ください tabindex を使用する。

デフォルトのフォーカス リングを使用するかどうかにかかわらず、フォーカスが常に表示されるようにする 識別可能なカスタム フォーカス スタイルを適用します。攻撃を仕掛けて 要素からフォーカスを離せるようにする必要があります 使用できます。

オートフォーカスを使用する

HTML のオートフォーカス属性を使用すると、作成者は特定の 要素が自動的にフォーカスを取得 ページの読み込み時に 自動的に適用されます autofocus はすでにサポートされており、 すべてのウェブフォーム コントロール 必要があります。 独自のカスタム UI コンポーネントで要素をオートフォーカスするには、 focus() メソッドを呼び出す フォーカス可能なすべての HTML 要素で （例: document.querySelector('myButton').focus()）。

キーボード操作を追加する

UI コンポーネントがフォーカス可能になったら、適切なキーボード操作ストーリーを提供する 適切なキーボード イベントを処理することでコンポーネントがフォーカスされたとき。 たとえば、ユーザーが矢印キーでメニュー オプションを選択できるようにします。 ボタンと、Space または Enter を使用してボタンを有効にします。 ARIA 設計パターン ガイド ガイダンスが提供されています

最後に、キーボード ショートカットが検索可能であることを確認します。 一般的な方法としては、キーボード ショートカットの凡例（画面上のテキスト）を用意しておきます。 ショートカットが存在することをユーザーに通知します。たとえば、「?を押してキーボード あります。または、ツールチップなどのヒントを使用してユーザーに通知することもできます。 ショートカットについてです

フォーカスを管理することの重要性は計り知れません。重要な例は ナビゲーションドロワーページに UI コンポーネントを追加すると その中の要素にフォーカスを合わせる必要がある そうしないと、ユーザーはこのページにたどり着くためにタブを最後まで移動しなければならない場合があります。 ストレスを感じるかもしれませんが ページ上のすべてのキーボード操作可能なコンポーネントで フォーカスをテストしてください

WalkMe の状態切り替えテスト。 
// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

スクリーン リーダーを適切に使用する

スクリーン リーダーは約 1 ～ 2% の人が使用しています。重要なポイントをすべて理解できますか スクリーン リーダーとキーボードを使用してコンポーネントを操作できます。 一人で？

以下の質問は、スクリーン リーダーのユーザー補助機能に対応するためのものです。

すべてのコンポーネントと画像に、意味のある代替テキストがあるかどうか。

名前や目的に関する情報は常に 視覚的に伝えられるため アクセシビリティ テキストの代替テキストを提供できます。

たとえば、<fancy-menu> UI コンポーネントが歯車アイコンのみを表示する場合 設定メニューであることを示すために 「settings」のような代替テキストが必要です。 同じ情報を伝えるのが最適です コンテキストに応じて、 alt 属性を使用して代替テキストを指定できます。 aria-label 属性、aria-labelledby 属性、 テキストデータを生成できます 一般的な技術的なヒントについては、WebAIM クイック リファレンスをご覧ください。

画像を表示する UI コンポーネントには、 画像の代替テキストを指定します（alt 属性と同様）。

コンポーネントはセマンティック情報を提供しますか？

支援技術は、他の方法では表現されていないセマンティック情報を 書式設定、カーソルのスタイル、位置などの視覚的な手がかりを持つ目の見えるユーザー。 標準化された要素には、このセマンティック情報がブラウザによって組み込まれており、 カスタムコンポーネントの場合は [ARIA] をクリックして情報を追加します。

一般的に、マウスクリックやホバーイベントをリッスンするコンポーネントは、 なんらかのキーボード イベント リスナーと ARIA ロールが必要です ARIA の状態と属性も確認できます。

たとえば、カスタム <fancy-slider> UI コンポーネントには、スライダーの ARIA ロール、 これには関連する ARIA 属性 aria-valuenow、aria-valuemin、aria-valuemax があります。 これらの属性をカスタム コンポーネントの関連プロパティにバインドすることで、 支援技術を利用するユーザーが要素を操作できます それに応じて要素の視覚的な表示も変化します。

<ph type="x-smartling-placeholder">
</ph> スライダーのスクリーンショット。
範囲スライダー コンポーネント。
<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

色に頼らなくてもすべてを理解できるか？

情報を伝える手段としては色のみを使用しないでください。 ステータスの表示、ユーザーへの応答のプロンプト、データの可視化などがあります。 たとえば、円グラフの場合は、各スライスのラベルと値を指定します 視覚障がいのあるユーザーが情報を理解できるように スライスの開始位置と終了位置が わからない場合でも

<ph type="x-smartling-placeholder">
</ph> アクセシビリティを確保するために、ラベルと値を含む円グラフ。
簡単にアクセスできる円グラフ。（W3C Web Accessibility Initiative より）。

十分なコントラストがありますか？

コンポーネントに表示されるテキスト コンテンツはすべて、 WCAG の AA レベルの最小コントラストしきい値。 要件を満たす高コントラストのテーマを AAA のしきい値が高い ユーザー エージェント スタイルシートが カスタム コントラストや色の違いをユーザーが求めている場合。 こちらのカラー コントラスト チェッカーをご利用ください。 コンポーネントを設計する際の参考になります。

コンテンツの移動やフラッシュは停止可能で安全ですか？

ユーザーが移動、スクロール、または表示するコンテンツを一時停止、停止、または非表示にできるようにする必要があります。 点滅します。通常は、コンテンツを書き込まないでください。

点滅させる必要がある場合は、1 秒間に 3 回を超えて点滅させないようにしてください。

ユーザー補助ツールとテスト

100 を超えるツールが用意されており、 サイトのアクセシビリティを評価して 説明します。自動化されているツールもあれば、手動でのテストが必要なツールもあります。

考慮すべき点をいくつか紹介します。

  • Axe はユーザー補助の自動化を実現 使用するフレームワークやブラウザでテストできます。 斧人形 自動ユーザー補助機能テストの作成に使用できます。

  • Lighthouse のユーザー補助機能 監査は、ユーザー補助に関する一般的な問題を発見するための有用な分析情報を提供します。 ユーザー補助スコアは、すべてのユーザー補助監査の加重平均です Axe ユーザー影響評価に基づきます。 継続的インテグレーションによるユーザー補助のモニタリングについては、以下をご覧ください。 Lighthouse CI。

    Lighthouse のユーザー補助機能の監査のスクリーンショット。

  • Tenon.io は、ユーザー補助機能に関する一般的な問題をテストするのに役立ちます。 Tenon は、さまざまなビルドツールやブラウザ（ 拡張機能、テキスト エディタなどです。

  • ハイライト表示のためのライブラリやフレームワーク固有のツールが多数あります。 コンポーネントでのアクセシビリティの 問題を改善できますたとえば、 eslint-plugin-jsx-a11y を使用して、React コンポーネントのユーザー補助機能の問題をエディタでハイライト表示します。

    eslint-plugin-jsx-a11y によって報告されたユーザー補助機能の問題があるコードエディタのスクリーンショット。

    Angular を使用する場合は、codelyzer エディタ内のユーザー補助監査も実施しています。

    Codelyzer によって報告されたユーザー補助機能の問題があるコードエディタのスクリーンショット。

支援技術を利用する

  • 支援技術がウェブ コンテンツをどのように認識しているかを調べるには、 ユーザー補助インスペクタ（Mac） または Windows Automation API テストツール AccProbe（Windows）。 また、Chrome で作成された一連のユーザー補助機能ツリーも表示できます。 about://accessibilityに移動して
  • Mac でスクリーン リーダーのサポートをテストするには、VoiceOver の使用をおすすめします ユーティリティです有効または無効にするには ⌘F5 を、移動するには Ctrl+Option ←→ を使用します ページ、Ctrl+Shift+Option + ↑↓ キーでユーザー補助機能を上下に移動できます。 表示されます。詳しい手順については VoiceOver コマンドの一覧をご覧ください。 VoiceOver のウェブコマンドの一覧をご覧ください。

  • Windows では、NVDA は無料のオープンソースの画面である。 読み取りますしかし、視覚障がいのあるユーザーにとっては習得に時間がかかります。

    ChromeLens のスクリーンショット。

  • ChromeOS には 組み込みのスクリーンリーダー。

ウェブのアクセシビリティを改善するには、まだ長い道のりが続いています。 Web Almanac によると、

  • 5 社中 4 社のサイトには背景に溶け込むテキストがある 読み取れなくなります。
  • 49.91% のページが、一部の画像に alt 属性を指定していません。
  • ボタンやリンクを使用するページにラベルが含まれているのはわずか 24% です。
  • すべてのフォーム入力にラベルを付けるページの割合は、わずか 22.33% です。

誰もが利用しやすいエクスペリエンスを構築するために、Google ができることはたくさんあります。 できます。