Subject: Comprehensive Accessibility (a11y) Overhaul for [My Application Name]
Prompt:
You are an expert web developer specializing in digital accessibility (a11y) and WCAG compliance. Your task is to perform a comprehensive accessibility overhaul on my application based on the context I provide below. The goal is to make the application compliant with WCAG 2.1 Level AA standards, ensuring it is usable and navigable for people with a wide range of disabilities.
1. Context of My Application (I will provide this)
Application Purpose: [BRIEF DESCRIPTION OF THE APPLICATION, ITS GOAL, AND KEY FUNCTIONALITY. e.g., "A project management dashboard for small teams."]
Technology Stack: [e.g., React with Material-UI, Vue.js, Svelte, plain HTML/CSS/JS]
Key User Flows: [LIST THE MOST CRITICAL USER ACTIONS. e.g., "1. User logs in. 2. User creates a new task. 3. User navigates to the settings page."]
Code/Description: [PASTE YOUR APP CODE, COMPONENT SNIPPETS, OR A DETAILED DESCRIPTION HERE]
2. Comprehensive Accessibility Implementation Checklist
Given the context, please implement the following 15 enhancements with meticulous attention to detail.
Semantic HTML & Landmark Roles: Refactor any non-semantic elements (<div>, <span>) used for interactive controls or content structure into their correct HTML counterparts (e.g., <button>, <a>, <ul>, <nav>). Ensure that HTML5 landmark elements like <main>, <nav>, <header>, <footer>, and <aside> are used to define the primary regions of the page layout, providing a structural map for assistive technologies.
Logical Heading Hierarchy: Structure all page content using a logical and sequential heading hierarchy. Ensure there is only one <h1> per page for the main title, and that subsequent headings (<h2> through <h6>) are used to create a clear and organized outline of the content without skipping levels.
Full Keyboard Navigability & Logical Order: Ensure all interactive elements—including links, buttons, form fields, and custom-built components—are fully focusable and operable using only the keyboard. The tab order must be logical and intuitive, following the visual flow of the page from top to bottom, left to right.
Visible & Compliant Focus Indicators: Implement a highly visible and clear focus style for all focusable elements. This style must have a sufficient color contrast against the surrounding background to be easily seen, going beyond the browser's default dotted outline where necessary.
Descriptive Page Titles & Language: Ensure every page has a unique and descriptive <title> element that clearly communicates its purpose. The root <html> element must also have a correct lang attribute (e.g., lang="en") to inform assistive technologies of the page's primary language.
Descriptive Alt Text for All Images: Provide concise, descriptive alt text for all informative images to convey their meaning to users who cannot see them. For images that are purely decorative and add no informational value, use an empty alt="" attribute to hide them from screen readers.
Descriptive & Unique Link Text: Replace ambiguous link text like "Click Here," "Read More," or "Learn More" with descriptive text that clearly explains the link's destination or function, ensuring the purpose of the link is understandable even out of context.
Sufficient Color Contrast: Verify that all text has a contrast ratio of at least 4.5:1 against its background to meet WCAG AA standards. For large text (18pt / 24px or 14pt / 19px bold), the ratio must be at least 3:1.
Explicit Form Labels: Ensure every form input (<input>, <textarea>, <select>) is explicitly associated with a visible <label> element using the for and id attributes. This programmatic link is essential for screen reader users to understand what information is requested.
Accessible Form Error Handling: Clearly identify form fields with errors visually and programmatically. Error messages must be displayed clearly and associated with their respective inputs using aria-describedby, so screen readers can announce the error when the user focuses on the invalid field.
ARIA for Interactive Component States: Use ARIA attributes to communicate the state and properties of custom interactive components. This includes using aria-expanded for accordions, aria-selected for tabs, aria-current for active navigation links, and aria-label for providing an accessible name to icon-only buttons.
ARIA Live Regions for Dynamic Updates: For content that updates dynamically without a page reload (such as status messages, toast notifications, or live search results), use ARIA live regions (aria-live="polite" or aria-live="assertive") to ensure these changes are announced by screen readers.
"Skip to Main Content" Link: Implement a "Skip to Main Content" link as the very first focusable element on the page. This link should be visually hidden until it receives keyboard focus, allowing keyboard-only users to bypass repetitive navigation blocks and go directly to the main content.
Proper Focus Management for Modals & Dialogs: When a modal dialog, pop-up, or off-screen menu is opened, ensure that keyboard focus is programmatically trapped within it. Users should not be able to tab to elements in the background. Upon closing, focus must be returned to the element that originally triggered it.
Respect for User Motion Preferences: Wrap any significant animations, video auto-play, parallax scrolling, or other motion-heavy effects in a prefers-reduced-motion CSS media query. This will disable or minimize the motion for users who have enabled this setting in their operating system due to vestibular disorders or other sensitivities.
Deliverables:
Complete, Updated Code: Provide the full code for the modified files or components.
Inline Comments: Add concise comments directly in the code to explain why each accessibility change was made (e.g., <!-- Added aria-describedby to link error message to input -->).
Accessibility Summary Report: At the end, provide a brief markdown report summarizing the key changes, the WCAG criteria they address, and a recommended testing plan.