Semantic markup
Pages use real landmarks, one h1 each, and headings that do not skip levels, so a screen reader can navigate the structure instead of guessing at it.
Legal
Accessibility Statement
Hypd wants stayhypd.com to be usable by everyone, including people who browse with a screen reader, a keyboard, magnification, or reduced motion. This page says where we actually stand, what still needs work, and how to tell us when something blocks you.
Last updated: Target: WCAG 2.1 Level AA
Found a barrier? Email hello@stayhypd.com and we will reply within 5 business days.
Section 1
Our commitment
We build automation systems for owner-led businesses, and those businesses serve customers with a full range of abilities. It would be inconsistent to sell that work from a site people cannot use. We treat accessibility as part of the build, not as a retrofit.
We also think an accessibility statement is only worth reading if it is specific. So this page names the standard we measure against, the word that honestly describes our current status, and the gaps we already know about.
Section 2
Conformance status
Current status
Partially conformant with WCAG 2.1 Level AA.
"Partially conformant" means most of the site meets the standard, but some content does not yet fully conform. The specific gaps are listed in section 4. We do not claim full conformance, because we have not completed an independent third-party audit.
The Web Content Accessibility Guidelines (WCAG) define how to make web content more accessible. We measure against WCAG 2.1 Level AA, which is the level referenced by most public-sector and procurement requirements, including Section 508 in the United States and EN 301 549 in Europe.
Section 3
What we do
Keyboard access
Navigation, links, and the Audit and Contact forms are operable by keyboard alone, with a visible focus indicator. There is no keyboard trap anywhere on the site. Two known gaps are listed in section 4.
Text alternatives
Every image on the pages we tested has an alt attribute. Images that carry meaning describe it; purely decorative ones are hidden from assistive technology.
Colour and contrast
We target a contrast ratio of at least 4.5:1 for body text and 3:1 for large text and interface borders, and never use colour alone to convey meaning.
Responsive and zoomable
Layouts reflow down to 320px and support 200% zoom without loss of content or horizontal scrolling.
Accessibility in review
Accessibility checks are part of how we review new pages, not a pass we do at the end of a project.
Section 4
Known limitations
Despite our efforts, some parts of the site fall short. We list them here rather than wait until they are all fixed, because you deserve to know what to expect:
Low-contrast small text
Some secondary text — in the site footer, and in small captions on the Contact, Blog and Privacy Policy pages — sits between 2.9:1 and 4.5:1 against its background, below the 4.5:1 we target for normal-size text.
The main navigation menu
The header menu opens on hover and on keyboard focus, but cannot yet be closed with the Escape key. While open it can cover the field below it, so a keyboard user can focus a control they cannot see.
The short form on the home page
Its three fields are not yet programmatically linked to their visible labels and show no focus outline when selected. The full forms on the Audit and Contact pages do not have these problems and are the better route if you use a screen reader.
Autofill is not offered
Our forms do not yet declare autocomplete information, so your browser or assistive technology may not offer to fill in your name, email address, or website for you.
One card row on mobile
On the home page at small screen sizes, a horizontally scrolling row of cards may not be reachable by keyboard in some browsers. Chrome handles it; Safari does not.
Motion is only partly covered
Most animation stops when your system asks for reduced motion. Smooth scrolling and the animated hero sequence are not yet covered by that setting. The hero does not autoplay — it moves only as you scroll.
If something not on this list blocks you, tell us. A real report from someone who hit the problem is worth more than another automated scan.
Section 5
Tell us about a barrier
If any part of this site stops you from doing what you came to do, contact us and describe what happened. Include the page address, what you were trying to do, and the browser or assistive technology you were using, if you know it.
We aim to acknowledge accessibility reports within 5 business days. If a fix will take longer, we will tell you what we are doing and offer another way to get the information or complete the task in the meantime.
Section 6
If the site does not work for you
Nothing on this site is available only through the site. If a page, form, or document is not accessible to you, we will provide the same information and the same service another way — by email, over the phone, or in a format that suits you. There is no charge for that and you do not need to explain why.
Section 7
Technical information
Accessibility on this site depends on the following technologies:
- HTML
- WAI-ARIA
- CSS
- JavaScript
- SVG
The site is tested to work with current versions of Chrome, Edge, Firefox, and Safari on desktop and mobile, used with the screen readers built into those platforms. JavaScript is required for some interactive elements, such as the navigation menu and the audit form.
Section 8
How we assess this site
We evaluate accessibility using a combination of:
- Automated testing with axe-core 4.10 against the home, audit, contact, blog, and privacy policy pages.
- Manual keyboard-only walkthroughs using real key presses, covering navigation, the menu, and both forms.
- Contrast measured by compositing the actual rendered colours, because automated tools misread this site's colour format and return a false all-clear.
- Reduced-motion checks comparing running animations with the setting on and off.
- Layout reflow checks at 1280px, 390px, and 320px widths.
This is a self-assessment, last carried out on August 28, 2026. It has not been reviewed by an independent third party, and we say so plainly rather than imply an external audit we have not had.
Two limits on that assessment are worth stating. We have not yet run a session with a screen reader such as VoiceOver, NVDA, or JAWS, so how well each page is announced is only partly covered. We also tested five pages, not every page — though most findings come from shared components, so they likely apply throughout. Automated tools alone catch roughly a third of accessibility problems, which is why the keyboard testing matters.
We re-check the site when we ship significant changes, and we revisit this statement at least once a year. The date at the top of the page tells you when a person last reviewed it.
Section 9
What we are working on
Accessibility work here is continuing, not finished. In priority order we are raising the low-contrast text tokens, making the header menu close on Escape and when focus leaves it, giving the home page form real labels and a focus ring, adding autocomplete to every form field, and making the mobile card row reachable by keyboard.
When we fix something on the known-limitations list, we remove it from this page and update the date — rather than quietly leaving a stale list in place.