ユーザー補助の審査方法

サイトにアクセシビリティの問題がないか確認する方法

ウェブサイトまたはアプリケーションにアクセスできるかどうかを判断するのは、手間のかかる作業のように思えるかもしれません。ユーザー補助に初めて取り組む方には、トピックが広範であるため、どこから手をつければよいか迷ってしまうかもしれません。多種多様な能力に対応しようとするということは、それに応じて多様な問題を検討する必要があるということです。

この投稿では、こうした問題を論理的かつ段階を追って既存のサイトのユーザー補助機能を審査するプロセスに分けて説明します。

キーボードを使用する場合

キーボード アイコン。

マウスを使用できない、または使用しないことを選択するユーザーにとって、キーボード ナビゲーションは、画面上のすべてのものにアクセスする主な手段となります。このオーディエンスには、反復性ストレス損傷(RSI)や麻痺などの運動機能障がいのあるユーザーと、スクリーン リーダーのユーザーが含まれます。優れたキーボード エクスペリエンスのためには、論理的なタブオーダーと、識別しやすいフォーカス スタイルを用意することをおすすめします。

要点

  • まず、サイトをタブで移動します。要素がフォーカスされる順序は、DOM 順序に従うようにしてください。どの要素がフォーカスを受け取るべきか不明な場合は、フォーカスの基礎を参照して復習してください。一般的な経験則として、ユーザーが操作または入力できるコントロールは、フォーカス可能にしてフォーカス インジケーター(フォーカス リングなど)を表示する必要があります。CSS で outline: none を使用して代替手段を提供せずにフォーカス スタイルを無効にするのは一般的ですが、これはアンチパターンです。キーボード ユーザーは、フォーカスされている項目が見えなければ、そのページを操作することはできません。スタイル設定のためにマウスとキーボードのフォーカスを区別する必要がある場合は、what-input などのライブラリを追加することを検討してください。

  • カスタムのインタラクティブ コントロールは、フォーカス可能になるようにします。JavaScript を使用して <div> を手の込んだプルダウンにしても、タブオーダーに自動的に挿入されることはありません。カスタム コントロールをフォーカス可能にするには、tabindex="0" を指定します。

  • tabindex が 0 より大きいコントロールは避けます。これらのコントロールは、DOM 内での位置に関係なく、タブオーダーで他のものよりも前にジャンプします。スクリーン リーダーのユーザーは、DOM を直線的に移動する傾向があるため、混乱を招く可能性があります。

  • インタラクティブでないコンテンツ(見出しなど)はフォーカス可能にならないようにする必要があります。デベロッパーが見出しに tabindex を追加するのは、そもそも重要だと考えている場合もあります。これは、画面を見ることができるキーボード ユーザーの効率が低下するため、アンチパターンでもあります。スクリーン リーダーのユーザーの場合、スクリーン リーダーはこれらの見出しをすでに読み上げているため、フォーカス可能にする必要はありません。

  • 新しいコンテンツがページに追加されたら、ユーザーがそれに対してアクションを起こせるように、ユーザーのフォーカスがそのコンテンツに向けられるようにします。例については、ページレベルでのフォーカスの管理をご覧ください。

  • どの時点でも、完全に集中できないことに注意してください。キーボードのフォーカスが止まる可能性があるオートコンプリート ウィジェットにご注意ください。モーダルを表示するなど、ユーザーにページの他の部分を操作させたくない特定の状況でフォーカスが一時的に閉じ込められることがありますが、キーボードからアクセスできるモーダルのエスケープ方法も提供する必要があります。例については、モーダルとキーボード トラップに関するガイドをご覧ください。

フォーカス可能なものがあるからといって、使用できるとは限りません

カスタム コントロールを作成した場合は、ユーザーがキーボードだけでその機能をすべて利用できるようにすることを目指します。キーボード アクセスを改善する方法については、コンポーネント内のフォーカスの管理をご覧ください。

画面に表示されないコンテンツも忘れないようにしてください

レスポンシブ ドロワー メニュー内のリンクや、まだ表示されていないモーダル ウィンドウ内のボタンなど、DOM には存在しているが表示されていないオフスクリーン コンテンツは多くのサイトにあります。これらの要素が DOM 内に残っていると、特に画面外コンテンツをページの一部であるかのように読み上げるスクリーン リーダーでは、キーボード操作が複雑になる可能性があります。これらの要素に対処する方法については、画面外コンテンツの処理をご覧ください。

スクリーン リーダーで試してみる

スピーカー ノート アイコン

一般的なキーボードのサポートを改善することで、次のステップ(適切なラベル付けとセマンティクス、スクリーン リーダーのナビゲーションを阻害する要因などについてページをチェックする)の土台を築くことができます。支援技術によるセマンティック マークアップの解釈について詳しくは、セマンティクスの概要をご覧ください。

要点

  • すべての画像で alt テキストが正しいことを確認してください。ただし、画像が主にプレゼンテーションを目的としたもので、コンテンツの必須要素でない場合は例外です。スクリーン リーダーで画像をスキップすることを示すには、alt 属性の値を空の文字列に設定します(例:alt="".

  • ラベルのすべてのコントロールを確認します。カスタム コントロールの場合は、aria-label または aria-labelledby の使用が必要になる場合があります。例については、ARIA ラベルと関係をご覧ください。

  • すべてのカスタム コントロールで、適切な role と、状態を提供する必要な ARIA 属性を確認します。たとえば、カスタムのチェックボックスでは、状態を適切に伝達するために role="checkbox"aria-checked="true|false" が必要になります。ARIA がカスタム コントロールに欠落しているセマンティクスを提供する仕組みの概要については、ARIA の概要をご覧ください。

  • 情報のフローは理にかなっている必要があります。スクリーン リーダーは DOM 順にページを移動するため、CSS を使用して要素の表示位置を変更している場合、意味のない順序で読み上げられることがあります。ページの早い段階で何かを表示する必要がある場合は、それを DOM の早い段階で物理的に移動してみてください。

  • ページ上のすべてのコンテンツへのスクリーン リーダーのナビゲーションに対応することを目指します。サイトのどのセクションも完全に非表示にしたり、スクリーン リーダーによるアクセスをブロックしたりしないでください。

  • コンテンツがスクリーン リーダーで非表示になるべき場合(画面外のコンテンツの場合や単にプレゼンテーション用である場合など)は、コンテンツを aria-hidden="true" に設定します。詳しくは、コンテンツの非表示に関するガイドをご覧ください。

スクリーン リーダーが 1 つでも使い慣れたことが大いに役立つ

スクリーン リーダーの習得は大変に思えるかもしれませんが、実は簡単に習得できます。一般的に、ほとんどのデベロッパーはいくつかの簡単なキーコマンドだけで移行できます。

Mac をご利用の場合は、Mac OS に付属のスクリーン リーダーである VoiceOver の使用に関するこちらの動画をご覧ください。PC をお使いの場合は、NVDA の使用に関するこちらの動画をご覧ください。NVDA は、寄付によってサポートされている Windows 用のオープンソース スクリーン リーダーです。

aria-hidden でキーボードのフォーカスが妨げられない

ARIA は要素のセマンティクスにのみ影響し、要素の動作には影響しないことを理解することが重要です。aria-hidden="true" を使用するとスクリーン リーダーに対して要素を非表示にできますが、その要素のフォーカス動作は変更されません。画面外のインタラクティブなコンテンツでは、多くの場合、aria-hidden="true"tabindex="-1" を組み合わせて、キーボード フローから確実に削除する必要があります。提案された inert 属性は、両方の属性の動作を組み合わせることで、これを容易にすることを目的としています。

コントロールの機能に関する視覚的なヒントを提供することで、サイトの運用やナビゲーションに役立ちます。これらのヒントはアフォーダンスと呼ばれます。アフォーダンスを提供することで、ユーザーがさまざまなデバイスでサイトを利用できるようになります。

要点

  • リンクやボタンなどのインタラクティブな要素は、非対話型の要素と区別できるようにする必要があります。要素がクリック可能かどうか判断できないと、ユーザーがサイトやアプリのナビゲーションが難しくなります。この目標を達成するには 多くの有効な方法があります一般的な方法の一つは、周囲のテキストと区別するためにリンクに下線を引くことです。

  • フォーカス要件と同様に、リンクやボタンなどのインタラクティブな要素では、マウスユーザーがクリック可能なものにカーソルを合わせたかどうかを把握できるように、マウスオーバー状態が必要です。ただし、インタラクティブな要素は、それ自体が識別可能でなければなりません。クリック可能な要素を示すのにマウスオーバー状態のみに依存しても、タッチ スクリーン デバイスは役に立ちません。

見出しやランドマークを活用する

map icon

見出しとランドマークの要素によってページにセマンティック構造が組み込まれ、支援技術ユーザーのナビゲーション効率が大幅に向上します。多くのスクリーン リーダー ユーザーは、よく知らないページにアクセスしたときに、見出しを使って移動しようとすることが多いと報告しています。同様に、スクリーン リーダーには <main><nav> などの重要なランドマークにジャンプする機能もあります。こうした理由から、ページの構造をユーザー エクスペリエンスのガイドとしてどのように使うかを検討することが重要です。

要点

  • h1-h6 階層を適切に使用します。見出しはページの概要を作るためのツールです見出しに組み込まれているスタイル設定に依存しないでください。代わりに、すべての見出しを同じサイズと見なし、第 1、第 2、第 3 のコンテンツに対して意味的に適切なレベルを使用します。CSS を使って見出しをデザインします

  • ユーザーが繰り返しコンテンツを回避できるように、ランドマークの要素と役割を使用します。多くの支援技術には、<main> 要素や <nav> 要素で定義されたものなど、ページの特定の部分に移動するためのショートカットが用意されています。これらの要素には、暗黙的なランドマークの役割があります。ARIA role 属性を使用して、ページ上の領域(<div role="search">。その他の例については、見出しとランドマークに関するガイドをご覧ください。

  • 以前に使用したことがある場合を除き、role="application" は使用しないでください。application ランドマーク ロールは、ショートカットを無効にして、キーが押されるたびにページに渡すように支援技術に指示します。つまり、スクリーン リーダーのユーザーがページ内を移動する際に通常使用するキーは機能しなくなるため、すべてのキーボード処理を自身で実装する必要があります。

スクリーン リーダーで見出しやランドマークをすばやく確認する

VoiceOver や NVDA などのスクリーン リーダーは、ページ上の重要な領域にスキップするためのコンテキスト メニューを提供します。ユーザー補助機能のチェックを行っている場合は、これらのメニューを使用してページの概要を確認し、見出しレベルが適切かどうか、どのランドマークが使用されているかを判断できます。詳細については、VoiceOverNVDA の基本に関する解説動画をご覧ください。

プロセスの自動化

レンチアイコン

サイトのアクセシビリティを手動でテストするのは面倒で、間違いも起こりがちです。 最終的には、このプロセスを可能な限り自動化する必要があります。これを行うには、ブラウザ拡張機能とコマンドラインのユーザー補助機能テストスイートを使用します。

要点

  • ページはブラウザ拡張機能 aXe または WAVE からのすべてのテストに合格しているか。これらの拡張機能は利用可能なオプションの 2 つにすぎず、コントラスト比の失敗や ARIA 属性の欠落などの微妙な問題をすばやく検出できるため、手動テストプロセスに追加すると便利です。コマンドラインから行う場合、axe-cli は aXe ブラウザ拡張機能と同じ機能を提供しますが、ターミナルから簡単に実行できます。

  • 特に継続的インテグレーション環境で回帰を回避するには、axe-core などのライブラリを自動テストスイートに組み込みます。axe-core は aXe Chrome 拡張機能と同じエンジンですが、簡単に実行できるコマンドライン ユーティリティです。

  • フレームワークやライブラリを使用している場合、独自のユーザー補助ツールが用意されていますか?例として、Angular の場合は protractor-accessibility-plugin、Polymer および Web Components の場合は a11ysuite があります。可能な限り利用可能なツールを活用して 一から一からやり直さないようにします

プログレッシブ ウェブアプリを作成する場合は、Lighthouse を使用することをご検討ください。

Lighthouse のロゴ。

Lighthouse は、プログレッシブ ウェブアプリのパフォーマンスの測定に役立つツールですが、ユーザー補助機能のテストを強化するため axe-core ライブラリも使用します。すでに Lighthouse を使用している場合は、レポートでユーザー補助テストの失敗に注意する必要があります。これらを修正すると サイトの全体的なユーザーエクスペリエンスが向上します

まとめ

ユーザー補助機能のレビューをチームのプロセスの一環として定期的に行い、この確認を早い段階から頻繁に行うことで、サイトの全体的なエクスペリエンスの向上につながります。優れたアクセシビリティは優れた UX と同じであることを忘れないでください。

参考情報