An icon-only cart link needs an accessible name. A visible Add to Cart button already has one. Knowing that difference helps you fix a real screen reader problem without adding ARIA everywhere.
Review method, September 28, 2026: This guide uses the W3C WAI-ARIA Authoring Practices and WCAG 2.2. The customer story and revenue figures previously published here were illustrative, not documented research or a measured store outcome, and have been removed. AmazingPlugins publishes the plugin discussed below.
What are ARIA labels, and why should you care?
ARIA stands for Accessible Rich Internet Applications. That’s a mouthful, so here’s the short version.
ARIA labels are invisible text tags that you add to elements on your website. They tell screen readers what things are and what they do. Think of them like braille stickers that a sighted person can’t see but a blind visitor reads with their screen reader.
Without ARIA labels, a screen reader might announce “button” when your customer tabs to the “Add to Cart” button. With proper labels, it says “Add Blue Ceramic Mug to Cart.” That’s the difference between a confused visitor and a confident buyer.
Use native HTML when it supplies the right name and behavior. Add an ARIA attribute only when the rendered control needs it, then test with a keyboard and screen reader.
The 10 ARIA attributes every WooCommerce store needs
For each attribute below, you’ll see what it does, what the wrong version looks like, and what you should aim for instead.
1. role: Tell screen readers what an element is
The role attribute tells screen readers how to interpret an element. Is it a button? A navigation menu? The main content area? Without roles, screen readers guess, and they often guess wrong.
Wrong:
<div onclick="addToCart()">Add to Cart</div>Right: Use a real button, which already supports keyboard activation:
<button type="submit">Add to Cart</button>Why it matters: Screen readers announce roles to users. If your add-to-cart element is a plain div, a screen reader won’t tell the user it’s clickable. They’ll never know they can buy anything.
2. aria-label: Name elements that don’t have visible text
Not every interactive element has visible text. Your search icon, your cart icon, your hamburger menu. These all need labels, even though sighted users understand them from context.
Wrong:
<a href="/cart"><img src="cart-icon.png"></a>Right:
<a href="/cart" aria-label="Shopping cart, 3 items"><img src="cart-icon.png" alt=""></a>Why it matters: Without an aria-label, a screen reader might just say “image” or “link.” Your customer has no idea where that link takes them. Adding a label with the item count is even better, because it tells the user their cart status immediately.
3. aria-labelledby: Reference existing text on the page
Sometimes you want to label an element by referencing text that’s already visible on the page. That’s what aria-labelledby does. It points to another element’s text as the label.
Wrong:
<div class="product-section">
<h2>Popular Products</h2>
<div class="product-grid">...</div>
</div>Right:
<div class="product-section">
<h2 id="popular-heading">Popular Products</h2>
<div class="product-grid" aria-labelledby="popular-heading">...</div>
</div>Why it matters: This connects the product grid to its heading so screen readers understand the relationship. Without it, someone browsing with a screen reader hears “Popular Products” and then a bunch of products with no connection between them.
4. aria-describedby: Add extra context and descriptions
aria-describedby links an element to a longer description elsewhere on the page. It’s perfect for things like shipping policies, sale terms, or product details that add context.
Wrong:
<label for="coupon">Coupon Code</label>
<input type="text" id="coupon" name="coupon">
<p class="small">Enter your 8-character code. Sale items not eligible.</p>Right:
<label for="coupon">Coupon Code</label>
<input type="text" id="coupon" name="coupon" aria-describedby="coupon-help">
<p id="coupon-help" class="small">Enter your 8-character code. Sale items not eligible.</p>Why it matters: When a screen reader user focuses on the coupon field, they hear the label. But they also hear the help text right after. No guessing about rules or restrictions. It makes checkout smoother and reduces abandoned carts.
5. aria-live: Announce dynamic content changes
WooCommerce is full of dynamic updates. Items added to the cart, search results filtering, stock status changing, error messages appearing. If nothing announces these changes, screen reader users have no idea what just happened.
Wrong:
<div id="cart-count">3</div>
<!-- JavaScript updates this number silently -->Right:
<div id="cart-count" aria-live="polite" aria-atomic="true">3</div>
<!-- When JavaScript updates this, screen readers announce the change -->Why it matters: Without aria-live, a screen reader user adds a product to their cart and nothing happens from their perspective. They might add it three more times because they don’t know it worked. With aria-live, the screen reader says “Shopping cart, 4 items” after each addition.
6. aria-hidden: Hide decorative elements from screen readers
Not everything on your page needs to be read aloud. Decorative icons, background images, and purely visual separators should be hidden from screen readers so they don’t clutter the experience.
Wrong:
<span class="icon-star">★</span>
<span class="icon-star">★</span>
<span class="icon-star">★</span>Right:
<span class="icon-star" aria-hidden="true">★</span>
<span class="icon-star" aria-hidden="true">★</span>
<span class="icon-star" aria-hidden="true">★</span>
<span class="sr-only">3 out of 5 stars</span>Why it matters: Without aria-hidden, a screen reader reads “star, star, star” out loud. That’s noise. With it hidden and a screen-reader-only text added, the user hears “3 out of 5 stars.” Clean, useful, and exactly what they need.
7. aria-expanded: Show toggle states for menus and accordions
Your mobile menu, your product filter panels, your FAQ accordions. These all open and close. Screen readers need to know which state they’re in.
Wrong:
<button class="menu-toggle">Menu</button>
<nav class="main-nav">...</nav>Right:
<button class="menu-toggle" aria-expanded="false" aria-controls="main-nav">Menu</button>
<nav id="main-nav" class="main-nav">...</nav>
<!-- When menu opens, JavaScript changes aria-expanded to "true" -->Why it matters: Without aria-expanded, a screen reader user doesn’t know if the menu is open or closed. They press the button, and if nothing announces the change, they press it again. Or they don’t press it at all because they don’t know it’s a toggle.
8. aria-current: Show the current page in navigation
When a visitor is on your shop page, they should know that. aria-current tells screen readers which page in your navigation is the current one.
Wrong:
<nav>
<a href="/shop" class="active">Shop</a>
<a href="/about">About</a>
<a href="/contact">Contact</a>
</nav>Right:
<nav aria-label="Main navigation">
<a href="/shop" aria-current="page">Shop</a>
<a href="/about">About</a>
<a href="/contact">Contact</a>
</nav>Why it matters: CSS classes like active don’t mean anything to screen readers. Without aria-current="page", a blind visitor has no way to know where they are in your store. They hear all three links and have to guess which one they’re on.
9. aria-required: Mark required form fields
Your checkout has required fields. Last name, shipping address, email. Screen readers need to know which fields are required before the customer hits submit.
Wrong:
<label for="email">Email Address</label>
<input type="email" id="email" name="email">Right:
<label for="email">Email Address <span aria-hidden="true">*</span></label>
<input type="email" id="email" name="email" required aria-required="true">
<span id="email-note" class="sr-only">Required</span>Why it matters: The asterisk is a visual cue that only works for sighted users. Without aria-required, a screen reader user doesn’t know which fields they can skip. They might submit an incomplete order and get error messages back, leading to frustration and abandonment.
10. aria-invalid: Tell users when something went wrong
When a form submission fails, you need to communicate that to screen reader users. aria-invalid marks fields that have validation errors.
Wrong:
<label for="phone">Phone Number</label>
<input type="tel" id="phone" name="phone">
<p class="error">Please enter a valid phone number</p>Right:
<label for="phone">Phone Number <span aria-hidden="true">*</span></label>
<input type="tel" id="phone" name="phone" aria-required="true"
aria-invalid="true" aria-describedby="phone-error">
<p id="phone-error" class="error" role="alert">Please enter a valid phone number</p>Why it matters: Without aria-invalid and aria-describedby, a screen reader user submits the form and hears nothing. No error message, no indication of what went wrong. They might try again, fail again, and leave your store for a competitor that works.
5 common WooCommerce ARIA mistakes (and how to fix them)
Knowing the right attributes is one thing. Avoiding the most common mistakes is another. Here are five errors that show up on WooCommerce stores constantly.
Mistake 1: Using aria-label on elements that already have visible text
If a button says “Add to Cart,” you don’t need aria-label="Add to Cart" on top of it. Screen readers will read the visible text.
Fix: Only use aria-label when there’s no visible text to read, like icon buttons.
Mistake 2: Forgetting to update aria-expanded when toggling
You add aria-expanded="false" to your menu button but forget to change it to true when the menu opens. The screen reader still announces the menu as closed.
Fix: Make sure your JavaScript updates aria-expanded whenever the element’s state changes.
Mistake 3: Using aria-hidden on interactive elements
Never put aria-hidden="true" on a button, link, or form field that users need to interact with. It makes the element invisible to screen readers.
Fix: Only hide purely decorative elements. If a user needs to click it or type in it, it should not be hidden.
Mistake 4: Overloading aria-describedby with too much text
Linking every error, help tip, and description to one input field creates a wall of text when a screen reader reads it all at once.
Fix: Keep descriptions concise. If you have multiple pieces of information, use separate elements and only describe the most relevant one per field.
Mistake 5: Mixing up aria-label and aria-labelledby
aria-label puts text directly into the attribute. aria-labelledby points to the ID of another element. Mixing these up means the label either doesn’t show up or points to nothing.
Fix: Use aria-label for short, self-contained labels. Use aria-labelledby when you want to reference text that’s already on the page.
How to test ARIA labels on your store
You don’t need to be a tester to check your store’s accessibility. Here are quick methods you can use right now.
Chrome DevTools (2 minutes)
Open your store in Chrome. Right-click any element and choose “Inspect.” In the Elements panel, look for the Accessibility tab on the right side. It shows you the accessibility tree, including all ARIA attributes on each element. Check that buttons, links, and form fields have proper names and roles.
VoiceOver on Mac (5 minutes)
Press Cmd + F5 to turn on VoiceOver. Navigate your store using Tab to move between elements and VO + Space (Control + Option + Space) to activate things. Listen to what VoiceOver announces. If you hear “button” without a name, or “image” without a description, you’ve found an accessibility gap.
NVDA on Windows (5 minutes)
Download NVDA for free. Turn it on and use Tab to navigate. NVDA reads each element as you reach it. Visit your product pages, your cart, and your checkout. Listen for missing labels, unlabeled buttons, and silent form fields.
Automated tools
Lighthouse in Chrome DevTools has an accessibility audit that catches many common ARIA issues. Run it on your homepage, a product page, and your checkout. It won’t catch everything, but it’s a fast way to find obvious problems.
For a deeper automated check, run your site through axe DevTools or WAVE. Both are free browser extensions that flag specific ARIA errors with explanations of why they matter and how to fix them.
Quick reference cheat sheet
Here’s a handy table you can share with your developer or keep bookmarked.
| Attribute | Purpose | WooCommerce Example |
|---|---|---|
role | Defines what an element is | role="button" on Add to Cart |
aria-label | Names elements without visible text | Labeling the cart icon |
aria-labelledby | References existing visible text | Connecting a product grid to its heading |
aria-describedby | Links to extra descriptions | Attaching shipping policy to a field |
aria-live | Announces dynamic changes | Updating cart count after adding items |
aria-hidden | Hides decorative elements from screen readers | Hiding star rating icons |
aria-expanded | Shows if a menu or panel is open/closed | Mobile navigation toggle |
aria-current | Marks the current page in navigation | Highlighting active Shop link |
aria-required | Marks form fields as mandatory | Checkout email field |
aria-invalid | Indicates a validation error | Failed phone number format |
What if you don’t want to fix all of this manually?
We get it. ARIA labels are important, but going through every template, plugin, and custom code snippet on your store is a big task. That’s exactly why we built the WooCommerce Accessibility Fixer.
The public 1.5.1 release has nine targeted fixers. Its form-label fixer filters post content, and its error-message script associates selected WooCommerce errors with fields. It does not prove that every product widget, navigation control, cart, or checkout field has a correct name. Test the examples in this guide on the rendered page.
If you want a hands-on approach, check out our guides on keyboard navigation testing and screen reader testing for WooCommerce to learn more about making your store work for everyone.
Your ARIA labels checklist
Use this checklist to audit your store. Work through each item, and you’ll cover the most impactful accessibility fixes.
- All buttons have visible text or aria-labels
- Icon-only links (cart, search, menu) have descriptive aria-labels
- Product grids and sections use aria-labelledby to connect headings
- Mobile menu and accordions toggle aria-expanded on open and close
- Cart count updates use aria-live=“polite” so screen readers announce changes
- Decorative icons and images have aria-hidden=“true”
- Current page in navigation uses aria-current=“page”
- Required checkout fields use aria-required=“true”
- Form validation errors use aria-invalid and aria-describedby
- Navigation elements have descriptive aria-labels (like “Main navigation” and “Cart navigation”)
The bottom line
ARIA labels aren’t optional. They’re how your WooCommerce store communicates with the 15 to 20 percent of web users who rely on assistive technology. Without them, you’re losing customers, and you’re exposed to legal risk.
The good news is that most ARIA fixes are small changes that make a big difference. A labeled button here, an expanded attribute there, a live region on your cart count. Individually, each one is simple. Together, they transform your store from unusable to welcoming.
Whether you fix things manually or use a tool like the WooCommerce Accessibility Fixer, the goal is the same. Make your store work for every customer who walks through your digital door.
Sarah did it. Her store is now fully accessible, her conversion rate improved, and she sleeps better at night knowing she’s not losing sales to invisible problems. You can do the same.