開発者およびQAテスター向けアクセシビリティ
概要
これらの文書は主要なデザインの基礎をすべて網羅しており、プロジェクト開始時にチームが確認する必要があります。これらは特定のコンポーネント設計に関連しない主要なウェブアクセシビリティのベストプラクティスをすべて扱っています。多くのコンポーネント文書と同様に、QAの受け入れ基準としてプロジェクトマネージャーが使用できるテストや、開発者がその基準を満たすために使用できる手法が含まれています。
これらのガイドは、Googleの マテリアルデザインを含むあらゆるデザインシステムをサポートするように設計されており、WordPress、SAP、Salesforceなどのサードパーティプラットフォーム向けのアクセシブルデザインを支援するためにも使用できるため、任意のプロジェクトのどのスプリントでも使用できます。
さらにアクセシビリティのトレーニングやアドバイスは、以下のYouTubeチャンネルで見つけることができます：
1. アクセシブルなコンポーネントの作成
新しいコンポーネント設計を行う際、特定のインタラクション設計に固有であるためアクセシビリティガイドラインでカバーされない問題が発生することがあります。
そのような場合は、ウェブ上の他の場所で利用可能なベストプラクティスを特定するために追加の調査が必要です。次のページでは、追加の調査が必要なコンポーネントの一覧と、コンポーネントがユーザーの期待に応えるために使用できる手法と方法論を提供します。
適切な場合、ガイダンス文書には要求されるコードの振る舞いを示す参照実装と推奨されるQAテストが含まれています。
テスト
チームがテスト基準を作業計画に組み込めるよう、以下のアクセシビリティテストスクリプトはプロジェクトマネージャーと開発者の双方がアクセシビリティの成功基準を満たすのに役立ちます。自動テストも次を通じて利用可能です： UTS Test Magic, Cypress, Sa11y for Salesforce そして次の手動テストスクリプトと組み合わせて使用する必要があります： Colt 開発者テストスクリプト.
スクリーンリーダーのアクセシビリティをテストするには、Windows Narrator を使用してコンポーネントやアプリケーションのアクセシビリティを確認してください。ガイド「 Webアクセシビリティをテストするための Windows Narrator の使用」 はコントロール、アプローチ、および期待される数値を概説しています。
ウェブページはブラウザプラグインで部分的にテストできます。Microsoft Edge と Google Chrome で動作する商用・非商用のプラグインがいくつかあります。信頼性が高く無料で使用でき、バグ追跡に使えるスプレッドシートを出力するもののひとつが IBM の Equal Access Tracker です：
自動テストツールによって結果が異なる場合があり、中には商用または準商用でレポートを出力しないものもあります。プロダクトチーム全員が同じツールを使用していることを確認してください。
ガイドラインの手動テストや Windows Narrator によるテストと組み合わせて使用すれば、ほとんどの利用上のアクセシビリティ問題は簡単に見つけて修正できます。
この Sparkbox による概要 は IBM のテストツールの主要な機能をすべて扱っています。
コンポーネントガイド
以下のベストプラクティスガイドは、さまざまなサードパーティのデザインシステム、ブログ、信頼できるドキュメントリソースから引用したもので、デザインが Colt によって実装されているものとまったく同じでない場合でも、方法論や手法は潜在的な問題とその解決策を理解する有効な手段です。
ナビゲーション
インタラクティブコンテンツ
チャート, グラフ, データテーブル & インフォグラフィック
メタフィールド
データ入力
2. プラットフォームのアクセシビリティ
Salesforce、SAP、WordPressなどのサードパーティのプラットフォームやフレームワーク上でウェブページ、アプリ、コンポーネントを作成する場合、各プラットフォームはそれぞれ固有のガイダンスを提供します。これらはColtアクセシビリティガイドに加えて使用する必要があります。
WordPress
Salesforce
SAP
3. 色の知覚
すべての色は人によってわずかに、あるいは大きく異なって知覚され、色相のいくつかをまったく区別できない人も多くいます。Colt のウェブページデザインが正確な色の知覚に依存しないようにすることは、デザイン上のいくつかの機能が色に依存しているために誰も排除されないようにすることを意味します。
しかし、Colt のブランドカラーを配慮して使用することで、一部のユーザーのアクセシビリティを高め、多くのユーザーにとっての使いやすさを向上させることができます。したがって、ウェブページで色に基づく意味を避けるのではなく、色が視覚的手がかりとして使われる場合は、色以外の代替の視覚的手がかりも提供されていることを確認してください。これはデザインやエンジニアリングではしばしば「冗長性.'
赤緑色覚異常は、いわゆる最も一般的な形態です 色覚異常。男性では約12人に1人、女性では約200人に1人に影響します。青黄色の色知覚障害ははるかに一般的ではなく、単色の色覚異常はさらに稀です。さらに、次のような他の状態も色の処理に問題を引き起こすことがあります： 共感覚（シネスセシア）, 緑内障, アーレンズ症候群（Irlens 症候群） および一部の人々では 発達障害（ASC） が色の処理に問題を引き起こすことがあります。
テスト方法
各ウェブページについて、次のチェックを実行してください。各質問に「はい」または「いいえ」で回答を記録します。合格結果は各質問の後に大文字で示されます（例：[Y/N]）。Y が合格のために必要です。不合格の結果については、次のいずれかとして記録してください：
欠陥として
欠陥だが例外として許容される理由の説明付き
欠陥だが該当しない理由の説明付き
手動で実施すべきテスト
以下は、確認すべき主要な質問の例をいくつか示します：
ページ上の各リンクは、色を使わなくても視覚的に識別可能ですか？ [Y/N]
ページ上の各機能（検証や進捗表示など）とやり取りしたときに、色が無効でもそれぞれの状態がわかりますか？ [Y/N]
チャートやグラフに関して、カテゴリやデータセットは色以外の視覚処理で識別できるようになっていますか？ [Y/N]
追加のテスト方法と戦略
もしあなた自身が色覚異常でない場合は、色覚異常シミュレータでウェブページをテストできます。 Sim Daltonism アプリを携帯電話にインストールすると、カメラの前のものすべてに色覚フィルターを適用するビューワーが開きます。
4. フォームのやり取り
フォームは視覚障害や認知障害のあるユーザーにとって困難となることがあります。フォームが適切に設計され、アクセシブルであることを確保するということは、ユーザーが意図どおりにそれらのフォームを理解し使用できることを意味します。
ウェブフォームが慣習と良好なユーザビリティの実践を適用すると、ユーザーはフォームをより速く、初回の試行でより少ないエラーで完了できます。フォームはログインや雇用機会、顧客になるための最終ステップ、あるいは問題や苦情を報告する唯一の手段を通じて Colt のコンテンツやサービスへの入口となり得ます。フォームが不適切に設計または実装されていると、障害のあるユーザーを完全に排除してしまいます。
テスト方法
各ウェブページについて、次のチェックを実行してください。各質問に「はい」または「いいえ」で回答を記録します。合格結果は各質問の後に大文字で示されます（例：[Y/N]）。Y が合格のために必要です。不合格の結果については、次のいずれかとして記録してください：
欠陥として
欠陥だが例外として許容される理由の説明付き
欠陥だが該当しない理由の説明付き
自動化できるテスト
以下は手動スキャンを必要としないテストの例です：
各入力項目にセマンティックに有効な HTML の label 要素が関連付けられていますか？ [Y/N]
手動で実施すべきテスト
以下は、確認すべき主要な質問の例をいくつか示します：
キーボードのみで、フォーム全体を完了し、エラーの訂正を行い、送信することができますか？ [Y/N]
フォームのタブ順（ 視覚的なフォーカスインジケータで示されるように）は、視覚を有するキーボードユーザーにとって論理的で予測可能ですか？ [Y/N]
必須の入力フィールドは視覚的にマークされていますか、また入力要素に HTML input required 属性が使用されていますか？ [Y/N]
エラーメッセージは、どの入力フィールドが入力を拒否したのか、その理由、そしてどのように修正すればよいかを明確に示す形で記述および表示されていますか？［Y/N］
リセット、時間制限 & 検証
リセットボタン
フォームで リセットボタン の使用は避けてください。リセットボタンはほとんど使われず、誤ってクリックするだけで記入済みのフォーム全体が消えてしまうと非常に苛立ちます。リセットボタンがない場合、ラジオボタングループは特定のケースで問題になることがあります。これらの特徴の一つは、一度グループ内の任意のオプションを選択するとそのグループを「選択解除」できず、同じグループ内の別のラジオボタンに選択を移すことしかできない点です。このため、適切な場合には「上記のいずれでもない」タイプのオプションを含めることを推奨します。
タイミング
処理に時間がかかる場合（見積りの仕様入力や求人応募など）、タイムアウトが短すぎるフォームは苛立たしいことがあります。フォームにタイムアウトの必要性がない場合は、データが少なくとも 20時間は保持されるようにしてください。もしタイムアウトを設ける必要がある場合は、平均的な視覚ユーザーが必要とする時間の少なくとも5倍以上の長さにし、 タイミングを指示書で伝えること.
検証
フォームを検証する際、エラーの原因となったユーザーが入力した元の値を消去しないようにしてください。ユーザーの元の値を保持することで、ユーザーは自分の間違いを見つけやすくなり、編集して修正できます。WAI-ARIA 属性を使用すると、支援技術の利用者にとって検証エラーが追いやすくなる場合があります。各無効な入力フィールドにエラーがあることを示すために aria-invalid 属性 を使用し、特定のエラーメッセージをその入力フィールドに関連付けるために aria-describedby 属性 を使用してください。
エラーメッセージ
エラーメッセージがまったく表示されない場合は重大な欠陥と見なされるべきです。フォーム送信が拒否されても、続行するために何を修正すべきかを説明するフィードバックがないと、フォームは使えなくなります。
エラーメッセージは、フォーム送信が拒否された理由を簡潔かつ具体的に説明するべきであり、長い専門用語の羅列を含めないようにします。エラーコードがある場合は、技術的ではない方法で説明するべきです。
表示されうるすべてのエラーメッセージが次の要件を満たしているか確認してください：
具体的であること： 「エラーが発生しました」や「フォームが無効です」だけでは役に立ちません。メッセージはどの入力フィールド（複数ある場合はどの複数のフィールド）が無効であったか、なぜ拒否されたのかを明確にするべきです。エラー内の入力フィールド名は、エラーが発生した入力フィールドのラベルと正確に一致していなければなりません。
親切であること： ユーザーがミスをした場合でも、体験は助けになるものであるべきです。「ユーザーエラー：不正な入力」のような攻撃的に聞こえる表現は、たとえ技術的に正しくても良いユーザー体験を生まないため避けてください。
実行可能であること： 問題があることとその内容を伝えるだけでは十分ではありません。ユーザーは問題を解決するためにどのような手順を踏めばよいかも知る必要があります。次に進むために何をすべきかについての情報があるか確認し、必要に応じてFAQやヘルプデスクへのリンクを提供してください。
プレースホルダーテキスト
これは入力欄の 内部に 表示される語句で、役立つヒントとして提示されます。正しいラベルの代替ではなく、ラベルを重複するべきではなく、追加の指示やヒントを提供するものです。
ラベルの代替となるプレースホルダーは、キーボードユーザーにとって使いにくいです。なぜなら、ユーザーがタブでテキストフィールドに入ると指示が消えてしまうためです。プレースホルダーテキストのコントラストは意図的に低く設定されているためラベルの代替には適さず、プレースホルダーテキストは折り返しができないので、狭い画面では全文を表示できない場合があります。
5. キーボードアクセス
多くの種類のキーボード（または同等の スイッチデバイス）が人々によりウェブページのナビゲーションに使われますが、実装の観点から次のグループを考慮する必要があります：
その他すべてのキーボードユーザー、つまり 少なくとも 部分的に画面を見ることができ、スクリーンリーダーを補助的に使うかどうかは問わないが、画面上に表示される視覚的手がかりに依存してナビゲートするユーザー。
トラックパッドやマウスなどのポインティングデバイスにアクセスできない、または 反復性負荷障害（RSI）や脳性まひ、四肢の差異などの身体的な状態があり、キーボードの方が適しているユーザー。
その ウェブコンテンツアクセシビリティガイドライン（WCAG） ウェブページ提供者に対して「可能な限り、コンテンツがキーボードまたはキーボードインターフェースで操作できることを確保するように」" キーボードサポートがないと、これらのユーザーはあなたのウェブページにアクセスできなくなります。A スクリーンリーダーユーザーに関するWebAIMの調査 はかなりの割合のユーザーが「キーボードアクセシビリティの欠如」が問題だと示したことを明らかにしました。アクセスにはフォーム、ナビゲーションメニュー、インタラクティブウィジェット、ポップアップ、アラート、およびページ上のその他すべてのタイプのコンポーネントの使用が含まれる場合があります。
フォーカス可能なコントロール要素
リンク： Enterキーでリンクをアクティブ化/フォローできるべきです
ボタン： EnterキーまたはSpaceキーでボタンをアクティブ化/押せるべきです
チェックボックス/ラジオボタン： 矢印キーでハイライト項目を移動し、Spaceキーでハイライト項目をチェックまたはチェック解除できるべきです
セレクト（ドロップダウン）： 矢印キーでハイライト項目を移動し、Enterキーでハイライト項目を選択できるべきです
ダイアログ： Escキーでダイアログを閉じるべきです
フォーカスを視認可能に保つこと
ウェブブラウザは、ページ上でどの要素がフォーカスを持っているかを示すために可視のアウトラインを追加することで、フォーカス表示に関してはすでにアクセシブルです。CSSでそのフォーカスをスタイル指定することで、インジケータをカスタマイズしたり無効にすることもできます。フォーカスインジケータが欠落している、または見づらい場合は欠陥と見なすべきです。
注1：フォーカスを示すために色の変化だけを使用することは、色を識別できないユーザーにはアクセシブルではありません。
注2：キーボードナビゲーションで必要な機能（例：:focus {outline:none;}）を無効にしないでください。
フォーカス時に可視であること
画面上で視覚的に隠されているが、キーボードナビゲーションでフォーカスを受け取ることができるコンテンツは、フォーカスを受けたときに可視になるように作成する必要があります。例としては、各ページの上部にあるすべてのナビゲーションコンテンツを素早く飛ばしてメインコンテンツに移動できるようにする「メインコンテンツへスキップ」リンクがあります。
検証
フォームを検証する際、エラーの原因となったユーザーが入力した元の値を消去しないようにしてください。ユーザーの元の値を保持することで、ユーザーは自分の間違いを見つけやすくなり、編集して修正できます。WAI-ARIA 属性を使用すると、支援技術の利用者にとって検証エラーが追いやすくなる場合があります。各無効な入力フィールドにエラーがあることを示すために aria-invalid 属性 を使用し、特定のエラーメッセージをその入力フィールドに関連付けるために aria-describedby 属性 を使用してください。
キーボードショートカット
デスクトップアプリケーションで定義された多くのよく知られたキーボードショートカットがある一方で、存在する無数の異なるウェブページでは同じことは言えません。accesskey属性を使ってカスタムショートカットキーを定義することは可能ですが、ユーザーがそれらを予測したり明白に学習できない場合、アクセシビリティの向上にはつながりにくいです。さらに、こうしたショートカットキーがブラウザや支援技術で定義された組み込みの標準ショートカットと競合すると、状況を悪化させる可能性もあります。一般的なショートカットについては BBC GEL メガペディア.
キーボードトラップの回避
「キーボードトラップ」は、ウェブページ上の機能がユーザーがフォーカスされた要素から離れることを妨げるときに存在します。もちろんこれは起こるべきではありませんが、実装が不適切なJavaScriptは、ウェブページの作成者が注意しないとキーボードフォーカスの通常の動作を破壊することがあります。
テスト方法
各ウェブページについて、次のチェックを実行してください。各質問に「はい」または「いいえ」で回答を記録します。合格結果は各質問の後に大文字で示されます（例：[Y/N]）。Y が合格のために必要です。不合格の結果については、次のいずれかとして記録してください：
欠陥として
欠陥だが例外として許容される理由の説明付き
欠陥だが該当しない理由の説明付き
（少なくとも部分的に）手動で実施すべきテスト
以下は、確認すべき主要な質問の例をいくつか示します：
Tabキーを使って前方に移動し、 Tab キーで、Shift+Tabキーの組み合わせを使ってフォーカスを移動させ、それぞれのリンクとコントロールにマウスやタッチスクリーンを使わずにアクセスして使用できるようになっていますか？ [Y/N] Shift+Tab キーの組み合わせでフォーカスを移動でき、各リンクやコントロールにマウスやタッチスクリーンを使わずにアクセスでき、使用できますか？ [Y/N]
フォーカスを移動すると、現在ウェブページ上でどの要素がフォーカスを持っているかが一貫した、視覚的にコントラストのあるアウトラインなどで明確に表示されますか？ [Y/N]
フォーカスを移動すると、フォーカスを受け取る各要素は論理的で予測可能な順序（英語などの左から右へ読む言語の場合は上から下、左から右）に従って移動しますか？ [Y/N]
フォーム要素を含むインタラクティブなコンポーネントに関して、矢印キー、Enterキー、Spaceキー等を使って各要素をナビゲートおよび操作し、可能なオプションの設定を含めて操作できますか？ [Y/N]
新しいコンテンツが開くまたは表示されるときに自動的にフォーカスを移動する複雑なコンポーネントについて、当該コンテンツが閉じられたときにフォーカスは元の要素に戻りますか？ [Y/N]
ページ読み込み時に視覚的に隠されているコンテンツについて、キーボードフォーカスがその要素に移動したときにそのコンテンツは可視になりますか？ [Y/N]
6. インタラクティブ要素のラベル
フォームコントロールやその他のインタラクティブ要素には適切にラベルが付けられている必要があります。これを怠ると、支援技術ユーザーがコントロールの目的を理解するのが難しくなります。ラベルが欠如している、または誤ってラベル付けされたインタラクティブ要素は、ユーザーに問題や混乱を引き起こす可能性があります。
その ウェブコンテンツアクセシビリティガイドライン すべてのインタラクティブ要素にはラベルとアクセシブルネームの両方が必要であると規定しています。ラベルは視覚的に表示され、アクセシブルネームはスクリーンリーダーのような支援技術で使用されます。多くの場合、この二つは同じです。例えば、リンクがテキストをラップしている場合、 "ホーム"のように、 Home というテキストが "ホーム" ラベルでありアクセシブルネームです。
同様に、テキストを含むボタン "送信" は視覚的なラベルとアクセシブルネームの両方として "送信".
テスト方法
各ウェブページについて、次のチェックを実行してください。各質問に「はい」または「いいえ」で回答を記録します。合格結果は各質問の後に大文字で示されます（例：[Y/N]）。Y が合格のために必要です。不合格の結果については、次のいずれかとして記録してください：
欠陥として
欠陥だが例外として許容される理由の説明付き
欠陥だが該当しない理由の説明付き
手動で実施すべきテスト
以下は、確認すべき主要な質問の例をいくつか示します：
どの種類の情報を入力することが期待されているかを識別する可視のテキストラベルがありますか？ [Y/N]
ラベルはそれが説明するコントロールの近くにあり、どのコントロールを指しているのかが明らかですか？ [Y/N]
コントロールにフォーカスがあるときでもラベルはまだ見えますか？ [Y/N]
コントロールがドロップダウンメニューやラジオボタンやチェックボックスのリストなどの選択可能なオプションのグループである場合、オプションの集合を説明する可視のテキストラベルがありますか？ [Y/N]
スクリーンリーダーでコントロールに遭遇したとき、ラベルは期待どおりに読み上げられますか？ [Y/N]
例と追加情報
ラベルとアクセシブルネームの正しい実装に必要な三つの側面は、ユーザーとそのウェブページとの相互作用に基づいています。視覚的なラベルは、カーソルやマウスでナビゲートする視覚ユーザーがインタラクティブ要素の機能を知るために明らかに必要です：例えば「タブを閉じる」ボタンをクリックする、または「サポートページ」リンクにタブ移動することが例です。
によって それらのラベルをアクセシブルな方法で提供することで、 スクリーンリーダーを使用するユーザーにも役立ちます。スクリーンリーダーはそのテキストを利用してアクセシブルネームをユーザーに読み上げます。しかし場合によっては、視覚的ラベルとアクセシブルネームが異なるように表示ラベルを適用することが可能です。これは「送信をクリック」など音声コントロールや音声認識でナビゲートするユーザーにとって問題を生み得ます。これらのユーザーはラベルを見てそれを使って支援技術を操作し、支援技術はアクセシブルネームに依存します。このため、 視覚的なラベルをアクセシブルネームと同じにしておくことを推奨します.
プレースホルダーテキストに頼らないでください
プレースホルダーテキスト プレースホルダーテキストはページ作成者によってラベルの代替として使われることがあります。これはプレースホルダがフォーム入力内に表示され、横に置かれるラベルよりスペースを節約できるためです。しかしこれは正にラベルとして不適切な理由です。デフォルトでコントラストが低いことに加え、設計上ユーザーが入力を開始するとすぐに消えます。その時点で可視のラベルはなくなります。短期記憶に障害のあるユーザーや気が散って視線を外したユーザーは、その入力が何のためのものか分からなくなるかもしれません。
title属性を追加しないでください
title属性がフォーム入力要素に追加されることがあります。多くのスクリーンリーダーはtitle属性を読み上げるのは事実ですが、これには利益がありません：より セマンティックなlabel要素 を使うことでも機能し、ラベルをクリックして入力にフォーカスを移せるという利点があります。ラベルとtitle属性の両方があると、当然両方の文字列が読み上げられ重複を招きます。
ラベルの一部をスクリーンリーダーから隠すこと
場合によっては、ラベルに使われるテキストの特定の部分が視覚的に見たときにのみ慣習的な意味を持つことがあります。例えば、アスタリスクはフォーム項目が必須であることを視覚的に示すためによく使われますが、一部のスクリーンリーダーはアスタリスクを読み上げるかもしれませんが、多くは読み上げません。代替の方法で情報が明確にされている場合、アスタリスクをスクリーンリーダーから隠すことは容認されます。
非スクリーンリーダーからラベルの一部を隠すこと
ラベルは多くの場合プレーンテキストですが、画像のような代替テキストを持つ要素であることもあります（画像がよく理解されたアイコンである場合）。ラベルがアイコンとしてのみ表示される場合、アイコンを見られないユーザーのために代替テキストを提供する必要があります。理想的には、コントロールはアイコンとともにそのテキストをすべての人に可視化しますが、デザイン上の制約で理想的でない場合があります。その場合、アイコンが視覚ユーザーにとってよく知られ理解されていることを前提に、スクリーンリーダーのみがアクセスできるラベルとしてテキストを提供することは許容されます（例：検索フォームのラベルとしての「虫眼鏡」アイコン）。
下の例は、 画像の代替テキスト セクションのテクニックの一つを使用しています。これらのテキスト代替は、画像を見ているユーザーから自然に隠されます。
7. ランドマーク
HTMLランドマークをウェブページに追加することで、支援技術がユーザーが素早く移動したい領域（例えばheader、nav、main、section、footerタグなど）を識別できるようにします。 W3CのWAI ARIAランドマークガイド.
スクリーンリーダーユーザーに関するWebAIMの調査 は、回答者の半数以上が少なくとも時々HTMLランドマークを使ってページ内をナビゲートすると明らかにしました。調査によれば、 見出し および リンクなどの他の機能の方がより頻繁に使われるかもしれませんが、仮想の道しるべの配列にHTMLランドマークを追加することは、特に視覚的に文書をスキャンできないユーザーには助けになります。
HTMLランドマークによるナビゲーションは、スクリーンリーダーがなくても視覚ユーザーと盲目のユーザーの両方で利用できる技術です。
ブラウザや支援技術にランドマークによるナビゲーション機能がないユーザー向けに、ウェブページ自体の機能として「スキップリンク」を提供することができます。スキップリンクはボディの最初のコンテンツであり、mainランドマークで識別されたコンテンツにリンクするべきです。
これは、例えばキーボードで大量のナビゲーションリンクやヘッダーコンテンツをスキャンしてから目的のコンテンツに到達しなければならないユーザーにとって有益です。ポインタ（マウスやタッチなど）でナビゲートするユーザーのためにページの乱雑さを避けるため、スキップリンクを隠すことは許容されます。 CSSを適用して そのリンクがキーボードフォーカスを受けるまで視覚的に隠されるようにします。
テスト方法
各ウェブページについて、次のチェックを実行してください。各質問に「はい」または「いいえ」で回答を記録します。合格結果は各質問の後に大文字で示されます（例：[Y/N]）。Y が合格のために必要です。不合格の結果については、次のいずれかとして記録してください：
欠陥として
欠陥だが例外として許容される理由の説明付き
欠陥だが該当しない理由の説明付き
自動化できる可能性のあるテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
ウェブページにmainランドマークで識別された領域が正確に1つありますか？ [Y/N]
ウェブページ上のすべてのコンテンツはランドマーク領域内に含まれていますか？ [Y/N]
（少なくとも部分的に）手動で実施すべきテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
主にナビゲーションリンクを表示することを目的としたページの領域はnavランドマークで識別されていますか？ [Y/N]
ページのヘッダーコンテンツはheaderランドマークで識別されていますか？ [Y/N]
ページのフッターコンテンツはfooterランドマークで識別されていますか？ [Y/N]
使用されている場合、その他のランドマークはそれぞれ含むコンテンツ（section、article、aside）を正しく伝えていますか？ [Y/N]
スキップリンクが存在する場合、そのリンクはページの上部またはその近くにあり、キーボードでナビゲートしたときにメインコンテンツにジャンプするのに使えますか？ [Y/N]
8. リンク
リンクのテキストを作成する際は、リンク先のリソースを簡潔かつ完全に記述するテキストを使用してください。これはページ全体をスキャンしてリンクのみのリストを読み上げるスクリーンリーダーユーザーにとって特に重要です。各リンクは文脈を持たず、それ自体で理解されなければなりません。
例えば、記事の要約が並んでおり、それぞれに「続きを読む」というテキストのリンクが含まれていると、スクリーンリーダーユーザーにはたくさんの「続きを読む」がリストとして提示され、どのリンクが何についてさらに読むことができるのか分かりません。
スクリーンリーダーユーザー： 「続きを読む」何を？
リンクのテキストに文脈を追加することで、スクリーンリーダーユーザーの障壁を取り除き、視覚ユーザーがどこへ移動するかを把握するのにも役立ちます。例外的な場合、視覚ユーザーにとって冗長または気を散らす可能性があるときは、文脈をスクリーンリーダーユーザーのみに利用可能な視覚的に隠されたテキストとして追加して管理できます。
「Our Values」という記事の文脈ではリンクテキストが視覚的には単に「続きを読む」で表示されても、スクリーンリーダーユーザーがページのすべてのリンクのリストを開くと「私たちの価値について続きを読む…」のように表示されます。可能な限り、スクリーンリーダーユーザー向けのコンテンツは他のユーザー向けのコンテンツと視覚的に同じにしておくべきです。すべてのスクリーンリーダーユーザーが盲目であるわけではなく、テキストが見えるスクリーンリーダーユーザーは、聞く内容と見る内容が異なると混乱するかもしれません。
リンク内のアイコン
説明的で視認可能なテキストを持つことがリンクをラベル付けする最もアクセシブルな方法ですが、よく理解されたアイコンがより自然な場合もあります。その場合、アイコンを見られないスクリーンリーダーユーザーのために代替テキストを提供する必要があります。
単純な HTMLのimg要素 はアイコンを表示します。スクリーンリーダーは「画像」があることを通知し、要素の alt属性.
にあるテキストを読み上げます。 機能的な画像のテキスト代替に関するガイドを参照してください.
外部リンク
外部サイトへリンクする場合は、ユーザーがあなたの管理下にないコンテンツに移動しようとしていることを知らせるのが、セキュリティと説明責任の観点から良い考えです。ユーザーがあなたのサイトにログインしているか、離脱時にセッションが中断される可能性がある場合は特に懸念となることがあります。
新しいタブ
リンクを新しいタブやウィンドウで開くと、一部のユーザーにとって体験が混乱したりアクセシビリティが低下することがあるため、めったに使用すべきではありません。例外として外部サイトへのリンクが考えられます。リンクが モーダル やページを新しいタブやウィンドウで開く場合は、リンクテキストでそれを説明してください。
テスト方法
各ウェブページについて、次のチェックを実行してください。各質問に「はい」または「いいえ」で回答を記録します。合格結果は各質問の後に大文字で示されます（例：[Y/N]）。Y が合格のために必要です。不合格の結果については、次のいずれかとして記録してください：
欠陥として
欠陥だが例外として許容される理由の説明付き
欠陥だが該当しない理由の説明付き
手動で実施すべきテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
各リンクに可視テキストまたはよく理解された従来のアイコンがありますか？ [Y/N]
アイコンのみを含むリンクには、グラフィックに等価なテキストが割り当てられていますか？ [Y/N]
すべてのリンクは周囲のテキストと一貫して視覚的に区別されており、ユーザーが色だけに依存せずに識別できますか？ [Y/N]
キーボードを使ってページをナビゲートするとき、リンクがキーボードフォーカスを持っていることは視覚的に明らかですか？ [Y/N]
リンクが周囲の文脈から分離されたリストとして提示される場合、それらはすべて一意のテキストまたは簡潔でありながらリンク先リソースを明確に説明する代替テキストを持っていますか？ [Y/N]
ページ上のすべてまたは任意のリンクのテキストは、単独で読まれたときに完全に理解できますか？例えば「ここをクリック」や「詳細」などを使用していないか？ [Y/N]
9. メタデータ
メタデータは文字通り「データについてのデータ」であり、ウェブページのアクセシビリティにとって不可欠です。HTML標準は、いくつかの適切に名付けられたmetaタグや、言語、文字セット、タイトル、推奨ビューポートスケールなど文書に関連する事項を宣言するさまざまなタグや属性を含め、ウェブページ作成者がこのメタデータを提供する方法を定義しています。
ウェブページのメタデータはさまざまなタグや属性を使って提供できますが、共通しているのは確立された業界標準に従っており機械可読であるという点です。
アクセシビリティとSEO
正確でよく書かれたメタデータの利点は、機械可読性の二つのタイプ、つまり検索エンジンスパイダーと支援技術の両方に適用されることが知られています。例えば、意味のあるよく書かれた HTMLのtitleタグ は、Googleが検索結果ページでクリック可能な見出しとしてそのタイトルを表示したり、ソーシャルメディアでページを共有するときにタイトルが含まれたり、ユーザーのブラウザのブックマーク名として使われたりすることを可能にします。
さらに、その同じタイトルはページが読み込まれたときにスクリーンリーダーがページ名を発表するために使用されるので、画面を見られないユーザーがページの主題について正確で簡潔な説明を聞くことができます。
検証
HTMLの検証 は、基礎となるメタデータを確認する良い出発点です。Web Developerブラウザ拡張機能を使うとこれを簡単に行えます。メニュー項目を使用してください： ツール → HTMLを検証. メタタグの評価もこのツールで簡素化できます。メニューオプションを有効にしてください： 情報 → メタタグを表示 テスト対象のウェブページの情報。
最終的には、メタデータが機械向けに最適化されている性質上、ブラウザの開発者ツールのソース表示オプションを使用してテスト対象ページのHTMLに直接アクセスする必要があるかもしれません。htmlタグに設定されたメタデータやドキュメントのheadセクションで定義されたものを探してください。
ウェブページの言語を宣言すること
その lang属性 は多くのHTML要素に追加して、その要素内のテキストがどの言語で書かれているかを示すことができます。少なくとも外側のHTMLタグには言語が宣言されている必要があります。ページの一部が別の言語で書かれている場合（例えば外国語のフレーズが意図的に引用されている場合）、その要素には使用された言語に応じた正しいlang属性値を設定する必要があります。使用される言語が既定の左から右への読み順に従わない場合は、例えば右から左の表示パターンを示すためにdir属性で"rtl"を指定するなども含めることを確認してください。
言語を設定しないと、検索エンジンのランキングに悪影響を及ぼし、ツールがコンテンツの自動翻訳をレンダリングするのを難しくし、スクリーンリーダーがテキストコンテンツを読み上げる際に最も適切な発音エンジンを正確に使用するのを妨げる可能性があります。
タイトルは他と区別できるほど具体的にすること
ウェブページのタイトルは、そのウェブサイト内の他のページと区別できるほど具体的であるべきです。このルールに従うことで、各ウェブページに一意のタイトルが付くはずです。そうでない場合、選択したタイトルが十分に具体的でないか、あるいは同じコンテンツを持つ複数のページが存在することを意味します。
ズームのための「ピンチ＆スプレッド」を無効にしないでください
タッチスクリーンデバイスは通常、ピンチとスプレッドと呼ばれるジェスチャーをサポートしており、ユーザーはページの特定の表示領域をズームイン/ズームアウトできます。メタデータ（例：maximum-scale=1属性を設定するなど）でこれを無効にすることは技術的に可能です。これが見つかった場合、欠陥と見なすべきです。
テスト方法
各ウェブページについて、次のチェックを実行してください。各質問に「はい」または「いいえ」で回答を記録します。合格結果は各質問の後に大文字で示されます（例：[Y/N]）。Y が合格のために必要です。不合格の結果については、次のいずれかとして記録してください：
欠陥として
欠陥だが例外として許容される理由の説明付き
欠陥だが該当しない理由の説明付き
自動化できる可能性のあるテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
ウェブページを W3C HTML検証ツールでチェックしたときにHTML検証エラーが一切発生しませんか？ [Y/N]
ウェブページにHTMLの 標準の言語コード に従った少なくとも全体的な言語属性が設定されていますか？ [Y/N]
（少なくとも部分的に）手動で実施すべきテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
ウェブページに titleタグ があり、それがページ全体の主題を正確かつ簡潔に説明していますか？ [Y/N]
ページがピンチ＆スプレッドでズームできるタッチスクリーンで表示された場合、これらのジェスチャーを使用してページをズームできますか？ [Y/N]
10. 拡張とレスポンシブデザイン
プログレッシブエンハンスメントは、コアの目的が引き続き利用可能で理解可能である一方で、可能な限り多くの機器やソフトウェアでユーザーがウェブを利用できるようにします。追加の便利な機能は、より高機能なデバイスやブラウザ向けにそのコア体験に重ねて追加できます。
堅牢なアクセシビリティ
プログレッシブエンハンスメントを適用すると、ウェブページはより回復力があり包括的になります。すべてのユーザーが最速の接続、最も強力なコンピュータ、最新のソフトウェアを持っているわけではありませんし、時にはユーザーが機能を意図的にオフにしている場合もあります。彼らがそのようにしているには正当な理由があると仮定すべきですが、すべてのユーザーが選択の自由を持っているわけではありません。
1. テキストがリサイズ可能であることを保証する
テキストは切り取られたり他のテキストや近接する要素に重なったりしない場合に、使用可能で読みやすいと見なされます。必要に応じて折り返され、十分な行間、高さや文字間隔などのタイポグラフィ特性を維持するべきです。テキストやレイアウトなどのウェブページ要素のサイズ指定には相対単位（emやrem）を使用することを確認してください。これにより、デバイス画面のサイズや向き（縦向き・横向き）に相対してページがスケールし適応できます。
2. ウェブページがズーム可能であることを保証する
ページズームはページ全体の見かけ上のサイズを増加させます。一方テキストリサイズはテキストのサイズだけを増やします。ウェブページがデフォルトのレベルの少なくとも200％にズームされても、すべてのコンテンツが表示され使用可能であることを確認してください。
3. 小さい画面ではタッチターゲットを大きく調整する
タッチスクリーンを備えたモバイルデバイスでは、物理的に小さい画面と指でターゲット（リンクやボタンなど）をタップするという相互作用に対処する必要があります。これを考慮して、最小の物理的タッチターゲットサイズは少なくとも7 x 7 mm以上、可能ならより大きくするべきです。これにより、小さい画面でインタラクティブ要素のサイズを増やす必要が生じるでしょう。
4. noscriptフォールバックに頼らないでください
一部のウェブページは、JavaScriptが無効なブラウザ向けに代替コンテンツを定義するためにnoscriptタグを使用します。Gov.ukの調査によれば、JavaScriptを実行できなかったユーザーのかなりの割合はJavaScriptを無効にしていたわけではありません。つまり、JavaScriptは有効になっていたが何らかの理由で実行されなかったのです。これは重要です。なぜならブラウザはJavaScriptが無効になっている場合にのみnoscriptコンテンツを表示するため、JavaScriptが別の理由で実行されないときには、ユーザーはJavaScriptを必要とするコンテンツもnoscriptの代替コンテンツも見ることができないからです。
テスト方法
各ウェブページについて、次のチェックを実行してください。各質問に「はい」または「いいえ」で回答を記録します。合格結果は各質問の後に大文字で示されます（例：[Y/N]）。Y が合格のために必要です。不合格の結果については、次のいずれかとして記録してください：
欠陥として
欠陥だが例外として許容される理由の説明付き
欠陥だが該当しない理由の説明付き
自動化できる可能性のあるテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
デザイン（CSS）で指定されたすべてのサイズは、pxのような固定ピクセル単位を避け、相対単位（emまたはrem）のみで宣言されていますか？ [Y/N]
（少なくとも部分的に）手動で実施すべきテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
ブラウザ設定でテキストサイズをデフォルトの200％に変更したとき、ページ上のすべてのテキストは依然として表示され読みやすいですか？ [Y/N]
ブラウザでページズームを200％に増やしたとき、ページ上のすべてのテキストは比例して増加しますか？ [Y/N]
In DevToolsで、ブラウザのCPUおよびネットワークスロットルシミュレータを最も劣化させた設定にしても、ページのコアの目的はまだ提供されていますか？ [Y/N]
DevToolsで、ブラウザの デバイスモード シミュレータを利用可能な最小のデバイス画面に設定したとき、ページのコアの目的はまだ提供されていますか？ [Y/N]
追加のテスト実践
Chromeブラウザのようなツールを使用し、 DevTools設定を適用して デバイスモード テスト対象のウェブページをモバイルからタブレット、デスクトップに至るまでの範囲のデバイスで近似できます。タッチ、位置情報、デバイスの向きなどのデバイス入力もシミュレートできます。
なお、 ネットワークタブ ではCPUとネットワークのスロットリングをシミュレートできます。
11. セマンティックな構造
任意のウェブページ内で、見出しはコンテンツの全体的な組織と構造を伝えるために使用されます。 見出しはページコンテンツの高レベルなアウトラインとして機能するべきです 各トピックとサブトピックが階層的な順序で論理的にランク付けされていること。
WebAIMのスクリーンリーダーユーザー調査は、回答者の67.5％が長いウェブページで情報を見つけるためにまず 見出しを試す傾向がある ことを明らかにしました。そして85.7％が 適切な見出しレベル が見出しによるナビゲーション時に有用だと答えました。
使いやすく適切に整理された見出しを提供しないことは、スクリーンリーダーユーザーがコンテンツの構造を理解しページ内を効率的に移動するのを妨げます。見出しは誰にとっても有用ですが、見出しが欠如しているか不適切に実装されていると支援技術のユーザーはより大きく排除されます。
見出し
h1見出しはウェブページ全体の主題を記述するべきであり、その内容はページのtitle要素と似ているか同一であるべきです。
最初の見出しが通常h1であることが一般的ですが、例えば最初にh2が現れても必ずしも欠陥ではありません。見出しの論理的なランク付けと順序はどれが最初かより重要です。例えばh2の次にh4が続く（期待されるh3を飛ばす）ことがないようにすることです。例として、ナビゲーション部分がページの表示タイトルの前に表示される場合、ナビゲーション見出しをh2にし、その後ページ全体の主題を示すために下方でh1見出しを使うことがあるかもしれません。
スクリーンリーダーは、見た目だけを見出しとしてスタイルした要素を真の見出しとして認識できません。HTMLソースをチェックして実際の見出しを見つけるツールを使用してください（これはスクリーンリーダーが行うのと同じ方法です）。divは設計された目的でのみ使用し、他のより適切なタグの代替として決して使用しないでください。見出しをナビゲートするより本格的な体験を得るために、Windowsに組み込まれているNarratorスクリーンリーダーを使ってページをテストしてください。
これにより、スクリーンリーダー利用者にとって H1 の重要性がアクセスできなくなります。
テスト方法
各ウェブページについて、次のチェックを実行してください。各質問に「はい」または「いいえ」で回答を記録します。合格結果は各質問の後に大文字で示されます（例：[Y/N]）。Y が合格のために必要です。不合格の結果については、次のいずれかとして記録してください：
欠陥として
欠陥だが例外として許容される理由の説明付き
欠陥だが該当しない理由の説明付き
自動化できる可能性のあるテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
ページの HTML に h1 や h2 のような HTML 見出しタグが存在しますか？ [Y/N]
見出しは階層的な順序になっており、見出しレベルを飛ばしていませんか（例えば h2 から h4 など）？ [Y/N]
（少なくとも部分的に）手動で実施すべきテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
見出しは一貫して認識しやすいスタイルで表示されており、見出しでないコンテンツと区別しやすくなっていますか？ [Y/N]
各見出しのテキストは、それが見出しる主題を正確かつ簡潔に説明していますか？ [Y/N]
ページ上の主要な h1 はページ全体の主題を正確かつ簡潔に説明していますか？ [Y/N]
見出しのように視覚的にスタイル付けされたすべてのテキストが HTML の見出しタグで実装されていますか？ [Y/N]
12. テキスト代替
ユーザーがウェブブラウザで画像を利用できない場合、または障害により画像を見られない場合、テキスト代替は同等の情報源および機能を提供し、ユーザーが依然としてウェブページの主要な目的をアクセス、理解、利用できるようにする必要があります。
本書は、アイコン、ボタン、コントロール、ロゴ、ブランド資産などの機能的な画像がスクリーンリーダー利用者にとってアクセス可能であることを保証するために必要な技術とテストを扱います。
またコンテンツ画像を識別するための技術も扱いますが、テストによってコンテンツ画像がアクセス可能であることを決定的に証明することはできません。自動化された AI の代替テキスト生成ツールに頼ってはいけません。機能的な画像には、それがどのように見えるかではなく、何をするかあるいは何を表すかを説明するテキスト代替が必要です。ボタンやアイコンの視覚的な説明はユーザーにとってほとんど役に立ちません。
純粋に装飾的な画像
これらの画像はウェブページの内容に意味を付加しないため、スクリーンリーダーはそれらを無視するべきです。定義上、装飾的な画像はページの理解性や使用性に影響を与えずに削除できます。
同様に、背景画像（CSS に定義されたもの）はスクリーンリーダーによって自動的に無視されるため、純粋に装飾目的でのみ使用すべきです。
しばしば悪用される例外的なケースとして、背景画像を表示する要素が HTML の alt 属性ではなく、画像の代替として表示されるテキストを含むように作成されることがあります。
代替テキストがウェブページの本文内にあり、開発者定義の visually-hidden クラスなどでスタイルされてスクリーンリーダー利用者だけがアクセスできるようにされていることに注意してください。これは技術的にはスクリーンリーダー利用者にアクセス可能ですが、img 要素に alt 属性を使うより悪いアプローチです。なぜなら、画像が無効化されたり何らかの理由で読み込まれない場合、視覚的に隠されたテキストは決して表示されない一方で、alt 属性のテキストは表示されるからです。
コンテンツ画像
これらの画像はページの内容や機能に不可欠です。画像のテキスト代替を提供するには HTML の alt 属性を使用してください。
ただし、代替として使われるテキストが既に本文の近くにある場合は冗長になる可能性があるため注意してください。その場合、代替テキストは冗長と見なされ、画像は純粋に装飾的なものとして扱うべきです。そうでなければ、スクリーンリーダー利用者は同じテキストを二度読み上げられることになります。
代替テキストの品質を評価する際は、周囲のページ文脈における画像の編集上の意味や目的を考慮してください。代替テキストは画像が何を「示すか」だけでなく、画像が何を「意味するか」を簡潔に伝えるべきです。
次のことを前提にしてはいけません： 代替テキストを提供することを意図した他の HTML 機能（longdesc、title、figcaption 属性など）がスクリーンリーダーで機能するだろうと。特定のスクリーンリーダーが（その設定に依存して）これらの属性を無視するか、読んだとしてもどれを読むかは予測できません。
必要なテキスト情報の量が多いまたは複雑な場合、別の隣接する HTML 要素を代替テキストとしてマークするために ARIA 属性を使用することは受け入れられます。
コントロール内の画像
画像がコントロールのラベルとして機能する場合—例えばリンク内の唯一の内容が企業のソーシャルメディアフィードへのリンクであるソーシャルメディアロゴの画像など—画像を見られないユーザーのためにそのコントロールをアクセス可能にする必要があります。コントロールの動作を説明する代替テキストを使用してください。リンクは「ホームページ」「会社概要」など目的地を説明するべきです。ボタン内の画像は「検索」「ログイン」「送信」などボタンの目的を説明する代替テキストを使用すべきです。
SVG 形式のグラフィックス
場合によっては、表示される画像が従来の img タグで定義されていないことがありますが、それでもスクリーンリーダーがアクセスできるテキスト代替を提供する必要があります。以下の例は Léonie Watson によって文書化された技法を示しており、role と aria-labelledby 属性を組み合わせ、title と desc を参照して支援技術利用者がグラフィックを説明するテキストにアクセスできるようにします。
テスト方法
各ウェブページについて、次のチェックを実行してください。各質問に「はい」または「いいえ」で回答を記録します。合格結果は各質問の後に大文字で示されます（例：[Y/N]）。Y が合格のために必要です。不合格の結果については、次のいずれかとして記録してください：
欠陥として
欠陥だが例外として許容される理由の説明付き
欠陥だが該当しない理由の説明付き
自動化できる可能性のあるテスト：
以下はあなたが尋ねるべき重要な質問の例です：
各画像に代替テキストが関連付けられていますか（そのテキストが空の値であっても）？ [Y/N]
（少なくとも部分的に）手動で実施すべきテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
代替テキストは簡潔で文法的に正しく、綴りの誤りがありませんか？ [Y/N]
画像の目的が純粋に装飾的である場合、代替テキストは alt="" のように空の値になっていますか？ [Y/N]
代替テキストは、画像を見られないユーザーに対して同等の意味を伝える方法で画像を説明していますか？ [Y/N]
画像がコントロール、リンク、ボタンなどの唯一のラベルとして表示される場合、その代替テキストだけでコントロールの機能を理解できますか？ [Y/N]
代替テキストは隣接する本文を単に繰り返すだけでなく、独自で有用なものですか？ [Y/N]
代替テキストに使用されている言語は、文書の残りで宣言された言語と一致していますか？ [Y/N]
画像が機能的でないブランドロゴである場合、それは単にブランド名を示していますか？ [Y/N]
例えば Diageo のアイコンであれば、デザインシステムに記載されたそのアイコンに関連するテキストを使用していますか？ [Y/N]
自動化できる可能性のあるテスト：
以下はあなたが尋ねるべき重要な質問の例です：
自動コントラストチェッカーではコントラストエラーがないと示されていますか？ [Y/N]
（少なくとも部分的に）手動で実施すべきテスト：
以下は、確認すべき主要な質問の例をいくつか示します：
ぼやけ視覚エミュレーションを有効にした場合、画像やグラデーションの上に重ねられたテキストを簡単に読むことができますか？ [Y/N] 注：このプロジェクトに関わる他の少なくとも2人の意見を求めてください
ぼやけ視覚のエミュレーション
視覚がぼやけている、強いまぶしさがある、あるいは注意が散漫な場合には、十分なコントラストが特に重要です。ぼやけ視覚のエミュレーションを有効にすることは、テキストが十分に判読できるかをテストする素晴らしい方法です。
Chrome ブラウザでは、下記の手順でこのエミュレーションが利用可能です：
キーを入力します：command + shift + p を押し、次に "render" と入力して使用可能なレンダリングオプションをすべて表示します
"Emulate vision deficiencies"（視覚欠損のエミュレート）ドロップダウンまでスクロールします
次に "Blurred vision"（ぼやけ視覚）オプションを選択します
色覚障害を持つユーザーのコントラストと判読性を確認するには、すべての色を除去する "Achromatopsia" オプションを選択してください。
追加情報
画像を無効にすること（Web Developer ブラウザ拡張機能でも可能）は、画像が表示されない場合でも画像の上に重ねて表示されるように設計されたテキストが判読可能であり続けることを確認する効果的な方法です。背景画像を持つ要素にはフォールバックの背景色を設定することがそのようなケースに対処するために重要です。
14. Windows Narrator の使用
Narrator はすべての Windows オペレーティングシステムに組み込まれたスクリーンリーダーです。本ガイドは Narrator に不慣れな開発者とテスターが、ウェブページのテストに必要な基本的な操作を学ぶのを支援するためのものです。
現在 Narrator は MS Edge ブラウザで最もよく動作しますが、Chrome と Firefox のサポートもあります。
はじめに
Narrator を開始または停止するには、Windows キー + Ctrl + Enter を押します。これにより Narrator の詳細を学び設定を構成するためのオプションが表示されるウィンドウが開きます。Narrator を初めて使う場合は、 このビデオを視聴してください 簡単な入門チュートリアルです。
覚えておくと役立つこと：
設定にアクセスするには Windows キー + Ctrl + N を押します。ここで音声、相対音量、速度を変更できます。
Caps Lock と Insert の両方のキーは、多くのコマンドで使用される Narrator の「修飾」キーとして使用できます—以降これを Narrator キーと呼びます。
Ctrl + Home：ページの先頭へ移動します
Ctrl + R：ページを更新します（迷ったときや Narrator が期待どおりに動作しないときに便利です）
Narrator のショートカットの完全な一覧については https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
ウェブコンテンツのリスニング
Narrator を使ってウェブコンテンツにアクセスする方法はいくつかあります。以下は最も役立つキーです：
Ctrl + ↑/↓：前の/次の行を読む
↑/↓：前の/次の段落または項目を読む
Narrator + Tab：現在の項目を再読する
Narrator + +/-：読み上げ速度を上げる/下げる
Ctrl：読み上げを停止する
テストを始める前にいくつかの異なるページで読み上げの練習をすることをおすすめします。
ページのナビゲーションをテストする
視覚を持つ多くのユーザーはウェブページをざっと見て全体の位置関係を把握しますが、スクリーンリーダーではそうできないため、見出し、画像、フォーム要素、メッセージなどページに何が含まれているかが不明になります。ウェブページが適切に構造化され Colt のアクセシビリティガイドに従っていれば、ユーザーは見出し、ランドマーク、リンク、リスト等を使ってページをナビゲートできるはずです。
よく使われるページ要素で迅速にナビゲートするための単一キーショートカットがいくつかあります。これらが機能し、それぞれの要素タイプに正常にアクセスできることを確認してください。
これらには次が含まれます：
H：見出し
1 - 6：見出し1、見出し2、など
D：ランドマーク
Tab：リンクとフォームコントロール
F：フォームコントロール
B：ボタン
K：リンク
L：リスト
I：リスト内の項目
T：表
Shift + 任意のナビゲーションキーで操作を逆にします。
検索ダイアログを開き、さまざまな要素を検索してみてください
Narrator + Ctrl + F：検索ダイアログを開く
Narrator + F3：Narrator の検索結果を移動する（後ろに移動するには Shift を追加）
ナビゲーションのアクセシビリティガイダンス
フォームのテスト
フォームコントロールがキーボードフォーカスを受けると、Narrator はラベル（存在する場合）を読み、その後コントロールの種類をアナウンスします。チェックボックスやラジオボタンのグループが legend を持つ fieldset に含まれている場合、Narrator はフィールドセット内の項目をグループとして提示し、そのグループ内の何かに初めて移動したときに legend を読みます。
次のブラウザのキーボード操作を使用してフォームコントロールと対話し、それらにナビゲートできるか、ラベルが一意で記述的であるかをテストしてください。
Tab と Shift + Tab：フォームコントロール間を移動する
Space：チェックボックスの選択/選択解除
↑/↓：ラジオボタングループから選択する
Space の後に ↑/↓ またはオプションの先頭文字：コンボボックスを展開して選択する
Enter：フォームを送信する
フォームのアクセシビリティガイダンス
画像のテスト
画像は機能的、コンテンツ、または装飾的のいずれかです。Colt の ストリームグラフィックス は主に美的なものであり、装飾的と分類されます。これはスクリーンリーダーに対して無音であるべきことを意味します。代替テキストが定義されていない場合、Narrator は通常「画像」または「ラベルなしのグラフィック」と言います（ほとんどの他のスクリーンリーダーはこれらを無視します）。機能的またはコンテンツ画像の 代替テキスト は Narrator によって読み上げられ、画像が用いられている目的を説明すべきです。
例：
Colt ロゴ はブランド名「Colt Technology Services」とだけ言うべきです
共催ロゴ（コーブランディングロゴ） は両方のブランド名を言うべきです：「Colt Technology Services in Partnership with Cisco」
Colt のロゴがホームページへのリンクでもある場合、画像がリンクである場合はブランド名と目的地の両方に対応するべきです：「Colt ホームページ」。
画像のアクセシビリティガイダンス
データテーブルのテスト
ページ内の次の表に移動するには T キーを押します。データテーブル内をナビゲートするには、Ctrl + Alt を押しながら ↑/↓/←/→ を使ってセル間を移動します。テーブルに適切な行および列のヘッダーがある場合、それらはナビゲート中に自動的に読み上げられます。 データテーブル（上記の続き）
行と列に意味のあるラベルがあることを確認してください。
Narrator のショートカットの完全な一覧については： https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
15. ダウンロード
開発者が潜在的なアクセシビリティの問題をテストしやすくするために、テストを構造化するための手動アクセシビリティチェックリストを作成しました。
最終更新
役に立ちましたか？