Sample report

Accessibility review: checkout page

This is the kind of report Skilled A11y writes in Claude. The shop, code and findings are made up for illustration.

Scope

src/pages/Checkout.tsx, CartButton.tsx, PromoDialog.tsx, PaymentForm.tsx

Checked against

WCAG 2.2 A and AA

Method

Code review plus a pasted axe-core report

Not checked

Screen reader output, rendered colours in every state, other pages

Summary

Nine findings. Two are blockers: the cart button has no accessible name, and the card number field has no label, so screen reader users can't complete checkout. Focus is lost when the promo dialog closes. Fixes for the five confirmed findings are below; four items need a person to test.

Confirmed findings

1. Blocker Cart button has no accessible name

   • WCAG: 4.1.2 Name, Role, Value (A) · Certain
   • Where: CartButton.tsx line 12
   • Problem: The button contains only an icon and a count. Screen readers announce "button" or "button 3", so blind users can't find the cart.
   • Fix: add aria-label={`Cart, ${count} items`} to the button and aria-hidden="true" to the icon and count.
   • Verify: tab to it with VoiceOver or NVDA on and hear "Cart, 3 items, button". axe rule button-name should pass.

2. Blocker Card number field has no label

   • WCAG: 1.3.1 Info and Relationships (A), 3.3.2 Labels or Instructions (A) · Certain
   • Where: PaymentForm.tsx line 48
   • Problem: The placeholder "1234 5678 9012 3456" is the only label. It disappears when typing and isn't announced as a name.
   • Fix: add <label htmlFor="card">Card number</label> and keep the placeholder as a hint.
   • Verify: focus the field and hear "Card number, edit text". axe rule label should pass.

3. Serious Focus is lost when the promo dialog closes

   • WCAG: 2.4.3 Focus Order (A) · Likely
   • Where: PromoDialog.tsx onClose
   • Problem: After closing, focus goes to the top of the page. Keyboard users have to tab through the whole page again.
   • Fix: store the trigger with useRef and call triggerRef.current?.focus() in onClose, or use a native <dialog>, which returns focus on close.
   • Verify: open the dialog with Enter, press Escape, and check focus is back on "Add promo code".

4. Serious Payment errors aren't announced

   • WCAG: 3.3.1 Error Identification (A), 4.1.3 Status Messages (AA) · Certain
   • Where: PaymentForm.tsx error <div>
   • Problem: "Card declined" appears in red above the form with no role or link to the field. Screen reader users don't know the payment failed.
   • Fix: render the message in a role="alert" region, and set aria-invalid="true" and aria-describedby on the card field.
   • Verify: submit a test card that declines and hear the error read out.

5. Serious Promo code link text is grey on white at 3.1:1

   • WCAG: 1.4.3 Contrast (Minimum) (AA) · Certain
   • Where: .promo-link, colour #8a94a6
   • Fix: use #5b6576 (5.9:1) or the brand blue.
   • Verify: axe rule color-contrast should pass.

Likely issues (depend on context)

• The "Express checkout" buttons are images from a third-party script. If they have no names inside the iframe, report it to the provider.
• The order summary collapses on mobile. If it uses a div with a click handler, it needs to be a button with aria-expanded.

Needs a human test

• Product image alt text matches each photo.
• Checkout reads in a sensible order with a screen reader on a phone.

Quick wins

• Add autocomplete values (cc-number, cc-exp, postal-code) to the payment fields.
• Make the quantity buttons at least 24 by 24 px.

Suggested next steps

• Fix the two blockers before the next release.
• Run the keyboard and screen reader script on the full checkout once.
• For legal risk questions, ask a qualified lawyer; this review is not a conformance report.