Follow a customer from product to confirmation
For a Chicago retailer, a useful accessibility assessment includes finding a product, choosing an option, adding it to the cart, selecting delivery or pickup, and receiving order confirmation. A homepage scan cannot establish that those steps work together.
Use a safe test environment or an agreed production-testing procedure. Include an unavailable item, a missing option, and an invalid promotional code. These examples define assessment tasks; they are not claims about any particular store.
Make product choices understandable
Color swatches, size buttons, quantity controls, and product galleries need usable names and states. A customer should not need to recognize a color visually to understand which option is selected. Descriptions and image alternatives should accurately communicate the information required for the purchase.
Do not replace meaningful alternatives with repeated search keywords. An image showing a size chart needs information equivalent to the chart, while an image repeating nearby product text may need a different treatment. Context determines the appropriate alternative.
Purchase stage | What to check | Evidence of a usable outcome |
|---|---|---|
Select size or color | Names, grouping and selected states | The chosen option is understandable without vision |
Update the cart | Quantity controls and change announcements | The revised cart contents can be identified |
Select pickup | Store information and named location controls | The customer can understand the selected location |
Apply a promotion | Specific errors and preserved form information | The customer can correct an invalid code |
Recheck theme and app changes
A merchandising app can add a quick-view dialog, subscription selector, review section, or promotional popup. Those components may introduce new keyboard and screen-reader behavior after the theme was previously evaluated. Keep the assessment tied to the version and task actually tested.
For Shopify or WooCommerce, identify whether a barrier belongs to the theme, plugin, app, custom source, or checkout provider. A repair to an editable product template does not guarantee accessibility in a checkout area you cannot modify.
Verify a repair on the deployed storefront
Retain the finding and confirmed source difference. Then check the correct public page after deployment and repeat the affected product-to-cart task. If the proposed change is present only in a preview theme, record it as a preview, not a completed production repair.
Automated checks can identify certain technical problems. Human evaluation is still necessary for option meaning, focus management, dialog behavior, and the entire transaction. ADAFix does not certify full compliance based on a storefront scan.
Document an ADA complaint technically
Preserve the notice, alleged barriers, referenced pages, and relevant dates. Counsel should review legal deadlines and jurisdiction-specific questions. Technical work should describe what was observed and changed, not decide whether the complaint is valid or resolved.
Create a record for each tested state: the product, option, cart contents, delivery or pickup choice, testing method, and result. List untested apps and checkout steps as limitations. ADAFix provides remote technical support, not a Chicago law office.
Questions Chicago retailers ask
Is a clean product-page scan enough for checkout?
No. Checkout, pickup selectors, promotions, and error states need their own scoped evaluation.
Which platform guidance should we read?
See Shopify changes that can break accessibility or the WordPress and WooCommerce remediation guide.
How do we keep improvements from regressing?
Reassess important tasks after theme, app, and content changes. Preserve the tested version and date, then browse Illinois community coverage or review the technical complaint checklist.