アクセシビリティを念頭に置いてJavaScriptを書く

JavaScriptコンポーネントのアクセシビリティを改善するためのヒント

この記事では、JavaScriptコンポーネントのアクセシビリティを改善する方法に関するヒントを共有し、ユーザーにWebサイトやWebアプリケーションと対話するためのより良い方法を提供します。

この記事は、もともと で公開されていました

最初の記事で、アクセス可能なHTMLを書いて、Webアクセシビリティに焦点を合わせ始める理由と方法を説明し、タグ付けを改善してWebサイトをよりアクセスしやすくする方法についてのヒントを共有しました。これらのヒントのいくつかは非常に基本的ですが、それでも価値があります。それはすべて、フロントエンド開発における最も重要な非書かれていないルールの2つに帰着します。基本を学び、HTMLの計画と書き込みに十分な時間を費やします。明らかにセマンティックマークアップはあなたとあなたのユーザーに利益をもたらします。

幸いなことに、HTMLはWebサイトを作成する唯一の言語ではありませんが、言語が複雑であるほど、間違いを犯す可能性が高くなり、JavaScriptは非常に複雑になります。コードが機能するかどうかに焦点を合わせると、キーボードやスクリーンリーダーのユーザーなど、マウスやタッチパッド以外の入力デバイスを使用するユーザーを忘れがちです。 Web Accessibilityに関するこの4つの記事の2番目で、JavaScriptを作成する際に何を考慮すべきか、JavaScriptコンポーネントをよりアクセスしやすくする方法についてのヒントを集めました。

キーポイント

JavaScriptを使用して、Webサイトを妨げるのではなく、Webサイトのアクセシビリティを改善できます。より多くのオーディエンスがコンテンツにアクセスできるようにすることができます。これには、古いブラウザー、インターネット接続の遅い、または厳格なセキュリティ制限を使用しているコンテンツなどがあります。
フォーカス管理は、Webサイトのアクセシビリティにとって重要です。 Webサイトはキーボードをナビゲートできるようにし、ユーザーがドキュメントオブジェクトモデル（DOM）の順序で、1つのフォーカス可能な要素から別のフォーカス可能な要素にジャンプできるようにする必要があります。
• ボタンが必要なときに
要素を使用するなど、正しいHTML要素を使用することは、アクセシビリティにとって重要です。 HTML要素の誤用は、キーボードおよびスクリーンリーダーのユーザーに問題を引き起こす可能性があります。
• <button></button>コンテンツが動的に変更される場合、画面リーダーユーザーに通知する必要があります。これは、ARIAリアルタイムゾーンを使用することで実現できます。これにより、スクリーンリーダーはコンテンツの更新を発表できます。
• 開発者は、コンポーネントがアクセシビリティを提供する必要がある使用パターンを推測する必要はありません。 WAI-ARIAオーサリングプラクティス1.1ガイドなどのリソースは、貴重な洞察を提供できます。

javascriptは敵ではありません

ヒントを読む前に、重要なポイントを指摘したいと思います。アクセス可能なWebサイトを作成しても、JavaScriptを使用するかどうかを決定する必要があるという意味ではありません。アクセシビリティとは、できるだけ多くの人をコンテンツに入手することです。これには、古いブラウザーやコンピューターを使用しているユーザー、インターネット接続の遅い、厳格なセキュリティ制限（JavaScriptなしなど）なども含まれます。 JavaScriptのような状況では、このエクスペリエンスが理想的ではない場合がありますが、機能しすぎたり、ロードしすぎたりしない場合がありますが、Webサイトにアクセスして利用できる場合でも十分です。

JavaScriptが実行可能な場合、アクセシビリティを改善するためにも使用できます。 Sara Soueidanは、完全にアクセス可能なヘルプツールチップを構築する際のツールチップコンポーネントを作成した経験について書きました...私が思っていたよりも難しいです。彼女は、「すべてのJavaScriptを含まないソリューションには、ユーザーエクスペリエンスに悪影響を与える非常に悪い不利な点がある」と、JavaScriptがアクセシビリティに重要である理由を説明しています。

Marco Zeheは彼の記事「JavaScriptはアクセシビリティの敵ではありません！ javaScriptとアクセシビリティについて詳しく書いています。彼の記事を読むことを強くお勧めします。

しかし、それはすべての会話のためです！始めましょう...

優れたフォーカス管理が不可欠です

キーボードを介してウェブサイトをナビゲートできることを確認することが非常に重要です。多くのユーザーは、Webページを閲覧するときにキーボードに依存しています。これらには、運動障害のある人、盲人、および何らかの理由でマウスやタッチパッドを使用できない人が含まれます。

キーボードを介してウェブサイトをナビゲートすることは、あるフォーカス可能な要素からDOM順序で別のフォーカス可能な要素にジャンプすることを意味します。これは通常、Tabkeyまたはshift tab >を使用して達成されます。フォーカス可能な要素には、リンク、ボタン、フォーム要素が含まれます。 enterキーを使用して、時にはspacebarを使用して選択できます。さまざまな方法で集中して選択可能になることにより、非常に便利なデフォルト機能を備えています。したがって、正しいセマンティック要素を使用して、HTMLを論理的に記述することは理にかなっています。

、<div>、<so>などの要素をデフォルトで焦点を合わせることはできません。これらのタグを使用して、JavaScriptを搭載したカスタムコンポーネントを作成することがよくあります。これは、キーボードユーザーにとって問題になる可能性があります。 <code><span></span> <div>焦点を絞ることができない要素を作成できます<p><strong> </strong> </p>属性と整数値を追加することにより、焦点を絞ることができます。値が0に設定されている場合、要素はキーボードを介してフォーカス可能になり、アクセス可能になります。値が負の場合、要素はプログラムに焦点を当てています（たとえば、JavaScriptを使用する）が、キーボードからアクセスできません。 0を超える値を使用することもできますが、これにより自然なタブの順序が変更され、アンチパターンと見なされます。 <p> <code>tabindex

<h2 id="一个可聚焦的标题">一个可聚焦的标题</h2>

の詳細については、ロブ・ドドソンのA11ycastsエピソード「Tabindexでのコントロールフォーカス」をご覧ください。

JavaScriptを使用したtabindex

フォーカス要素要素が焦点を合わせていても、正しいDOM順序にない場合があります。これを説明するために、HTML、CSS、およびJSでシンプルなモーダルウィンドウコンポーネント（デモと編集ペン）を作成しました。

tabキーを使用してボタンにジャンプしてを押した場合、を入力すると、モーダルウィンドウがポップアップします。再びTab キーを押すと、モーダルウィンドウの下に視覚的に表示される次のリンクに焦点がジャンプします。予想される動作は、モーダルウィンドウ内の次の焦点要素である必要があります。ただし、要素はDOM順に焦点を合わせており、モーダルウィンドウはドキュメントの下部にあるため、そうではありません。この画面録音では、その実際の効果を確認できます。

この問題を解決するには、モーダルウィンドウをフォーカブルにしてから、JavaScriptを使用してフォーカスする必要があります。

<h2 id="一个可聚焦的标题">一个可聚焦的标题</h2>

これを更新された例（デモと編集ペン）で見ることができます。タブキーをボタンに切り替えて、

を押してを押し、タブキーをもう一度押します。モーダルウィンドウ自体が焦点を獲得したことがわかります。

これは良いことですが、ここにはまだ2つの問題があります。

esc を押してモーダルウィンドウを閉じると、焦点が失われます。理想的には、モーダルウィンドウを開く前に、フォーカスがボタンに戻る必要があります。これを達成するには、最後に焦点を絞った要素を変数に保存する必要があります。

を使用して、現在フォーカスを獲得している要素を取得できます。 document.activeElement

function showModal() {
  var modal = document.getElementById('modal2');
  modal.focus();
  ...
}

ボタンを参照したので、モーダルウィンドウを閉じるときに再度焦点を合わせることができます。

var lastFocusedElement;

function showModal() {
  lastFocusedElement = document.activeElement;

  var modal = document.getElementById(modalID);
  modal.focus();
  ...
}

別のペン（デモと編集ペン）でコードを更新しました。現在、アクセシビリティははるかに優れていますが、改善の余地がまだあります。

モーダルウィンドウを開くときは、モーダルウィンドウ内でフォーカスを維持することをお勧めします。モーダルウィンドウを今でもポップアップできます。ここでは詳しく説明しませんが、完全性のために、「キーボードトラップ」（デモと編集可能なペン）と呼ばれるものを含む4番目のペンを作成しました。モーダルウィンドウがアクティブである限り、この画面録画でわかるように、焦点はモーダルウィンドウ内に残ります。

最初と最後のペンを比較すると、追加のコードがあまりないことがわかります。完璧ではないかもしれませんが、最終的なソリューションははるかに使用する方がはるかに適しています。

Modal Windowsにアクセスする例と、Googleの人々が書いた「Tabindexを使用する」というタイトルの良い記事もあります。キーボードテストの詳細については、WebAim Webサイトをご覧ください。それらは、「テスト中に最も一般的なオンラインインタラクション、インタラクションの標準キー、およびその他の情報」のリストを提供します。

フォーカス管理の例については、Marcy SuttonのEgghead.ioビデオ「CSS、HTML、およびJavaScriptによるフォーカス管理」またはRob DodsonのA11ycastsエピソード「What's Focus？」をご覧ください。 》。

ボタンが必要な場合は、要素<button></button>を使用してください。

最初の投稿でボタンについて書いていますが、明らかに多くの人が普遍的な要素をボタンとして使用しています。したがって、このトピックについてもっと何かを書くことは害はないと思います。

ペン（コード付きデバッグモード/ペン）を作成して、<div>または<code><span></span>要素の代わりに<button></button>または<input type="button">をボタンとして使用することに関するいくつかの問題を説明しました。ページを閲覧すると、2番目のボタンではなく、最初のボタンに焦点を合わせることができます。理由はもちろんです - 最初のボタンは<button></button>であり、2番目のボタンは<div>です。この問題を解決することができます。<code><div>を<code>tabindex="0"に追加すると、最初は焦点を当てることなく焦点を当てることができます。これが、3番目と4番目のボタンが<div>であっても焦点を合わせている理由です。 <pre class='brush:php;toolbar:false;'>&lt;h2 id=&quot;一个可聚焦的标题&quot;&gt;一个可聚焦的标题&lt;/h2&gt;</pre> <p>ボタンの文字を追加しても、「Div-Button」は確かに焦点を絞っていますが、それでも<code><div>のように動作します。これを説明するために、すべての<code>.btn要素に簡単なクリックイベントハンドラー（ペン）を追加しました。ボタンをクリックすると、アラームボックスがポップアップ表示されますが、キー（入力またはspacebar）で同じことをしようとすると、最初のボタンのみがイベントをトリガーします。 。キーイベントハンドラーを「Div-Button」に追加して、デフォルトのボタン動作を完全にシミュレートする必要があります。これは不必要なオーバーヘッドのようですね。そのため、ボタンが必要な場合は、<button></button>要素を使用する必要があります。詳細と例については、ロブ・ドドソンのA11ycastsエピソード「Just Use Button」をご覧ください。

コンテンツが動的に変更されたときにスクリーンリーダーに通知する必要があります通常、画面読者は、要素がフォーカスを取得したとき、またはユーザーがスクリーンリーダー自身のナビゲーションコマンドを使用するときにのみコンテンツを発表します。コンテンツが動的にロードされ、DOMに挿入された場合、視力のある人だけがこれらの変更に気付くことができます。 ARIAリアルタイムゾーンは、この問題のいくつかの解決策を提供します。例でそれを行う方法をお見せします。

個人データを編集して保存できるプロファイル設定ページがあるとします。 [保存]ボタンがクリックされると、ページをリロードせずに変更が保存されます。アラートは、変更が成功したかどうかユーザーに通知します。これはすぐに起こる可能性があり、時間がかかる場合があります。説明したことを示すために短いビデオを録音しました。

操作が成功していることがわかりますが、聞こえません。スクリーンリーダーのユーザーは変更に気付くことはありませんが、この問題には簡単な解決策があります。メッセージボックスにステータスまたはアラートロールを追加することにより、画面リーダーは要素の更新をリッスンします。

メッセージテキストが変更された場合、新しいテキストは読み上げられます。このビデオで実際にどのように機能するかを見て聞くことができ、このペンでコードを見ることができます。

function showModal() {
  var modal = document.getElementById('modal2');
  modal.focus();
  ...
}

ユーザーを礼儀

で扱います

「ステータス」と「アラート」の違いは、「アラート」が他の何かを発表しているときにスクリーンリーダーを中断することです。代わりに、「ステータス」は、画面読者が発表を完了するのを待ちます。

オフ、礼儀正しい、または断定的な3つの可能な値を取ることができるaria-liveと呼ばれる属性もあります。これらの3つの値のうち、オフはデフォルト値、aria-live="polite"はrole="status"と同等であり、aria-live="assertive"はrole="alert"に相当します。よく知られている事前定義されたケースでは、特定の「リアルタイムゾーンロール」を使用することが最善です。さらに、ブラウザが役割をサポートしていない場合は、両方のプロパティを同時に使用する必要がある場合があります。 LéonieWatsonは、ARIAリアルタイムゾーンのスクリーンリーダーサポートのテスト結果を共有しました。

<h2 id="一个可聚焦的标题">一个可聚焦的标题</h2>

時々、それが変更されているわけではないことを宣言するのは理にかなっています

デフォルトでは、画面読者は変更されたコンテンツのみを表示します。たとえ同じリアルタイム領域に何か他のものがある場合でも、テキスト全体を発表することは理にかなっています。デフォルトの動作は、aria-atomic属性を使用して変更できます。 Trueに設定すると、Assistive Technologyは要素の内容全体を表示します。

Paul J. Adamには、異なるリアルタイムのロケールを比較するaria-atomicテストケースデモがあります。彼はまた、iOS 8.1でボイスオーバーでデモをテストし、実際にどのように機能するかを確認できるように録音しました。 aria-atomicの可能性のあるユースケースをよりよく理解したい場合は、録音を見ることをお勧めします（VoiceOver iOS 8.1は、aria-atomic領域の残りの文字aria-relevantおよびaria-liveを読み取ります）。

を考慮すべきことがあります

• リアルタイム領域は焦点を移動せず、テキストの発表のみをトリガーします。
• 重要な変更に対してのみアラートを使用します。 「ステータス」は、より丁寧であるため、ほとんどの場合、より優れています。
• 速すぎる可能性があるため、自動的に消えるアラームの設計は避けてください。
• 私のテストでは、ナレーションの問題に遭遇しました。 CSSを使用してアラートを非表示または動的にアラートを作成することは、常に効果的ではありません。リアルタイムゾーンをさまざまなブラウザと異なるソフトウェアで徹底的にテストしてください。

もちろん、ロブ・ドドソンには、詳細と例に関するA11ycastsのエピソードもあります。 》。 Heydon Pickeringには、彼のARIAサンプルコレクションに別のライブエリアの例があります。

コンポーネントが提供しなければならない使用パターンを推測する必要はありません

ナビゲーションとアクセシビリティの観点からコンポーネントが提供する必要があるすべての機能を考えることはしばしば困難です。幸いなことに、これを行うのに役立つWai-Aria Authering Practices 1.1と呼ばれるリソースがあります。 WAI-ARIAオーサリングプラクティスは、WAI-ARIAを使用してアクセス可能なリッチインターネットアプリケーションを作成する方法を学習するためのガイドです。推奨されるWAI-ARIAの使用パターンについて説明し、その背後にある概念を紹介します。

彼らはアコーディオン、スライダー、タブなどを構築するためのガイドを持っています。

アクセス可能なjavaScriptコンポーネント

アクセス可能なJavaScriptコンポーネントのための優れたリソースを次に示します。

実用的なAriaの例
Modaal -WCAG 2.0レベルAA
• がアクセスできるモーダルウィンドウプラグイン
フレンド - アクセス可能な一連のモダンなフロントエンドコンポーネント
A11yプロジェクトモード

他のリソースを知っている場合は、コメントで共有してください。

概要

JavaScriptの利点を使用して、Webサイトのアクセシビリティを向上させます。フォーカス管理に注意し、一般的な使用パターンを理解し、DOMを操作するときにスクリーンリーダーユーザーを検討してください。最も重要なことは、あなたが誰のためにウェブサイトを作ったかを忘れずに、生産プロセスを楽しんでください。

当面はすべてここにあります。これらのヒントが、よりアクセスしやすいHTMLとJavaScriptを書くのに役立つことを願っています。 Heydon Pickeringに感謝します。なぜなら、彼の本を含むフロントエンドのデザインパターンは、あなたが今読んだもののほとんどの基礎だからです。アクセシビリティと包括的デザインについて詳しく知りたい場合は、彼の本を読むことを強くお勧めします。

この記事を書くのを手伝ってくれたAdrian Roselliに感謝し、Evaが私の執筆を校正してくれたことに感謝します。

リソース

これは、この記事のすべてのリンクされたリソースのリストです。

a11ycasts＃03 - フォーカスとは何ですか？

• a11ycasts＃04 - tabindexを使用してフォーカスを制御します
• a11ycasts＃05 - ボタンのみを使用してください
• a11ycasts＃10 - アラート！
• book：「包括的フロントエンド設計モデル」
• 0
より大きいTabindexを使用しないでください CSS、HTML、JavaScript
• を使用したフォーカス管理フォーカス可能な要素 - ブロウザー互換性テーブル
リンク、ボタン、提出、div、ああ、私の神
mdn：htmlelement.focus（）
mdn：tabindex
MDN：キーボードを介してナビゲートできるJavaScriptコンポーネント信じられないほどアクセス可能なモーダルウィンドウ
• tabindexを使用します
• webaimキーボードテスト
• webaimキーボードアクセシビリティ
• wai-aria aria-atomic
• アクセス可能なjavascript
• を書き込むことで

faqs

アクセシビリティJavaScriptを作成することの重要性は何ですか？

アクセシビリティの作成JavaScriptは、障害者を含むすべての人がウェブサイトまたはアプリケーションを利用できるようにするため、重要です。これにより、ユーザーベースが広がるだけでなく、ユーザーエクスペリエンスと満足度も向上します。多くの分野では、さまざまな障害者差別法案にアクセシビリティが必要であるため、これは法的コンプライアンスにとっても重要です。

JavaScriptコードをよりアクセスしやすくするにはどうすればよいですか？

JavaScriptコードをよりアクセスしやすくする方法はいくつかあります。まず、ウェブサイトまたはアプリがキーボードに優しいことを確認してください。これは、ユーザーがキーボードのみを使用してWebサイトをナビゲートできる必要があることを意味します。第二に、あなたのウェブサイトがスクリーンリーダーで簡単にナビゲートできることを確認してください。これは、セマンティックHTMLおよびARIAの役割を使用することで実現できます。最後に、常に画像に代替テキストを提供し、ウェブサイトが十分な色のコントラストを持っていることを確認してください。

ARIAとは何ですか？アクセシビリティをどのように改善しますか？

Ariaは、アクセス可能なリッチインターネットアプリケーションの略です。これは、障害のある人がWebコンテンツとWebアプリケーションをよりアクセスしやすくする方法を定義するプロパティのセットです。 ARIAは、AJAX、HTML、JavaScript、および関連技術を使用した動的なコンテンツと高度なユーザーインターフェイスコントロールの開発に役立ちます。要素、その役割、および現在の状態に関する追加情報を提供することにより、アクセシビリティを改善できます。

キーボードナビゲーションはどのようにアクセシビリティを強化しますか？

キーボードナビゲーションは、マウスまたはタッチスクリーンを使用できないユーザーにとって不可欠です。 Webサイトまたはアプリのすべての機能がキーボードのみを使用してアクセスできるようにすることにより、動きや視覚障害のあるユーザーの影響をより敏感にすることができます。これは、JavaScriptコードのフォーカス管理を使用して実現できます。 tabindex

アクセシビリティにおけるセマンティックHTMLの役割は何ですか？

セマンティックHTMLとは、コンテンツのセマンティクスまたは意味を強化するためのHTMLタグの使用を指します。たとえば、スタイルの代わりにボタンに

ラベルを使用して、ボタンのように見えるようにします。これは、視覚障害のあるユーザーがコンテンツを理解し、ウェブサイトをナビゲートするのに役立つために、スクリーンリーダーに意味のある情報を提供するため、アクセシビリティにとって重要です。 <button></button>

アクセシビリティのために十分な色のコントラストを確保する方法は？

視覚障害のあるユーザーにとって、十分な色のコントラストが重要です。 WCAG 2.1コントラスト比ガイドに準拠するカラーの組み合わせを選択することで、これを確実にすることができます。選択した色のコントラスト比を確認するのに役立つオンラインツールがいくつかあります。

画像の代替テキストを提供することの重要性は何ですか？ 画面読者に依存している視覚障害のあるユーザーにとって、画像に代替テキストを提供することは不可欠です。代替テキストは、画像を表示できないユーザーがページコンテキストで目的を理解できるようにするため、画像コンテンツを正確に説明する必要があります。

JavaScriptコードのアクセシビリティをテストする方法は？

JavaScriptコードのアクセシビリティをテストするためのツールがいくつかあります。これらのツールには、AXやLighthouseなどの自動テストツール、スクリーンリーダーを使用した手動テストとキーボードのみのナビゲーションが含まれます。自動テストと手動テストの組み合わせを使用して、完全なアクセシビリティを確保することが重要です。

JavaScriptの一般的なアクセシビリティの問題は何ですか？

JavaScriptの一般的なアクセシビリティの問題には、キーボードのアクセシビリティの欠如、色のコントラストが不十分である、画像の代替テキストの欠如、ARIA文字の欠如、またはARIA文字の誤った使用が含まれます。これらの問題は、あなたのウェブサイトを障害のある人が使用することを困難または利用できない可能性があります。

JavaScriptとアクセシビリティの詳細についてはどうすればよいですか？

JavaScriptとアクセシビリティについて詳しく知るのに役立つ多くのリソースがあります。これらのリソースには、W3Cなどの組織からのオンラインチュートリアル、コース、ドキュメントが含まれます。さらに、アクセシブルなコードを作成し、アクセシビリティを定期的にテストすることを練習すると、理解とスキルが大幅に向上する可能性があります。