Designing Accessible E-Commerce in Figma

Accessible e-commerce design is decided mostly in the design file, not in the code editor. Contrast ratios, focus indicators, tap target sizes, and the reading order of a page are all choices a designer makes in Figma, and every one of them is far cheaper to fix on an artboard than after a developer has already built it. This tutorial walks through a practical process for auditing and improving an e-commerce Figma file for accessibility, step by step, using patterns you can apply to any storefront design — including our own Figma theme kits.

We are going to treat this as a working session rather than a checklist to skim. Open a product page or a collection grid from your own file as you read, and apply each step to it directly. By the end you will have a repeatable process you can run on any new page before it goes to development.

Why Accessibility Belongs in the Design Phase

It is tempting to treat accessibility as a QA-stage concern — something an auditing tool catches after launch and a developer patches with a few CSS tweaks. In practice, several of the most common accessibility failures on e-commerce sites are structural design decisions: a color palette that never had contrast checked, an icon-only button with no accompanying label, a filter panel with no visible focus state, or a product card whose entire clickable area is a single generic wrapper with no semantic meaning. None of these are quick fixes once a theme is built and populated with real products. Catching them in Figma, where a component is still just a component and not yet wired into a cart and checkout flow, is dramatically cheaper.

There is also a business case that is easy to underestimate. E-commerce is unusually dependent on wide reach: older shoppers, shoppers using screen magnification, shoppers navigating by keyboard because of a motor impairment, and shoppers on low-vision settings all convert less reliably when a storefront was designed and tested only for a mouse-and-perfect-vision user. A design that holds up under accessibility scrutiny is, in practice, a design that holds up for more of your actual traffic.

Step 1: Set Up Color and Contrast as Design Tokens, Not One-Off Choices

Start with color, because it touches every other component in the file. Rather than picking colors per-component as you design, define a small palette of text, background, border, and accent colors as Figma styles or variables, and check the contrast of each foreground/background pairing before you use it anywhere else. The two ratios worth memorizing from WCAG 2.1 AA are 4.5:1 for normal body text and 3:1 for large text (roughly 18pt+ or 14pt bold) and for meaningful UI elements like input borders and icons.

• Build a small, named set of text and background color pairs (e.g. body-on-surface, muted-on-surface, accent-on-surface) rather than sampling arbitrary hex values per screen.
• Check every pairing at the ratio it will actually be used at — a light gray that passes for a large price label may fail for a small caption using the same color.
• Do not rely on color alone to convey state. A "sold out" badge or a form error should also carry a label, icon, or pattern change, not just a color shift a colorblind shopper won’t register.
• Test your palette against a color-blindness simulation (Figma has plugins for this) before finalizing it, since red/green sale badges and stock indicators are a common failure point.

Once contrast-checked colors exist as reusable styles, every new component you build inherits them automatically, and you stop reintroducing contrast failures every time someone duplicates a frame and eyeballs a new shade.

Step 2: Build a Real Type Scale With Accessible Minimums

Type in e-commerce design tends to drift smaller over time as designers try to fit more product information into a card — price, variant, badge, rating — into a fixed width. Set hard floors before that drift starts: body copy should not go below roughly 16px on desktop and should scale sensibly on mobile rather than shrinking further, and line height should give text room to breathe (roughly 1.4–1.6x the font size for body copy). Save these as text styles in Figma so every designer touching the file, including a future collaborator, inherits the same minimums instead of guessing.

Pay particular attention to secondary text that gets treated as "decoration" — shipping notes, size guide links, filter labels. These are exactly the elements that tend to get set in a tiny, low-contrast gray because they feel unimportant, and exactly the elements a low-vision shopper is most likely to need clearly.

Step 3: Design Visible Focus and Interactive States for Every Component

A keyboard user navigating your storefront with Tab needs to see, at every step, exactly which element is focused. This is one of the most commonly skipped steps in e-commerce design files, because focus states only matter for keyboard and switch-device navigation, and most design review happens with a mouse. For every interactive component in your file — buttons, links, form inputs, quantity steppers, size/color swatches, accordion headers — build an explicit focus variant, not just a hover variant, and make sure it is visually distinct at a glance (a clear outline or ring, not a one-pixel border-color shift that is easy to miss).

• Give every component at minimum four states in Figma: default, hover, focus, and disabled — and treat focus as equally important as hover, not an afterthought.
• Use a focus indicator with real visual weight (an offset outline or ring), not just a subtle color change that fails the same contrast math as body text.
• Design the tap target, not just the visible icon — icon-only buttons (search, cart, wishlist) need a hit area of roughly 44x44px even if the icon itself is smaller, which matters for touch users and for anyone with limited fine motor control.
• Where you use color swatches for product variants, design a secondary indicator (a checkmark, a border ring) for the selected state, so it never depends on color perception alone.

Step 4: Structure Pages So Reading Order Matches Visual Order

Screen reader and keyboard users experience your page in the order it is structured, not the order it looks arranged on screen. A common e-commerce failure is a product page where the visual layout places reviews, size guide, and shipping info in tabs or floating panels that, structurally, come in a confusing order — or a filter sidebar that, in the underlying markup, is read before the page’s main heading. While Figma frames do not enforce a real DOM order, you can design with this in mind by grouping and naming layers in the logical reading sequence (heading, then price, then options, then add-to-cart, then supporting details) and by flagging in your handoff notes where a visually offset element — a sticky sidebar filter, a floating promo banner — needs a specific place in reading order once built.

This is also the step where heading hierarchy gets decided. Plan an H1 for the page title, H2s for major sections (product details, reviews, related products), and H3s for subsections, and annotate this in your Figma file rather than leaving it for a developer to infer from font size alone — visual size and semantic heading level are not the same thing, and a developer working from a design file with no annotation will often guess wrong.

Step 5: Annotate Alt Text, Labels, and ARIA Intent Directly in the File

Accessibility work that lives only in a designer’s head does not survive handoff. Use Figma’s annotation tools (or a simple sticky-note layer convention) to record what each image’s alt text should communicate, what an icon-only button’s accessible label should say, and where a component needs an ARIA role a developer wouldn’t infer from the visual alone — a custom dropdown that needs to behave like a native select element, a modal that needs focus trapped inside it while open, a carousel that needs pause controls. This turns accessibility from a set of intentions into a set of instructions a developer can actually implement without guessing.

• Alt text for product photography should describe what distinguishes that specific image (angle, color, detail shot), not a generic "product photo."
• Icon-only buttons need a written accessible label annotated next to them (e.g. "Add to wishlist," not just a heart icon).
• Note which elements are purely decorative and should be hidden from assistive technology, so a developer doesn’t waste effort giving a background pattern a redundant label.

Step 6: Design Forms and Checkout for Error Recovery

Checkout is where accessibility failures cost the most, because it is the step directly before revenue. Design every form field with a clearly associated label (not just placeholder text, which disappears once a shopper starts typing and offers no permanent context), a visible error state with both a color change and a written message, and enough spacing between fields that a shopper using zoom or a larger font size setting doesn’t end up with overlapping or hidden fields. Group related fields (like shipping address components) with a clear visual and structural grouping, and make sure required-field indicators are more than color alone — an asterisk plus the word "required," not a red border by itself.

Putting It Into Practice With a Figma Theme Kit

Running this process from a blank canvas is real work, which is why it helps to start from component libraries that already treat these decisions as defaults rather than afterthoughts. Our Wosa Figma and Optics Figma theme kits ship with contrast-checked color styles, a defined type scale, and interactive components built with hover, focus, and disabled states already separated — so instead of building your accessibility foundation from scratch, you are auditing and adjusting an existing one to fit your brand. If you are designing across more than one store concept, the e-commerce Figma bundle gives you several starting layouts to apply the same process against, which is a good way to internalize the checklist across genuinely different page types (a course catalog looks very different from a grocery listing) rather than just one.

Whichever file you start from, treat the six steps above as a pass you run before every handoff, not a one-time audit. New components get added to e-commerce files constantly — a new promo banner, a new filter type, a new upsell module — and each one needs its contrast, focus state, and reading-order placement checked the same way the original components were.

Frequently Asked Questions

Does designing for accessibility in Figma guarantee an accessible live site?

No — Figma defines the visual and structural intent, but the development stage still has to implement semantic HTML, correct ARIA usage, and keyboard behavior faithfully. Good Figma annotation dramatically reduces the chance of that intent getting lost or guessed at during development, but a final audit on the built, live site is still worth doing.

What is the minimum contrast ratio I should design for?

WCAG 2.1 AA calls for 4.5:1 for normal body text and 3:1 for large text and meaningful UI elements like borders and icons. Building your palette as contrast-checked Figma styles up front is the easiest way to keep every new component compliant automatically.

Do our Figma theme kits already meet these standards?

Our Figma kits are built with accessibility fundamentals as defaults — contrast-checked palettes, a defined type scale, and separated interactive states — so you are starting from a stronger baseline than a blank file. As with any theme, once you customize colors, fonts, or add new components, it is worth re-checking those specific changes rather than assuming the original defaults still apply everywhere.

Where should I start if I am auditing an existing e-commerce Figma file?

Start with color contrast, since it touches the most components and is the fastest to check with a plugin. From there, move to focus states on interactive components, then type scale minimums, then reading order and heading hierarchy, and finish with form and checkout error states, since those tend to be the most complex to retrofit. Browsing our Figma themes catalog is a useful way to see this checklist applied consistently across different page types.