アクセシビリティ (デザインの基本)

  • [アーティクル]

Note

この設計ガイドは Windows 7 用に作成されており、新しいバージョンの Windows では更新されていません。 ガイダンスの多くは原則として適用されますが、プレゼンテーションと例には 現在の設計ガイダンスは反映されていません。

アクセシビリティのためのソフトウェアを設計することは、障碍や障碍のあるユーザーを含む幅広いユーザーがプログラムと機能を簡単に利用できるようにすることを意味します。

アクセシビリティ機能が役立つユーザーの数は、あなたを驚かせるかもしれません。たとえば、米国では、すべてのコンピューター ユーザーの半数以上がアクセシビリティに関連する困難や障疵を経験しており、アクセシビリティ技術の使用の恩恵を受ける可能性が高いと調査されています。 さらに、アクセシビリティの特徴である柔軟性と包括性を備えたソフトウェア設計にアプローチすると、多くの場合、全体的な使いやすさと顧客満足度が向上します。

[簡単操作センター] ダイアログ ボックスのスクリーン ショット

コントロール パネルから利用できる簡単操作センターは、ユーザーが必要なアクセシビリティ機能を選択してカスタマイズできる一元的な場所を提供します。

メモ：キーボード、マウス、色、サウンドに関連するガイドラインは、別の記事で示されています。

設計概念

多くの物理的、知覚的、認知的な要因は、ユーザーがコンピューターのハードウェアとソフトウェアを操作するときに発生します。 プログラムの機能のアクセシビリティを高める方法を検討する前に、どのような種類の障閲や障闭が存在するか、ユーザーがコンピューターとやり取りする際に使用できる支援技術の一部について学ぶのに役立ちます。

減損の種類

次の表では、一般的なユーザー障害と障餿について説明し、コンピューターのアクセシビリティを高めるために使用される最も重要な解決策をいくつか示します。

障害 説明 ソリューション
ビジュアル
 軽度 (ユーザーの 17% に影響を与える) から重度 (ユーザーの 9% に影響を与える) までの範囲です。
 カスタマイズ可能な倍率、色、コントラスト。点字ユーティリティ;スクリーン リーダー。
聴力
 軽度 (ユーザーの 18% に影響を与える) から重度 (ユーザーの 2% に影響を与える) までの範囲です。
 情報の冗長性: テキストまたは視覚的な通信の補足としてのみ使用されるサウンド。
器用 さ
 軽度 (ユーザーの 19% に影響を与える) から重度 (ユーザーの 5% に影響を与える) までの範囲です。 この障害は、多くの場合、キーボードやマウスで特定の運動スキルを実行することが困難です。
 入力方法の冗長性: マウスまたはキーボードの同等物によってアクセスされるプログラム機能。
認知的
 メモリ障害と知覚の違いが含まれます。 ユーザーの 16% に影響します。
 高度にカスタマイズ可能なユーザー インターフェイス (UI);複雑さを隠すために 段階的開示 を使用する。アイコンやその他の視覚補助の使用。
発作
 動きと点滅に対する視覚的な感度が含まれています。
 アニメーションの使用など、インターフェイスを変調するための保守的なアプローチ。2 ヘルツ (Hz) ~ 55 Hz の範囲で画面のちらつきを回避します。
音声または言語
 失読症や口腔コミュニケーションの困難が含まれます。
 スペル チェックと文法チェックユーティリティ、音声認識とテキスト読み上げテクノロジ。

これらの障害を持つユーザーの支援に関するその他のガイドラインについては、この記事で後述 する「特定の障害に対処する 」を参照してください。

支援技術とアクセシビリティ機能の種類

スクリーン リーダー

スクリーン リーダーを使用すると、視覚障碡や障碡のあるユーザーは、ビジュアルをオーディオに変換して UI を移動できます。 したがって、UI テキスト、コントロール、メニュー、ツール バー、グラフィックス、およびその他の画面要素は、スクリーン リーダーのコンピューター化された音声によって読み上げられます。 スクリーン リーダー支援テクノロジ用に最適化されたプログラムを作成するには、スクリーン リーダーが各 UI 要素を識別する方法を計画する必要があります。

ユーザーが操作できる各 UI 要素は、キーボードでアクセスできるだけでなく、アクセシビリティ アプリケーション プログラミング インターフェイス (API) を介して公開される必要があります。 Windows Presentation Foundation (WPF) をサポートするすべてのバージョンの Microsoft Windows の新しいアクセシビリティ フレームワークである UI オートメーション を使用することをお勧めします。 UI オートメーションは、デスクトップ上のほとんどの要素へのプログラムによるアクセスを提供し、スクリーン リーダーなどの支援技術製品を使用して、ユーザーに UI に関する情報を提供し、標準入力以外の方法 (たとえば、マウスやキーボードの操作ではなく、または操作に加えて話すことによって) によって UI を操作できるようにします。 詳細については、「UI オートメーションの概要」を参照してください。

スクリーン リーダーは非常に重要な支援技術ですが、他にももあります。 使用可能なテクノロジの範囲の詳細については、「 支援技術製品の種類」を参照してください。

音声認識

音声認識は Windows のアクセシビリティ機能であり、ユーザーはコンピューターを音声で操作できるため、マウスやキーボードとのモーター操作の必要性が軽減されます。 ユーザーは、ドキュメントと電子メールをディクテーションしたり、音声コマンドを使用してプログラムを開始および切り替え、オペレーティング システムを制御したり、Web 上のフォームに入力したりできます。

拡大鏡

拡大は元の2から16倍に画面上の項目を拡大することによって低視野のユーザーを助ける。 ユーザーはこの機能を設定して、マウスを追跡できます (マウスが指しているものの拡大バージョンを表示する場合)、キーボード (タブ移動時にポインターが移動する領域を表示する場合)、テキスト編集 (入力内容を確認するため)。

ビジュアル設定と配色

画面の内容を大きくすることに加えて、視覚障;障;視覚障;ハイ コントラスト モード や背景と前景の配色をカスタマイズする機能などのシステム設定の恩恵を受ける場合があります。

Narrator

ナレーターは、Windows のスケールダウンスクリーン リーダーであり、ユーザーは画面上のテキストと UI 要素を声に出して読み上げることができます。一部のイベント (エラー メッセージを含む) が自発的に発生する場合でも読み上げられます。 ユーザーは、アクティブウィンドウを離れることなくナレーターメニューを聞くことができます。

[microsoft ナレーター] ダイアログ ボックスのスクリーン ショット

ユーザーは、Microsoft ナレーターを使用する範囲をカスタマイズできます。

スクリーン キーボード

物理キーボードが困難で、スイッチなどの代替入力デバイスを使用する必要があるユーザーには、スクリーン キーボードが必要です。 ユーザーは、オンスクリーン キーボードの設定方法に応じて、マウスまたは別のポインティング デバイス、小さなキー グループ、または 1 つのキーを使用してキーを選択できます。

マウス キー機能

マウス キーを有効にすると、キーボードを好むユーザーはテンキーの方向キーを使用してマウス ポインターを移動できます。

アクセシビリティ機能の完全な一覧については、Microsoft Web サイト の「Windows Vista のアクセシビリティ 」を参照してください。

キーボードベースのナビゲーション

キーボードベースのナビゲーションでは、Tab キー、方向キー、スペース バー、Enter キーが重要です。 Tab キーを押すと、さまざまなコントロール グループ間で 入力フォーカス が切り離され、方向キーを押すと、コントロール内またはグループ内のコントロール間で移動します。 スペース バーの押下は、入力フォーカスのあるコントロールをクリックするのと同じですが、Enter キーを押す操作は、入力フォーカスに関係なく、既定のコマンド ボタンまたはコマンド リンクをクリックした場合と同じです。

[空のごみ箱] ダイアログ ボックスのスクリーン ショット

この例では、ユーザーは目的のオプションに入力フォーカスが設定されるまで Tab キーを押し、Enter キーを押してオブジェクトを開くことができます。

アクセス キー

アクセス キーを使用すると、ユーザーは最初にコントロールに移動することなく、オプションを選択し、コマンドを直接開始できます。 アクセス キーは、各コントロールのラベルの文字の 1 つに下線を付けることで示されます。 その後、ユーザーは Alt キーと下線付き文字を押して、オプションまたはコマンドをアクティブにします。 アクセス キーでは大文字と小文字は区別されません。

ファイル メニューとアクセス キーのスクリーン ショット

この例では、Alt キーを押しながら O キーを押すと、[開く] コマンドがアクティブになります。

通常、制御に論理アクセス キーを選択しても問題はありません。ただし、ウィンドウ上のコントロールが多いほど、アクセス キーの選択肢が不足する可能性が高くなります。 この場合は、個々のグループではなく、制御グループにアクセス キーを割り当てます。

コントロール グループとアクセス キーのスクリーン ショット

この例では、アクセス キーは、個々のコントロールではなく、コントロール グループに割り当てられます。

アクセス キーは多くの場合、ショートカット キーと混同されますが、ショートカット キーはアクセス キーとは異なる方法で割り当てられ、目標が異なります。 たとえば、ショートカット キーは Ctrl キーと Function キー シーケンスを使用し、主にアクセシビリティの代わりに高度なユーザーのショートカットとして使用します。

詳細については、「 キーボード」を参照してください。

アクセシビリティのための設計: 3 つの基本的なプラクティス

アクセシビリティと使いやすさの目的が重複しているため、アクセシビリティプログラムは何らかの方法ですべてのユーザーを支援します。 たとえば、高度なユーザーを可能な限り効率的にするように設計された機能は、器用性障害のためにキーボードの使用を好むユーザーにも役立ちます。

アクセシビリティの高い設計に役立つ 3 つの基本的なプラクティス:UI の柔軟性を高め、ユーザーのニーズと好みを尊重して設計上の決定に大きな役割を果たし、UI へのプログラムによるアクセスを提供します。

柔軟な UI の提供

アクセシビリティの高い設計は、少なくとも部分的には、ユーザーに選択肢を与えることです。 フラストレーションが高く、めまいがする選択肢ではなく、ユーザーのニーズをスマートに予測する選択肢の数は限られています。 "マウスを使って移動するのが好きではないですか? ここでは、キーボードのみを使用してまったく同じ操作を行うことができます。 物理キーボードが気に入らない場合 画面上で使用できる仮想マシンを次に示します。"

たとえば、次の方法で柔軟性を提供します。

  • テキスト以外の要素に対してユーザーが選択できる同等の要素を提供します (たとえば、グラフィックスの代替テキスト、オーディオのキャプションなど)。

    サインイン ボタンのスクリーン ショット

    サインイン ボタンの代替テキストのスクリーン ショット

    グラフィックスをレンダリングしないことを選択したユーザーには、代わりに代替テキストが表示され、コントロールの動作とその操作方法が記述されている必要があります。

  • 色の代替手段を提供する (アイコンの区別やサウンドの使用など)。

    灰色の網掛け (グレースケール) のアイコンのスクリーン ショット

    この例では、標準アイコンはデザインに基づいて簡単に区別できます。

  • ユーザーがマウスまたはキーボードを使用してプログラム内で同じ操作を実行できるように、キーボード アクセス (たとえば、すべての対話型コントロールのタブ 位置) を確認します。

  • プログラムがユーザーに適切なカラー コントラスト オプションを提供していることを確認します。 Windows にはハイ コントラスト オプションが用意されていますが、これは本当に重度の視覚障穏のソリューションとして設計されています。 その他のコントラスト オプションは、低視力や色覚障睡などの軽度の障害を持つユーザーに最適です。

  • ユーザーがプログラムの UI 内のテキストのサイズを調整する方法があることを確認します (たとえば、スライダー コントロールやフォント サイズのドロップダウン ボックスを使用)。 可能であれば、高ドット/インチ (dpi) モードをサポートします。

  • プログラムがマルチモーダルであることを確認します。つまり、一部のユーザーがプログラムのプライマリ モードにアクセスできない場合、これらのユーザーは問題を回避できます。 たとえば、アニメーションを表示する場合、ユーザーのオプションで、少なくとも 1 つのアニメーション化されていないプレゼンテーション モードで情報を表示できる必要があります。

マルチモーダル インターフェイスと柔軟なナビゲーションは、基本的にユーザーに情報冗長性のアーキテクチャを提供します。 冗長性には負の意味合いがある場合があります。たとえば、ユーザー インターフェイス テキストでは、読み取りエクスペリエンスを効率化するために冗長性を削除することをお勧めします。 しかし、アクセシビリティのコンテキストでは、冗長性は肯定的でフェールセーフなメカニズムとエクスペリエンスを意味します。

ユーザーを尊重する

アクセシビリティの高いプログラムを設計するには、一般的な指針としての尊重が不可欠です。 知的な演習としても、無効になっているユーザーとしてプログラムに遭遇することがどのようなものでなければならないかを想像してください。 ハイ コントラスト モードとさまざまな解像度で UI 画面をテストし、視覚障疳を持つユーザーにとってエクスペリエンスが優れたエクスペリエンスであることを確認します。 [簡単操作センター] コントロール パネル項目の [下線] キーボード ショートカットとアクセス キー チェック ボックスを選択して、キーボードのアクセシビリティをテストします (アクセス キーが常に表示されるようにします)。 最初に他の人と共感するための自然な適性を持つ開発者やデザイナーを雇うことで、厳格なテストを超えることさえできます。

また、次の点で敬意を示す必要があります。

  • 特定のプログラムの設定をハードワイリングするのではなく、システム全体の設定 (システムカラーなど) を使用する。 ユーザーがプログラムを操作するために特別に選択したパラメーターだけでなく、使用しているプログラムに関係なく、ユーザーが有効にしたいオペレーティング システムに組み込まれているアクセシビリティ機能も考慮してください。 詳細については、「 Windows アクセシビリティ機能について」を参照してください。
  • 一般的なコントロールは既に Windows アクセシビリティ API を実装しているため、カスタム コントロールに共通のコントロールを優先します。
  • すべてのアクセシビリティ オプションと機能 (たとえば、すべてのキーボード ショートカット) を文書化します。 障害を持つユーザーは、アクセシビリティ機能を見つける意欲が高く、多くの場合、ヘルプで包括的な情報が収集されることを期待しています。
  • アクセシビリティ対応のドキュメントをアクセシビリティ対応形式で作成する。 したがって、ドキュメント自体は、フォント サイズを拡大する機能、グラフィックス用の代替テキストの使用、冗長な情報アーキテクチャ (テキストの補足としてのみ色分けを使用するなど) など、プライマリ UI と同じアクセシビリティ規則に従う必要があります。

ソフトウェア製品では、ユーザーに対する尊重は、ユーザビリティと市場調査、効果的なサポートサービスとドキュメント、そしてもちろん設計上の決定に現れる可能性があります。 たとえば、高度なユーザー向けの設計の観点から考え直します。この最先端の新機能は、必要な場合や、上級ユーザーが求めていることがわかっているからです。 後者のケースは、設計の意思決定プロセスが尊重の価値によって十分に知らされていることを示します。

プログラムによるアクセスの提供

UI へのプログラムによるアクセスを提供することは、支援技術 (スクリーン リーダー、代替入力デバイス、音声認識プログラムなど) がユーザーの画面を正しく解釈するために不可欠です。 プログラム内の各 UI 画面の "マップ" を作成することで、支援技術のユーザーが利用できるようにします。

これを行うには、次の方法を使用します。

  • すべての UI 要素とテキストへのプログラムによるアクセスを有効にする (たとえば、Active Accessibility COM インターフェイス IAccessible を使用)。
  • UI オブジェクト、フレーム、ページに名前 (またはタイトル) と説明を配置します (たとえば、 IAccessible Name プロパティを使用)。
  • プログラムイベントがすべての UI アクティビティ (フォーカス移動を含むすべての UI アクティビティのフォーカス イベントなど) によってトリガーされるようにします。

4 つの操作のみを行う場合...

  1. すべてのユーザーがプログラムの可能性を最大限に活用できることを確認します。
  2. アクセシビリティは、創造的な問題解決の機会であり、全体的なユーザー満足度を高めるもう 1 つの手段と考えてください。
  3. システム設定を尊重します。
  4. 可能な限り、一般的なコントロールを使用します。

ガイドライン

全般

  • オペレーティング システムや、アクセシビリティ機能として識別されている他の製品のアクティブ化された機能を中断または無効にしないでください。 これらの機能は、問題のオペレーティング システムまたは製品のドキュメントを参照することで識別できます。
  • ユーザーが画面の上部ウィンドウとしてプログラムを操作するように強制しないでください。 ユーザーがタスクを実行するために関数またはウィンドウが継続的に必要な場合、他のウィンドウに対する相対的な位置に関係なく、ユーザーが選択した場合、そのウィンドウは常に表示されたままにする必要があります。 たとえば、ユーザーが他のすべてのウィンドウの上に移動可能なスクリーン キーボードを持っていて、常に表示されるようにしている場合、プログラムは Z オーダーの上部にある必須の配置によって隠すことはありません。
  • 可能な限り、システムの色、フォント、および一般的なコントロールを使用します。 これにより、ユーザーが遭遇するアクセシビリティの問題の数を大幅に減らすことができます。

特定の障害に対処する

Visual

  • 意味を伝えるために色だけに頼ってはいけません。 色は、テキスト、デザイン、場所、またはサウンドによって提供される意味を強化する手段としてのみ使用します。

    赤いコミュニケーター アイコンとヒントのスクリーン ショット

    この例の通信の主な方法は、簡潔なヒント テキストです。 色の使用は意味を伝えるのに役立ちますが、二次的です。

  • 代替テキストヒント (代替) を使用して、グラフィックスを記述します。

  • グラフィックスでテキストを使用しないでください。 視覚障害のあるユーザーは、グラフィックスがオフになっている (Web ブラウザーなど) 場合や、グラフィックスに配置されたテキストが表示されない、または検索されない可能性があります。

  • ダイアログ ボックスとウィンドウにわかりやすい名前を付けて、 画面を表示せずに聞いているユーザー (スクリーン リーダーを使用するなど) が適切なコンテキスト情報を取得できるようにします。

  • 常に Theme API と GetSystemMetrics API からフォントの書体、サイズ、色、Windows 表示要素のサイズ、およびシステム構成設定を取得することで、視覚的な表示に対するユーザーの設定を考慮します。

  • 吹き出しのテキストを簡潔 にして、読みやすくし、スクリーン リーダーの中断を最小限に抑えます。

    ピン コードの制限を示すバルーンのスクリーン ショット

    吹き出しでは必要に応じて追加の本文を使用できますが、この例では、タイトル テキストだけでは、より経済的でアクセスしやすい方法で同じ目標を達成する場合があることを示しています。

聴力

  • 音だけに頼って意味を伝えてはいけません。 サウンドは、テキスト、デザイン、場所、または色によって提供される意味を強化する手段としてのみ使用します。
  • ユーザーがオーディオ出力の音量を制御できるようにします。 この目的のために Windows ボリューム ミキサーを使用します。 詳細については、「 サウンド」を参照してください。
  • 500 Hz から 3000 Hz の範囲で発生するプログラムのサウンドをターゲット にするか、その範囲にユーザーが簡単に調整可能です。 この範囲の音は、聴覚障を持つ人が検出できる可能性が最も高いです。

器用 さ

  • 絶対時間を使用する代わりに、GetDoubleClickTime() を基準にして UI タイムアウト値を設定します。 これにより、ユーザーの速度に合わせてタイムアウトが調整されます。
  • キーボードの操作を好むユーザーが、マウスを操作するユーザーと同じ機能を持つように、すべてのメニュー項目にアクセス キーを割り当てます。
  • アクションを実行する唯一の方法として、ダブルクリックやドラッグはしないでください。 これらは、一部のユーザーにとって困難な動きになる可能性があります。
  • プログラムからメニュー バーを削除しないでください。 メニュー バーは、キーボード ユーザーがアクセスできるツール バーよりも簡単です。 既定でメニュー バーを表示しない場合は、代わりに非表示にします。
  • ヘルプ ボタンとリンクのタブ位置を指定して、キーボードからヘルプにアクセスできるようにします。
  • プログラム内のアクセス キーの割り当ての認識を向上させるために、常に表示できます。 コントロール パネルで、[簡単操作センター] に移動し、[キーボードを使いやすくする] をクリックし、[下線のショートカット キーとアクセス キー] ボックスチェック選択します。

認知的

  • 複雑さを隠すには、段階的な開示を使用します。

    三角形の分割ボタンのスクリーン ショット

    これらの例では、コマンド ボタンから使用できるオプションは既定で非表示になり、ユーザーは段階的な開示コントロールを利用してオプションを表示できます。

  • アイコン、ツール バー、その他の視覚補助を使用して、 テキストの読み取り負荷を軽減します。

  • 可能な場合は、 テキスト ボックスと編集可能なドロップダウン リストでオートコンプリート機能を提供して、ユーザーが限られたオプション セットからコマンド名、ファイル名、または同様の選択肢の名前全体を入力する必要がないようにします。 これにより、すべてのユーザーの認知的負荷が軽減され、スペルや入力が困難、遅い、または痛みを伴うユーザーの入力量が減ります。

  • チュートリアルやアニメーションを含めることで、ヘルプで難しい概念を示します。 発作性障害を持つユーザーはアニメーションが困難な場合があるため、必要な場合にのみ使用する必要があることに注意してください。

発作

  • 点滅または点滅するテキスト、オブジェクト、または 2 ~ 55 Hz の範囲で点滅または点滅の頻度を持つ他の要素を使用しないでください。
  • アニメーションの使用を制限します。 一部のユーザーは、特に視覚分野の周辺で、画面の動きに特に敏感です。 アニメーションを使用して何かに注意を向ける場合は、注意が必要であり、ユーザーを中断する価値があることを確認してください。

音声または言語

  • 明確で簡潔でわかりやすいテキストを整理して書きます。 ユーザビリティ テストは、フレーズの末尾に重要な情報を展開すると理解力が向上することを示しています。 その他のガイドラインについては、「 スタイルとトーン」を参照してください。

正しくない:

3 桁は次の数字ですか?

[OK] をクリックして開始します。

正確:

次の数字は 3 ですか?

開始するには、[OK] をクリックします。

アクセス キー

  • 幅が広い文字 (w、m、大文字など) を優先します。
  • "Exit" の "x" など、独特の子音または母音を好みます。
  • (最も問題のある文字から最も問題の少ないものまで) など、下線が見えにくい文字は使用しないでください。
    • i や l など、幅が 1 ピクセルのみの文字。
    • g、j、p、q、y などの降順の文字。
    • 降順の文字の横にある文字。

  • すべてのメニュー項目にアクセス キーを割り当てます。 例外。

  • 動的メニュー項目 (最近使用したファイルなど) の場合は、アクセス キーを数値で割り当てます。

    最近使用したファイルを含む開いているメニューのスクリーンショット

    この例では、Windows の Paint プログラムによって、最近使用されたファイルに数値アクセス キーが割り当てられます。

  • メニュー レベル内で一意のアクセス キーを割り当てます。 アクセス キーは、さまざまなメニュー レベルで再利用できます。

  • アクセス キーを簡単に見つけられるようにする:

    • 最も頻繁に使用されるメニュー項目の場合は、ラベルの最初または 2 番目の単語の先頭にある文字 (できれば最初の文字) を選択します。
    • 使用頻度の低いメニュー項目の場合は、ラベル内の独特の子音または母音である文字を選択します。

ダイアログ ボックスのアクセス キー

  • 可能な限り、すべての対話型コントロールまたはそのラベルに一意のアクセス キーを割り当てます。読み取り専用のテキスト ボックス は対話型のコントロールです (ユーザーはスクロールしてテキストをコピーできるため)。そのため、アクセス キーの利点があります。 アクセス キーを次に割り当てないでください。

    • [OK]、[キャンセル]、[閉じる] の各ボタン。 Enter と Esc がアクセス キーに使用されます。 ただし、OK または Cancel を意味するが、ラベルが異なるコントロールには常にアクセス キーを割り当てます。

      アクセス キーが割り当てられたコントロールのスクリーン ショット

      この例では、正のコミット ボタンにアクセス キーが割り当てられます。

  • ラベルをグループ化します。 通常、グループ内の個々のコントロールにはアクセス キーが割り当てられるため、グループ ラベルにはアクセス キーは必要ありません。 ただし、アクセス キーが不足している場合は、個々のコントロールではなく、グループ ラベルにアクセス キーを割り当てます。

  • F1 でアクセスされる汎用ヘルプ ボタン。

  • ラベルをリンクします。 一意のアクセス キーを割り当てるリンクが多すぎることが多く、リンクアンダースコアによってアクセス キーのアンダースコアが非表示になります。 ユーザーに Tab キーを使用してリンクにアクセスしてもらう。

  • タブ名。 タブは、Ctrl + Tab キーと Ctrl + Shift + Tab キーを使用して循環されます。

  • "..." というラベルの付いた [参照] ボタン。 これらは、アクセス キーを一意に割り当てることはできません。

  • ラベルのないコントロール (スピン コントロール、グラフィック コマンド ボタン、ラベルなしプログレッシブ 開示コントロールなど)。

  • 非ラベル静的テキストまたは対話型ではないコントロールのラベル (進行状況バーなど)。

  • コミット ボタンのアクセス キーを最初に割り当てて、標準キーが割り当てられていることを確認します。 標準のキー割り当てがない場合は、最初の単語の最初の文字を使用します。 たとえば、[はい] および [いいえ] コミット ボタンのアクセス キーは、ダイアログ ボックスの他のコントロールに関係なく、常に "Y" と "N" である必要があります。

  • "Don't" と表現された負のコミット ボタン ([キャンセル] 以外) の場合は、"Don't" の "n" にアクセス キーを割り当てます。 "Don't" と表現されていない場合は、標準のアクセス キーの割り当てを使用するか、最初の単語の最初の文字を割り当てます。 そうすることで、すべての Don'ts と No' には一貫したアクセス キーがあります。

  • アクセス キーを見つけやすくするには、ラベルの早い段階に表示される文字にアクセス キーを割り当てます。ラベルの後に表示されるキーワード (keyword)がある場合でも、最初の文字が理想的です。

その他のガイドラインと例については、「 キーボード」を参照してください。

Text

  • 外部コントロール ラベルの末尾にコロンを使用します。 一部の支援テクノロジでは、制御ラベルを識別するためのコロンが検索されます。

  • ラベルがラベル付けされている要素を基準にして、ラベルを一貫して配置します。 これは、支援技術がラベルを対応するコントロールに正しく関連付けるのに役立ち、スクリーン 拡大機能のユーザーがラベルまたはコントロールを探す場所を知るのに役立ちます。

    一貫して配置されたラベルのスクリーン ショット

    この例では、各ドロップダウン リストのラベルを一貫して配置し、コロンを使用します。

  • 代替テキストを最大 150 文字に制限します。 コントロールをアクティブ化するアクション (クリック、右クリックなど) について説明し、コントロールの関数について説明します。

    普通：

    ボタン。

    青い丘。

    より適切な例:

    クリックしてアカウントにサインインします。

    遠くの丘の写真。遠くで色がフェードする様子を示しています。

  • テキストを使用して線、ボックス、またはその他のグラフィカル 記号を描画しないでください。 この方法で使用される文字は、スクリーン リーダーのユーザーを混乱させる可能性があります。 たとえば、テキストの領域の周りに文字 "X" で描画されたボックスは、スクリーン リーダー ソフトウェアによって最初の行に "X X X X X X" として読み取られ、その後に "X" とコンテンツと "X" が続きます。

ドキュメント

  • すべてのアクセシビリティ オプションと機能 (たとえば、すべてのキーボード ショートカット) を文書化します。
  • アクセシビリティ対応のドキュメントをアクセシビリティ対応の形式で作成します。 したがって、ドキュメント自体は、プライマリ UI と同じアクセシビリティ規則に従う必要があります。
  • ショートカット キー (意味と使用方法が異なる)、ニーモニック キー、アクセラレータではなく、アクセス キーを参照してください。
  • 一般に、障害のある人ではなく、ある種の障害を持つ人を参照してください。 ラベルではなく、最初に人物を考えてみましょう。
これらの用語を使用する 以前のシステム ストアド プロシージャ
器用さが限られており、運動障害がある
 Crippled、lame
障もなく
 正常、身体が可能、健康
片手で、片手で入力する人
 片手
障のあるPeople
 障がい者、障酛者、障酛者、障害者
認知障害、発達障害