Sarah lost 15% of her customers, and she never knew it

Sarah ran a WooCommerce store selling handmade ceramics. Her shop looked beautiful. She had gorgeous product photography, a clean layout, and her conversion rate for sighted visitors was solid. Then she ran an accessibility audit.

Her product pages were missing labels on buttons. Her cart icon had no text alternative. Her checkout form fields were unlabeled. For the 15 to 20 percent of users who rely on screen readers, her store was essentially invisible. Products they couldn’t navigate. Buttons they couldn’t find. A checkout they couldn’t complete.

Sarah was losing a significant chunk of potential revenue, and she had no idea. The good news? Once she learned about ARIA labels, most of the fixes were straightforward.

This guide is for store owners like Sarah. You don’t need to be a developer to understand what ARIA labels do. You just need to know what to ask your developer to fix, or what you can handle yourself with the right plugin.

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.

Here’s why this matters. Research shows that 94 percent of websites have WCAG failures. E-commerce sites are the number one target for accessibility lawsuits, with 70 to 80 percent of ADA lawsuits landing on online stores. The average settlement? Between $25,000 and $75,000. And that’s before you factor in the lost sales from customers who simply leave because your store is unusable for them.

ARIA labels aren’t a nice-to-have. They’re a business necessity.

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:

<div role="button" tabindex="0" onclick="addToCart()">Add to Cart</div>

Or better yet, just use a real button:

<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">&#9733;</span>
<span class="icon-star">&#9733;</span>
<span class="icon-star">&#9733;</span>

Right:

<span class="icon-star" aria-hidden="true">&#9733;</span>
<span class="icon-star" aria-hidden="true">&#9733;</span>
<span class="icon-star" aria-hidden="true">&#9733;</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.

AttributePurposeWooCommerce Example
roleDefines what an element isrole="button" on Add to Cart
aria-labelNames elements without visible textLabeling the cart icon
aria-labelledbyReferences existing visible textConnecting a product grid to its heading
aria-describedbyLinks to extra descriptionsAttaching shipping policy to a field
aria-liveAnnounces dynamic changesUpdating cart count after adding items
aria-hiddenHides decorative elements from screen readersHiding star rating icons
aria-expandedShows if a menu or panel is open/closedMobile navigation toggle
aria-currentMarks the current page in navigationHighlighting active Shop link
aria-requiredMarks form fields as mandatoryCheckout email field
aria-invalidIndicates a validation errorFailed 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.

It handles the heavy lifting automatically. It adds proper ARIA attributes to your product pages, checkout forms, navigation, and cart. It fixes the most common accessibility gaps so you can focus on running your store instead of rewriting your templates.

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.