Accessibility for Product Page Widgets

To make a product page widget accessible, build it so people can open, use and close it with a keyboard alone, give every control a clear name, and keep focus visible. The standard to measure against is the Web Content Accessibility Guidelines (WCAG), published by the W3C.

This guide is for store owners and developers adding third-party widgets, such as a size finder or a try-on button, to a WooCommerce store or any custom site. It covers what to check before and after you add one. This is general information, not legal or tax advice.

Why do widgets cause accessibility problems?

A widget is code you do not fully control. It can add buttons, pop-ups and images to your page, and any of them can trap a keyboard user or hide the page behind an overlay.

Your store is still responsible for the page as a whole. If a widget breaks keyboard use on your product page, shoppers who cannot use a mouse cannot buy.

What does WCAG ask of a widget?

WCAG groups its checks under four ideas: content must be perceivable, operable, understandable and robust. For a widget, most problems are in "operable" and "robust".

The most relevant checks are:

• Everything works by keyboard. No mouse-only controls.
• Controls have names. A screen reader should announce "Try it on, button", not "button".
• Focus is visible and not hidden. WCAG 2.2 adds Focus Not Obscured (Minimum), which says a focused item must not be completely hidden by content you author, such as a sticky bar or cookie banner.
• Targets are big enough. Target Size (Minimum) asks for at least 24 by 24 CSS pixels at Level AA, with exceptions such as enough spacing around smaller targets.

How should an accessible modal behave?

Many widgets open a modal, which is a window that sits on top of the page. The W3C's modal dialog pattern describes how it should work. Use it as your checklist.

1. Mark it up. The container has role="dialog" and aria-modal="true". A visible title is linked with aria-labelledby, or the container uses aria-label.
2. Move focus in on open. Focus goes to an element inside the dialog, usually the first focusable one.
3. Keep Tab inside. Tab moves to the next control and wraps from the last to the first. Shift+Tab does the reverse.
4. Close with Escape. Escape closes the dialog, and a visible close button does the same.
5. Return focus on close. Focus goes back to the button that opened the dialog.

If a widget fails any of these, ask the vendor to fix it, or choose another one.

How do you test a widget with a keyboard?

You do not need special tools for a first pass. Open a product page and put your mouse away.

1. Press Tab until you reach the widget's button. Is the focus outline visible?
2. Press Enter or Space to open it. Did focus move into the window?
3. Tab through every control. Can you reach all of them, and only them?
4. Press Escape. Did it close, and did focus come back to the button?
5. Repeat on a phone-sized window, where sticky bars can cover focused items.

Then try a screen reader such as VoiceOver or NVDA on the same steps. Listen for button names and for the dialog title when it opens.

Pages that change without a full reload add their own problems. The guide to routing pitfalls in single-page apps explains why widgets can lose their place when a shopper moves between products.

What about images and results inside the widget?

Any image a widget shows, such as a generated try-on picture, needs a text alternative that says what it is. A short phrase like "Your try-on preview of the blue linen shirt" is enough.

Status messages also matter. If the widget shows "Processing" and then a result, announce the change so screen reader users know something happened. A live region (aria-live="polite") is a common way to do this.

Do not rely on color alone for errors or success. Add text or an icon.

How do you add a button hook without breaking the page?

Where you place a button affects keyboard order. A button added in the product form sits near the other controls, so Tab reaches it at a sensible point. The guide to WooCommerce hooks for a try-on button shows where to put one.

Keep the trigger a real <button> element. A <div> styled like a button does not work with the keyboard unless you rebuild that behavior by hand.

What should you ask a widget vendor?

Before installing any widget, ask for answers in writing:

• Does the dialog follow the W3C modal pattern above?
• Can every control be used by keyboard?
• Are the buttons and images named for screen readers?
• Does it work at small screen sizes and with browser zoom?

Accessibility also supports trust. A page that works for everyone feels more reliable, which ties into which trust signals belong on a product page.

If you are adding a ZeDaq.ai widget, you paste one script tag into the product template, and the key is locked to your domain. Setup is in the widget docs. Test it with the steps above on your own theme, because your theme's sticky elements affect the result.

FAQs

Is accessibility a legal requirement for online stores?

It depends on where you sell. Laws differ by country and change over time, so check the rules for your market with an official source or a lawyer.

Which WCAG level should a store aim for?

Level AA is the common target. It covers the keyboard, focus and target size checks in this guide.

Can an accessibility overlay fix a broken widget?

Overlays do not change how the underlying code works. Fix the widget's markup and keyboard behavior at the source instead.

How often should you re-test?

Test after any theme change, widget update or new sticky element. A quick keyboard pass takes a few minutes.