Name, Role, Value — interactive state announcement

What it requires

A more focused subsection of WCAG 4.1.2. Visual state changes are useless to screen-reader users without programmatic state. A "Show details" disclosure button that visually rotates an arrow icon must announce its expanded/collapsed state via aria-expanded so screen-reader users hear "Show details, collapsed" → click → "Show details, expanded".

Standard ARIA pattern set: aria-expanded for disclosures, aria-pressed for toggle buttons, aria-checked for custom checkboxes, aria-selected for tabs/listbox options, aria-current="page" for current navigation item.

Common Shopify failure

Theme accordion / FAQ widget toggles open/closed visually with arrow icon rotation but ships without aria-expanded on the toggle button. Screen-reader users have no way to know whether the section is currently expanded.

How to fix it

Expose the component's actual state with the appropriate ARIA attribute and keep it synchronized with the visual and functional state. Adding a static attribute without updating the controlling script is not a fix.

Merchant QA checklist

• Scan the storefront page where this pattern appears: product pages, collection pages, cart drawer, customer-account pages, and any landing page built with theme sections.
• Confirm the issue is fixed in the rendered browser output, not only in the Liquid file. Shopify section settings, app blocks, and third-party scripts can reintroduce the same 4.1.2 (state) failure after a theme edit.
• Re-test the affected component with keyboard navigation and a screen-reader accessibility tree before publishing the theme, especially when the fix changes markup or ARIA attributes.

How AccessComply handles it

AccessComply uses automated rules to check supported patterns in the pages reached during a scan. Some WCAG requirements need human judgment, assistive-technology testing, or access to third-party content and cannot be established by an automated scan. This criterion is generally treated as a pattern that may have a supported suggested fix. If the app can safely match the issue to supported source code, nothing is written until the merchant says yes (one confirmation for the run, or change by change), and the result is checked afterward. Otherwise the merchant should use the guidance above and independent hands-on testing. The label is not a guarantee of detection, a fix, WCAG conformance, or legal compliance.

Primary source: W3C, Understanding WCAG 2.0 4.1.2 (state)