アクセシビリティテスト（スクリーンリーダーとしてMicrosoft Narratorを使用）？ここに誰かがいくつかの実用的なガイドラインを持っていますか？
小規模ビジネス代理店のフロントエンド開発者（30人未満の開発者）として、私はアクセシビリティテストをより良くするために努力しており、スクリーンリーダーは必須です。
私はWindowsユーザーであり、MACにもアクセスできるため、NVDA（およびMicrosoftナレーター）を使用してから、MACにアクセスしてボイスオーバーを使用します。スクリーンリーダーの使用経験がなく、テストで十分であれば、常に100％とは感じていません。多くのことを読んだ後、この便利なページを見つけました。 https://webaim.org/articles/screenreader_testing/ -ここでこの文に自分自身を見つける;
スクリーンリーダーのユーザーは、ユーザー補助の取り組みの主な受益者の1つであるため、ユーザーのニーズを理解することは理にかなっています。もちろん、アクセシビリティはスクリーンリーダーのユーザーにのみ関連していると考える罠に陥りたくはありません。
さて、次に質問です。あなたとあなたの会社は、スクリーンリーダーのテストにどのように対処していますか？
必要な能力レベルがありますか、これを外部委託していますか（手動でテストする必要があると思いますが、誰かが高度な自動テストも使用している可能性があります）。
そして、私はこれをMSナレーターで見つけました：
Windowsナレーターは実際のスクリーンリーダーではなく、おもちゃです！
（ https://stackoverflow.com/a/27756562/3365805 ）-しかし、今は2020年になりました。MSナレーターは「より良い」と思います-ここでの経験は何ですか？
ここでの目標は、もちろん100％WCAG 2.0 Aおよび2.1 A準拠です（AAも場合によっては）。
私はナレーターをあまり気にしませんが、ぜひテストスイートに追加してください。
webAim screenreader study から、NVDA、JAWS、VoiceOverがスクリーンリーダーの90％以上を占めていることがわかります。したがって、これらはテストで使用するものです。ナレーターが1％を占めることがわかります。
問題は、NVDA、JAWS、VoiceOverでアクセス可能で完全に使用可能なサイトを作成できれば、他のスクリーンリーダーでも機能することです。
スクリーンリーダーの使用経験に関しては、経験がない方が実際にメリットがあります（後で説明します）。
私たちは、NVDAですべての主要なテストを行い、最終段階でVoiceOverとJAWSを使用して、それらのスクリーンリーダーとの特異性を整理する傾向があります。
テストは、コンポーネントステージとページステージの2つのステージで行われます。
コンポーネントステージでは、コンポーネント（つまり、オートコンプリート検索ボックス）を設計し、特定の機能、「期待される動作」に該当するキーの組み合わせ、および一般的な使いやすさをテストします。
スクリーンリーダーのテストだけでなく、一連のテストを実行することに注意してください（フォーカスインジケーターの可視、色のコントラスト、800％ズームの画面拡大鏡（ラベル、ツールチップなどが十分に近く、干渉しないようにするため）。）
次に、「機能」テストである全ページテストを実行します。つまり、特定の目標を設定します（ページxに移動し、フォームyに入力しますが、間違いを犯し、間違いが何であったかを確認します）。
これら2つのタイプのテストの間に、Webサイト/ Webアプリを起動するときまでに何もする必要はありません（この方法で開発する場合は、おそらく2％余分に時間がかかります。多くのものが定期的に使用する再設計を必要とするため、企業としてのアクセシビリティから始めましたが、時間の経過とともに、デフォルトでアクセス可能なベースライブラリとコーディングガイドラインを構築する予定です。
テストするときは常に コアコマンド を使用するようにします。これは、キーボードだけでスクリーンリーダーを使用するために必要な最低レベルの知識であるため、サイト訪問者の1人が持つ最低レベルの知識である必要があるためです。
このように、あなたの「経験不足」は実際には良いことです。
それでは、外部委託すべきでしょうか？
私が言ったことはすべて、社内で行うべきであり、理想的な世界では行う必要があるように思えます。
ただし、これには他のUXシナリオと同様に問題があります。あなたは悪い習慣を身につけてしまい、「私はこのコンポーネントの使い方を知っているので、誰もがそれを使用できるはずです」と考えます。
私がお勧めすることは、社内で予備テストを行い、サイトをアクセス可能と思われる段階にしてから、会社を雇ってユーザーテスト。彼らはソフトウェアの「ブラインド」にアプローチし（しゃれは意図されていません）、ページのレイアウトなどを知りません。これは、ロジックに穴があり、特定のデザインの側面がそれほど明確でない場所を確認できるので、非常に有益です。あなたは考える。
テストのヒント
チェックリストを作成する
設計の技術的な側面、WCAGへの準拠などについては、チェックリストはアクセシビリティテストを容易にする優れた方法です。
コンポーネントの種類、ページのテーマ、ナビゲーション、および技術に分割しているため、すべてのルールを試して覚える必要がない（該当するチェックリストを取得できます）
ペルソナを構築する
gov.ukには、アクセシビリティのペルソナに関する優れた記事があります とともに githubリポジトリ を入力します。基本的に、さまざまな人々のニーズに対してテストします。これは、チームにとっても優れたテスト方法と思考プロセスです。
ブラウザーとスクリーンリーダーのさまざまな組み合わせ
タイトルはすべてを語っています。JAWSはInternet Explorerでより適切に動作し、NVDAはFireFoxなどで最適に動作します。ブラウザとスクリーンリーダーの幅広い組み合わせで動作することを確認するために「スイッチアップ」してみてください。
WAI-ARIAを使用するためのマイナスマークを自分に与える
うん、聞いたとおり、WAI-ARIAの使用を強調した。
これは少しおしゃべりですが、このルールの実際のポイントは、ネイティブHTML5コンポーネントについて考えるように促すことです。多くの人がrole="region"-リージョンを使用する、ボタンにボタンを使用するなど。
WAI-ARIAはあなたが思っているほど広くサポートされていないので、extra情報に使用します。コンポーネントがWAI-ARIAなしで使用できない場合は、あなたがそれをより困難な方法でやっているという「コード悪臭」。
WAI-ARIAを使用しますが、サイトにアクセスできるようにするためにそれに頼らないでください。ネイティブコンポーネントで作成できるシナリオはほとんどありません。
結論
アクセシビリティテストは難しい。開発プラクティスへのアクセシビリティの構築は、最初はより困難です。
特定のアクセシビリティの問題を複数回発見したかどうかをテストする場合は、その周りにコーディングのガイドラインを記述します。
これを行うと、チェックリストやペルソナなどと相まって、「アクセシビリティ第一」の考え方に移行するのに約6〜12か月かかります。追加のボーナスとして、おそらくはるかに優れたユーザーインターフェイスとはるかに優れたユーザーエクスペリエンスを設計できます。