Every Cart & Checkout UX Audit check

Carts stored only in React useState or non-persisted Zustand evaporate on refresh, tab close, and session timeout. Shoppers who added three items, got distracted, and returned thirty minutes later see an empty cart and abandon. Baymard Institute pegs abandonment around 70%, and volatile cart state compounds every other UX issue in this bundle. Lost cart data is lost revenue, and it disproportionately hurts mobile shoppers whose browsers aggressively reclaim memory.

Why this severity: Critical because a cart that empties on refresh directly causes purchase abandonment and revenue loss on every session.

Clicking Add to Cart with no visible response leaves the shopper guessing whether the click registered. They click again, then again, producing duplicate line items, or they give up and leave. Silent failures are worse: the network request 500s, the cart stays empty, and the next page load reveals nothing was added. This destroys trust in the checkout flow and is one of the most common causes of cart-abandonment micro-frustration documented in Nielsen Norman usability studies.

Why this severity: Medium because the defect frustrates every shopper and causes duplicate-add bugs, though the cart data itself is not corrupted.

Icon-only destructive controls — a bare "X" with no label, no confirmation, and no aria-label — remove items without warning and leave screen reader users with no way to identify what the button does. WCAG 2.2 SC 4.1.2 (Name, Role, Value) and SC 2.5.3 (Label in Name) both require that interactive controls expose an accessible name matching visible text. A user who accidentally taps an unlabeled remove button loses cart items with no recovery path; on mobile, mis-taps are routine. The business impact is measurable: unrecoverable cart losses increase abandonment and support load.

Why this severity: Medium because the damage is self-inflicted data loss rather than a security breach, but the WCAG 2.2 violations expose the site to accessibility litigation risk.

A cart that displays the wrong item count or a subtotal that double-counts tax erodes purchase confidence at the exact moment it matters most. ISO 25010:2011 functional correctness requires that computed outputs match specifications — a subtotal inflated by tax inclusion makes the cart total contradict the checkout total, producing customer support tickets, chargebacks, and cart abandonment. CWE-20 (Improper Input Validation) also applies when reduction logic operates on unvalidated price data that can produce negative or overflow subtotals.

Why this severity: Low because incorrect totals are visible to users before payment and do not expose sensitive data, but they erode trust and cause measurable abandonment.

When authenticated users' carts live only in localStorage, every device switch silently starts a fresh cart. A shopper who builds a cart on desktop, then completes checkout on mobile, finds an empty cart and abandons. ISO 25010:2011 functional correctness and CWE-20 both apply: cart state is user data that must persist correctly across sessions. Cross-device cart loss is a documented e-commerce abandonment driver — Baymard Institute consistently ranks it among top reasons for checkout failure. Without backend sync, any tab closure, browser clear, or device change wipes the cart irrecoverably.

Why this severity: High because cart data loss for authenticated users is a direct revenue impact that occurs silently on every multi-device session without any error signal.

Every additional checkout step sheds buyers. Baymard's large-sample checkout research shows conversion rate falls measurably with each extra page between cart and confirmation. Forcing shoppers through Address, Shipping, Billing, Coupon, Payment, Review, and Confirm as seven distinct pages is a self-inflicted revenue cut. Long flows also amplify error-recovery pain — a validation failure on step six means re-traversing the whole sequence — and mobile users drop off at the highest rates on multi-page flows.

Why this severity: High because excess steps directly reduce conversion on every order, compounding across the entire customer base.

A multi-step checkout with no progress indicator leaves shoppers wondering whether they're two forms away from paying or six. Uncertainty drives abandonment — Nielsen Norman research shows users tolerate longer flows when they can see the end. Missing progress cues also break screen-reader navigation, since assistive tech users rely on landmark regions and aria-current to orient. The progress indicator is also the primary anchor for back-navigation jumps, so its absence forces linear-only movement.

Why this severity: High because uncertainty about remaining steps measurably increases mid-checkout abandonment on multi-page flows.

Shoppers fix mistakes by going back. If the back button is missing from the payment step, a shopper who notices a wrong shipping address has to abandon and start over. Worse, if back navigation clears form data, every mistake forces re-entry of twenty-plus fields. Both behaviors drive abandonment on an otherwise-committed buyer. The underlying bug is almost always state being scoped to the step component instead of the checkout container.

Why this severity: Medium because the defect blocks error recovery on committed buyers, not on every shopper, but data loss is severe when it hits.

Forcing account creation before checkout is the single highest-impact abandonment driver in e-commerce — Baymard Institute's research consistently places mandatory registration at the top of checkout usability failures. OWASP A01:2021 (Broken Access Control) applies when auth middleware blocks a business-critical flow without a bypass: it is a misapplication of access control that excludes legitimate paying customers. CWE-306 (Missing Authentication for Critical Function) names the inverse failure — but the cart-checkout direction is an over-application, not an absence. Requiring signup before payment costs conversions directly and measurably.

Why this severity: Critical because mandatory registration before payment is the leading conversion killer in checkout flows, with direct, immediate revenue impact on every guest purchase attempt.

Presenting a payment form without a complete order summary — line items, shipping cost, tax amount, and final total — violates the reasonable expectation of informed consent before a financial transaction. ISO 25010:2011 functional correctness requires that the system accurately communicate what the user is authorizing. CWE-20 applies when placeholder values ("TBD", "$0.00") appear in tax or shipping fields: the user authorizes an amount they cannot verify, which leads to chargebacks, disputes, and loss of trust. Regulatory guidance in many jurisdictions (EU Consumer Rights Directive, FTC rules) also requires clear pre-payment disclosure of total charges.

Why this severity: Critical because a user who pays without seeing a complete summary can claim they did not authorize the actual charge, triggering chargebacks and regulatory exposure.

Typing a full address on mobile is the single slowest part of checkout. Without autocomplete, shoppers hunt-and-peck through street, city, state, and zip on a cramped keyboard, with every typo risking a shipping failure downstream. Browser-level `autocomplete` attributes alone let the OS fill saved addresses in one tap — skipping them is a pure self-own. Richer autocomplete via Google Places or Smarty cuts typing by roughly 20% and catches undeliverable addresses before the order is submitted.

Why this severity: High because missing autocomplete adds measurable friction to every address entry and drives mobile-checkout abandonment.

A generic "Validation failed" toast on submit tells the shopper nothing about which of the twelve fields is wrong. They scroll, squint, guess, retry, and leave. Field-specific inline errors — surfaced on blur next to the offending input — turn a recovery into a three-second fix. Screen-reader users are hit hardest: a toast with no `aria-live` region and no `role="alert"` on the field error is invisible to them, excluding customers who rely on assistive tech.

Why this severity: Medium because generic errors slow recovery for everyone and effectively block screen-reader users from completing checkout.

Every required field that isn't essential for fulfillment is a chance for the shopper to abandon. Asking for company name, middle name, birthday, or newsletter opt-in as mandatory fields on a one-time purchase is a self-inflicted conversion cut. Baymard's checkout benchmark sets the median essential-field count near seven — forms demanding twelve required fields underperform the median by a wide margin, and the damage is concentrated on mobile where each extra tap compounds.

Why this severity: Low because the defect reduces conversion incrementally per extra field rather than blocking checkout outright.

Most shoppers pay with a card registered to the same address they're shipping to. Making them type the exact same seven fields twice is pure friction with no payoff. A default-checked "Same as shipping" toggle collapses the billing section to a single checkbox for the common case while preserving separate-address entry for the minority that needs it. Missing this pattern adds roughly thirty seconds of typing and a fresh set of typo opportunities on every checkout.

Why this severity: Low because the defect only affects shoppers with matching addresses, but it adds friction on the majority path.

Hardcoding "State" and a 5-digit ZIP regex locks out every customer outside the United States. A Canadian shopper entering `K1A 0B1` hits a validation error on a valid postal code; a British shopper doesn't recognize "State" as the field for their county. Both abandon. If the country selector offers fifteen countries but the form never adapts to them, you're advertising international shipping and then blocking it at the form layer — a worse failure than not offering the countries at all.

Why this severity: Low in aggregate because most stores are US-first, but the block is total for every non-US shopper who reaches it.

A confirmation page that shows only "Thank you!" with no order number leaves the customer with no reference to use for support, returns, or tracking. ISO 25010:2011 functional correctness requires the system to confirm what actually happened: without a real order ID rendered from database data, the customer cannot verify the transaction completed, cannot initiate a return, and cannot contact support with a reference. CWE-20 applies when a hardcoded placeholder like `Order #12345` appears instead of the actual order ID — the system is presenting false information as confirmation. Post-purchase anxiety that goes unresolved by a clear confirmation page directly increases support ticket volume.

Why this severity: High because customers who cannot reference an order ID after payment cannot self-serve returns or tracking, driving support load and undermining purchase confidence.

A confirmation email is the shopper's receipt, their order-number reference for support tickets, and their trust signal that the payment went through. Missing it triggers support load ("did my order go through?"), chargebacks from shoppers who don't remember the purchase, and erodes repeat-purchase trust. It's also often a legal requirement under consumer-protection regimes — EU Consumer Rights Directive Article 8 mandates confirmation of distance contracts in a durable medium, which a missing email fails outright.

Why this severity: Medium because missing confirmation emails drive support load and can breach EU consumer-protection disclosure requirements.

Checkout forms with fixed pixel widths — a table at `width: 600px`, an input at `width: 400px` — cause horizontal scrolling at 375px viewport width, the baseline mobile target. WCAG 2.2 SC 1.4.10 (Reflow) requires content to reflow at 320px without horizontal scroll; SC 2.5.5 (Target Size) sets 44x44px as the minimum touch target. A payment button shorter than 44px on a touch screen has a measurably higher mis-tap rate, which causes failed submissions and abandonment at the highest-value step of the funnel. Mobile accounts for a majority of e-commerce sessions in most markets, making a broken mobile checkout a revenue-critical defect.

Why this severity: Medium because WCAG 2.2 Reflow and Target Size violations at the checkout step produce measurable mobile abandonment and expose the site to accessibility complaints.

A shipping method named "Standard" or "Express" tells the shopper nothing about when the box will actually arrive. Without a concrete date or day range, shoppers can't decide between shipping tiers, can't plan around the delivery, and default to the cheapest option by pure uncertainty. Showing "Arrives by Thursday, April 23" next to each tier turns an abstract choice into a comprehensible one and lifts upgrade rates on expedited shipping. It also reduces "where is my order?" support tickets downstream.

Why this severity: Low because the defect slows decision-making and nudges shoppers toward the cheapest tier rather than blocking purchase.

After the confirmation email lands, the shopper's next question is "where is my order?" Without an order-specific tracking link, every answer requires a support ticket. That's support cost per order, plus shopper anxiety that compounds into refund requests and chargebacks on orders that are merely in transit. A dynamic tracking URL containing the order ID — reachable from the confirmation page, the email, and the account order history — deflects the entire "WISMO" support category.

Why this severity: Low because the defect drives support volume rather than blocking checkout, but it scales linearly with order count.