Skip to main content

Accessibility: what Storista handles and what you control

Storista's widget and player are built and tested to WCAG 2.2 level AA.

Written by Irek Khasianov

Short answer: Storista's widget and player are built and tested to WCAG 2.2 level AA. Two things are in your hands rather than ours: the colors you choose, and whether your videos have captions. This article covers both, plus how to avoid breaking accessibility with custom CSS.

What Storista handles for you

You do not need to configure any of this — it ships on by default:

  • Every control can be reached with the keyboard and activated with `Enter` or `Space`.

  • Every control shows a visible focus outline when reached by keyboard.

  • Controls have proper names and roles for screen readers, translated into every language we support. Adding to the cart is announced out loud.

  • Decorative icons are hidden from screen readers.

  • Auto-scrolling carousels stop completely for shoppers who have "reduce motion" enabled in their operating system, and always offer a pause button for everyone else.

  • The story player closes with `Escape` and returns focus to where the shopper was.

  • Small controls such as pagination dots meet minimum touch-target size.

What you control

1. Colors and contrast

You choose your widget's button and text colors in your Storista settings. Storista applies them faithfully — including combinations that are too low in contrast to read.

WCAG level AA requires a contrast ratio of at least:

  • - 4.5:1 for normal text against its background

  • - 3:1 for large text (roughly 18pt and up, or 14pt bold) and for the edges of buttons and controls

How to check: paste your two color values into a contrast checker such as the

WebAIM Contrast Checker. If it fails, darken the text or lighten the background until it passes.

The combination to watch is a light button colour with white text — it is the single most common failure we see, because it looks fine on a designer's monitor and fails in daylight or on a lower-quality screen.

2. Captions on your videos

Storista transcribes videos automatically and shows a captions button on the videos that have been transcribed. Videos that have not been transcribed show no captions button, since a button that does nothing is worse than none at all.

WCAG level AA requires captions on prerecorded video with audio. If your videos carry spoken information a shopper needs, check that they show a captions button in the player. If a video matters and has none, upload or generate captions.

A video with no speech and no meaningful audio does not need captions.

3. The page around the widget

Storista is embedded in your theme. An accessibility audit of your store also looks at your heading structure, your navigation, your own color scheme, and your checkout — none of which Storista can influence. If an audit flags problems outside the widget, those belong to your theme or your other apps.

If you write custom CSS

Custom CSS aimed at Storista is supported, and merchant CSS deliberately takes precedence over our own styles. That also means custom CSS can remove accessibility features. In order of how often we see it go wrong:

1. Never remove focus outlines. Rules like `outline: none`, or a blanket

  *:focus { outline: 0 }

in your theme, make Storista unusable for keyboard shoppers — they can no longer see where they are. This is a direct WCAG 2.4.7 failure. If our default ring clashes with your branding, restyle it rather than deleting it:

   /* Fine — a different visible indicator */
.storista-close_btn:focus-visible {
outline: 3px solid #c026d3;
outline-offset: 2px;
}

/* Not fine — removes the indicator entirely */
.storista-close_btn:focus-visible {
outline: none;
}

2. Do not shrink controls below 24x24 pixels. Tightening the spacing or size of pagination dots and arrows can take them under the minimum target size (WCAG 2.5.8). Our pagination spacing treats your configured gap as a minimum for this reason, so pagination may be slightly wider than you set it.

3. Do not hide controls with `display: none` to "tidy up". A hidden close or pause control is still required for shoppers who cannot use a mouse. If you do not want a control, turn the feature off in settings instead.

4. Avoid `!important` on Storista classes. You rarely need it — merchant CSS already wins ties — and it overrides accessibility styling you cannot see, such as focus rings.

5. Do not rely on our internal element structure. Class names that look like

_7tIBxW_navControls are internal and change without notice. Only class names beginning storista- are stable and safe to target. Descendant selectors that assume a particular nesting (.storista-spotlight-item > div) can also break when we restructure for accessibility — prefer targeting the storista- class you actually want.

Frequently asked

Our audit flagged color contrast inside the Storista widget. Whose problem is that?

It comes from the colors configured in your Storista settings, so it is fixed by changing those colors — see "Colors and contrast" above. Storista does not override merchant branding.

Our audit flagged missing video captions.

Captions follow transcription coverage of your own videos — see "Captions on your videos" above.

Is the widget usable with a screen reader?

Yes. We test with VoiceOver on macOS and with automated checks of the accessibility tree on every change. We have not yet completed an equivalent manual pass with NVDA or JAWS on Windows;

A shopper reported a problem. What do you need?

The store address, what they were trying to do, and their browser plus assistive technology. Contact us via in-app chat or help@storista.io

Did this answer your question?