Error not associated
Moderate effortFound on 2% of audited stores.
Add `aria-invalid="true"` and a linked `aria-describedby` error message to every form field that fails validation, so screen reader users are told exactly what went wrong.
What it is
When a customer fills out a form on your site (checkout, contact, newsletter sign-up) and submits it with a mistake, your site needs to tell them two things: (1) that the field is in an error state, and (2) what the error actually is. Sighted users see this visually — a red border, an error message below the field. But screen reader users rely on invisible HTML attributes called `aria-invalid` and `aria-describedby` to receive the same information. Without these attributes, a screen reader user hits Submit, nothing seems to happen, and they have no idea which field failed or why. WCAG 2.1 Success Criterion 3.3.1 (Error Identification) requires that input errors be identified and described to the user in text.
Why it matters
Roughly 7–8 million people in the US use screen readers, and many more use other assistive technologies. If your checkout or contact form is inaccessible, these customers simply cannot complete a purchase or inquiry — which is lost revenue you may not even know about. Beyond conversions, the ADA and similar laws in many countries treat web accessibility failures as discrimination, creating legal exposure including demand letters and lawsuits that have cost retailers thousands to hundreds of thousands of dollars to resolve. Fixing form error accessibility is also a direct ranking signal for Google's Core Web Vitals and overall page-experience scores, meaning it can influence organic search visibility. This is a quick, targeted fix with an outsized impact on inclusivity, revenue, and legal risk.
How to fix it
- Identify every form field that can enter an invalid/error state after the user submits or blurs the field (e.g. required fields left empty, email format errors, password mismatches).
- For each error message element, give it a unique `id` attribute (e.g. `id="email-error"`).
- On the corresponding `<input>` (or `<select>` / `<textarea>`), add `aria-describedby="email-error"` pointing to that error message's `id`.
- When validation fails and the error message becomes visible, also set `aria-invalid="true"` on the input; when the error is cleared, remove the attribute (or set it to `"false"`).
- Ensure the error message element is always present in the DOM (not removed/added dynamically with JS) but hidden when there is no error — use CSS `display:none` or `hidden` attribute rather than removing the element, so the `aria-describedby` reference is never broken.
- Test by tabbing to a field, triggering an error, and confirming a screen reader (NVDA, JAWS, VoiceOver) announces both the field's invalid state and the error message text.
Fix it on your platform
Pick your platform for the exact steps.
How to fix error not associated on Shopify
- In your Shopify admin, go to Online Store → Themes → click 'Edit code' on your active theme.
- Locate the form templates: checkout is controlled by Shopify's native checkout (customisable only on Shopify Plus via checkout.liquid or Checkout Extensibility); contact forms are in templates/page.contact.liquid or sections/contact-form.liquid.
- Open the relevant Liquid file and find each <input> or <textarea> element inside the form.
- Directly below each input, add a hidden error span: <span id="FIELDNAME-error" class="form-error" hidden></span>
- Add aria-describedby="FIELDNAME-error" to the matching input element.
- In your theme's main JavaScript file (assets/theme.js or assets/application.js), hook into the form's submit/validation logic to: set input.setAttribute('aria-invalid','true'), set errorSpan.textContent = 'Your descriptive error text', and errorSpan.removeAttribute('hidden') when invalid; reverse these on correction.
- For Shopify Plus stores, use Checkout Extensibility (checkout UI extensions) or the checkout.liquid theme section to add the same ARIA attributes to checkout fields.
- Save all files and test with a screen reader.
How to fix error not associated on WooCommerce
- Go to your WordPress admin → Appearance → Theme File Editor (or use a child theme and edit files via FTP/SSH).
- WooCommerce checkout fields are rendered by woocommerce/templates/checkout/form-checkout.php and individual field templates in woocommerce/templates/form-fields/.
- The recommended approach is to use WooCommerce's woocommerce_form_field filter in your child theme's functions.php to modify field output and inject aria-describedby and a sibling error span into each field's HTML.
- Alternatively, install the 'Accessible WooCommerce' plugin or a dedicated WooCommerce accessibility plugin that patches ARIA attributes automatically.
- For custom or page-builder checkout pages, add a small JavaScript snippet (via Appearance → Customize → Additional CSS/JS or a plugin like 'Code Snippets') that hooks WooCommerce's checkout_error event to apply aria-invalid and populate the linked error spans.
- Test on the /checkout and /my-account pages with a screen reader.
How to fix error not associated on BigCommerce
- In your BigCommerce control panel, go to Storefront → My Themes → click 'Edit Theme' (Stencil) or use the Theme Files editor.
- Locate the relevant Handlebars templates: templates/components/common/forms/ contains reusable form partials; checkout fields live in templates/pages/checkout/ or are handled by the Optimized One-Page Checkout.
- In each form partial, add id="FIELDNAME-error" error span elements adjacent to inputs, and add aria-describedby="FIELDNAME-error" to the input tags.
- In your theme's JavaScript (assets/js/theme/ directory), extend the validation logic (often in utils/form-utils.js or a page-specific file) to set aria-invalid and toggle the error span's hidden state.
- For the Optimized One-Page Checkout (which is a React app BigCommerce controls), use the Checkout SDK or Checkout Customization scripts injected via Script Manager (Storefront → Script Manager) to patch ARIA attributes after React renders the fields.
- Save, push your Stencil theme, and test with a screen reader.
How to fix error not associated on Wix
- Open your site in the Wix Editor.
- Click on the form widget (Wix Forms) to select it, then click 'Settings' in the toolbar.
- Wix Forms has built-in error messages; ensure 'Show error messages' is enabled in the form settings panel — Wix renders these visually but ARIA support depends on your Wix version.
- For full ARIA control, switch to Wix Studio (Wix's advanced editor) or use Wix Velo (developer mode): enable Velo via Settings → Developer Tools → Enable Velo.
- In the Velo IDE, open the page code and use $w('#inputEmail').onCustomValidation() or the form's onSubmit handler to call element.validity and then manually set the associated error text element's text property and add/remove aria-invalid via custom HTML components.
- For the most robust fix, replace the native Wix Form with a Custom HTML Element (<iframe>) that contains a fully accessible hand-coded form with proper ARIA, embedded via Add → Embed → Custom Code.
- Preview and test with VoiceOver or NVDA.
How to fix error not associated on Squarespace
- Log in to your Squarespace dashboard and open the page containing the form block.
- Click the form block → Edit → Form tab: ensure every required field has a meaningful field label (this becomes the error reference).
- Squarespace's native form blocks have limited ARIA customisation. To inject aria-invalid and aria-describedby, go to Website → Pages → select the page → click the </> icon (Page Header Code Injection) or use Settings → Advanced → Code Injection (site-wide).
- In the Code Injection footer, add a <script> block that listens for the form's submit event, validates fields, and programmatically sets aria-invalid and inserts/updates a sibling <span id="FIELDNAME-error"> with the error text.
- Alternatively, embed a fully accessible third-party form (e.g. Tally, Typeform accessible mode, or a hand-coded HTML form) via an Embed Block for complete control over ARIA markup.
- Save and test with a screen reader.
How to fix error not associated on Webflow
- Open your Webflow project in the Designer.
- Select the Form Block containing the field with validation errors, then click on the individual input element.
- In the Element Settings panel (right sidebar), scroll to 'Custom Attributes' and add: Name = aria-describedby, Value = FIELDNAME-error (matching the id you will give the error element).
- Add a Text Block element directly after the input inside the same Form Block wrapper; set its ID to FIELDNAME-error and set its initial visibility to hidden (toggle display:none via class).
- In the Webflow Interactions panel (or in a custom <script> added via Project Settings → Custom Code → Footer Code), write JavaScript that on form submission detects invalid fields and: sets aria-invalid='true' on the input, reveals the error Text Block, and populates its text content.
- Publish the site and test with VoiceOver (Mac) or NVDA (Windows).
How to fix error not associated on Adobe Commerce (Magento)
- Connect to your server via SSH or use your IDE to navigate to the active theme directory: app/design/frontend/VENDOR/THEME/.
- Locate the relevant form template, e.g. Magento_Customer/templates/form/register.phtml for registration, Magento_Checkout/templates/ for checkout forms, or Magento_Contact/templates/form.phtml for contact.
- In each .phtml template, find the <input> elements and add aria-describedby="FIELDNAME-error" as an attribute, then add a sibling <span id="FIELDNAME-error" class="mage-error" role="alert" style="display:none"></span>.
- Magento uses the mage/validation jQuery widget for client-side validation. In your theme's requirejs-config.js or a custom JS mixin, extend the showLabel and highlight methods of the validation widget to additionally set aria-invalid='true' on the field and show/hide the error span.
- Run bin/magento setup:static-content:deploy and bin/magento cache:flush after changes.
- Test on /checkout, /customer/account/create, and /contact using a screen reader.
Does your site have this issue?
Run a free SEOLZ scan to find error not associated — and every other issue — across your whole site in minutes.
Scan my site freeFrequently asked questions
What is Error not associated?
When a customer fills out a form on your site (checkout, contact, newsletter sign-up) and submits it with a mistake, your site needs to tell them two things: (1) that the field is in an error state, and (2) what the error actually is. Sighted users see this visually — a red border, an error message below the field. But screen reader users rely on invisible HTML attributes called `aria-invalid` and `aria-describedby` to receive the same information. Without these attributes, a screen reader user hits Submit, nothing seems to happen, and they have no idea which field failed or why. WCAG 2.1 Success Criterion 3.3.1 (Error Identification) requires that input errors be identified and described to the user in text.
Why does error not associated matter?
Roughly 7–8 million people in the US use screen readers, and many more use other assistive technologies. If your checkout or contact form is inaccessible, these customers simply cannot complete a purchase or inquiry — which is lost revenue you may not even know about. Beyond conversions, the ADA and similar laws in many countries treat web accessibility failures as discrimination, creating legal exposure including demand letters and lawsuits that have cost retailers thousands to hundreds of thousands of dollars to resolve. Fixing form error accessibility is also a direct ranking signal for Google's Core Web Vitals and overall page-experience scores, meaning it can influence organic search visibility. This is a quick, targeted fix with an outsized impact on inclusivity, revenue, and legal risk.
How do I fix error not associated?
Add `aria-invalid="true"` and a linked `aria-describedby` error message to every form field that fails validation, so screen reader users are told exactly what went wrong.