レビュー

ultrahand: review

専門の検査官のようにUIデザインをレビューします。すべてのフロー、インタラクション、コントロールをプラットフォームの原則、ニールセンの10のヒューリスティック、WCAG 2.2 AAに照らして検証し、デザインが他のサイズでも維持されているかを確認します。出力は重大度でランク付けされた発見事項のリストです。各発見事項は要素、原理とそのソースを示し、具体的な修正方法を提示します。

すべてのチェックはreferences/checklist.mdにあり、各チェックはreferences/sources.mdを引用しています。プラットフォームルールの詳細については、デザインスキル独自の原則を参照してください： mobile、 tablet、 desktop。 テーマを持つプロジェクトの場合は、デザインをtheme-reviewスキルで確認してください。トークンの使用、コンポーネントの再利用、画面間の一貫性はこのスキルの担当ではありません。

1. デザインを入手し、表示可能な内容を把握する

ユーザーが提供できる最も豊富な証拠を使用してください。どの種類の証拠を使用しているかを明示してください。これは確認できる内容を制限するためです。

• ultrahandキャンバスアーティファクト（claude.aiのアーティファクトリンク）：そのHTMLを読み取ってください。マークアップ、ラベル、色、すべての画面と状態が含まれています。ブラウザツールが利用可能な場合は、アーティファクトを開いてください。window.ultrahandCanvas（shared/canvas/内のキャンバスREADMEを参照）を使用して各ビューを設定します：usePreset(id)、setSize(w, h)、setScheme('dark')、setTextScale(2)、setState('error')、navigate(id)。タップターゲットを表示をオンにし、その結果（#uh-targets-result）を読み取ります。これにより、プラットフォームの最小値未満のターゲット数がカウントされます。シートまたはメニューを開いた後はrefresh()を呼び出して、カウントにそれらを含めます。キャンバスREADMEには、ツールバーの要素IDがリストされています。プロトタイプのスタブ（実際のネットワークや画面上のキーボードがないもの）は、発見事項には含めず未確認の下に配置します。ハードウェアキーボードは実際のものです。すべてのフローをそれで操作してください。
• ローカルキャンバスビルド（build.mjsからのindex.html）または開くことができる任意のページ：アーティファクトと同様に扱い、入力ドライバー（ステップ4）と一緒に使用します。
• コード（HTML、SwiftUI、Compose、Flutterなど）：ラベル、ロール、フォーカス順序、色、ブレークポイントを確認できますが、実行できない限り外観は確認できません。
• スクリーンショットまたはモックアップ：レイアウト、階層、表現、おおよそのコントラストとサイズを判断できます。ラベル、フォーカス順序、動作を確認することはできません。これらの発見事項は可能性ありとマークするか、未確認の下にリストしてください。

各発見事項の証拠を確認済み（コードで確認、またはキャンバス上で測定）または可能性あり（画像から推測）とマークしてください。隠された動作に関する推測を事実として提示しないでください。

2. コンテキストを確立する

何かを判断する前にこれらを書き留めてください。発見事項はそれらに対してのみ意味を持ちます。

• プラットフォーム：iOS、iPadOS、Android、macOS、Windows、またはWeb。キャンバス（size.platform）、コード、またはビジュアルスタイルから読み取ってください。不明な場合は、一度質問してください。
• 現在のサイズ：幅×高さ、および幅サイズクラス：compact < 600、medium 600–839、expanded 840–1199、large 1200–1599、extra-large 1600+。高さcompact < 480、medium 480–899、expanded 900+。向きと分割がある場合はそれを記録してください。
• 入力方法：タッチ、ポインター、キーボード、またはそれらの組み合わせ。タブレットやタッチ対応ラップトップは3つすべてを持つ場合があります。
• ユーザーと主要タスク：各画面を使用する人、およびその画面の唯一の目的。推測できない場合は質問してください。タスクのないレビューは意見のリストになります。
• 製品またはツール：エンドユーザー向けのデザイン、または所有者向けに構築されたツール（キャンバス自体、エディター、ビューアー）。ツールは任意のサイズのブラウザウィンドウで使用されるデスクトップアプリです。デスクトップルールでレビューし、パス8に合格させてください。そのクロームは、デザインのプリセットではなく、パス8でリストされているパス7のチェック（ウィンドウサイズ、ブラウザズーム、独自のテーマ）を受け、構成パスは他の画面と同様です。

プラットフォームルールは、デバイス名ではなくウィンドウサイズクラスと入力で選択します：コンパクトタッチ→モバイル原則。ミディアムおよびエクスパンデッドタッチ、または分割→タブレット。ポインターとキーボードウィンドウ→デスクトップ。レスポンシブデザインは、カバーするサイズのすべてのセットを取得します。

3. デザインを一覧化する

すべての画面と状態、画面間のすべてのフロー、各画面のセクション（ツールバーとそのグループ、ペイン、ペインヘッダー、フォームグループ、カード、リスト、バー）、および各セクション内のすべてのインタラクティブコントロール（ボタン、リンク、フィールド、トグル、タブ、メニュー、ジェスチャー、ドラッグターゲット）をリストアップします。この一覧がレビューのカバレッジです。リストアップしなかったセクションやコントロールはチェックしていないことになります。

3つのレベルでレビュー：画面全体、各セクション、各コンポーネント。すべてのコントロールが合格した画面でも、散らかっていて秩序がなく混乱を招く可能性があります。これはポリッシュの問題ではなく、それ自体が発見事項です。

4. パスに沿って検査する

references/checklist.mdのパスを順に実行してください。デザインを2回確認します。1回目は学習のため、2回目は問題を見つけるためです。

実際の入力で、複数のサイズですべてのコントロールを使用してください。 マークアップを読んだり、el.click()、dispatchEvent、セッターを呼び出したりすると、ヒットテスト、フォーカス、デフォルトアクション、スクロールチェーンがスキップされるため、覆われたボタンやトラップされたホイールでも問題なく見えてしまいます。ユーザーと同じようにページを使用してください。node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs"からの信頼できるマウス、ホイール、キー、タッチイベント（READMEに手順とレシピがあります）、またはブラウザツールの実際のクリックとキーを使用します。スクリプトはビューの設定とその後の状態の読み取りのみに使用します。

• 3つ以上のサイズで実行：最大サイズ、中間サイズ、およびサポートされている最小サイズ（デザインの場合はプリセット、ツールの場合は1440×900、1024×700、640×900などのブラウザウィンドウ）。
• 各サイズで、コントロールをリストアップし（controls）、それぞれの種類が意図されたとおりに使用します：クリックまたはタップ、タイプ、ドラッグしてEscでキャンセル、右クリック、キーボードで開閉、すべてのスクローラー上でホイールまたはスワイプを最後まで行います。
• 一部のネイティブコントロールは、ヘッドレスで信頼できる入力を使用して操作できません。セレクトのポップアップ、ファイルピッカー、カラーピッカー、デートピッカーなどです。セレクトのオプションはドライバーのchooseステップで選択し、残りは未確認の下にリストします。
• 各結果を読み取ります：covered（覆われている）、ビュー外で到達方法がない、または1つのサイズで欠落しているコントロール。scrolledでホイールがトラップされていることを示します。フォーカスがbodyに失われている。ページエラー。それぞれがそのサイズでの発見事項です。

1. タスクウォークスルー：各フローについて、すべてのステップで4つの認知的ウォークスルーの質問をします。
2. 構成：画面全体、次に各セクションを構成ルール（shared/composition/principles.md）に照らして確認します。最大サイズと最小サイズで監査を実行し、まずぼかしたスクリーンショットを読み取り、その後個々のコントロールを確認します。リビジョンをレビューする場合は、以前のバージョンと比較します。ラウンドで何が追加され、画面がより忙しくなったかどうか。
3. コントロールごと：インベントリ内のすべてのコントロールをコントロールチェックに照らして確認します。
4. ヒューリスティック：各画面をニールセンの10に照らして確認します。
5. アクセシビリティ：WCAG 2.2 AA。コントラストを計算し、目視で判断しないでください。
6. プラットフォーム：ステップ2のプラットフォームとサイズクラスのルール。
7. リサイズとバリアント：すべてのプリセット、分割幅、320幅のリフロー、200%テキスト、ダークモード、各データ状態、タッチデバイスでは両方の向きとキーボード表示（デスクトップウィンドウは回転しません。代わりに最小、最大、および短いウィンドウを確認します）。
8. ツール：所有者向けに構築されたツールの場合、作業はすべてのウィンドウサイズで表示され続け、ステージは端を越えてパンし、ズームには制限があり、ショートカットとドラッグが適切に動作します。

問題を確認したらすぐに、どこで確認したか（画面 › 要素、およびサイズ、スキーム、状態）を記録します。複数の場所に現れる1つの問題は、複数の場所を持つ1つの発見事項です。

5. 重大度を評価する

ニールセンの0〜4スケールを使用します。問題に遭遇するユーザーの数、それがどれだけ深刻に影響するか、ユーザーがそれを知った後も影響が続くかどうかを考慮します。チェックリストの重大度ガイドを参照してください。

評価	意味
4 壊滅的	タスクの完了を妨げる、またはデータが失われる。リリース前に修正。
3 メジャー	多くの人を遅らせる、または混乱させる、または主要フローでWCAG AAに違反する。早急に修正。
2 マイナー	一部の人を遅らせる、または明らかな回避策がある。
1 外観	ポリッシュ。時間があれば修正。

0は報告しないでください。WCAG AA違反は決して2未満ではありません。

6. 報告

1段落の評決で始めます：プラットフォーム、レビューしたサイズ、持っていた証拠、第一印象（ぼかした画面が示すもの、画面が整理されているか散らかっているように見えるか）、重大度別の件数、および最大の問題。整理されていない主要サーフェスは、バグと同等に評価します。それは1つのパスだけでなく、すべての使用を遅くします。次に発見事項を、重大度の高い順に、同じ重大度内ではフロー順に、チェックリストのテンプレートを使用してリストします：

• IDと重大度、例 R3 · 3 Major
• 要素： 画面 › セクション › 要素（または画面 › セクション、画面全体（構成の発見事項の場合））、およびそれが表示されるサイズ、スキーム、状態
• 証拠： 確認済みまたは可能性あり
• 問題： ユーザーにとって何が問題か、1〜2文で
• 原則： 違反するルールとそのソースキー（WCAG 1.4.3、NNG-H4、tablet:AND-T2）
• 修正： 値付きの具体的な変更（ラベルを#595959に上げて7.0:1にする、コントラストを改善するではない）

最後に、うまく機能している点（簡潔に）、確認できなかった点とその理由（スクリーンリーダー出力、実機、モーション）、および1人のレビューアでは他の人が気づく問題を見落とす可能性があるため、2人目のレビューアまたはユーザビリティテストを実施する価値があることを記載します。

レポートが他の人に送られる場合は、アーティファクトとして公開することを提案してください。一致するultrahandデザインスキルを使用して修正を適用することを提案してください。