Accessible eCommerce Filters and Checkout: A Practical WCAG 2.2 Audit

An online shop may look polished and still be awkward for someone using a keyboard, screen reader, touchscreen with limited dexterity, or a small phone at high zoom. The trouble tends to appear at decisive moments: opening a product filter, selecting a variation, reading an error message, or completing checkout. Accessibility is not a decorative layer added after development. It is a way to make everyday shopping actions understandable and operable for more people. This practical audit focuses on product discovery and checkout, with examples relevant to Webasyst Shop-Script and other catalogue-driven stores.

Map the journey before testing individual components

Start with a real task: find an item in a large category, narrow results by two attributes, inspect the item, add it to the basket, and complete a test order. Include a product with several variants and another with a longer technical description. Note every control that changes content without moving to another page. Repeat the journey without a mouse. Then repeat at increased browser zoom, on a narrow mobile viewport, and with a screen reader when possible. This reveals problems a static accessibility scanner cannot find.

Record the page, action, expected result, actual result, device and severity for each issue. A keyboard trap inside a filter panel is more urgent than a decorative icon missing a description. Treat stock, price and payment accuracy as part of the test: a technically accessible button is not useful if it adds the wrong variant.

Make category filters work without precise mouse movements

Filters are particularly fragile in shops with custom themes and many plugins. A checkbox may look clickable but only respond when its tiny square is hit. A dropdown may open on hover and vanish as soon as keyboard focus moves. An AJAX refresh may replace the whole product grid without telling the shopper that results changed. Prefer native buttons, checkboxes and select elements where they suit the interaction. Make the entire visible filter label clickable and provide a clear Apply or Reset action where immediate updates would be confusing.

When results change, retain a sensible focus position and communicate the updated count in an accessible status message. Avoid unexpectedly sending focus to the top of the page after every filter selection. Test combinations that return zero products: a useful empty state explains why nothing matched and provides a route to remove filters. These details improve the workflow for everyone, including shoppers on slow mobile connections.

Show visible keyboard focus and avoid hidden controls

Press Tab from the header through navigation, sorting, filters, product cards and basket controls. Can you see exactly where you are? A custom outline removed by CSS may make focus impossible to track. Sticky headers and floating chat widgets can also hide the active element. The W3C's WCAG 2.2 explanation of Focus Not Obscured describes the Level AA requirement that a focused component must not be entirely hidden by author-created content. Check the actual layout after menus, notices and cookie banners appear, not only the initial screenshot.

A practical repair might involve restoring an obvious focus indicator, adjusting scroll margins beneath a sticky navigation bar, and managing focus when a modal opens and closes. Do not insert positive tabindex values merely to force a visual order. Aim for document order that follows the reading and interaction sequence.

Give mobile controls enough room

Small close icons, adjacent quantity buttons and narrow pagination links require precision that not everyone has. The W3C's Target Size (Minimum) guidance explains the WCAG 2.2 Level AA criterion of 24 by 24 CSS pixels, subject to stated exceptions including sufficient spacing. That is a technical threshold, not automatically the best design size. In a purchasing flow, larger, comfortably separated controls can be more forgiving. Check the live clickable area, not just the icon's appearance.

Test at ordinary mobile widths and high zoom. Inspect the filter drawer, remove-filter chips, product gallery arrows, variant selectors and checkout accordions. Where controls sit close together, accidental taps can silently alter a shipping method or quantity. Clear selection states and an easy reversal path are just as important as larger targets.

Use real labels and instructions in checkout

Placeholder text that disappears while typing is a poor substitute for a persistent field label. A shopper should know whether the form asks for billing address, delivery address, company name or optional VAT details without guessing from an example. The W3C's form-label tutorial explains how visible labels and controls should be programmatically associated; its instructions guide recommends explaining mandatory fields and expected formats. Apply this to search boxes, coupon fields, address forms and account registration, not just payment.

Group related choices, such as delivery method and payment method, under a meaningful heading or legend. If the shop supports both personal and business customers, hide irrelevant fields carefully and make newly revealed fields reachable and understandable. Ask for information only when the process needs it. If the customer has already entered a valid address, do not discard it on an unrelated validation error.

Explain errors beside the field that needs attention

“Something went wrong” after a long checkout form leaves the customer to hunt for the mistake. Show a concise error summary, identify each invalid field, and describe how to fix it in words, not colour alone. For instance, “Enter an email address such as name@example.com” is more useful than a red border. The W3C's input-validation tutorial explains practical approaches to checking entries and reporting problems. Errors should be associated with their inputs so assistive technology can expose them.

Preserve correct answers after an error. Allow users to correct the specific issue and continue rather than restarting payment or losing a shipping choice. If a payment provider returns a failure, distinguish a declined payment from a system error and do not claim that an order failed before the order state is verified. Accessibility work must be tested with the actual integrations used by the business.

Keep account access compatible with password managers

Customers should not have to memorise arbitrary secrets or retype codes unnecessarily simply to purchase. The W3C's Accessible Authentication (Minimum) explanation highlights mechanisms such as password managers and copy-and-paste as ways to reduce cognitive effort. Avoid blocking paste in password or verification fields. Check that browser autofill works with clearly named inputs and that one-time codes can be entered without focus unexpectedly jumping between boxes.

Guest checkout may also be a sensible option for some stores, but it depends on the business model and fraud controls. Accessibility does not mean removing necessary security. It means designing security steps that people can understand, complete and recover from.

Do not confuse automatic checks with a complete audit

Automated tools can flag missing labels, low contrast in many contexts and structural defects. They cannot reliably determine whether an inventory filter makes sense, a stock warning is understandable, or a user can finish a complicated order without assistance. Combine scanning with keyboard testing, screen-reader checks, mobile zoom, and real user observations where available. Test both the initial page and states that appear after AJAX updates, form errors and successful submissions. Plugins often introduce their own interface elements; changing the theme alone may not fix them.

Prioritise by harm, frequency and cost of correction

Make a small issue register instead of ordering every observation by tool score. First fix blockers: impossible keyboard actions, invisible focus, unlabeled required fields and checkout errors that cannot be corrected. Next handle repeated friction such as undersized buttons or confusing filter feedback. Finally refine lower-impact presentation details. For each repair, name an owner and a measurable acceptance test. “Tab to every filter and select it without a mouse” is more actionable than “improve accessibility”.

Work in a safe staging environment when a change touches live checkout, payment callbacks, delivery options or tax calculation. Retest the original flows plus edge cases: no results, expired sessions, out-of-stock variants, failed payments and mobile browsers. Back up changed templates and preserve a rollback path. The smallest code change is not always the safest change if it disrupts stock or orders.

How a Shop-Script team can begin this week

Choose five representative pages and two checkout scenarios. Capture a short screen recording of the keyboard journey. List each blocker with the affected template or plugin and an expected correction. Confirm which system owns each component before changing it; a filter can be rendered by the theme but controlled by a plugin script. After repairs, repeat the same journeys and ask somebody unfamiliar with the store to carry them out. This keeps the work grounded in customer tasks rather than a theoretical score.

For complex catalogues, accessibility and discovery must be considered together. A filter needs accurate underlying attributes as well as usable controls; clear checkout messages require correct order and payment status. Quadro Design's eCommerce development service covers catalogue structure and shopping journeys, while our process page explains how requirements are evaluated before implementation.

Conclusion: make every action understandable and recoverable

A usable store lets people find the right product, see what changed, correct mistakes and finish the purchase with their preferred input method. WCAG 2.2 provides an important reference, but successful implementation also requires testing real categories, themes, plugins and integrations. Begin with the interactions customers depend on most, document concrete failures and verify the fixes without weakening the order flow. If a Shop-Script or another eCommerce site needs a focused review, contact Quadro Design with the pages and tasks that are causing difficulty.