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

アクセシビリティを高めることで、誰もがサイトを利用しやすくなります。

Addy Osmani
Addy Osmani
X GitHub

誰もがアクセスできる包括的なサイトを構築することが重要です。 最適化の対象にできる障がいには、少なくとも視覚、聴覚、可動性、認知、会話、ニューラルの 6 つの主要な領域があります。ウェブ アクセシビリティが初めてでも、多くのツールやリソースが役立ちます。

10 億人以上の人々が、なんらかの障がいを抱えています。

サイトにアクセスできるようにするには、画面サイズと入力の種類（スクリーン リーダーなど）が異なる複数のデバイスで機能する必要があります。また、障がいのあるユーザーを含め、最も幅広いユーザーがサイトを使用できるようにする必要があります。

ユーザーが抱く可能性のある障がいには、次のようなものがあります。

ビジョン 聴覚 移動補助
  • ロービジョン
  • 視覚障害
  • 色覚異常
  • 白内障
  • 太陽の光
  • 難聴
  • 聴覚障害
  • ノイズ
  • 耳の感染症
  • 脊髄損傷
  • 運動機能障がい
  • 手がふさがっている
認知 音声 神経
  • 学習障がい
  • 眠気、注意散漫
  • 偏頭痛
  • 自閉症
  • 発作
  • 周囲のノイズ
  • 喉の痛み
  • 発話障害
  • 話せません
  • 憂鬱
  • PTSD
  • 双極性障害
  • 不安症

視覚の問題には、色を識別できない、視力がまったく見えないなど、さまざまな問題があります。

  • テキスト コンテンツが最小コントラスト比のしきい値を満たしていることを確認します。
  • 色のみを使用して情報を伝えることは避け、すべてのテキストがresizableになるようにします。
  • すべてのユーザー インターフェース コンポーネントで、スクリーン リーダー、拡大鏡、点字ディスプレイなどの支援技術を使用できるようにします。そのためには、ユーザー補助 API が任意の要素の role、state、value、title をプログラマティックに決定できるように、UI コンポーネントをマークアップする必要があります。

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

個人的にロービジョンの家で、サイトや DevTools、ターミナルにズームインすることがよくあります。ズームのサポートは、開発者の ToDo リストの一番上にあることはほとんどありませんが、私のようなユーザーにとっては大きな違いをもたらします。

聴覚に関する問題とは、ユーザーがページから発信された音声が聞こえない状態である可能性があることです。

  • テキスト以外のすべてのコンテンツについて、代替テキストを指定します。
  • UI コンポーネントが音声なしで引き続き機能することをテストします。

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

運動障がいには、マウス、キーボード、タッチスクリーンを操作できないことなどが挙げられます。

  • マウスを使用するアクションを行うために、UI コンポーネントのコンテンツにキーボードから機能的にアクセスできるようにします。
  • 同じ API を使用することが多い支援技術（スクリーン リーダー、音声操作ソフトウェア、物理的なスイッチ コントロールなど）用に、ページが正しくマークアップされていることを確認します。

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

  • アニメーションを使用する場合は注意が必要です。繰り返しまたは点滅する動画やアニメーションは避けてください。ユーザーによっては問題が生じる可能性があります。

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

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

  • タイミング ベースのインタラクションは避けてください。

多数の基本事項をカバーするように思われるかもしれませんが、ここでは、UI コンポーネントのユーザー補助機能を評価し、改善するプロセスについて説明します。

英国政府のユーザー補助チームは、視覚的なサポートを強化するために、ユーザー補助の推奨事項と禁止事項に関するデジタル ポスターを作成しました。これを使用して、ベスト プラクティスをチームと共有してください。

ユーザー補助の推奨事項と禁止事項を示すデジタルポスター。
ユーザー補助に関するおすすめの方法が紹介されている 6 枚のポスター。全文をご覧ください。

UI コンポーネントのアクセシビリティを測定する

ページの UI コンポーネントのユーザー補助機能を監査する際は、次の点を確認します。

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

    コンポーネントがフォーカスを管理し、フォーカス トラップを回避しているか。適切なキーボード イベントに反応できるか。

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

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

  • UI コンポーネントは音声なしで動作しますか？

    スピーカーをオフにして、ユースケースを確認してください。

  • UI コンポーネントは色なしで機能できますか？

    色が見えない人でも UI コンポーネントを使用できるようにします。 色覚異常をシミュレートするための便利なツールは、Colorblindly という Chrome 拡張機能です。（4 種類の色覚異常のシミュレーションをすべて試してみてください）。 また、同様に便利な Daltonize 拡張機能もあります。

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

    最新のオペレーティング システムはすべて高コントラスト モードをサポートしています。このような場合に役立つ Chrome 拡張機能は高コントラストです。

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

カスタム UI コンポーネント（<button> などの標準要素を拡張するコンポーネントを除く）には、ユーザー補助機能などの組み込み機能がないため、提供する必要があります。ユーザー補助を実装するには、まず、コンポーネントを類似の標準要素（または、コンポーネントの複雑さに応じていくつかの標準要素の組み合わせ）と比較します。

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

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

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

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

Safari の [要素] パネルの [ノード] タブにユーザー補助情報が表示されます。

以下に、UI コンポーネントを利用しやすくしようとするときに自問すべき項目の一覧を示します。

キーボード フォーカスの改善

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

まず、コンポーネントごとに適切なフォーカス ターゲットがあることを確認します。たとえば、メニューなどの複雑なコンポーネントは、ページ内の 1 つのフォーカス ターゲットである場合がありますが、アクティブなメニュー項目が常にフォーカスされるように、そのコンポーネント内でフォーカスを管理する必要があります。

フォーカス管理が必要なメニューとサブメニューのスクリーンショット。
複雑な要素内のフォーカスを管理します。

tabindex を使用する

tabindex 属性を使用すると、要素と UI コンポーネントのキーボード フォーカスを追加できます。キーボードのみを使用する支援技術のユーザーが、操作する要素にキーボードのフォーカスを配置できる必要があります。

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

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

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

カスタム UI コンポーネントの場合は、特定のページの要素の順序を事前に判断できないため、常に tabindex の値に 0 または -1 を使用します。tabindex の値を -1 にすると、複雑なコンポーネント内のフォーカスを管理する場合に特に役立ちます。

デフォルトのフォーカス リング スタイルを使用するか、認識可能なカスタム フォーカス スタイルを適用しても、フォーカスが常に表示されるようにします。キーボードのユーザーだけを操作して要素からフォーカスを移動できるようにする必要があるので、キーボードを閉じないように注意してください。

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

HTML のオートフォーカス属性を使用すると、ページの読み込み時に特定の要素が自動的にフォーカスされるようにすることを指定できます。autofocus は、ボタンを含むすべてのウェブフォーム コントロールですでにサポートされています。独自のカスタム UI コンポーネントで要素をオートフォーカスするには、フォーカスできるすべての HTML 要素（document.querySelector('myButton').focus() など）でサポートされている 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 コンポーネントで、設定メニューであることを示すために歯車アイコンのみを表示する場合は、同じ情報を伝える「設定」などのアクセス可能なテキストが必要です。コンテキストに応じて、Shadow DOM の alt 属性、aria-label 属性、aria-labelledby 属性、または書式なしテキストを使用して、代替テキストを指定できます。一般的な技術的なヒントについては、WebAIM クイック リファレンスをご覧ください。

画像を表示する UI コンポーネントには、alt 属性と同様に、その画像の代替テキストを提供するメカニズムを提供する必要があります。

コンポーネントがセマンティック情報を提供するか。

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

一般に、マウスのクリックまたはホバーイベントをリッスンするコンポーネントには、なんらかのキーボード イベント リスナーと ARIA ロール（場合によっては ARIA の状態と属性）が必要です。

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

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

ユーザーは色に頼らずにすべてを理解できるか？

ステータスを表示する、ユーザーにレスポンスを求める、データを可視化するなど、情報を伝える唯一の手段として色を使用しないでください。たとえば、円グラフの場合は、視覚障がいのあるユーザーがスライスの開始点と終了点がわからなくても情報を理解できるように、各スライスにラベルと値を提供します。

アクセシビリティを確保するためのラベルと値が表示された円グラフ。
アクセス可能な円グラフ。（W3C Web Accessibility Initiative より）。

コントラストは十分ですか？

コンポーネントに表示されるテキスト コンテンツは、WCAG AA レベルのコントラストの最小しきい値を満たしている必要があります。より高い AAA しきい値を満たす高コントラスト テーマを用意し、ユーザーがカスタム コントラストやさまざまな色を必要とする場合にユーザー エージェント スタイルシートを適用できるようにすることを検討してください。カラー コントラスト チェッカーは、コンポーネントを設計する際の参考になります。

移動したり点滅したりするコンテンツは、停止可能で安全ですか？

ユーザーが 5 秒以上移動、スクロール、点滅するコンテンツを一時停止、停止、非表示にできるようにする必要があります。一般に、コンテンツのフラッシュは避けてください。

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

ユーザー補助ツールとユーザー補助機能のテスト

サイトのアクセシビリティを評価するためのツール（およびそのコンポーネント）は 100 以上あります。自動化されているツールもあれば、手動テストが必要なツールもあります。

次の方法をご検討ください。

  • Axe は、選択したフレームワークまたはブラウザのユーザー補助機能の自動テスト機能を提供します。Axe Puppeteer を使用すると、自動化されたユーザー補助テストを作成できます。

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

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

  • Tenon.io は、一般的なユーザー補助の問題をテストするのに便利です。Tenon は、さまざまなビルドツール、ブラウザ（拡張機能を使用）、テキスト エディタなどの統合を強力にサポートしています。

  • コンポーネントのユーザー補助機能の問題をハイライト表示するためのライブラリ固有のツールやフレームワーク固有のツールは数多くあります。たとえば、eslint-plugin-jsx-a11y を使用して、エディタ内の React コンポーネントのユーザー補助機能に関する問題をハイライト表示します。

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

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

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

支援技術を利用する

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

  • Windows では、NVDA は無料のオープンソースのスクリーン リーダーです。ただし、目の見えるユーザーにとっての習得は容易ではありません。

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

  • ChromeOS には組み込みのスクリーンリーダーがあります。

Google は、ウェブのユーザー補助機能の改善に、まだ多くの時間を費やしています。 ウェブ アルマナックによると、

  • サイトの 5 件中 4 件は、テキストが背景に溶け込んで判読できていません。
  • 49.91% のページで、まだ一部の画像に alt 属性が指定されていません。
  • ボタンやリンクを使用するページのうち、ラベルが含まれているのは 24% のみです。
  • すべてのフォーム入力にラベルを提供しているページは、わずか 22.33% です。

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