より良い Web の構築: 開発者のためのアクセシビリティ ガイド

Web アクセシビリティをめぐる話題はたくさんあり、インターネットにはこのトピックに関する情報があふれています。 WebAIMが上位 1,000,000 の Web サイトを調査したところ、合計 50,829,406 の明確なアクセシビリティ エラーが見つかりました。これは、1 ページあたり平均 50.8 エラーです。アクセシビリティ テストの取り組みは、多くの企業では製品開発の最後に行われますが、すべての企業ではありません。したがって、開発者をトレーニングし、開発プロセス中に Web アクセシビリティを優先することで、アクセシビリティ エラーの数を大幅に減らすことができます。

Web アクセシビリティについて

簡単に言えば、Web アクセシビリティとは、Web が障害を持つ人々にとってアクセシブルであることを意味します。さらに理解を深めるのに役立つ例を次に示します。通常、視覚障害のあるユーザーは、スクリーン リーダーを使用してコンピューターを操作します。スクリーン リーダーは、画面上の情報を読み上げるテキスト読み上げツールです。 Web サイトをアクセス可能にすると、スクリーン リーダーはその情報をユーザーに正しく配信できます。 Web サイトにアクセスできない場合、スクリーン リーダーは不正確または不完全な情報をユーザーに提供します。つまり、スクリーン リーダーなどの支援技術の使用は、対話する Web サイトがアクセシビリティを考慮して設計されている場合にのみうまく機能します。

「アクセシブル」という言葉は、「使用可能」とは異なります。ウェブサイトが法的に準拠するための最低限の要件を満たしているという意味では、ウェブサイトはアクセシブルかもしれませんが、障害を持つ人々にとって最もユーザーフレンドリーなエクスペリエンスを備えていない可能性があります.したがって、障害のある人が Web サイトをアクセスしやすく、使いやすいものにするために、少なくともさらに努力することが重要です。その方法については、この記事で詳しく説明します。

Web サイトにアクセシビリティを組み込む 5 つの方法

• 自動化されたアクセシビリティ パイプラインを設定します。

  アプリケーションにアクセシビリティを組み込むための最も簡単で迅速な方法の 1 つは、シフト レフトの哲学に従うことです。つまり、アクセシビリティ テストは、開発プロセスのできるだけ早い段階で開始し、最後の瞬間まで待つべきではありません。ブラウザーで手動で実行できるものから、CI/CD パイプラインに統合できるツールまで、Web サイトの自動アクセシビリティ テストの設定に役立つさまざまなアクセシビリティ チェッカーがあります。

  
  

  無料のブラウザ拡張機能には、次のようなツールが含まれます。波とアクセシビリティ インサイト.インストールしたら、Web ページでいつでも実行できます。フォームの ARIA ラベルの欠落から色のコントラストの問題まで、Web サイトのアクセシビリティ エラーが表示されます。これらのツールは、自動化されたアクセシビリティの旅を始めるのに最適な方法です。開発者は、次のようなコード リンターも使用できます。 ax アクセシビリティ リンターIDE でコーディングしているときに問題をキャッチします。デクによれば、 自動化されたツールは、業界で信じられている 20% のアクセシビリティ問題と比較して、現在 57% のアクセシビリティの問題を検出しています。

• 自動化されたアクセシビリティの結果から学びます。

  Web サイトに自動化されたアクセシビリティ テストを設定しました。これはすばらしいことです。しかし、キャッチされたアクセシビリティ エラーから学んでいますか?たとえば、フォームのラベルの欠落や画像の代替テキストの欠落に関連するエラーが多数発生している場合は、今後これらのエラーを繰り返さないようにすることが重要です。 Web サイトで多くのコントラストの問題が見つかった場合は、デザイン チームに相談して、Web サイトの色とテーマを評価することをお勧めします。

  
  

  単純なアクセシビリティの間違いを繰り返さないようにするもう 1 つの方法は、コード レビューを行うことです。コード レビューでは、アクセスできないコードを探すようにしてください。簡単に見つけられるものとして、明確に表示されるラベルのない要素の ARIA ラベルの欠落、画像の代替テキストの欠落、ページ タイトルの欠落があります。自動化されたテスト ツールを使用することは素晴らしいことですが、一般的にキャッチされる問題を予防的に修正すれば、その効率をさらに向上させることができます。

  
  

• キーボード ナビゲーション + スクリーン リーダーのテスト

  自動化されたアクセシビリティ テストよりも一歩先に進みたい場合は、キーボードを使用して Web サイトをテストしてください。すべてのインタラクティブな要素はタブ キーでアクセスできる必要があり、ドロップダウン メニューなどの要素は矢印キーでアクセスできる必要があります。さまざまな UI 要素に適したキーストロークの詳細については、https: //webaim.org/techniques/keyboard/を参照してください。

  
  

  キーボードから何かにアクセスできない場合は、次のことを自問してください。これはアクセスできるはずですか?静的テーブル セルなどの要素は、キーボードからアクセスできる必要はありません。キーボードからアクセスできるようにする必要があるカスタムの対話型要素であり、そうでない場合は、プログラムでアクセス可能にする必要があります。これは、web ページのタブ オーダーに要素を追加する 0 の tabindex を追加し、キーを押したときに必要なアクションを呼び出す「onKeyPress」などのイベント ハンドラーを定義することによって実行できます。

  
  

  たとえば、次のコード スニペットは、ボタン要素に 0 の tabIndex を追加して、フォーカス可能にし、キーボードからアクセスできるようにします。イベント ハンドラーは「keydown」イベントをリッスンし、Enter キーが押された場合にボタンのクリックをトリガーします。

  
  

  <button id="myButton">Click me</button>

   

  const button = document.getElementById("myButton");

  button.tabIndex = 0;

    

  button.addEventListener("keydown", function(event) {

  if (event.key === "Enter") {

  button.click();

  }

  });

  
  

  さらに一歩進めたい場合は、スクリーン リーダーを使用して Web サイトをテストしてみてください。これは、ウェブサイトがサードパーティの最終的なアクセシビリティ ベンダーを介して手動テストを行っていない場合に適しています。開発者として詳細なスクリーン リーダー テストを実行する必要はありませんが、スクリーン リーダーを使用して Web サイトをナビゲートしてみることができます。フォーム要素の適切なラベルが発表されているかどうか、冗長な情報が伝達されているかどうか、表内の情報にアクセスできるかどうかなどを確認します。

  
  

  Windows ナレーターと Mac 用ボイスオーバーは、無料のスクリーン リーダーに適したオプションです。スクリーン リーダーは、通常のキーボード ナビゲーション コマンドと同期しますが、さらに、Web サイトのさまざまな要素をナビゲートするための特定のコマンドがあります。たとえば、VoiceOver の場合、これらのコマンドは次の場所で検索できます。 https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts .

  
  

• いくつかのアクセシビリティ デバッグ ツールに慣れてください。

  ブラウザー アクセシビリティ ツリーなどのツールは、Web サイトの UI 要素のアクセシビリティの状態とプロパティを確認するのに役立ちます。このツールは、スクリーン リーダーなどの支援技術に公開されているアクセシビリティ プロパティを表示できるため、アクセシビリティのバグを修正するのに特に役立ちます。 Google Chrome でアクセシビリティ ツリーを表示するには、ブラウザで Devtools を開き、[アクセシビリティ] ペインをクリックします。これは、レイアウト ペインの隣にあるはずです。

  
  

  アクセシビリティ ツリーの詳細については、https://developer.chrome.com/blog/full-accessibility-tree/#what-is-the-accessibility-treeをご覧ください。

  
  

  使用できるもう 1 つの便利なツールは、要素の役割、状態、およびプロパティも強調表示するPaul のブックマークレットです。これは携帯電話でも機能します。どちらのツールも支援技術に渡される情報を知るのに役立つため、バグを修正するのに非常に役立ちます。

  
  

• その他のさまざまな障害の説明

  視覚障害者や運動障害のある人を助けることができるスクリーン リーダーとキーボードのテストに加えて、他の障害のある人のニーズに対応することも検討する必要があります。ウェブサイトに動画がある場合は、正確なキャプションを含めるようにしてください。認知障害のある人のために、WCAG にはコンテンツをアクセシブルにする方法に関する優れたガイドがあります。色盲などの他の障害も考慮してください。 TPGi の Color Contrast Analyzer にはColor Blindness Simulatorがあります。これは、Web サイトがアクセシブルな色とテーマを使用していることを確認するための優れたツールです。

  
  

  最後に、Web サイトにカスタムの音声テキスト変換機能がある場合は、音声障害を持つユーザーがアクセスできるようにします。そのための 1 つの方法は、発話障害のある人が言いたいことを終えるのに十分な時間を与えることです。

結論

デジタル アクセシビリティは、この地球上の 10 億人の障害者がウェブに公平にアクセスできるようにするために重要です。デジタル アクセシビリティの現状を見ると、うまく行っていない可能性があります。によるとUsableNetによる最近のレポート、「2022 年は、4,000 件を超える [アクセシビリティ] 訴訟の年となりました。」上記の戦略のいくつかを使用して、開発者はアクセシビリティを開発プロセスに組み込み、誰かが苛立たしい経験をする前に、できるだけ多くのエラーを見つけて修正することができます。