Web Accessibility (WCAG) Implementation

You are a web accessibility expert certified in WCAG standards who has remediated and built accessible applications for government, healthcare, and enterprise clients. Create a comprehensive accessibility implementation plan for the following project.

Project Details:
Project Type: [PUBLIC WEBSITE/WEB APPLICATION/E-COMMERCE/GOVERNMENT/HEALTHCARE]
Compliance Target: [WCAG 2.1 AA/WCAG 2.2 AA/WCAG 2.2 AAA/SECTION 508]
Framework: [REACT/NEXT.JS/VUE/ANGULAR/VANILLA]
Current Accessibility Status: [NO AUDIT/KNOWN ISSUES/PARTIALLY COMPLIANT/REMEDIATING]
User Base: [GENERAL PUBLIC/ENTERPRISE/INTERNAL/EDUCATION]
Legal Requirements: [ADA COMPLIANCE/EU ACCESSIBILITY ACT/NONE SPECIFIC]

Section 1 - Semantic HTML and Document Structure:
Define the semantic HTML foundation requiring proper use of landmark elements including header, nav, main, aside, and footer to create a navigable page structure that screen readers can parse into a meaningful outline. Establish the heading hierarchy rules ensuring every page has exactly one h1 element and subsequent headings follow a logical nesting order without skipping levels while being descriptive enough to serve as a table of contents when listed by a screen reader. Create guidelines for form element semantics including associating every input with a label element using the for attribute, grouping related fields with fieldset and legend, and using the correct input type attributes for email, telephone, URL, and date fields. Specify the link and button semantics ensuring links are used for navigation and buttons are used for actions and that both have descriptive accessible names that make sense out of context. Address the table markup requirements for data tables including proper use of caption, thead, th with scope attributes, and aria-describedby for complex tables that need additional context.

Section 2 - ARIA Patterns and Widget Accessibility:
Define the ARIA usage policy following the first rule of ARIA which is to use native HTML elements and attributes over ARIA whenever possible and specifying the limited scenarios where ARIA roles, states, and properties are necessary. Create implementation patterns for common ARIA widgets including tabs using role tablist, tab, and tabpanel with proper aria-selected and aria-controls relationships, accordions using aria-expanded and aria-controls, and dialog modals using role dialog with aria-modal and aria-labelledby. Establish the live region strategy using aria-live polite for non-urgent updates like search results counts, aria-live assertive for critical alerts, and role status for ongoing state changes. Specify the implementation patterns for custom select components, autocomplete comboboxes, and date pickers following the WAI-ARIA Authoring Practices patterns with proper keyboard interaction models. Address the aria-label versus aria-labelledby versus aria-describedby usage guidelines specifying when each is appropriate and how to avoid common mistakes like redundant labeling and using ARIA to fix problems that semantic HTML would solve.

Section 3 - Keyboard Navigation and Focus Management:
Define the keyboard navigation requirements ensuring every interactive element is reachable via the Tab key in a logical order, all custom components support expected keyboard patterns, and no keyboard traps exist where focus cannot escape a component. Create the focus management system for dynamic content including how to move focus to newly appeared content like modals and toast notifications, how to restore focus to the triggering element when dynamic content is closed, and how to handle focus when content is removed from the page. Establish the skip navigation pattern implementing a skip to main content link that appears on focus before the page navigation allowing keyboard users to bypass repetitive header and navigation links. Specify the focus indicator styling ensuring custom focus styles meet the 3:1 contrast ratio requirement against adjacent colors, are visible in both light and dark modes, and use outline or box-shadow instead of outline none which removes the default browser focus indicator. Address the roving tabindex pattern for composite widgets like toolbars, radio groups, and menu bars where Tab moves focus into and out of the widget while arrow keys move focus between options within the widget.

Section 4 - Color, Contrast, and Visual Accessibility:
Define the color contrast requirements ensuring normal text meets a 4.5:1 contrast ratio against its background and large text meets 3:1 for WCAG AA compliance with guidance on verifying contrast for all color combinations in the design system. Establish the non-color information rule ensuring that color is never the sole means of conveying information and that status indicators, form validation, links within text, and chart data use additional visual cues like icons, patterns, or text labels alongside color. Create the text resizing strategy ensuring the layout remains functional and readable when users scale text up to 200 percent without loss of content or functionality and without requiring horizontal scrolling at standard viewport widths. Specify the motion and animation accessibility including implementing the prefers-reduced-motion media query to disable or reduce animations, providing pause and stop controls for any auto-playing content, and ensuring no content flashes more than three times per second. Address the target size requirements from WCAG 2.2 ensuring interactive elements have a minimum target size of 24 by 24 CSS pixels for Level AA with sufficient spacing between adjacent targets.

Section 5 - Screen Reader Optimization:
Define the screen reader testing protocol specifying which screen readers to test with including VoiceOver on macOS and iOS, NVDA on Windows, and TalkBack on Android and the key interaction patterns to verify on each. Create the accessible name computation guidelines ensuring every interactive element has a meaningful accessible name that is computed correctly from the element content, associated labels, aria-label, or aria-labelledby. Establish the image accessibility strategy including descriptive alt text guidelines for informative images, empty alt attributes for decorative images, and long description patterns for complex images like charts and diagrams using aria-describedby or figure with figcaption. Specify the dynamic content announcement strategy for single-page applications where content changes without page reloads including how to announce route changes, form submission results, and content loading completion to screen reader users. Address the accessible error handling pattern ensuring form validation errors are announced to screen readers, error messages are programmatically associated with their form fields using aria-describedby, and focus moves to the first error field or an error summary when a form submission fails.

Section 6 - Testing, Auditing, and Compliance Maintenance:
Define the automated accessibility testing integration using axe-core within the component testing suite and Lighthouse accessibility audits in the CI pipeline specifying which rules to enforce as blocking and which to track as warnings. Create the manual testing protocol covering keyboard-only navigation testing, screen reader testing scripts for critical user flows, and zoom and text scaling verification at 200 and 400 percent. Establish the accessibility audit process including how to conduct VPAT documentation for procurement requirements, how to prioritize remediation of identified issues by severity and user impact, and how to track compliance status against the target WCAG success criteria. Specify the ongoing compliance maintenance strategy including accessibility checks in the pull request review process, training resources for developers, and regular re-audits to catch regressions. Address the user testing with disabled users including how to recruit participants, what to test, and how to incorporate feedback into the development process for authentic accessibility rather than checkbox compliance.