diff --git a/templates/web_accessibility_improvements.md b/templates/web_accessibility_improvements.md
new file mode 100644
index 0000000..9719140
--- /dev/null
+++ b/templates/web_accessibility_improvements.md
@@ -0,0 +1,342 @@
+# Runbook: Web Application Accessibility Improvements
+
+## Summary of Changes
+- [Customize: List accessibility audit findings from automated and manual testing]
+- [Customize: Document current WCAG compliance level and target level (typically WCAG 2.1 AA)]
+- [Customize: Summarize major violation categories discovered in the codebase]
+- High-level improvements covering semantic HTML, keyboard accessibility, screen reader support, forms, images, color contrast, and dynamic content
+
+## Prerequisites
+- Familiarity with WCAG 2.1 guidelines: https://www.w3.org/WAI/WCAG21/quickref/
+- WAI-ARIA Authoring Practices for custom widget patterns: https://www.w3.org/WAI/ARIA/apg/
+- Automated testing tool installed (axe-core, pa11y, or Lighthouse)
+- Screen reader available for manual testing (NVDA on Windows, VoiceOver on macOS/iOS, TalkBack on Android)
+- Browser accessibility extensions (axe DevTools, WAVE, or similar)
+- [Customize: Note any organization-specific accessibility guidelines or design system documentation]
+- [Customize: Identify existing component libraries in use and their accessibility documentation]
+
+## Execution Steps
+
+### Step 1: Audit and Establish Baseline
+Context: Before making changes, establish a clear picture of current accessibility state. Automated tools catch approximately 30-40% of issues; manual testing is essential for the remainder.
+
+#### 1.1: Automated Accessibility Scan
+Run automated tooling across the application to identify programmatically detectable violations.
+- [Customize: Configure scanning tool appropriate to project's test infrastructure] \
+  Common options: axe-core for unit/integration tests, pa11y for CLI scanning, Lighthouse for page-level audits.
+- Scan all unique page templates and route endpoints in the application.
+- Generate baseline report documenting violations by WCAG criterion and severity.
+- Export findings to `docs/accessibility-audit-baseline.md` with violation counts as metrics for measuring progress.
+- [Customize: Note any existing accessibility tests in the codebase and their coverage]
+
+#### 1.2: Manual Keyboard Navigation Audit
+Test all interactive elements using keyboard only (no mouse).
+- Tab through every page and document the focus order—it should follow logical reading order.
+- Identify interactive elements that cannot be reached via Tab key.
+- Identify interactive elements that cannot be activated via Enter or Space keys.
+- Note any focus traps where keyboard users get stuck.
+- Note any missing or invisible focus indicators.
+- Test for presence and functionality of skip links ("Skip to main content").
+- Document findings in `docs/accessibility-audit-baseline.md` under keyboard navigation section.
+
+#### 1.3: Screen Reader Testing
+Test critical user flows with screen reader software to identify issues automated tools miss.
+- [Customize: Identify the 3-5 most critical user journeys to test (e.g., signup, login, checkout, primary feature workflows)]
+- Test each journey and document where announcements are missing, confusing, or incorrect.
+- Note images missing alt text or with unhelpful descriptions like "image" or filename.
+- Note form fields lacking proper labels or where labels don't match visible text.
+- Note dynamic content changes that aren't announced.
+- Document findings in `docs/accessibility-audit-baseline.md` under screen reader section.
+
+#### 1.4: [NO-CODE-CHANGE] Prioritization and Planning
+Categorize findings by impact and effort to create remediation roadmap.
+- Group all findings by WCAG success criterion.
+- Prioritize by user impact: blockers (prevent task completion) vs. obstacles (slow users down) vs. annoyances.
+- Identify quick wins (high impact, low effort).
+- Create remediation roadmap in `docs/accessibility-remediation-plan.md` mapping issues to subsequent steps in this runbook.
+
+### Step 2: Semantic HTML and Document Structure
+Context: Proper semantic structure is foundational—it improves screen reader navigation, provides implicit ARIA roles, and makes subsequent fixes easier. These changes often have broad positive impact with relatively low risk.
+
+#### 2.1: Landmark Regions
+Ensure proper page structure using HTML5 landmark elements so screen reader users can navigate by region.
+- Add or verify presence of `<header>` for site/page header content.
+- Add or verify presence of `<nav>` for navigation regions; use `aria-label` to distinguish multiple nav regions (e.g., "Main navigation", "Footer navigation").
+- Add or verify presence of single `<main>` element per page containing primary content.
+- Add `<aside>` for complementary content (sidebars, related links).
+- Add or verify presence of `<footer>` for footer content.
+- [Customize: Identify components/layouts where landmark elements should be added based on project structure] \
+  Typical locations: root layout component, page templates, navigation components.
+- Remove redundant `role` attributes where HTML5 elements provide the role implicitly (e.g., remove `role="navigation"` from `<nav>`).
+- Verify landmarks are announced correctly by testing with screen reader.
+
+#### 2.2: Heading Hierarchy
+Fix heading structure to create logical document outline that screen reader users can navigate.
+- Ensure single `<h1>` per page that describes the page's purpose.
+- Audit heading levels and fix any skipped levels (e.g., `<h1>` followed directly by `<h3>`).
+- Convert elements styled to look like headings but using `<div>` or `<span>` to proper heading elements.
+- Convert heading elements used only for styling (not structural) to styled `<p>` or `<div>` elements.
+- Ensure each heading accurately describes the content that follows it.
+- [Customize: Identify common heading patterns in the codebase—page titles, section headers, card titles—and standardize approach]
+
+#### 2.3: List Structures
+Use proper list markup for grouped items to convey structure to screen reader users.
+- Convert navigation menus to `<ul>` with `<li>` children.
+- Use `<ol>` for sequential or numbered content (steps, rankings).
+- Use `<dl>`, `<dt>`, `<dd>` for term/definition pairs (FAQs, glossaries, metadata).
+- Remove list markup used purely for styling purposes where content isn't actually a list.
+- [Customize: Identify navigation components, menus, and grouped content that should use list markup]
+
+### Step 3: Interactive Element Accessibility
+Context: Users must be able to operate all interactive elements via keyboard and assistive technology. Incorrect element usage is one of the most common accessibility failures.
+
+#### 3.1: Button and Link Semantics
+Ensure correct element usage for all interactive controls.
+- Identify clickable `<div>` and `<span>` elements and convert to `<button>` or `<a>` as appropriate.
+- Use `<a>` (anchor) for navigation—actions that take the user to a new URL or location on the page.
+- Use `<button>` for actions—operations that don't navigate (submit, toggle, open modal, delete).
+- Remove `<a href="#">` and `<a href="javascript:void(0)">` patterns; use `<button>` for non-navigation actions.
+- Add `type="button"` to buttons inside forms that should not submit the form.
+- Ensure all links have `href` attributes (required for keyboard focusability).
+- [Customize: Search codebase for onClick handlers on non-interactive elements] \
+  Search patterns: `div.*onClick`, `span.*onClick`, or framework equivalents.
+
+#### 3.2: Accessible Names for Interactive Elements
+Ensure all interactive elements have meaningful accessible names.
+- Add text content or `aria-label` to icon-only buttons (e.g., close button, menu toggle).
+- Ensure link text describes the destination, not generic "click here" or "read more".
+- For repeated links like "Read more", add `aria-label` with context (e.g., "Read more about accessibility testing") or use visually-hidden text.
+- Ensure accessible names are concise but descriptive—typically 2-5 words.
+- [Customize: Identify icon button components and ensure they have accessible name props/patterns]
+
+#### 3.3: Keyboard Operability
+Make all interactive elements fully keyboard accessible.
+- Ensure custom interactive components are in the tab order (`tabindex="0"` if not natively focusable).
+- Remove positive `tabindex` values (e.g., `tabindex="5"`) that disrupt natural tab order.
+- Implement keyboard event handlers for custom controls: \
+  Enter and/or Space for activation; Arrow keys for navigation within composite widgets.
+- Ensure all functionality available on hover is also available on focus.
+- Ensure all functionality available via click is available via keyboard activation.
+- [Customize: Identify framework-specific patterns for keyboard handlers] \
+  React: `onKeyDown`; Vue: `@keydown`; Angular: `(keydown)`.
+
+#### 3.4: Focus Management
+Implement visible and logical focus handling.
+- Add visible focus indicators to all interactive elements—minimum 2px solid outline or equivalent visible change.
+- Do not remove focus outlines (`:focus { outline: none }`) without providing alternative visible focus styling.
+- [Customize: Implement focus management for client-side route changes if using SPA architecture] \
+  Typical pattern: move focus to main content heading or container on navigation.
+- Implement focus return when closing modals, dropdowns, or overlays—focus should return to the element that triggered the overlay.
+- [Customize: Identify focus management utilities in existing component libraries or create shared utility]
+
+### Step 4: Forms and Input Accessibility
+Context: Forms are where users provide input and complete tasks. Inaccessible forms directly prevent users from accomplishing their goals.
+
+#### 4.1: Form Labels
+Associate all form inputs with descriptive, visible labels.
+- Add `<label>` elements with `for` attribute matching input `id` for all text inputs, selects, and textareas.
+- For inputs where visible label isn't feasible, use `aria-label` or `aria-labelledby`.
+- Ensure label text matches or contains any visible label/placeholder—do not use `aria-label` that contradicts visible text.
+- Do not use `placeholder` as the only label—placeholders disappear on input and have contrast issues.
+- [Customize: Identify form components and establish consistent labeling pattern across the application]
+
+#### 4.2: Form Instructions and Hints
+Provide additional context for fields that need it.
+- Add instruction text for fields with specific format requirements (dates, phone numbers, passwords).
+- Associate instructions with inputs using `aria-describedby` pointing to instruction element's `id`.
+- Position instructions so they are visible before the user enters data.
+- [Customize: Identify common form patterns in the codebase and ensure consistent approach to instructions]
+
+#### 4.3: Required Fields
+Clearly indicate which fields are required.
+- Add `required` attribute or `aria-required="true"` to required fields.
+- Indicate required fields visually with text "(required)" or symbol with explanation, not only asterisk.
+- If most fields are required, consider indicating optional fields instead.
+- [Customize: Establish consistent required field pattern—update form components or field wrapper components]
+
+#### 4.4: Error Handling and Validation
+Make form errors perceivable, understandable, and actionable.
+- Display error messages adjacent to the field with the error.
+- Associate error messages with inputs using `aria-describedby`.
+- Add `aria-invalid="true"` to fields with validation errors.
+- Provide specific, actionable error messages—not "invalid input" but "Email must include @ symbol".
+- Do not rely solely on color to indicate errors—use text and/or icons.
+- [Customize: Implement screen reader announcement of errors on form submission] \
+  Options: move focus to first error, use `aria-live` region to announce error summary, or both.
+- [Customize: Identify validation library and form components in use; establish consistent error handling pattern]
+
+#### 4.5: Field Groups
+Group related form fields and provide group labels.
+- Wrap related fields (address, payment info) in `<fieldset>` with `<legend>` describing the group.
+- Wrap radio button groups in `<fieldset>` with `<legend>` as the group label/question.
+- Wrap checkbox groups in `<fieldset>` with `<legend>` when checkboxes form a logical group.
+- [Customize: Identify multi-field form sections that would benefit from fieldset grouping]
+
+### Step 5: Images and Media
+Context: Users who cannot see images need text alternatives. Users who cannot hear audio need captions or transcripts.
+
+#### 5.1: Informative Image Alt Text
+Provide text alternatives for images that convey information.
+- Add `alt` attribute to all `<img>` elements.
+- Write alt text that conveys the image's meaning or purpose, not just its appearance. \
+  Example: "Chart showing 40% increase in sales Q3" not "Bar chart".
+- Keep alt text concise—typically one sentence or less.
+- For linked images, alt text should describe the link destination.
+- [Customize: Identify image components and ensure alt text prop is required or enforced via linting]
+
+#### 5.2: Decorative Images
+Mark purely decorative images so screen readers skip them.
+- Add empty alt attribute (`alt=""`) to decorative images.
+- Do not omit the alt attribute—this causes screen readers to announce the filename.
+- For CSS background images that are decorative, no action needed.
+- For CSS background images that convey information, add visually-hidden text or `aria-label` on container.
+- [Customize: Identify decorative vs. informative images in common UI patterns—icons, backgrounds, illustrations]
+
+#### 5.3: Complex Images and Data Visualizations
+Provide extended descriptions for images where alt text is insufficient.
+- Add detailed text descriptions for charts, graphs, and infographics.
+- Link description to image using `aria-describedby` pointing to description element.
+- Consider providing data tables as alternative to charts.
+- For SVG elements, add `role="img"` and accessible name via `aria-label` or `aria-labelledby`.
+- [Customize: Identify charting libraries in use and document accessibility patterns for each]
+
+#### 5.4: Video and Audio Content
+Ensure media content is accessible to users who cannot see or hear it.
+- Add synchronized captions to all video content with audio.
+- Provide transcripts for audio-only content (podcasts, audio messages).
+- Provide audio descriptions for videos where important visual information isn't described in the dialogue.
+- Ensure media player controls are keyboard accessible.
+- Ensure media player controls have accessible names.
+- [Customize: Identify video/audio components and third-party players in use; document captioning workflow]
+
+### Step 6: Color and Visual Design
+Context: Not all users perceive color the same way. Information must be perceivable without relying on color alone, and text must have sufficient contrast.
+
+#### 6.1: Text Color Contrast
+Ensure text is readable by meeting minimum contrast ratios.
+- Fix text failing 4.5:1 contrast ratio against its background (WCAG AA for normal text).
+- Fix large text (18pt+ or 14pt+ bold) failing 3:1 contrast ratio.
+- Check contrast in all states: default, hover, focus, disabled.
+- [Customize: Identify design tokens/CSS variables for colors; audit and update color palette if needed] \
+  Useful tool: https://webaim.org/resources/contrastchecker/
+- [Customize: Coordinate with design team if contrast fixes require design system updates]
+
+#### 6.2: Non-Text Contrast
+Ensure UI components and meaningful graphics are distinguishable.
+- Fix UI component boundaries (form inputs, buttons) failing 3:1 contrast against background.
+- Fix meaningful graphical elements (icons, chart segments) failing 3:1 contrast.
+- Ensure focus indicators meet 3:1 contrast against adjacent colors.
+- [Customize: Audit borders, input fields, and icon colors for contrast compliance]
+
+#### 6.3: Color Independence
+Do not use color as the only means of conveying information.
+- Add secondary indicators (icons, patterns, text labels) to color-coded information.
+- Ensure links are distinguishable from surrounding text without relying on color alone. \
+  Common solutions: underline, font weight, icon, or other visual indicator.
+- Add secondary indicators for form validation states (error icons, success icons, text).
+- [Customize: Identify UI patterns using color-coding (status indicators, charts, alerts) and add secondary indicators]
+
+### Step 7: Dynamic Content and ARIA
+Context: Screen readers need to be informed when content changes dynamically. ARIA (Accessible Rich Internet Applications) attributes help make custom interactive components accessible.
+
+#### 7.1: Live Regions for Dynamic Updates
+Announce content changes to screen reader users.
+- Add `aria-live="polite"` to regions that update with non-urgent status information.
+- Use `aria-live="assertive"` sparingly—only for critical, time-sensitive alerts.
+- Implement status announcements for async operations: loading states, success messages, error alerts.
+- Do not use live regions for content that updates very frequently (stock tickers, timers)—this creates excessive announcements.
+- [Customize: Identify dynamic content patterns in the application—notifications, toasts, loading states, real-time updates] \
+  [Customize: Implement or utilize existing toast/notification component with built-in live region support]
+
+#### 7.2: Modal and Dialog Accessibility
+Make overlay components fully accessible.
+- Add `role="dialog"` to modal containers.
+- Add `aria-modal="true"` to indicate the dialog is modal.
+- Provide accessible name via `aria-labelledby` pointing to the modal's title element.
+- Add optional description via `aria-describedby` if modal has descriptive content.
+- Trap focus within modal while open—Tab should cycle through modal content only.
+- Move focus into modal when it opens (to first focusable element or the modal container).
+- Return focus to triggering element when modal closes.
+- Allow Escape key to close the modal.
+- Prevent background content from being scrolled or interacted with while modal is open.
+- [Customize: Identify modal/dialog components in use; audit and update to meet these requirements]
+
+#### 7.3: Disclosure Widgets (Accordions, Expandable Sections)
+Make expand/collapse patterns accessible.
+- Use `<button>` for disclosure triggers (not divs or links).
+- Add `aria-expanded="true|false"` to toggle button reflecting current state.
+- Add `aria-controls` pointing to the `id` of the controlled content panel.
+- Update `aria-expanded` state when toggled.
+- Ensure content panel is visible/hidden appropriately (not just visually, but also to assistive technology).
+- [Customize: Identify accordion and disclosure components; audit and update to meet these requirements]
+
+#### 7.4: Tab Interfaces
+Make tab components follow ARIA tab pattern.
+- Use `role="tablist"` on the container holding tab buttons.
+- Use `role="tab"` on each tab button.
+- Use `role="tabpanel"` on each content panel.
+- Add `aria-selected="true"` to the active tab, `aria-selected="false"` to inactive tabs.
+- Associate tabs with panels using `aria-controls` (tab points to panel) and `aria-labelledby` (panel points to tab).
+- Implement arrow key navigation between tabs (Left/Right for horizontal, Up/Down for vertical).
+- Move focus with selection, or use `aria-activedescendant` for focus management.
+- [Customize: Identify tab components in use; audit and update to meet these requirements]
+
+#### 7.5: Custom Component ARIA Patterns
+Apply correct ARIA patterns to other custom widgets.
+- Reference WAI-ARIA Authoring Practices for pattern guidance: https://www.w3.org/WAI/ARIA/apg/patterns/
+- Common patterns: menu button, combobox/autocomplete, tree view, carousel, tooltip.
+- [Customize: Inventory custom interactive components in the application] \
+  [Customize: For each custom component, identify applicable ARIA pattern and implement required roles, states, and keyboard interaction]
+
+### Step 8: Testing Infrastructure
+Context: Establish automated and manual testing processes to catch accessibility issues early and prevent regressions.
+
+#### 8.1: Automated Accessibility Testing in CI
+Add accessibility checks to continuous integration pipeline.
+- [Customize: Select testing approach appropriate to project's test infrastructure] \
+  Options: axe-core with Jest/Vitest, cypress-axe, @axe-core/playwright, pa11y-ci.
+- Install and configure accessibility testing package.
+- Add accessibility assertions to existing component or integration tests.
+- Configure CI to fail builds when accessibility violations are detected. \
+  Consider starting with "serious" and "critical" violations only, then expanding.
+- Generate accessibility reports as CI artifacts for review.
+- [Customize: Document testing setup and assertion patterns for team reference]
+
+#### 8.2: Component-Level Accessibility Testing
+Add accessibility tests for reusable components.
+- Add axe-core checks to component test files for shared/reusable components.
+- Test components in multiple states (expanded/collapsed, error/success, enabled/disabled).
+- Test components with different content lengths and configurations.
+- [Customize: Identify component library or shared component directory; add accessibility tests to each]
+- [Customize: Consider adding accessibility tests to component development workflow (Storybook a11y addon, etc.)]
+
+#### 8.3: [NO-CODE-CHANGE] Manual Testing Protocol
+Establish repeatable manual testing procedures to catch issues automated tools miss.
+- Create keyboard testing script documenting steps to test each critical user flow with keyboard only.
+- Create screen reader testing checklist for each critical user flow.
+- Document zoom testing procedure at 200% and 400% magnification.
+- Document reduced motion testing procedure.
+- Add manual accessibility testing to release checklist.
+- Store testing documentation in `docs/accessibility-testing-procedures.md`.
+
+#### 8.4: [NO-CODE-CHANGE] Ongoing Accessibility Process
+Establish processes to maintain accessibility going forward.
+- Add accessibility review to pull request checklist.
+- Schedule recurring manual accessibility audits (quarterly recommended).
+- Document how to add accessibility tests when creating new components.
+- Create accessibility guidelines document for designers and developers.
+- [Customize: Identify training needs and accessibility champions within the team]
+
+## Validation Criteria
+Each step should be validated against:
+- Automated accessibility scan shows reduced violation count compared to baseline
+- Keyboard-only navigation test passes for affected components and flows
+- Screen reader testing confirms correct announcements for affected components
+- No new WCAG AA violations introduced (verified via automated testing)
+- Affected functionality continues to work correctly for all users
+
+## Notes
+- Automated tools catch only 30-40% of accessibility issues; manual testing with keyboard and screen reader is essential
+- Accessibility is an ongoing practice, not a one-time fix; processes established in Step 8 help maintain compliance
+- When in doubt, test with real users who rely on assistive technology
+- WCAG 2.1 AA is the typical target for legal compliance; WCAG 2.2 and AAA provide additional enhancements
\ No newline at end of file