Office アドインのアクセシビリティ ガイドライン

アクセシビリティ対応のアドインは、スクリーン リーダーを使用したり、キーボードで移動したり、ハイ コントラストに依存したり、タッチ操作を行ったりするユーザー全員に適しています。 最初からアクセシビリティを念頭に置いて構築すると、すべてのユーザーの使いやすさが向上し、ソリューションの市場が拡大します。

Web コンテンツ アクセシビリティ ガイドライン (WCAG) は、アドインにアクセスするために必要なものを定義する国際標準です。 ビルドを開始する前に、それらを理解することをお勧めします。

複数の入力方法の設計

デバイスや機能に関係なく、すべてのユーザーが操作できるように、アドインはキーボード、タッチ、マウスの入力をサポートする必要があります。

  • キーボード操作を単独で使用して、ユーザーがすべての操作を完了できることを確認します。 ユーザーは 、Tab キーと方向キーの組み合わせを使用して、ページ上のすべてのアクション可能な要素にアクセスできる必要があります。
  • モバイル デバイスでは、ユーザーがタッチ操作でコントロールを操作するときに、アドインで便利なオーディオ フィードバックを提供する必要があります。
  • DOM または UI ツリーで論理的な読み取りとナビゲーションの順序を保持します。
  • すべての対話型要素が、適切な ARIA ラベルを使用して支援テクノロジに名前、ロール、および状態を公開していることを確認します。

アドインを使いやすいようにする

予測可能な動作と明確なフィードバックは、すべてのユーザーがアドインで何が起こっているかを理解するのに役立ちます。

  • サウンドだけに依存して、重要な情報をユーザーに警告しないでください。
  • 意味や指示を伝えるために、色、形、サイズ、または視覚的な場所だけに依存しないでください。
  • よりシンプルな代替手段を提供することなく、複雑なジェスチャー(ドラッグ、マルチタッチ、タイミングモーション)を必要としません。
  • フォーカスを慎重に管理します。 ユーザーが変更を開始しない限り、フォーカスを別の要素に移動しないでください。 ガイダンスについては、「 Office アドインのナビゲーション パターン」を参照してください。
  • すべてのバインディング操作について、それを検証、確認、取り消す方法を提供します。
  • ユーザー アクションに時間制限を課さないでください。

アドインを見やすいものにする

視覚的なデザインを明確にし、十分なコントラストにより、視覚障疵や色覚異常を持つユーザーが UI を読み取って理解できるようにします。

  • 予期しない色の変更は避けます。
  • UI 要素、タイトル、見出し、入力、エラーについて、意味のあるタイムリーな説明を提供します。 コントロール名にコントロールの意図が明確に記述されていることを確認します。
  • UI 要素が、水生、砂漠、夕暮れ、夜空の 4 つの Windows 組み込みコントラスト テーマすべてで正しくレンダリングされることを確認します。 テストするには、Windows 設定>Accessibility>Contrast テーマに移動し、それぞれを選択し、アドイン内のすべてのテキスト、ボタン、リンク、およびその他の UI 要素が表示され、十分なコントラストを持つチェックします。
  • WCAG カラー コントラストのガイドラインに従ってください。 通常のテキストの場合は少なくとも 4.5:1、大きなテキストの場合は 3:1 のコントラスト比を目指します。

コンテンツとメディアにアクセスできることを確認する

  • 意味のあるテキスト以外のすべてのコンテンツ (画像、アイコン、SVG、グラフ、カスタム コントロールなど) に代わるテキストを提供します。
  • 同等の代替テキストが提供されない限り、画像内に意味のあるテキストを配置しないでください。
  • オーディオのみのコンテンツのトランスクリプトを指定します。
  • オーディオを使用して、事前に記録されたビデオまたはライブ ビデオの同期キャプションを指定します。
  • ユーザーに警告する手段として、視覚的な合図や振動など、サウンドに代わる方法を提供します。
  • ユーザーがオーディオまたはアニメーションを一時停止、停止、またはミュートする方法を提供します。

アクセシビリティのテスト

定期的 なアクセシビリティ テスト は、ユーザーに到達する前に問題をキャッチするのに役立ち、標準とプラットフォームの進化に合わせてアドインが支援テクノロジと連携し続けられるようにします。

自動チェックを統合する

自動化されたツールでは多くの問題を検出できますが、アドインが支援テクノロジとどの程度連携しているかを評価することはできません。

  • ビルドまたは CI パイプラインの一部として Accessibility Insights を実行して、アクセシビリティに関する一般的な問題を早期に特定します。
  • 自動チェックを使用して、次の検証を行います。
    • 色のコントラスト。
    • アクセス可能な名前とラベル。
    • キーボードフォーカスの順序。
    • ARIA ロールと属性。
    • ターゲット のサイズと間隔。

支援技術のサポートを検証する

一般的に使用される支援技術を使用してアドインをテストし、ユーザーが次のことができることを確認します。

  • キーボードを単独で使用して、すべての対話型要素を移動します。
  • スクリーン リーダーの出力を通じてコントロールの目的を理解します。
  • 視覚、聴覚、正確なポインターの動きに依存することなく、タスクを完了します。

次を使用してエクスペリエンスを確認します。

次の点を確認します。

  • すべての機能は、マウスを使用せずに使用できます。
  • フォーカス インジケーターは表示され、隠されません。
  • 動的更新プログラムは適切に発表されます。
  • カスタム UI コンポーネントは、ロール、状態、および値を公開します。

相互作用パターンをテストする

個々のコントロールだけでなく、ユーザー フローを評価して、次のことを確認します。

  • ドラッグまたはジェスチャ ベースの操作には、キーボードでアクセスできる代替手段があります。
  • 時間制限のある操作は、一時停止、延長、または無効にすることができます。
  • アラートと通知は、サウンドだけに依存することなく伝達されます。
  • 認証と入力の方法は、メモリ、ビジョン、またはタイミング応答に依存しません。

標準の進化に合った再テスト

支援技術と国際的なアクセシビリティ ガイドラインは、時間の経過と同時に変化します。 国際アクセシビリティ ガイドラインの変更に対応するために定期的にテストします。 詳細については、「 アクセシビリティ テスト」を参照してください。

関連項目

  • Last updated on