Making Your Online Store Accessible
Before You Start
Accessibility is not a separate project that you complete once and forget. It is a design approach that applies to every page, every new product listing, every theme update, and every new feature. The Web Content Accessibility Guidelines (WCAG) 2.1, published by the W3C, define the international standard for web accessibility. WCAG organizes requirements into three levels: Level A (the minimum), Level AA (the standard most laws and regulations reference), and Level AAA (the highest level, which is aspirational rather than required). For ecommerce stores, meeting WCAG 2.1 Level AA is the practical target because it covers the most impactful accessibility requirements without demanding impractical changes, and it is the level referenced by most legal frameworks including the Americans with Disabilities Act (ADA) as interpreted by US courts.
The business case for accessibility extends beyond legal compliance. The Purple Pound research estimates that the spending power of disabled consumers and their households exceeds $8 trillion globally. Accessible websites also tend to have better SEO performance because search engines rely on many of the same structural elements that screen readers use: descriptive alt text, logical heading hierarchy, proper link text, and semantic HTML. Accessibility improvements also benefit non-disabled users: captions help people watching without sound, keyboard navigation helps power users, high contrast helps people reading in bright sunlight, and clear form labels help everyone complete checkout faster.
Step by Step Accessibility Implementation
Start with automated tools that scan your pages for common accessibility violations. The WAVE Web Accessibility Evaluator (wave.webaim.org) provides a visual overlay showing errors, alerts, and structural elements on any page. The Axe browser extension runs a detailed audit and reports violations with specific remediation guidance. Chrome DevTools Lighthouse includes an accessibility category that scores your page and lists issues by severity. Run all three tools on your homepage, a category page, a product page, and your checkout page. Automated tools catch approximately 30 to 50 percent of accessibility issues, primarily structural and code-level problems like missing alt text, insufficient contrast, missing form labels, and incorrect heading hierarchy. The remaining issues require manual testing. Navigate your entire store using only the keyboard (Tab to move between elements, Enter to activate, Escape to close modals) and verify that every interactive element is reachable and operable. If you reach a point where you cannot proceed, that is a keyboard trap that blocks assistive technology users entirely. Test with a screen reader (VoiceOver on Mac, NVDA or JAWS on Windows) on at least the product page and checkout page to hear how your store sounds to a blind visitor.
Every image on your store needs an alt attribute that serves one of two purposes: describing what the image shows (for informational images) or marking it as decorative (for images that convey no meaning). Product images should have alt text that describes the product: "Blue cotton crew neck t-shirt, front view" is descriptive and useful. "IMG_4532.jpg" or "product image" is useless to a screen reader user. Banner images with text need alt text that conveys the message the banner communicates: "Summer sale, 30 percent off all outdoor furniture" rather than "banner" or the filename. Icons that serve as visual labels (like a truck icon next to "Free Shipping") need alt text describing their meaning ("Free shipping") not their appearance ("truck icon"). Decorative images that add visual interest but convey no information, such as background patterns or separator lines, should use an empty alt attribute (alt="") so screen readers skip them entirely. For stores with large product catalogs, create alt text templates by product category: "[Color] [Material] [Product Type], [View]" generates consistent, descriptive alt text across thousands of products.
Every interactive element on your store must be operable using only a keyboard. This means every link, button, form field, dropdown menu, modal dialog, image carousel, product variant selector, quantity control, and the entire checkout flow must work without a mouse or touchscreen. Use native HTML elements (button for actions, a for links, input for form fields, select for dropdowns) because they come with built-in keyboard support. Custom interactive elements built with div or span tags are invisible to keyboard navigation unless you manually add tabindex, role attributes, and keyboard event handlers. Test keyboard navigation on every page by pressing Tab to move forward through interactive elements, Shift+Tab to move backward, Enter to activate buttons and links, and Escape to close modals and popups. Verify that the focus order follows a logical reading sequence (left to right, top to bottom) rather than jumping erratically across the page. Add visible focus indicators (a colored outline around the currently focused element) so keyboard users can see where they are on the page. The default browser focus indicator is often too subtle, add a custom focus style with a 2 to 3 pixel outline in your accent color for all focusable elements.
WCAG requires a contrast ratio of at least 4.5:1 between text and its background for normal-sized text (under 18 pixels bold or 24 pixels regular) and 3:1 for large text. Check every text element on your store using the WebAIM Contrast Checker or the contrast checker built into Chrome DevTools (inspect an element, look at the color property, and click the color swatch to see the contrast ratio). Common failures include light grey text on white backgrounds (often used for placeholder text, metadata, or secondary information), white text on light-colored banners or hero images, and colored text on colored backgrounds in promotional sections. Fix failures by darkening the text, lightening the background, or both until the contrast ratio meets the 4.5:1 threshold. Beyond text contrast, do not rely on color alone to convey information. If you use red to indicate sale prices, add another visual indicator like a "Sale" label or strikethrough on the original price so that colorblind visitors can distinguish sale prices from regular prices. The color psychology guide covers how to build a palette that satisfies both branding and contrast requirements.
Every form field needs a visible label that is programmatically associated with the field using the HTML label element's for attribute matching the input's id. Placeholder text inside the field is not an acceptable substitute for a label because it disappears when the visitor starts typing, leaving them unable to verify which field they are completing. For checkout forms, provide clear, specific error messages when validation fails. "Please enter a valid email address" is helpful. "Invalid input" is not. Position error messages adjacent to the field that caused the error, not in a summary at the top of the page that requires scrolling to find the specific problem. Use aria-describedby to associate error messages with their fields so screen readers announce the error when the visitor focuses the field. Group related form fields (shipping address fields, payment fields) using fieldset and legend elements so screen readers announce the group context. The entire checkout flow must be completable using keyboard navigation and screen readers, since checkout is where the store generates revenue and inaccessible checkout means lost sales from disabled customers.
Semantic HTML elements communicate the structure and purpose of content to assistive technologies. Use header for site header, nav for navigation sections, main for primary content, footer for footer, aside for sidebars, and section or article for content blocks. These landmarks let screen reader users jump directly to the section they want rather than listening to the entire page linearly. Use heading tags (h1 through h6) in a logical hierarchy that outlines the page content: one h1 per page for the page title, h2 for major sections, h3 for subsections within an h2. Do not skip heading levels (jumping from h2 to h4) because screen reader users navigate by heading level and skipped levels break their mental model of the page structure. Where native HTML semantics are insufficient, use ARIA (Accessible Rich Internet Applications) attributes to provide additional context. Add aria-label to icon buttons that have no visible text (a magnifying glass search icon needs aria-label="Search"). Add aria-expanded to toggle buttons and menu triggers to communicate whether the associated content is currently visible. Add aria-live="polite" to regions that update dynamically (like cart count updates or search results) so screen readers announce the change without interrupting the user.
Common Accessibility Issues in Ecommerce
Image carousels and product galleries are frequently inaccessible. Auto-advancing carousels violate WCAG because users with motor impairments may not be able to pause them, and screen reader users may miss content that advances automatically. Make all carousels controllable with play/pause buttons, add keyboard controls for next and previous slides, and ensure each slide's content is accessible when the carousel is paused. Product image zoom functionality needs keyboard equivalents so users who cannot use a mouse can still magnify images.
Modal dialogs and popups, including email signup popups, cookie consent banners, size guides, and quick-view modals, are some of the most common accessibility violations in ecommerce. When a modal opens, keyboard focus must move into the modal, the modal must trap focus (Tab should cycle through modal elements only, not escape to the page behind), and closing the modal must return focus to the element that triggered it. Modal content must be announced to screen readers using the role="dialog" and aria-modal="true" attributes. A cookie consent banner that cannot be dismissed with a keyboard blocks the entire store for keyboard-only users.
Product variant selectors (size, color, quantity) built with custom JavaScript widgets often lack keyboard support and screen reader labels. A color selector that uses colored circles without text labels is invisible to screen reader users and useless to colorblind visitors. Add text labels to all color swatches ("Navy Blue," "Forest Green"), ensure variant selectors are operable with arrow keys, and use aria-selected to communicate which option is currently chosen. Quantity selectors built with plus and minus buttons need aria-label attributes identifying their function and must be operable with keyboard controls.
Testing and Maintaining Accessibility
Accessibility testing should be part of your routine for any store update: new product listings, theme changes, app installations, and promotional content. Create a simple accessibility checklist: alt text on all images, keyboard navigability confirmed, contrast ratios passing, form labels present, heading hierarchy logical, and modals properly focused. Run this checklist before publishing any significant change. Schedule a comprehensive accessibility audit (including manual screen reader testing) quarterly or semi-annually, since gradual changes can introduce accessibility regressions that automated scans miss. If your budget allows, consider a professional accessibility audit by a WCAG specialist, which typically costs $2,000 to $10,000 depending on store complexity and provides detailed remediation guidance tailored to your specific platform and theme.