🙌
俺なりの最速[要出典]アクセシビリティチェック

2024/09/10に公開
最速[要出典]アクセシビリティチェック
ナイスなアンサーソング！みなさんもぜひ「俺のアクセシビリティチェック」を書いていただけたら嬉しいです
Rikiya Ihara / magi (@magi1125)

https://twitter.com/magi1125/status/1832473908928507936
ということで、「俺なりのアクセシビリティチェック」について書いてみます。実はこの「最速アクセシビリティRTA」こと「最速アクセシビリティチェックRTA」についてはmagiさんと以前にも話をしていてお互いの目的や手法の違いを確認していて、それをちゃんと表に出すという意味もあります。

 チェックの目的や重視するものmagiさんのチェック手法がWCAGやJISの一定の基準を満たしているかを網羅的に確認してレポートすることを目的としている（ように見える）のと比較すると、私のチェックの目的は開発チームにいち早くどんな問題があるり、どう改善するべきかを伝えることにあります。これは、開発組織や開発サイクルの外部の存在としてチェックをしているか、それらの内部や近い立場でチェックしているかという立場の違いから生まれているのかなと思っています。
私がアクセシビリティチェックをしたり、頼まれたりしているのは以下のようなときです。
自分や自分のチームが作っているものをチェックする（開発者自身の立場）
他のチームや協力会社の作っているものをチェックする（QAの立場）
誰かがチェックしたものが、妥当にチェックされているのかを確認する（QAのQAの立場）
いずれの場合も開発中のもの、リリース前のものを対象としています。JISやWCAGの網羅的な適合チェックのような「問題がないことを確認する」「これから直すもののリストを作る」ことよりも、「問題のある場所を見つけて片っ端から開発チームにフィードバックする」ことのほうが求められる・期待されている・または勝手にそうしていると理解しています。
また、チェックの対象となるのはWebアプリケーションのいち機能やキャンペーンページなど、大きなWebアプリ/サイトのうちの、ごく一部の1〜数画面のWebページであることがほとんどです。

 チェックリストどんな観点を見ていくかはだいたい頭に入っているので、軽く確かめる程度だったり、すぐに見つかる問題が多すぎる場合には記入に時間がかかるのでチェックリストを作りません。これは特殊な訓練により獲得される技術なので、ふつうはチェックリストというか、チェック手順を書き出した何かを用意して挑むべきです。
チェックリストを作るのは、本当にこのままリリースして良いのかを確かめる、つまり「リストに載っている観点で問題がなかった」「こういう問題があったのでこれはリリース前に、これはリリース後でもいいので直してほしい」というコミュニケーションをするときです。つまりリリース前の最終段階に入ってくると、チェックリストを用意して記入することに大きな意味が出てくると思っています。
チェックリストが必要なときは大抵freee社内の案件なので、freeeのチェックリストの「プロダクト: Web」を使います。このチェックリストはQAで使うことが想定されていて、WCAG 2.1のレベルAA（一部レベルAAA相当を含む）に準じた内容になっていますが、WCAGの内容と完全に一致するものではありません。JISやWCAGへの「適合」「準拠」が求められている場合は、それらに適したチェックリストを使うべきです。freeeのチェックリストはあくまで、freee社内で運用するうえでチェックに必要となるものをまとめているものです。
なお、モバイル向けのWebであっても「プロダクト: Web」のシートを使用します。「プロダクト:モバイル」のシートはアプリ向けのシートなので、アプリが対象の場合以外は使用しません。ただしシートの項目はパソコンで表示するWebページ/Webアプリを想定しているので、モバイル向けページで使用するには一部の手順を読み替える必要があります。

 チェックの手順チェックは普段使っている端末をそのまま使います。私の場合はmacOSです。スクリーンリーダーの確認でNVDAやPC-Talkerが必要となる場合にはWindowsマシンが必要になりますし、モバイルでの利用が多く想定される場合はスマートフォンも用意します。

 ウォークスルー先に対象となる画面を操作したり開発者ツールでDOMツリーを見たりしながらざっと眺めて、どういうふうにチェックするか、どんな観点が必要になりそうかを考えながら観察します。ここですぐに見つかる問題もあります。
だいたい以下のようなことを気にしています。
対象の画面構成や見出しの構成はどうなっているのか
対象が複数の画面にまたがる場合は、それぞれの画面への行き来の仕方や、共通部分はどこにあるのか
モバイル用に表示が切り替わる場合は、どこがどう変化するのか。どうやって切り替えを実現しているのか（同じ要素をモバイル用とPC用で使い回しているのか、完全に別の要素を表示しているのか）
クリックや文字入力などを受け付ける要素（リンク、ボタン、フォームetc）はどこにあるのか、どんな挙動をするのか
ディスクロージャー（ユーザーの操作によって折り畳んだり開いたりできる箇所）やモーダルダイアログ、手順を進めると現れる追加項目のように、ユーザーの操作によってあとから画面に現れたり隠れたりする部分はないか
条件によって表示される項目が変わっていく場合は、それらすべてのパターンを洗い出しておきます

フォーカスやマウスオーバーによって出現するものはあるか
動いたり光ったり音が鳴ったりするものがないか
色のみによって表現されている情報がないか（表示をグレイスケールにしてもわかる状態になっているか）
ボタンやリンクの押下アクションは、マウスボタンを押したままそれらの領域の外にドラッグしてマウスボタンを離すことでキャンセルできるか
ページ内の情報を「右の」みたいな方向や「赤い」みたいな色のみで指し示したりしていないか
リンクの名前が「こちら」だけになっていたりしないか
動画や音声コンテンツがある場合、字幕や書き起こしや手話通訳が提供されているか
コンポーネントシステムやデザインシステムが使われているか
見た目や振る舞いをどの程度こだわって作り込んでいるか
見た目の作り込み度合いが高い場合は画像の代替テキストの問題やマークアップの間違いを警戒します
振る舞いの作り込み度合いが高い場合はキーボードによる操作が可能か、操作による変化が機械可読であるかを警戒します
見た目の作り込み度合いが高いのにコントラストが低そうな色で文字が書いてあったり、見た目の作り込み度合いが低いのに不釣り合いに振る舞いを作り込んだものを提供しようとしている場合は、長期戦を覚悟します

この時点で、無意識のうちにキーボード操作などをしてしまって問題を見つけていることもしばしばあります。

 自動チェック「チェックツールで見つけられる問題は、ウェブアクセシビリティの問題の 2 割から 3 割程度」（出典: デジタル庁 ウェブアクセシビリティ導入ガイドブック）と言われているものの、自動的なチェックで発見できる問題の出現頻度は非常に高く、あくまで私の体感ですが6〜7割くらいは自動チェックで問題のある箇所を発見できます。
チェックにはaxe DevToolsを使用します。無料版では WCAG 2.1のAとAAの達成基準と、開発元Dequeによる「Best Practices」のルールが使用できます。レベルAA相当のチェックをするにはこの範囲で十分でしょう。
axe DevTools（Chromeウェブストア）
axe DevTools（Firefox Add-Ons）
axe DevToolsを使用したアクセシビリティー・チェック（freeeアクセシビリティー・ガイドライン）
Lighthouseでも、axe DevToolsと同じくaxe-coreを使用したチェックができます。ただしLighthouseで適用されるルールセットがaxe DevToolsのルールのうち無料版で使われるものよりも少なく、また対象をAccessibilityに絞っていてもaxe DevToolsより一度のテストに時間がかかる印象があるので、アクセシビリティチェックだけを目的にするのには使いません。Lighthouseは他の指標も含めて100点満点で採点してくれるので、点数が表示されると純粋にうれしいのでモチベーション維持に活かしたいとか、他の指標も含めてスコアの改善を目標として追いつづけたいみたいな用途には向いていると思います。
Best Practicesに地味に大事なものがあったりするので、ONにした状態でスキャンします（結果画面でもON/OFFができます）。モーダルダイアログやディスクロージャーがある場合には、それらの状態を切り替えながら繰り返しaxe DevToolsのスキャンを実施します。モバイル向けに画面が切り替わる場合は、開発者ツールでモバイル向けの表示に切り替えた状態でスキャンします。
ます。一部、「Potential Issue」として人の目によるレビューが必要になるものが出てくることがあるので、それは個別に見ていくことになります。よくあるのはコントラスト比に関するもので、そういう場合はWebAIM Contrast Checkerで確認します。

 Accessibility VisualizerAccessibility Visualizerは、自動チェックで指摘されない問題の有無を、スクリーンリーダーを使わずに視覚的な方法で表示して確認するためのツールで、まさに自分（たち）がチェックを速く（早く）、手軽にやるために作っているものです。
Accessibility Visualizer（Chromeウェブストア）
Accessibility Visualizer（Firefox Add-Ons）
HTMLを直接読み書きせず、スクリーンリーダーも使わずに、アクセシビリティを向上させられないだろうか（と思ってブラウザ拡張を作ってる）
アクセシビリティチェックを後回しにしないためのツールを作ってる（Google Slides）
この先の確認と並行して、Accessibility Visualizerのポップアップで全体の有効・無効を切り替えたり、要素の種別ごとに表示・非表示を切り替えたりしながら、機械によるチェックができない以下のようなところを見ていきます。
見出し
同じような種類の情報を扱う見出しのレベルが画面内の場所によって違う状態になっていないか
見出しっぽい役割の場所が適切に見出しになっているか
見出しが画像などを含む場合、その代替テキストまで含めて適切な見出し文言（見出しのAccessible Name）になっているか

画像
画像の代替テキストが、画像の内容と食い違ってないか、過不足のない情報が書かれているか
知覚できなければページの理解に支障のある画像が、alt 属性が空になっていたりaria-hidden="true" になっていたりしないか（ただし、リンクやボタンになっている場合は、画像ではなくリンクやボタンの要素に aria-label などを設定している場合がある）
画像化されたテキストが存在するか

aria-hidden
装飾を除く、視覚的に見えている情報が aria-hidden="true" になっていないか

フォームコントロール
入力欄のアクセシブルネーム（おもに <label> 要素によって紐付けられる）は適切か（ほかの入力欄と入れ替わったり、説明文まで入ってやたら長くなっていたりしないか）
ラジオボタンの name 属性が適切に指定されているか（name 属性によるラジオボタンのグループ化ができているか）

ボタン
リンクやボタンが入れ子になっていたりしないか
アイコンなどがボタンになっている場合、適切なAccessible Nameが付与されているか
WAI-ARIAによって表現されるステート（aria-pressed:「押されている」 や aria-expanded:「展開されている」など）が実態に即しているか

リンク
リンクやボタンが入れ子になっていたりしないか

target="_blank" を示すアイコン等がある場合、すべてに付いているか
「href のないリンク」のような怪しい存在はないか
適切なAccessible Nameが付与されているか

セクション
適切なランドマークロールが使われているか（おもに main と nav）

ページ

lang 属性の値が適切か（ほとんどの場合日本語なので ja）
ページのタイトルは、そのページに固有のものが付けられているか

言語
外国語を含む場合、その部分に lang 属性が適切に指定されているか

テーブル
見出しセルが使われているか

リスト
変なdivが挟まったりしていないか
箇条書きの見た目なのにリストになっていない場所がないか

書き出すといっぱいあるように見えますが、上記はチェックリスト的に見ているというよりは、Accessibility Visualizerで変な表示があった場合に「これはおかしいのでは？」と見ていくような使い方をしています。支援技術が使用するAccessible Name（緑色）の内容は必ず変な文言になっていないか確認するべきなのと、特に怪しいものはエラー（赤色）、注意深く見るべきものは警告（黄色）として表示するので目印となります。
また、ARIAライブリージョンを使っている場合は、その内容をAccessibility Visualizerで可視化できるので、この頻度や内容も見ておきます。出現頻度が高かったり、内容が長文になっている場合はスクリーンリーダーでの使用時にかなり邪魔な可能性があるので、そういう場所を見つけたらスクリーンリーダーでの確認を重点的にやれるようマークしておきます。
密集度の高い画面では、Accessibility Visualizerを有効にするとぐちゃぐちゃに表示されます。チェック対象にマウスオーバーで操作するものがある場合は、Accessiblity Visualizerの要素が邪魔をして、操作が上手くいかなくなることもあります。そういう場合は要素ごとに絞ってみたり、あきらめてスクリーンリーダーでの確認に回したりします。

 キーボード操作によるチェックキーボードによる操作は、画面の最初の地点から最後の地点まで、Tabキーで移動しながら操作できるかも含めて確認します。そのため、まずアドレスバーをクリックしてからTabキーを連打して、リンクやボタンやフォームを操作し、画面遷移が発生したりした場合は戻ってきて同じ場所からフォーカスの移動を再開します。ただしヘッダーやナビゲーションなど、複数の画面をチェックしていくうちに同じ挙動をすることがわかっている場所については省略して、そのページのメインコンテンツの開始地点あたりをクリックしてからTabキーを押していきます。
その中で、特に以下のようなことを確認していきます。
Tabキーを押してフォーカスを進めていったとき
順序は自然なものになっているか
Shift+Tabキーで逆順に辿ることができるか
フォーカスしている位置が視覚的に提示されているか
フォーカスが閉じ込められるような状況が発生しないか

メニューやモーダルダイアログを開いたとき
フォーカスがメニューやモーダルダイアログ内に移動するようになっているか
メニューやモーダルダイアログを閉じたら元いた場所にフォーカスが戻るようになっているか
メニューやモーダルダイアログ内でフォーカスが閉じ込められるようになっているか。その場合、簡単でわかりやすい操作で抜け出せるようになっているか

入力フォームがある場合
ラジオボタンやチェックボックスやセレクトボックスはフォーカスでき、キーボードで操作可能か（ブラウザのスタイルではない、独自の見た目をしている場合は怪しくなりがち）
コンボボックスや日付選択フィールドはフォーカスでき、キーボードで選択肢を選ぶことはできるか（これも独自で実装したりライブラリを使って実装していることが多く、怪しくなりがち）
ラジオボタンは正しくグループ化されているか（ラジオボタンのグループ内でTabキーでフォーカスするのは1つのみ、上下左右キーで選択しているものを変更できるのが正しい挙動）

マウスオーバーで表示されるものがある場合
キーボード操作によっても表示できるか
その中にボタンやリンクなどがある場合、それらもキーボードで操作できるか

Tabキーによるフォーカス移動によって画面が遷移したり、画面の表示内容が大きく変化したり、モーダルダイアログが開いたり、ユーザーがフォームに入力した内容が書き変わったりすることはないか
リンクやボタンなど、ユーザーの操作を受け付けるものがすべて、フォーカスを受け取り、キーボードでも操作できるか
フォーカス順序を視覚化するツールなどもありますが、私は使っていません。結果を見ても使用時のイメージを思い浮かべることが難しく、どのみち実際に操作できるかどうかを確認する必要もあるので、実際にキーボードで触っておかしくないかを確認するようにしています。

 マウスオーバー系のチェックマウスオーバーで表示されるものは問題を起こしやすいので、しっかりと目を光らせておきます。なお、Accessibility Visualizerがマウスオーバー操作の邪魔の邪魔をしてしまう場合があるので、挙動が怪しい場合は無効にしておきます。
その上にマウスポインタを移動させても消えたりしないか
キーボード操作によりマウスポインタを動かさずに非表示にすることはできるか
マウスオーバー以外で、キーボードも使わずに表示する方法が提供されているか（スマートフォンやタブレットでの操作を想定）

 拡大や見た目を変更している場合のチェック画面を拡大していたり、ウィンドウサイズが小さい場合に問題がないかを確認していきます。
ページを200%まで拡大しても、見切れて読めなくなったり操作できなくなったりする場所がないか
ブラウザのフォントサイズ設定を大きなサイズに変更しても、
見切れて読めなくなったり操作できなくなったりする場所がないか
表示されている文字のサイズが、設定を変更したときに「全ての文字が大きくなる」または「全く変わらない」のどちらかであること（大きくなるほうが望ましい）


ブックマークレットでカスタムCSSを適用しても、見切れて読めなくなったり操作できなくなったりする場所がないか
ウィンドウサイズを小さく変更しても、見切れて読めなくなったり操作できなくなったりする場所がないか

 正常系・異常系のチェックフォームにバリデーションがある場合など、入力エラーとなることがある場合には、必ず正常系と異常系についてチェックを行います。これはスクリーンリーダーのチェックと同時に行うほうが効率が良いです（視覚的な表示とスクリーンリーダーの挙動を同時に確かめられるため）。
エラーになった場合に（異常系）
エラーが起きていることを、視覚的な表示で気付くことができるか
エラーが起きていることを、スクリーンリーダーの音声で気付くことができるか
エラーが起きて修正が必要な場所を、視覚的な表示で把握することができるか
エラーが起きて修正が必要な場所を、スクリーンリーダーの音声で把握することができるか
エラーメッセージの内容は具体的なものになっているか

エラーにならない場合に（正常系）
視覚的な表示とスクリーンリーダーの音声で、正常に完了したことを把握できるか


 スクリーンリーダーによるチェックスクリーンリーダーによるチェックは、もちろん視覚障害者が使えることの確認でもありますが、将来登場するものも含めてあらゆる支援技術に向けて、機械可読性（マシンリーダビリティ）が提供できていることを確認するものでもあります。
スクリーンリーダーの種類は、静的なWebサイトであればmacOSのVoiceOverで済ませてしまうことが多いですが、ほかのPC向けスクリーンリーダーと比較するとだいぶ癖の強い挙動がある[1]うえ、日本の視覚障害者のスクリーンリーダーでVoiceOverのシェアが低いので、状況によって他のスクリーンリーダーでも確認をします。このとき、Windows機さえあれば無料ですぐに使える選択肢はNVDA日本語版か、クリエイター版 PC-Talker Neo Plusとなります。複雑な挙動があったりWAI-ARIAを駆使していたりする場合はNVDAでのチェックを重視し、広いターゲット層に向けたものや視覚障害者の割合が高いことが想定されるセグメントに向けたものの場合はPC-Talkerでのチェックを重視します。
さらに、NVDAはEdge/ChromeとFirefoxで挙動がだいぶ違ったり、PC-Talkerは専用ブラウザのNetReader Neoが存在したりもするので、ブラウザを変えながらチェックすることもあります。そんなことをやっていると最速にならないので、こういうのはUIコンポーネントを開発している途中で、コンポーネントの単位で早めにやっておくべきです。もし複雑な動きのあるコンポーネントが存在するのにやってない場合は……時間がかかります……。
モバイルでの利用が多く想定される場合、あるいは要素を切り替えてモバイル向けの画面を作っている場合はスマートフォンのスクリーンリーダー（iOSのVoiceOverまたはAndroidのTalkback）でもチェックします。自分がメインで使っているし、当事者のスマートフォンの利用率でもiOSのシェアが高いので、iPhoneのVoiceOverでチェックをしています。iOSのVoiceOverはmacOSのVoiceOverとは操作体系が違う上に、iOS VoiceOverでしか発生しない謎の問題を発見したりするので油断なりません。
ここまでのチェックでスクリーンリーダーに影響のある問題（見出しレベル、フォームのラベル付け、代替テキスト、キーボード操作など）が見つかっている場所は、スクリーンリーダーでわざわざ触らなくても問題があるのはわかってるので深追いはせず、ちょろっと触って「うん、ダメだね」で終わりにします。
ページの最初のほうから順番にスクリーンリーダーで読みすすめて、不自然な順序で読み上げられる場所はないか（もちろんTabキーではなく、スクリーンリーダーカーソルを進める操作を行う）
ページに画面遷移してきたときや他のページに遷移したときに、画面遷移に気付けて、ページの冒頭またはメインコンテンツの冒頭にスクリーンリーダーカーソルがある状態になっているか
見出しは見出し、ダイアログはダイアログ、ボタンはボタン、リンクはリンク……というように、UIの種類をちゃんと読み上げるようになっているか
ディスクロージャーやメニューやモーダルダイアログの開閉状態がわかり、スクリーンリーダーでも問題なく操作できるようになっているか
スクリーンリーダーの提供する音声情報だけで、その画面にある情報を十分に読み取ることができたり、その画面で行えるタスクを完了できるようになっているか
特にARIAライブリージョンを使用している場合に適切なタイミングで適切にアナウンスされるか
フォーカスの移動などによって画面の変化に気付けるようになっているか

なお、これらの操作は画面をなるべく注視せずに行うようにしています（音声の出ないクリエイター版PC-Talkerを除く）。完全に見ないでやると読み上げられなかった情報に気付けないこともあるので、画面はチラチラ見つつ「これ言わなったな」みたいな場所がないことを確認します。
ここまででチェック自体は終わりで、問題点を指摘して改善を提案するフェーズに入っていきます。こっちのほうがチェックより労力が要ります。

 問題の重さを評価するfreeeのチェックリストには「重篤度」欄があり、[CRITICAL] [MAJOR] [NORMAL] [MINOR] の4種類が書かれています。その定義は以下のようになっています。
重篤度

そのチェック内容を満たしていない場合の影響の大きさを示す、以下の4段階の指標です。
[CRITICAL]

操作不能になる人がいる

[MAJOR]

操作や情報取得が著しく難しくなる人がいる

[NORMAL]

不便を感じる人が少なからずいる

[MINOR]

問題はあるが影響は小さい
freeeアクセシビリティー・ガイドラインについて
ややふんわりした書き方になっていますが、[CRITICAL] は「その画面自体が使えないどころか、他の画面に行けなくなったり、心身に悪影響があったりする」[2]、[MAJOR] は「心身の障害のある人や支援技術のユーザーが、機能を使えなくなり、役に立たなくなる」、[NORMAL] は「心身の障害のある人や支援技術のユーザーにとって不便なことがある」、[MINOR]は「影響は大きくないが、直しておいたほうが良くなる」くらいのニュアンスです。この重篤度に関してはWCAGのレベルAからレベルAAAの基準とはあまりが関係なく、また [CRITICAL] [MAJOR]の問題をすべて潰したからといって「『使えない』人がいなくなった」ということにはならないので注意が必要です。
チェックリストに書かれている重篤度は、そのチェックの問題が引き起こす最悪のケースを想定して重めに設定されています。つまり、状況によってはそこから下げた重篤度にすることができます。 [MAJOR] な問題であっても、代替する機能が用意されていて、使えない・使いづらい状況の人がそちらに自然と誘導されるように作られていれば、  [NORMAL] どころか [MINOR] にまで下げても良いでしょう[3]。
[CRITICAL] [MAJOR] 以上の問題がある場合、その画面や機能が「使えない」状況が明らかに存在しているので、リリースまでに直してね、というコミュニケーションを取っていきます。 特に [CRITICAL] の場合は、ほかの機能の利用にまで影響が及ぶため、直すまでリリースするべきではありません。 [NORMAL] 以下についても、直せるものは早めに直しておくべきで、このあたりは開発体制や今後のリリーススケジュールの中でベストな方法を探ります。
なお、axe DevToolsの結果から辿れるDeque University内のページには「深刻度（User Impact）」という基準があります。これも上記と似たようなレベル分けになっているので、問題の重さの参考になりそうです（私はあんまり見てません）。
Rule Impact Levels (Deque University)

 問題を説明し、改善方法を提案する問題がどれくらい重くて、いつ直してほしいかがわかったら、フィードバックをします。問題を指摘する場合にはなるべく「このときこの情報が表示されていますが、スクリーンリーダーを使用する人にはこの情報は伝わりません」とか「画面を視覚的に捉えながらキーボードを使っている人[4]は、ここに表示されているものを操作したいと思ってもフォーカスを移動させられません」というふうに、なるべく具体的に「どんな人にとって、どんな問題があるのか」を説明するようにしています。
問題点を指摘したからといって、すぐに直せるとは限りません。特にHTMLやJavaScriptを使ってアクセシビリティを高めていく分野に精通している人は多くないので、なるべく問題の指摘といっしょに改善方法の提案までするようにしています。
まず、誰がそこに責任を持っていそうかを考えます。実装者がコーディング時に気をつけたり工夫をしたりする必要がありそうなものであればエンジニア、UIの設計（情報設計や文言や色の選び方など）から再考する必要がある場合はデザイナーという感じです。エンジニアやデザイナーのように開発チーム内やチームに近い立場の人に責任や修正する権限がある場合はやりやすいのですが、そもそもの企画時点からアクセシビリティを考える必要のあったもの（だいたい「ドラッグ＆ドロップで直感的に〜」とか「グラフィカルで動きのあるビジュアルを重視して〜」とかが最初から決まっていたりします）や、どこかから納品された動画素材に字幕や音声ナレーションが足りないみたいな場合には、その企画者にどうにかアクセシブルな代替版を用意するなどの対応をする余地がないかを相談しにいく必要があります。開発のいわゆる上流の問題であればあるほど、リリース前のチェックではじめて問題が発覚した場合に面倒くさい状態になります。
axe DevToolsが指摘する問題については、axe DevTools内に「To solve this problem, you need to fix the following:」や「To solve this problem, you need to fix at least (1) of the following:」といった、修正方法の提案が表示されます。ただしこれは、「at least...」のように複数の修正方法が表示される場合、一般的にベストプラクティスとされているものもそうでないものも並んでいるので、せっかく人が介在して伝える以上はベストプラクティスを選んだり、その場に最適な方法を選んで提案するべきだと思います。
HTMLのセマンティクスが正しくなかったり、あるべき属性が付いていないなどの場合は、そのことの指摘をすれば終わりですが、「この要素にこの属性を付けてください」「このファイルの○行目にこれを追加してください」というふうになるべく具体的に指示を出します。
キーボード操作時やスクリーンリーダー使用時については、「とりあえずこういう操作・条件のときに、フォーカスをここに移せば何とかなりそう」みたいな方法でとりあえずの回避策を提案することがよくあります。エンジニアでもTabキーを使ってフォーカスを動かしながら操作したことのある人は必ずしも多くなく、また tabindex 属性を使ったテクニックなどもピンと来ないことが多いので、フォーカス移動の挙動については移動順序に細かく指示を出したり、場合によっては具体的なコード例を示しながら提案を行います。
よく見かけるUIパターンであれば、ARIA Authoring Practice Guide（APG）のPatternsの実装を参考にしてもらうことが多いです。英語のページを雑に投げて必要な情報を拾ってもらうことは残念ながらあまり期待できないので、「APGの『Accordion Pattern (Sections With Show/Hide Functionality) 』のページにある『Accordion Example』の実装を参考にしてください」みたいにとにかく具体的に伝えます。
場合によってはライブラリやコンポーネントシステムによって問題が発生している場合があります。まず、原因が実装者にあるのかライブラリやコンポーネントにあるのかを見極めるため、使用しているライブラリやコンポーネントシステムのコードや実装サンプルに同じ問題があるかどうかを調査します。また、ライブラリやコンポーネントシステムの最新版では直っているものが、最新版を使っていないせいで直っていないということも起こりがちです。OSSライブラリの場合は起きている問題に関係ありそうなワードを検索して、出てきたGitHub Issueを眺めているとけっこう前に直してあったり、まだ直されていないが利用側での回避方法が紹介されているという場合もたまにあります。
という感じで、チェック自体よりもそのあとに何をするかが大事なのではと思って書きはじめると、けっこういろいろと考えていることが出きてしまいました。書いていてあらためて思ったのは、単に「チェックを早くする」というよりは、企画やデザイン時点でアクセシビリティを視野に入れておく、画面の仕様を明確にしておく、アクセシビリティを気にしながら実装するといったシフトレフトの動きをすることで、チェックも開発プロセス全体も早くなり、最終的なアクセシビリティも高まるというところです。それぞれの立場の人が、少しずつアクセシビリティを気にするようになるだけでも、速く（早く）良いものを作れるようになっていくはずです。

脚注
macOS VoiceOverの、画面内の項目に入る・出る操作や、テーブルを読み上げるときの挙動などはだいぶ癖があると思います。ほかにもいろいろ、NVDAやPC-Talkerとの差分があります ↩︎
[CRITICAL] については「非干渉」とほぼ一致している認識をしています ↩︎
WCAGの「適合」の要件では「適合している代替版」でも良いとされていますが、「代替版を使わざるを得ない」よりは「同じものが使える」のほうが良いと思うので、 [MINOR] が妥当であると考えます ↩︎
「キーボードによる操作」で「スクリーンリーダー」を連想してしまう人が多く、「視力に不便はなく、キーボードのみで操作している人」もいる想定が忘れられてしまいがちなため、特にスクリーンリーダー利用時以外でのキーボード操作を強調する必要があるとき「画面を視覚的に捉えながらキーボードを使っている人」というややこしい言い方をしています ↩︎
チェックの目的や重視するもの

チェックリスト

チェックの手順

ウォークスルー

自動チェック

Accessibility Visualizer

キーボード操作によるチェック

マウスオーバー系のチェック

拡大や見た目を変更している場合のチェック

正常系・異常系のチェック

スクリーンリーダーによるチェック

問題の重さを評価する

問題を説明し、改善方法を提案する

Discussion
