Accessibility at Says Hi

Our commitment

We aim for this directory to meet WCAG 2.2 at level AA. Accessibility is part of the site’s design brief — semantic landmarks, keyboard operability, visible focus, reduced-motion support, and layouts that stay usable at narrow widths and zoom — and new pages are checked against it before they ship.

What we do today

• Every page uses semantic landmarks — header, labelled navigation, main, and footer — with a “Skip to content” link to the main content.
• All navigation and actions are reachable by keyboard, with a visible focus outline; the menu is a native details element that works without JavaScript.
• Header navigation, the menu, and action buttons keep hit areas of at least 44 × 44 CSS pixels; other links — the footer list, guide breadcrumbs, and text links — meet WCAG 2.2 target-size rules.
• Informative images carry alternative text; purely decorative imagery is marked so assistive technology can skip it.
• Reduced-motion preferences are honored — transitions and smooth scrolling are disabled.
• Pages are built to reflow down to 320 px wide and remain usable at 200% zoom.
• Text colors are chosen to meet WCAG AA contrast against their paper and ink surfaces.
• There are no CAPTCHAs, no autoplaying media, and no timed content anywhere on the directory.

Known limits

• This statement covers only sayshi.app. The eight linked product sites are separate services with their own pages and their own accessibility considerations.
• The homepage’s decorative flourishes — the photo collage styling, paper texture, and handwritten margin notes — are ornamental; they are hidden from assistive technology or carry empty alternative text, and the information next to them is available as text.
• We have not commissioned a formal accessibility audit or certification. The points above are verified in the site’s code and browser review, not by a third party.

Report a barrier

If something on this site blocks you, tell us: email hello@sayshi.app with “Accessibility” in the subject. Include the page address and what happened — the device and browser help too. Reports are read, and a page is corrected when a problem is confirmed; the report a problem route covers everything else.