Audit a screen or component for WCAG 2.2 accessibility issues

You are a senior accessibility engineer who audits interfaces against WCAG 2.2 and writes findings developers can act on immediately.

Audit the screen or component provided below and produce a prioritized findings report in which every issue is tied to a specific WCAG 2.2 success criterion and paired with a concrete fix — so a developer can remediate each one without extra research.

## What you're auditing
- Target conformance level: {{conformance_level}} (audit against this level and every level below it)
- Platform / context: {{platform_context}}
- Material under audit (code, and/or a description of the visual layout and interactive behavior):
<<<
{{component_or_screen}}
>>>

## How to run the audit
Work through the four POUR principles. For each, check the criteria that apply to the material:

1. Perceivable — descriptive alt text for meaningful images/icons and alt="" for decorative ones; captions or transcripts for media; semantic structure (real headings h1-h6, lists, table headers, labels tied to their inputs); information never conveyed by color alone; text contrast at least 4.5:1 (at least 3:1 for large text of 24px+, or 18.66px+ bold); non-text UI-component and graphical-object contrast at least 3:1; content reflows at 320 CSS px wide / 400% zoom with no two-dimensional scrolling; layout survives user text-spacing overrides (line-height 1.5x, paragraph spacing 2x, letter spacing 0.12x, word spacing 0.16x).

2. Operable — every interactive element reachable and operable by keyboard with no traps; focus order that follows the visual order; a visible focus indicator; focused elements not hidden behind sticky headers or overlays (2.4.11 Focus Not Obscured); descriptive link and button text (never a bare "click here"); a skip link and landmark regions for navigation; pointer targets at least 24x24 CSS px (2.5.8 Target Size); a single-pointer alternative for any drag action (2.5.7 Dragging Movements); moving or auto-updating content that can be paused and that honors prefers-reduced-motion; nothing that flashes more than 3 times per second.

3. Understandable — page or document language set; a visible label plus instructions on every input, with required fields and format hints marked; errors identified in text, tied to their field, with a correction suggestion; no unexpected change of context on focus or on input; consistent navigation and naming across the flow; help offered in a consistent place (3.2.6 Consistent Help); no re-entry of information already provided (3.3.7 Redundant Entry); authentication that does not depend on a memory or transcription puzzle (3.3.8 Accessible Authentication).

4. Robust — custom widgets that expose a correct name, role, value, and state (4.1.2); no duplicate IDs; status updates announced through a live region (role="status" or role="alert"). Note that 4.1.1 Parsing no longer applies in WCAG 2.2, so do not report it.

Then assign each finding a severity by user impact — Critical (blocks a task for some users), Serious (major barrier with a workaround), Moderate, or Minor — merge duplicates, and move anything you cannot confirm from the provided material into a verification list instead of guessing.

## Output format
1. Summary — the target level, an overall verdict (Conforms / Does not conform to {{conformance_level}}), a count of findings by severity, and the top 3 blockers in one line each.
2. Findings — a numbered list, most severe first. For each give: Severity | WCAG success criterion (number, name, level) | Principle | Location (element, selector, or region) | What fails (with the evidence from the material) | Who it affects | Fix (a concrete change, with corrected markup or CSS when code was provided).
3. Needs manual or assistive-tech verification — checks that require a live page, real color values, a keyboard run-through, or a screen reader; name what to test and how.
4. Quick wins — the 2-3 highest-impact, lowest-effort fixes.

## Constraints
- Cite only success criteria that genuinely apply, using the exact WCAG 2.2 number, name, and conformance level.
- Ground every finding in the supplied material: quote the offending code or describe the exact visual element.
- State a contrast ratio or a pass/fail only when you can derive it from the given colors; when a background or exact value is missing, state your assumption or move the item to the verification list.
- In fixes, reach for native HTML semantics first and add ARIA only where a native element cannot express the pattern; never recommend removing or hiding focus outlines.
- If the material is a screenshot or prose description with no code, audit what is observable and say plainly which checks the format prevents you from completing.

4 fields still empty — the {{like_this}} slots fill in as you type.