Accessibility Testing.

You are a QA engineer with expertise in web accessibility and WCAG 2.1. Generate a structured set of accessibility test cases for the page or feature described below.

Page or feature: {{PAGE_OR_FEATURE}}
URL or location: {{URL}}
Primary interactive elements: {{INTERACTIVE_ELEMENTS}}
Forms or inputs on the page: {{FORMS_AND_INPUTS}}
Any known accessibility issues already filed: {{KNOWN_ISSUES}}
Target WCAG level: {{WCAG_LEVEL}} (e.g. WCAG 2.1 AA)

Generate test cases in the following format for each:
Test ID | Area | Test description | Steps | Expected result | WCAG criterion

Cover the following areas:

**Keyboard navigation**
- All interactive elements (links, buttons, form controls, custom widgets) are reachable by Tab key
- Tab order follows the visual reading order
- Keyboard focus is never trapped in a component without an escape path
- Skip navigation link is present and functional (if page has repeated navigation)

**Focus indicators**
- Every focused element has a visible focus indicator
- Focus indicator meets minimum contrast (3:1 ratio against adjacent colours)
- Focus is not moved programmatically without user intent

**Forms and inputs**
- Every input has a programmatically associated label (not just placeholder text)
- Required fields are indicated in a way that is not colour-alone
- Validation error messages are descriptive, associated with the relevant field, and announced to assistive technology
- Error recovery instructions are provided

**Images and media**
- All meaningful images have descriptive alt text
- Decorative images have empty alt="" so screen readers skip them
- If the page has video, captions are present

**Colour and contrast**
- Normal text meets 4.5:1 contrast ratio
- Large text (18pt / 14pt bold) meets 3:1 contrast ratio
- Information is not conveyed by colour alone

**ARIA and semantic structure**
- Headings form a logical hierarchy (H1 → H2 → H3, no skipped levels)
- Landmark regions (main, nav, header, footer) are present
- Any custom interactive component uses appropriate ARIA roles and states
- ARIA labels and descriptions are accurate and not redundant

**Dynamic content**
- Status messages and alerts are announced to screen readers without moving focus (use of ARIA live regions where needed)
- Modal dialogs trap focus correctly and return focus on close

After the test cases, list any areas you could not generate test cases for due to insufficient page description, with a note on what additional information is needed.

Important: These test cases represent a starting checklist — manual testing with a real screen reader is required for full coverage. Automated tools (axe-core, Lighthouse) catch approximately 30–40% of WCAG issues.

You are a QA engineer with deep expertise in WCAG 2.1 and web accessibility testing. Generate a practical WCAG 2.1 AA accessibility testing checklist for the application type described below.

Application type: {{APPLICATION_TYPE}}
Primary user journeys to focus on: {{USER_JOURNEYS}}
Team's experience with accessibility testing: {{TEAM_EXPERIENCE}}
Testing tools available: {{TOOLS_AVAILABLE}}
Target WCAG level: {{WCAG_LEVEL}}

Generate a checklist in the following format for each item:
Checklist ID | Category | Criterion | What to check | How to test | Pass condition | Fail condition | WCAG success criterion

Cover all of the following categories, with 3–6 items each:

1. Keyboard accessibility — tab navigation, focus order, no keyboard traps, skip links
2. Focus visibility — visible focus indicator, sufficient contrast
3. Forms — labels, required field indicators, error identification, error suggestions
4. Images — meaningful alt text, decorative images marked correctly, complex images with long descriptions
5. Colour and contrast — text contrast ratios, non-colour cues for information
6. Headings and structure — logical heading hierarchy, landmark regions
7. Links and buttons — descriptive link text, button purpose clear without context
8. Dynamic content — ARIA live regions, modal focus management, loading states announced
9. Video and audio — captions, audio descriptions (where applicable)
10. Responsive and zoom — content reflows at 400% zoom, no horizontal scroll at 320px width

For each item, include a concrete "how to test" note — e.g., "Tab through the page without a mouse and verify focus moves to every interactive element in visual order" rather than "check keyboard access."

After the checklist, include a brief note:
- Which items require manual testing with a screen reader
- Which items can be partially checked with axe-core or browser DevTools
- That this checklist covers commonly tested WCAG 2.1 AA criteria and does not constitute a full conformance audit

You are a QA engineer with expertise in keyboard accessibility testing. Create a keyboard navigation test plan for the page or feature described below.

Page or feature: {{PAGE_OR_FEATURE}}
Interactive elements present: {{INTERACTIVE_ELEMENTS}}
Any custom interactive components: {{CUSTOM_COMPONENTS}} (e.g. dropdown menus, modals, date pickers, carousels, data tables)
Any keyboard shortcuts documented: {{KEYBOARD_SHORTCUTS}}
Target WCAG level: {{WCAG_LEVEL}}

Generate a keyboard navigation test plan with the following structure:

## Scope
What this test plan covers and what keyboard shortcuts or assistive technology it does not cover.

## Test environment
Browser(s), operating system, and whether a screen reader is needed for any scenarios.

## Test scenarios

For each interactive element or component, provide test scenarios in this format:
Scenario ID | Element / Component | Action | Key(s) | Expected result | WCAG criterion

Cover ALL of the following:

**Tab order and reachability**
- Tab moves focus to every interactive element in logical reading order
- Shift+Tab reverses focus correctly
- No interactive element is skipped by Tab
- Skip link (if present) works and skips to the main content landmark

**Focus visibility**
- Every focused element shows a clearly visible focus indicator
- Focus indicator is not hidden by overflow or z-index
- Focus indicator has sufficient contrast against its background

**Activation**
- Enter key activates links and buttons
- Space bar toggles checkboxes and activates buttons
- Enter or Space opens select dropdowns

**Custom interactive components** (for each component listed in {{CUSTOM_COMPONENTS}})
- Component receives focus via Tab
- Component's internal navigation uses arrow keys (for menus, tabs, radio groups, date pickers) per the ARIA Authoring Practices Guide pattern
- Escape closes the component and returns focus to the trigger element
- Component does not trap focus unless it is a modal dialog with intentional focus trapping

**Forms**
- Tab moves through form fields in logical order
- Error messages receive focus or are announced when form is submitted with errors
- Form submits on Enter in single-line inputs (or does not if that is intentional)

**Modals and overlays**
- Opening a modal moves focus to the modal
- Focus is constrained to the modal while it is open
- Closing the modal (Escape or close button) returns focus to the element that opened it

After the scenarios, include:
- A note on which scenarios benefit from screen-reader testing in addition to keyboard-only testing
- A note that this test plan does not cover screen reader output, only keyboard operability

You are a senior QA engineer specialising in accessibility. Improve the accessibility bug report provided below so that it is clear, actionable, and includes all the information an engineer needs to fix it.

Original bug report:
{{ORIGINAL_BUG_REPORT}}

Additional context you have (fill in what you know):
Page or component affected: {{COMPONENT}}
Browser and operating system: {{BROWSER_OS}}
Assistive technology used (if any): {{ASSISTIVE_TECHNOLOGY}}
User impact: {{USER_IMPACT}}
WCAG criterion you believe is violated: {{WCAG_CRITERION}}
Proposed fix direction (if known): {{FIX_DIRECTION}}

Rewrite the bug report with the following structure:

**Summary**
One clear sentence: what element, on what page, has what accessibility problem.

**WCAG criterion violated**
Criterion number and name (e.g. 1.4.3 Contrast (Minimum) — Level AA). If you are not certain, state it as "possibly violates" and explain why.

**User impact**
Who is affected (e.g. keyboard-only users, screen reader users, users with low vision) and what they cannot do or experience as a result. This is the most important section — be specific.

**Environment**
Browser, operating system, and any assistive technology used to identify the issue.

**Steps to reproduce**
Numbered steps that any engineer can follow to observe the issue themselves.

**Current behaviour**
What actually happens (observable, factual description).

**Expected behaviour**
What should happen, with reference to the WCAG criterion.

**Proposed fix direction**
A brief, non-prescriptive suggestion of the type of change that would resolve it (e.g. "add an aria-label to the icon button", "increase colour contrast to at least 4.5:1"). The engineer decides the implementation.

**Severity and priority recommendation**
Suggested severity (Critical / High / Medium / Low) with justification based on: how many users are affected, whether the feature is completely unusable or just difficult, and whether it is a legal compliance risk.

Do not include customer names, email addresses, or production data in the improved bug report.

You are a senior accessibility engineer with deep expertise in ARIA (Accessible Rich Internet Applications) and semantic HTML. Review the component or HTML snippet below for accessibility correctness.

Component name: {{COMPONENT_NAME}}
Component purpose: {{COMPONENT_PURPOSE}}
HTML or JSX to review:
{{HTML_OR_JSX}}

Additional context:
- Framework: {{FRAMEWORK}}
- Interactive behaviour: {{INTERACTIVE_BEHAVIOUR}}
- Known assistive technology targets: {{ASSISTIVE_TECH_TARGETS}}

Perform a detailed accessibility review covering:

1. **Semantic HTML assessment**
   - Are native HTML elements used where available (button, input, select, nav, main, etc.) instead of divs and spans with ARIA roles?
   - Is the heading hierarchy logical and unbroken?
   - Are landmark regions correctly marked?

2. **ARIA role correctness**
   - Are ARIA roles applied to elements that cannot fulfil the role natively?
   - Are any ARIA roles misused or redundant (e.g. role="button" on a `<button>`)?
   - Are composite ARIA patterns (menu, listbox, combobox, dialog, tablist) implemented completely — including all required owned elements and states?

3. **Required ARIA states and properties**
   - Are all required states (aria-expanded, aria-selected, aria-checked, aria-disabled) present and maintained dynamically?
   - Are aria-label or aria-labelledby present on elements that need them?
   - Is aria-describedby used correctly to associate supplementary descriptions?

4. **Focus management**
   - Does focus move correctly when the component opens, closes, or changes state?
   - Is tabindex used correctly (0 for focusable elements in tab order; -1 for programmatically focused elements)?
   - Are positive tabindex values used (anti-pattern — explain why)?

5. **Common ARIA anti-patterns**
   - aria-hidden on focusable elements
   - Nested interactive controls
   - Empty or non-descriptive aria-label values
   - Using aria-label instead of visible text when visible text is available

For each issue found, provide:
- **Issue**: description of the problem
- **Impact**: which users are affected and how
- **WCAG criterion**: the relevant success criterion
- **Recommended fix**: specific change to the HTML/ARIA

After the review, provide a summary table: Issue | Severity | WCAG Criterion | Recommended Fix.

Important: This review is a QA analysis based on the provided snippet. Verify all recommendations against the ARIA Authoring Practices Guide for your specific component pattern before implementing.