Accessibility Statement

Last updated: April 17, 2026

1. Our commitment

Sellium believes commerce tools should work for everyone. We design and build our marketing site, signup flow, admin panel, and customer-facing storefronts with accessibility in mind from day one, not as an afterthought.

This commitment includes:

• Using semantic HTML (<nav>, <main>, <button>, proper heading hierarchy).
• Meeting WCAG 2.1 Level AA color-contrast requirements on all text and interactive elements.
• Ensuring all interactive elements are reachable and operable by keyboard alone.
• Providing visible focus indicators on focusable elements.
• Writing alternative text for all informational images (and marking decorative images with empty alt).
• Testing with screen readers (VoiceOver on macOS/iOS, NVDA on Windows) during feature development.
• Building forms with explicit <label> associations, clear error messaging, and accessible validation feedback.
• Respecting user preferences for reduced motion, font size, and color scheme where relevant.

2. Conformance status

This accessibility statement applies to the Sellium marketing site (sellium.app), signup flow, admin panel (/admin-site), platform admin (/platform), and the storefronts our customers build on Sellium.

Self-assessment, April 2026: We believe the marketing site and legal pages are largely conformant with WCAG 2.1 Level AA. The admin panel and signup flow are partially conformant (see known issues below).

3. Measures we take

Design

• All text meets the 4.5:1 contrast ratio against its background for normal text, and 3:1 for large text and UI components.
• Font sizes scale with browser zoom up to 200% without loss of functionality.
• Interactive states (hover, focus, active, disabled) are visually distinct and not conveyed by color alone.
• No information is conveyed by color alone — icons, text labels, and patterns supplement color.

Development

• Semantic HTML wherever a native element exists for the job (native buttons for buttons, native inputs for inputs — not <div> with click handlers).
• ARIA attributes only where semantic HTML falls short, and tested with screen readers.
• Keyboard navigation in a logical tab order; skip links where content precedes a long navigation.
• Modal dialogs trap focus, restore focus on close, and can be dismissed with Escape.
• Forms announce errors programmatically (not just visually).

Content

• Plain language over jargon wherever possible.
• Descriptive link text (no "click here" or "read more" as the sole anchor).
• Heading hierarchy reflects the document outline (one H1 per page, no skipped levels).
• Videos (when published) include captions or transcripts.

4. Known issues & limitations

We aim to be candid about where we fall short. The following are known or suspected issues we are tracking and working on:

• Admin panel keyboard navigation: some custom modals in the CRM may not fully trap focus. Workarounds: use the close button or Escape key. Full audit planned.
• Data tables: large tables in Ad Manager and Comment Hub may not yet expose complete row/column header relationships to screen readers.
• Charts: analytics charts are rendered as SVG/canvas without screen-reader-accessible data summaries. Each chart is paired with a numeric summary card, but the raw chart is not independently accessible.
• Creative Studio preview: AI-generated video previews do not yet have automatic captions (underlying videos may be silent or include captions depending on the creative).
• Cookie banner and impersonation banner: both should be tested more thoroughly with screen readers.

None of these prevent use of core commerce features, but we recognize they reduce the quality of the experience for some users and we are prioritizing fixes.

5. Compatibility

Sellium is designed to work with the following combinations. We test with the latest two major versions of each:

• Browsers: Chrome, Safari, Firefox, Edge (desktop and mobile).
• Screen readers: VoiceOver (macOS, iOS), NVDA (Windows), TalkBack (Android, limited testing).
• Assistive inputs: keyboard-only navigation, speech input (Dragon NaturallySpeaking, Voice Control), high-contrast OS themes.

We do not officially support Internet Explorer. If you use assistive technology that isn't listed above and encounter issues, please tell us — we want to know.

6. Technical specifications

Accessibility of Sellium relies on the following technologies to work with the combination of web browser and any assistive technologies or plugins installed on your device:

• HTML
• WAI-ARIA
• CSS
• JavaScript

These technologies are relied upon for conformance with the accessibility standards used.

7. Feedback & contact

We welcome your feedback on the accessibility of Sellium. Please let us know if you encounter accessibility barriers:

If you don't receive a satisfactory response from the accessibility address, you can escalate to contact@sellium.app.

8. Enforcement & formal complaints

If you live in a jurisdiction with specific accessibility enforcement bodies (for example, the U.S. Access Board, the UK Equality and Human Rights Commission, or an EU member state authority implementing the European Accessibility Act), you have the right to contact them if you believe Sellium is not meeting applicable standards. We ask that you contact us first so we have a chance to address the issue directly.

9. Assessment approach

Sellium assesses the accessibility of its products using the following approaches:

• Self-evaluation: Internal team review against WCAG 2.1 Level AA criteria using automated tools (axe DevTools, Lighthouse) and manual testing.
• User testing: We include a small number of users of assistive technology in usability tests when feasible.
• Third-party audit: Planned. An independent accessibility audit is budgeted for the quarter following our first enterprise contract. We will publish the results on this page.

10. Continuous improvement

Accessibility is not a one-time project. As we add features, refactor code, and onboard customers, we bake accessibility into our development process:

• Every new UI component is reviewed against WCAG 2.1 AA criteria before shipping.
• We regression-test keyboard navigation on the login, signup, and main admin flows monthly.
• We update this statement whenever we ship changes that materially affect accessibility.

This statement will evolve. If you're reading this and something feels outdated, please let us know.