包括的なブラウザ拡張機能の構築:ステップバイステップのアクセシビリティ設計

ブラウザ拡張機能を構築するのは簡単ですが、誰でもアクセスできるようにするには、慎重な注意とスキルが必要です。

あなたの拡張機能はデータを完璧に取得し、美しいインターフェースを備えているかもしれませんが、スクリーン リーダー ユーザーやキーボード ナビゲーターがそれを使用できない場合、多くの潜在的なユーザーを意図せずに除外していることになります。

この記事では、Chrome ブラウザ拡張機能のアクセシビリティの問題を監査し、すべての人にとって機能する包括的なエクスペリエンスに変換します。

目次

• ブラウザ拡張機能でアクセシビリティが重要な理由

• 手動ブラウザ拡張機能のアクセシビリティ テストを実行する方法

• ブラウザ拡張機能のアクセシビリティ向上を実装する方法

• 自動化されたブラウザ拡張機能のアクセシビリティ テストを実行する方法

• アクセス可能なブラウザ拡張機能のベスト プラクティス

• 結論

ブラウザ拡張機能でアクセシビリティが重要な理由

ブラウザ拡張機能をクリックするたびに、ユーザーに権限を与えるか、アクセシビリティが設計の一部でない場合はユーザーを排除する機会となります。

ブラウザ拡張機能は、独自のアクセス可能なインターフェイスを維持しながら、既存の Web ページに機能を挿入する必要があるため、独特のアクセシビリティの課題に直面しています。この二重の責任により、潜在的な障壁が生じる可能性があります。たとえば、ポップアップがキーボード ユーザーを罠にかけたり、スクリーン リーダーとの通信に失敗したりすると、拡張機能が使用できなくなる可能性があります。

世界保健機関によると、10 億人以上の人々が障害を抱えて暮らしており、アクセシブルなデザインは膨大なユーザー ベースを解放し、すべての人にとってより良いエクスペリエンスを生み出します。

ブラウザ拡張機能の場合、一般的にアクセシビリティの障壁は次のように現れます。

• キーボード ナビゲーションの行き止まり :キーボード ユーザーをトラップまたは除外するポップアップとインターフェイス。

• サイレント インタラクション :アイコンのみのボタンなど、ラベルと説明が欠落しており、スクリーン リーダーによって「ラベルのないボタン」として読み上げられ、ユーザーはその目的を推測できます。

• 未発表の動的コンテンツ更新 :支援技術を意識せずに発生するコンテンツの変更。たとえば、スクリーン リーダーに変更を通知せずに引用を更新するなど、読み込み状態やエラーに関するフィードバックの欠落など。

• コンテキスト統合の競合 :既存の Web ページを変更する拡張機能は、ページのアクセシビリティ機能を誤って壊したり、確立されたナビゲーション パターンと衝突する要素を導入したりする可能性があります

これらの障壁を理解することで、開発者は的を絞った手順を実行して、拡張機能のアクセシビリティをテストし、改善することができます。

手動ブラウザ拡張機能のアクセシビリティ テストを実行する方法

自動ツールは明らかな問題を発見しますが、手動テストでは実際のユーザー エクスペリエンスが明らかになります。拡張機能のアクセシビリティを体系的に評価する方法は次のとおりです。

キーボード ナビゲーション テスト

マウスを取り外し、拡張機能を完全にキーボードのみで使用してみてください。 Tab を使用して移動します 要素間を移動するには、Enter または Space コンポーネント内のボタンや矢印キーをアクティブにします。

• どの要素にフォーカスがあるかは常に明らかですか?

• Enter でボタンをアクティブにできますか? または Space 予想通りですか？

• ユーザーはモーダル ダイアログまたはドロップダウン メニューを終了できますか?

行き止まりや混乱点に遭遇すると、キーボード ユーザーも同じ障壁に直面することになります。

スクリーン リーダーの評価

オペレーティング システムの組み込みスクリーン リーダーを使用して内線に移動し、アナウンス内容を聞きます。 macOS では、VoiceOver を有効にします。 Windows ではナレーターを使用します。 Linux では Orca を試してください。

• ボタンは単なる「ボタン」ではなく「新しいアドバイスを生成する」とアナウンスされるなど、各要素の目的が明確に伝わっていますか?

• 見出し、リスト、その他の構造は適切に伝えられていますか?

• ユーザーは、コンテンツが読み込まれているとき、選択されているとき、または変更されたときを理解していますか?

このテスト段階では、多くの場合、伝えようとしていた内容と実際にユーザーに届く内容との間のギャップが明らかになります。

視覚的なアクセシビリティのレビュー

さまざまな視覚的コンテキストで拡張機能を調べます。 WebAIM のコントラスト チェッカーなどの開発者ツールを使用して、テキストが WCAG の読みやすさの 4.5:1 コントラスト比を満たしていることを確認します。システムのハイコントラスト設定で拡張機能がどのように表示されるかをテストします。以下を確認してください:

• 機能は 200% ズームでも引き続き使用できます。

• 色分けされたインジケーターとテキスト ラベルを併用するなど、色だけでは情報が伝わりません。

これらの手動テストにより、アクセシビリティに関する重大な問題が明らかになり、拡張機能を包括的なものにするための的を絞った改善への道が開かれます。

ブラウザ拡張機能のアクセシビリティ向上を実装する方法

何も知らずにページを更新したり、明確な目的もなくボタンをクリックしたりすることを想像してみてください。上記で実行した手動テストにより、次の 3 つの主要なアクセシビリティの問題のうち、拡張機能のスクリーン リーダー ユーザーのエクスペリエンスが以下のとおりであることが明らかになりました。

• ボタンのラベルがありません :サイコロ ボタンには代替テキスト「サイコロ アイコン」が付いた画像のみがあり、画面読者が必要とするコンテキストが欠けています。

• サイレント動的更新 :新しいアドバイスが読み込まれるとき、スクリーン リーダーはコンテンツが変更されたことを認識しません。

• 読み込み状態なし :アドバイスを取得するときに、ユーザーは何かが起こっているというフィードバックを受け取りません

自動テストを実行する前に問題に対処しましょう。

ボタンのラベルと代替テキストの欠落に対処する方法

aria-label を追加します ボタンの目的を明確に説明し、アイコンの説明的な代替テキストを提供します。 role="presentation" 属性により、画像がスクリーン リーダーによって装飾として扱われることが保証されます。

<!--Before: Unclear Button Purpose and icon alt text-->
<button class="dice-button" id="generate-advice-btn">
 <img src="/icons/icon-dice.png" alt="Dice icon">
</button>
<!--After: Clear, Accessible Button and icon alt text-->
<button class="dice-button" id="generate-advice-btn" aria-label="Generate new advice">
 <img src="/icons/icon-dice.png" alt="A dice icon with green background" role="presentation">
</button>

サイレント動的アップデートに対処する方法

aria-live="polite" を追加します スクリーン リーダーが新しいアドバイスと aria-atomic="true" をアナウンスするための 引用文全体が読まれていることを確認します。つまり:

<!--Before: Silent Dynamic Updates-->
<p class="advice-quote" id="advice-quote">
 "It is easy to sit up and take notice, what's difficult is getting up and taking action."
</p>
<!--After: Announced Content Changes-->
<p class="advice-quote" id="advice-quote" aria-live="polite" aria-atomic="true">
 "It is easy to sit up and take notice, what's difficult is getting up and taking action."
</p>

無読み込み状態に対処する方法

setLoadingState を追加します 読み込みインジケーターを提供する関数。これにより、コンテンツが取得されたときにスクリーン リーダー ユーザーに通知が確実に送信されます。

// Before: No Loading Feedback
function requestNewAdvice() {
 chrome.runtime.sendMessage({ action: "fetchAdvice" }, (response) => {
 // No loading indicators...
 });
}
// After: Accessible Loading States
function requestNewAdvice() {
 setLoadingState(true); 
 chrome.runtime.sendMessage({ action: "fetchAdvice" }, (response) => {
 setLoadingState(false);
 // Handle response with proper announcements...
 });
}
function setLoadingState(isLoading) {
 if (isLoading) {
 // Disable button and show loading text
 generateAdviceBtn.disabled = true;
 generateAdviceBtn.setAttribute('aria-label', 'Loading new advice...');
 // Show loading text in the advice quote element
 adviceQuoteElement.textContent = "Loading new advice...";
 } else {
 // Re-enable button
 generateAdviceBtn.disabled = false;
 generateAdviceBtn.setAttribute('aria-label', 'Generate new advice');
 }
}

手動テストの問題が解決されたので、同じ拡張機能の自動テストの実行に進むことができます。

自動化されたブラウザ拡張機能のアクセシビリティ テストを実行する方法

手動テストでは重要な洞察が得られますが、自動ツールでは一般的な問題を効率的に検出し、継続的な監視を行うことができます。

この拡張機能アクセシビリティ チェッカーは、WCAG 準拠のためにポップアップやコンテンツ スクリプトなどのブラウザ拡張機能インターフェイスを分析することでテストを簡素化し、ポップアップの制約やコンテンツ インジェクションの競合などの固有の課題に対処します。

拡張機能アクセシビリティ チェッカーを使用するには:

<オル>

ブラウザ拡張機能フォルダーを .zip ファイルに圧縮します

.zip ファイルを https://extensiona11ychecker.vercel.app/ にアップロードします。

生成されたレポートで特定のアクセシビリティ違反を確認し、提案された修正を実装します。

上の GIF に示されているように、このワークフローは、後付けではなく、開発プロセスの日常的な部分としてアクセシビリティを確立するのに役立ちます。

自動テストを導入したら、開発全体を通じて拡張機能に確実にアクセスできるようにするためのベスト プラクティスを検討してみましょう。

アクセス可能なブラウザ拡張機能のベスト プラクティス

私たちは、サンプルのアドバイスを生成するブラウザ拡張機能を、機能的ではあるがアクセスできないツールから、誰にとっても機能する包括的なツールに変換しました。

私たちの改善に基づいて、アクセス可能なブラウザ拡張機能を設計するための 4 つの重要な原則を次に示します。

<オル>

セマンティック HTML と明確で説明的なラベル

ARIA 属性を追加する前に、常に適切な要素 (たとえば、「アドバイスの生成」アクションの場合、適切な見出し階層) を使用して、適切な HTML 構造から始めてください。

aria-label により、すべてのインタラクティブな要素に明確な目的があることを確認します。 、aria-labelledby 、またはそのアクションを説明する目に見えるテキスト。

<オル>

あらゆる段階での明確なコミュニケーション

すべてのインタラクティブな要素は、その目的を効果的に伝える必要があります。ユーザーは次のことを理解する必要があります。

• • 何が起こっているか (たとえば、状態をロードする場合は「新しいアドバイスをロード中…」)

    • 何が問題だったのか (たとえば、エラーの場合は「アドバイスの読み込みに失敗しました」)

    • 変更内容 (更新されたコンテンツの aria-live リージョンなど)

<オル>

完全なキーボード アクセシビリティ

すべての機能はキーボード ナビゲーションを通じて利用できる必要があります。これには、Tab でのテストが必要です。 、Enter 、Space 必要に応じて、 、および矢印キーを使用します。

モーダルや複雑なインタラクションを終了するための明確な方法を備えたインターフェース内を予測どおりに移動する、明確で思慮深いフォーカス インジケーターを提供します。

<オル>

ユーザー設定とコンテンツ スクリプトに関する考慮事項

システムのフォント サイズ設定をサポートし、ユーザー定義のカラー スキームを不必要に上書きしないことにより、ユーザーの選択を尊重します。

拡張機能で既存の Web ページを変更する場合は、ページの確立されたアクセシビリティ機能、フォーカス管理、およびナビゲーション パターンを壊さないようにしてください。挿入する新しい要素がアクセシビリティ標準に従っていることを確認してください。

結論

アドバイス生成拡張機能で見てきたように、アクセシビリティの問題に対処すると、機能的なツールが包括的なツールに変わります。

ただし、既存の拡張機能の問題を修正することは役立ちますが、最も効果的なアプローチは、アクセシビリティをコードの最初の行から設計と開発の決定に導くことです。

次のブラウザ拡張プロジェクトを開始するときは、次のように尋ねてください。

• キーボードだけを使ってこれをどうやって操作するでしょうか?

• すべてのインタラクティブな要素の目的は、スクリーン リーダーにとってすぐにわかりますか?

• 状態の読み込み中に何が起こっているかをユーザーはどのように理解するのでしょうか?

ここでは役立つリソースをいくつか紹介します

• Chrome 拡張機能のアクセシビリティに関するドキュメント

• 拡張機能アクセシビリティ チェッカー

• ウェブ コンテンツ アクセシビリティ ガイドライン (WCAG) 2.1

無料でコーディングを学びましょう。 freeCodeCamp のオープンソース カリキュラムは、40,000 人以上の人々が開発者としての職に就くのに役立ちました。始めましょう