Accessibility statement

1. Our commitment

Wehoz is committed to making the storefront usable by everyone. We design and build to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA, the international standard for accessible web content.

We treat accessibility as a quality bar, not a checklist — every shipped feature is reviewed against keyboard navigation, screen-reader experience, and color/contrast standards before it goes live.

2. How we test

Automated — axe-core scans run on every pull request; we block merges with critical or serious findings.
Manual — screen-reader passes on macOS VoiceOver, NVDA with Firefox, and JAWS with Chrome. Keyboard-only navigation testing on every major flow.
Lighthouse — we hold an Accessibility score of 95+ on all production pages.

3. What we've built for

Keyboard navigation — every interactive element reachable by Tab; skip-to-main-content first focusable element; drawers and modals trap focus while open and restore it on close.
Screen readers — semantic HTML, descriptive alt text on all images, ARIA only where native semantics fall short.
Color and contrast — 4.5:1 minimum text contrast (3:1 for large text); UI components meet 3:1 against background.
Touch targets — 44×44 px minimum for interactive elements.
Motion — prefers-reduced-motion honored across animations, rotating banners, and auto-playing carousels.
Text resizing — content reflows at 200% zoom without horizontal scroll.
Forms — every input has a programmatic label; errors are announced with aria-live; required fields are clearly marked.

4. Known gaps

We publish known gaps so you know what to expect:

Stripe Elements payment form — third-party iframe with some limitations on focus order. Stripe is working on it; we'll move to their updated drop-in once available.
PDP image gallery — keyboard pagination works, but the swipe gesture announcer for screen readers is being refined.
Phase 2 reviews UI — when shipped, will undergo a dedicated a11y pass before public release.

5. Reporting an issue

If you encounter an accessibility barrier on Wehoz, please tell us. We treat accessibility bug reports as high priority.

Email: accessibility@wehoz.com.

In your message, please include:

The URL where the issue occurred
A description of the problem
The assistive technology you were using, if applicable (e.g., NVDA + Firefox)

We aim to acknowledge within one business day and resolve within 14 days for serious issues.

6. Standards we reference

WCAG 2.2 AA — primary conformance target
Section 508 of the US Rehabilitation Act — applicable for US federal accessibility expectations
ADA Title III — applied through the WCAG 2.2 lens

7. Ongoing work

Accessibility is never “done.” We re-run automated scans on every release, re-test the top customer flows monthly, and budget time each sprint for incremental improvements.

If anything in this statement is unclear, or if you have suggestions for how we can do better, reach out.

1. Our commitment

We treat accessibility as a quality bar, not a checklist — every shipped feature is reviewed against keyboard navigation, screen-reader experience, and color/contrast standards before it goes live.

2. How we test

Automated — axe-core scans run on every pull request; we block merges with critical or serious findings.

Manual — screen-reader passes on macOS VoiceOver, NVDA with Firefox, and JAWS with Chrome. Keyboard-only navigation testing on every major flow.

Lighthouse — we hold an Accessibility score of 95+ on all production pages.

3. What we've built for

Keyboard navigation — every interactive element reachable by Tab; skip-to-main-content first focusable element; drawers and modals trap focus while open and restore it on close.

Screen readers — semantic HTML, descriptive alt text on all images, ARIA only where native semantics fall short.

Color and contrast — 4.5:1 minimum text contrast (3:1 for large text); UI components meet 3:1 against background.

Touch targets — 44×44 px minimum for interactive elements.

Motion — prefers-reduced-motion honored across animations, rotating banners, and auto-playing carousels.

Text resizing — content reflows at 200% zoom without horizontal scroll.

Forms — every input has a programmatic label; errors are announced with aria-live; required fields are clearly marked.

4. Known gaps

We publish known gaps so you know what to expect:

Stripe Elements payment form — third-party iframe with some limitations on focus order. Stripe is working on it; we'll move to their updated drop-in once available.

PDP image gallery — keyboard pagination works, but the swipe gesture announcer for screen readers is being refined.

Phase 2 reviews UI — when shipped, will undergo a dedicated a11y pass before public release.

5. Reporting an issue

If you encounter an accessibility barrier on Wehoz, please tell us. We treat accessibility bug reports as high priority.

In your message, please include:

The URL where the issue occurred

A description of the problem

The assistive technology you were using, if applicable (e.g., NVDA + Firefox)

We aim to acknowledge within one business day and resolve within 14 days for serious issues.