Keyboard first
Core actions should be reachable and operable without a mouse, with visible focus and a skip-to-content link.
ACCESSIBILITY & INCLUSIVE USE
ClaraWide should be usable without requiring one “right” way to see, hear, point, click, or move.
This foundation adds browser accessibility preferences, keyboard-first navigation support, stronger focus visibility, reduced-motion behavior, larger-text and higher-contrast options, link underlining, maker image-alt requirements, and a dedicated accessibility support route.
Readable choices
People can request larger interface text, stronger contrast, and underlined links in this browser preview.
Motion can be reduced
ClaraWide respects the device reduced-motion preference and also offers an explicit browser preference.
Content needs descriptions
Maker listing photos already require alt text before publish readiness reaches 100%.
Choose what makes ClaraWide easier to use.
These preferences stay in this browser preview and apply across ClaraWide pages that load the shared accessibility foundation.
Keyboard navigation should be predictable.
Press Tab when a page opens. The first keyboard link should offer “Skip to main content,” bypassing repeated navigation.
Links, buttons, form controls, and other keyboard-operable elements receive a strong focus outline that should remain visible across ClaraWide themes.
The floating Aa accessibility menu can be opened by keyboard and closed with Escape, returning focus to the trigger.
Production QA must verify every control has an accessible name, required state, understandable error feedback, and logical focus movement after errors.
Important async states—uploads, moderation checks, ticket status, saved preferences—should use appropriate live-region behavior rather than visual-only messages.
Production testing must verify headings, landmarks, dialog semantics, tables/lists, controls, and dynamic content with common screen-reader/browser combinations.
Accessible marketplace content is partly created by makers.
ClaraWide can provide the tools and publishing requirements, while makers remain responsible for describing products accurately and accessibly.
The Listing Editor already requires non-empty alt text for every product image before publish readiness reaches 100%.
Open Listing Editor →Useful alt text should communicate what a shopper needs from the image—product, material, visible details, color, arrangement, or customization—not repeat keyword stuffing.
Size, ingredients, warnings, personalization requirements, pricing, processing time, and other essential purchase information should also exist as page text.
If ClaraWide later enables maker video or audio, the publishing model needs captions/transcripts and accessible media controls before broad launch.
Accessibility is a test plan, not one CSS file.
Use this checklist while moving toward launch. Items remain In Progress until tested against the real production experience.
Tell ClaraWide what is preventing you from using the site.
Accessibility problems should be routed as support issues and prioritized based on impact, especially when a barrier prevents account access, shopping, checkout, selling, safety reporting, or support itself.
Open an accessibility support ticket
Contact Accessibility Support →
The Help Center has a dedicated Accessibility Support category so the issue can enter support routing without being mislabeled as a safety report or order dispute.
Known prototype limitation
There has not yet been a complete independent audit of every ClaraWide page, dialog, theme, mobile breakpoint, screen reader, browser, keyboard flow, color pairing, zoom level, or dynamic interaction. That work belongs in launch QA and should remain visible on the checklist until completed.