How to Make Your eCommerce Website WCAG 2.1 AA Accessible

Making your eCommerce website WCAG 2.1 AA accessible requires a phased approach: audit your current site against the 50 success criteria, prioritize fixes by customer impact (checkout and navigation first), implement technical remediation across HTML semantics, keyboard interactions, color contrast, and form accessibility, and establish ongoing testing processes to maintain compliance as your site evolves. This guide provides the practical implementation steps for enterprise eCommerce teams.

Phase 1: Conduct a Comprehensive Audit (Weeks 1-3)

You cannot fix what you have not measured. A thorough accessibility audit combines automated scanning with manual expert testing.

Run automated accessibility scans. Tools like axe DevTools, WAVE, Google Lighthouse, and Siteimprove catch approximately 30 to 40 percent of accessibility issues automatically. Run these across your most critical pages: homepage, category pages, product detail pages, cart, checkout (every step), search results, account pages, and your most-trafficked content pages. Automated tools excel at catching missing alt text, insufficient color contrast, missing form labels, duplicate IDs, and incorrect ARIA attributes.

Conduct manual keyboard testing. Tab through every page using only the keyboard. Can you reach every interactive element? Is the tab order logical? Can you activate buttons and links with Enter or Space? Can you navigate dropdown menus, filter panels, and modal dialogs? Can you complete the entire checkout process without touching a mouse? Document every point where keyboard navigation fails or becomes confusing.

Test with screen readers. Use VoiceOver (macOS/iOS), NVDA (Windows, free), or JAWS (Windows, paid) to navigate your site as a screen reader user would. Listen to how your product pages are announced. Can a screen reader user understand the product name, price, and availability? Can they select variants, add to cart, and complete checkout? Screen reader testing reveals issues that neither automated tools nor keyboard testing catch — logical reading order, meaningful link text, and proper heading hierarchy.

Prioritize findings by customer impact. Not all accessibility issues are equal. Organize findings into three tiers. Tier 1 (critical) — issues that prevent task completion: inaccessible checkout forms, non-functional keyboard navigation for core flows, cart that cannot be managed without a mouse. Tier 2 (significant) — issues that substantially impair the experience: missing alt text on product images, insufficient contrast on pricing or CTAs, inaccessible filters or search. Tier 3 (moderate) — issues that degrade but do not block the experience: decorative images with unnecessary alt text, minor contrast issues on non-essential text, missing skip navigation links.

Phase 2: Fix Your Foundation (Weeks 3-8)

Before addressing individual page issues, fix the structural patterns that affect every page.

Implement proper heading hierarchy. Every page should have exactly one H1 (the page title or product name). Subsequent headings should follow a logical hierarchy — H2 for major sections, H3 for subsections within those. Do not skip heading levels (no H1 to H3 without an H2). Screen reader users navigate pages by heading structure, so a well-organized heading hierarchy is as important for accessibility as visual layout is for sighted users.

Add skip navigation links. Place a "Skip to main content" link as the first focusable element on every page. This allows keyboard users to bypass the header navigation and jump directly to the page content. The link can be visually hidden until focused (a common CSS pattern), but it must be present in the DOM and reachable via keyboard.

Fix semantic HTML throughout. Replace generic elements with semantic equivalents. Use the button element for actions (not styled div or span elements). Use nav for navigation. Use main for the primary content area. Use header and footer for their respective regions. Use aside for secondary content. Semantic HTML communicates page structure to assistive technologies without requiring ARIA attributes.

Establish ARIA landmark regions. For sections that semantic HTML alone does not adequately describe, add ARIA landmarks: navigation (if multiple nav elements exist, label each with aria-label), search, main content, complementary content, and contentinfo. These landmarks allow screen reader users to jump between page sections efficiently.

Implement visible focus indicators. Every interactive element — links, buttons, form fields, dropdown triggers — must show a visible focus indicator when reached via keyboard. The default browser outline is sufficient if you have not suppressed it with CSS. If your design requires custom focus styling, ensure the indicator meets WCAG 2.1 contrast requirements (3:1 ratio against adjacent colors in WCAG 2.2, good practice even for 2.1).

Phase 3: Fix Product and Catalog Experiences (Weeks 6-12)

Product browsing is where your eCommerce-specific accessibility work delivers the most revenue impact.

Write meaningful alt text for product images. Alt text should describe the product in terms useful for purchasing decisions. Instead of "product image" or "IMG_4523.jpg," write "Navy blue performance running shoe, mesh upper with reflective heel tab, men's size shown" or "K&N Engineering high-flow air filter, red cotton gauze media, part number 33-5110." For decorative images that add no informational content, use empty alt attributes (alt="") so screen readers skip them.

Make product image galleries accessible. If your gallery uses a carousel or lightbox, ensure previous/next controls are keyboard accessible, the current image position is announced (for example, "Image 3 of 6"), zoom functionality works via keyboard (not just mouse hover), and the gallery can be exited via keyboard (Escape key for lightboxes).

Fix layered navigation and filters. Product filtering must work entirely via keyboard. Filter categories should be expandable/collapsible with Enter or Space. Individual filter options should be toggleable with keyboard. Active filters should be announced by screen readers. Filter results should update the product count in an ARIA live region so screen readers announce "24 products found" when filters change.

Bemeir implements accessible filtering patterns in Hyvä-powered Magento storefronts using Alpine.js, which provides clean declarative interactivity that maps naturally to ARIA patterns. The lightweight framework makes accessible interactions performant rather than requiring heavy accessibility overlay libraries.

Ensure color is not the only indicator. Sale prices should not rely on red text alone to indicate the discount — add a "Sale" label or strikethrough on the original price. Availability should not rely on green/red indicators alone — include text labels ("In Stock" / "Out of Stock"). Size selection should not rely on grayed-out colors for unavailable options — add a visual indicator like a diagonal line or explicit "Unavailable" text.

Phase 4: Fix Checkout Accessibility (Weeks 8-14)

Checkout accessibility directly determines whether customers with disabilities can complete purchases. This is the highest-stakes accessibility work.

Label every form field. Every input field must have a programmatically associated label using the label element with a for attribute matching the input's id. Placeholder text is not a substitute for labels — placeholders disappear when the user starts typing, leaving no context for the field's purpose.

Implement clear error messaging. When form validation fails, errors must be clearly identified. Move focus to the first error on submission. Associate error messages with their respective fields using aria-describedby. Describe what went wrong and how to fix it — "Please enter a valid email address (example: name@company.com)" rather than "Invalid input."

Make address autocomplete accessible. If you use Google Places or a similar autocomplete service, ensure the suggestion dropdown is keyboard navigable, selected suggestions are announced by screen readers, and the autocomplete does not trap keyboard focus.

Ensure payment method selection works via keyboard. Radio buttons or tabs for selecting credit card, PayPal, or other payment methods must be keyboard operable with proper ARIA roles and states.

Provide order review in accessible format. The order summary before final submission must present all information — items, quantities, prices, shipping method, total — in a structured format that screen readers can parse. Use data tables or definition lists rather than visual-only layouts.

Phase 5: Maintain Compliance (Ongoing)

Accessibility is not a project — it is a discipline that must be integrated into your development and content workflows.

Add accessibility to your QA process. Every new feature, every design change, and every content update should include accessibility testing before deployment. Integrate axe-core into your automated test suite to catch regressions. Include keyboard and screen reader testing in your QA checklist.

Train content creators. Anyone publishing product descriptions, images, blog posts, or promotional content needs to understand alt text requirements, heading hierarchy rules, and link text best practices. Create a content accessibility guide specific to your eCommerce platform.

Schedule periodic audits. Conduct comprehensive accessibility audits annually at minimum — quarterly for high-traffic, frequently updated storefronts. Use these audits to catch issues introduced by new features, design changes, and third-party extension updates.

Monitor user feedback. Provide an accessibility feedback mechanism on your website. Customers who encounter barriers will often report them if given a clear channel to do so. This feedback supplements your formal testing with real-world usage insights.