Platform guide
Are Smart Add-Ons product fields accessible to screen reader users?
Every field type carries aria-required and aria-invalid, validation errors are marked role="alert" so they're announced automatically, and the image/color swatch picker is built on real native radio inputs inside a role="radiogroup" fieldset rather than a custom JavaScript-only widget — which means arrow-key navigation between options works through the browser's own built-in behavior, not a hand-written keyboard handler. One real gap: field errors aren't linked to their input with aria-describedby, so a screen reader announces the error when it appears but doesn't repeat it if the user tabs back to a field afterward.
Smart Add-Ons accessibility ARIA support is a real question worth answering with the actual markup, not a marketing claim — this is what the frontend components genuinely render, checked field type by field type, including the one place coverage isn’t complete.
Smart Add-Ons accessibility ARIA support, field by field
Text, textarea, dropdown, date, checkbox, checkbox group, radio, custom price, and image select all carry the same two attributes tied to real component state:
<input
aria-required={ required }
aria-invalid={ Boolean( error ) }
...
/>aria-required is what lets a screen reader announce “required” on a field without the sighted-only visual asterisk being the only signal — that asterisk itself carries aria-hidden="true", specifically so it isn’t read aloud as a confusing stray character before the label. aria-invalid flips to true the moment a field has a validation error, which most screen readers use to change how the field is announced on next focus.
Errors as a live region
A validation error renders with role="alert":
<p className="saue-field__error" role="alert">{ error }</p>An ARIA live region announces itself automatically the moment it appears in the DOM, without the user needing to have focus anywhere near it — a shopper who submits with an empty required field hears the error immediately, not only if they happen to tab back to that exact input afterward.
Image and color swatches: native radios, not a custom widget
The image-select field looks nothing like a plain radio button visually — swatches, product photos, a grid layout — but underneath, each option is a genuine native <input type="radio">, just visually hidden and styled through its paired <label>:
<div className="saue-image-select__grid" role="radiogroup" aria-label={ field.label }>
<label htmlFor={ inputId } className="saue-image-select__option">
<input id={ inputId } type="radio" name={ `saue_addons[${field.id}]` }
checked={ selected } aria-required={ required } onChange={ ... } />
...
</label>
</div>That choice matters more than it looks: because the actual interactive elements are real radio inputs, arrow-key navigation between swatch options, space-to-select, and screen-reader radio-group semantics all come from the browser’s own native behavior — none of it had to be reimplemented in JavaScript, and none of it can silently drift out of sync with how assistive technology expects a radio group to work. A photo swatch gets a real alt attribute from the option’s label; a color swatch (no photo) renders as a decorative aria-hidden span instead, since the color name is already present as visible, readable text next to it.
Common questions
Does Smart Add-Ons meet a specific WCAG conformance level?
No formal WCAG audit or conformance statement exists for the plugin — this article describes the real ARIA attributes and semantics present in the code as Smart Add-Ons accessibility ARIA support stands today, not a certified compliance level. A site with a formal accessibility requirement should still run its own audit against the finished page, the same as with any third-party component.
Is the color swatch itself distinguishable without seeing color?
Yes — the option’s label text (the color name, as entered in the admin) renders as visible text next to the swatch regardless of the swatch itself, so the selection is never conveyed by color alone.
Does keyboard-only navigation work without a mouse?
Yes, for the same reason the image-select field’s radiogroup works with assistive tech — every interactive control across every field type is a real native form element (input, select, textarea), not a div with a click handler standing in for one. Tab moves between fields, arrow keys move within a radio or checkbox group, and space/enter activate a control, all through ordinary browser keyboard handling rather than anything Smart Add-Ons accessibility ARIA support had to reimplement.
For the field types this accessibility coverage applies to, see the image select options guide, and the WAI-ARIA Authoring Practices Guide (opens in new tab) for the patterns referenced above.
Comments