Accessibility Statement

WebGrowly LLC ("WebGrowly," "we," "our," or "us") is committed to supporting digital accessibility for people with disabilities. We continually work to improve the user experience for everyone, and we apply relevant accessibility principles in our design, development, and content authoring across the WebGrowly marketing website, the WebGrowly OS platform, and any real estate websites hosted by us under our customers' custom domains (collectively, the "Service").

This Accessibility Statement describes the measures we take to support accessibility, the conformance target we work toward, how to request accommodations, and how to share feedback about accessibility barriers you encounter.

WebGrowly strives to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA, published as a W3C Recommendation on December 12, 2024 and as ISO/IEC 40500:2025. We additionally implement a number of Level AAA success criteria where they can be addressed in code without compromising design or functionality. Specific AAA criteria addressed are listed in Section 2(m) below.

WebGrowly does not, however, warrant or represent that this site or any specific page fully conforms to WCAG 2.2 at any level, the Americans with Disabilities Act (ADA), Section 508 of the Rehabilitation Act, the European Accessibility Act, or any other specific accessibility standard. Despite our best efforts, some content may not be fully accessible, particularly content sourced from third parties or newly added product surfaces that have not yet completed our accessibility review.

WebGrowly takes the following measures to support accessibility on the marketing site:

(a) Keyboard Navigability. We build the site with the goal of full keyboard navigability, including a visible focus indicator on every interactive element.

(b) Semantic Structure. We use semantic HTML landmarks — main, nav, header, footer, and section — so assistive technologies can parse and navigate page structure reliably. Each route exposes exactly one <h1> element so screen-reader users can orient by primary heading (WCAG 2.4.6 Headings and Labels, 2.4.10 Section Headings).

(c) Skip Links. We provide a localized skip-to-main-content link as the first focusable element on every page so keyboard users can bypass repeated navigation blocks (WCAG 2.4.1 Bypass Blocks). The link's accessible name is rendered in the page's active locale.

(d) Color Contrast. We design our default theme with WCAG-aligned color contrast targets, including elevated targets for body copy on dark backgrounds (≥ 7:1 for body text, satisfying WCAG 1.4.6 Contrast (Enhanced) at AAA). When the user enables an OS-level "Increase contrast" preference, we honor prefers-contrast: more to remove semi-transparent surfaces and force fully opaque text and borders.

(e) Focus Visibility. We ensure focused elements are not visually obscured by sticky headers (WCAG 2.4.11 Focus Not Obscured (Minimum) at AA, and 2.4.12 Focus Not Obscured (Enhanced) at AAA via generous scroll-margin offsets). Focus indicators meet the 2.4.13 Focus Appearance (AAA) target with a 2 px solid cyan outline plus a dark halo so the indicator remains visible on every surface in the design system, including on light or accent-tinted backgrounds.

(f) Reduced Motion. We honor the user's operating-system-level prefers-reduced-motion preference at both the CSS and JavaScript layers. CSS-driven animations and transitions are suppressed via a global media query, and Framer Motion animations are governed by <MotionConfig reducedMotion="user"> at the root of every locale tree. This satisfies WCAG 2.3.3 Animation from Interactions (AAA) and supports WCAG 2.2.2 Pause, Stop, Hide.

(g) Form Labels and Status. We structure form fields with programmatically associated <label> elements via htmlFor/id pairs, set the HTML required attribute and corresponding autoComplete tokens (per WCAG 1.3.5 Identify Input Purpose at AA), and announce form submission status to assistive technology with role="status" (success) and role="alert" (error) live regions.

(h) Text Alternatives. We provide tools and design patterns to support text alternatives for non-text content. Decorative iconography is hidden from assistive technology with aria-hidden="true"; meaningful icons that act as buttons receive an explicit aria-label.

(i) External Link Disclosure. Every link that opens a new browser tab or window includes a visually hidden "(opens in new tab)" announcement so screen-reader users are advised of the context change before activating the link, supporting WCAG 3.2.5 Change on Request (AAA) and aligning with WCAG technique G201.

(j) Touch Target Size. Interactive controls in the navigation chrome — including the mobile menu trigger, mobile menu close button, and cookie banner dismiss button — provide a minimum 44 × 44 CSS-pixel hit area, satisfying WCAG 2.5.5 Target Size (Enhanced) (AAA) without altering visible icon size.

(k) Modal Semantics. Dialogs use role="dialog", aria-modal="true", programmatic aria-labelledby/aria-describedby pointers, an Escape-to-close handler, body scroll lock, a Tab/Shift+Tab focus trap that cycles within the dialog, an initial focus target inside the dialog, and focus restoration to the triggering control on close (WCAG 2.1.2 No Keyboard Trap, 2.4.3 Focus Order, 4.1.2 Name, Role, Value).

(l) Forced-Colors and System Themes. We honor the forced-colors: active media feature for users who run Windows High Contrast Mode or equivalent, deferring to system-defined Canvas/CanvasText/Highlight colors so the OS theme is never overridden by decorative styling.

(m) Specific WCAG 2.2 AAA Criteria Addressed in Code. We have implemented the following AAA-level success criteria at the code layer; each is a strictly additive enhancement on top of our AA baseline:

• 1.4.6 Contrast (Enhanced) — body text on dark surfaces exceeds the 7:1 ratio.
• 1.4.8 Visual Presentation — long-form prose on legal and accessibility pages opts into the .prose-aaa utility (line height ≥ 1.5×, paragraph spacing ≥ 1.5× line height, no full justification, line length ≤ 80 characters).
• 2.3.3 Animation from Interactions — non-essential motion is suppressed when prefers-reduced-motion: reduce is set.
• 2.4.10 Section Headings — content is structured with a logical heading hierarchy across all routes.
• 2.4.12 Focus Not Obscured (Enhanced) — focus is never visually obscured by the sticky header, regardless of scroll position.
• 2.4.13 Focus Appearance — focus indicators are 2 px solid with ≥ 3:1 contrast against adjacent colors and a contrasting halo for visibility on every background in the design system.
• 2.5.5 Target Size (Enhanced) — primary chrome interactive controls meet a 44 × 44 CSS-pixel target.
• 3.2.5 Change on Request — context changes (such as opening a new tab) are announced before activation rather than triggered automatically without warning.

Several other AAA criteria — including 2.2.3 No Timing, 2.2.5 Re-authenticating, and 3.1.6 Pronunciation — are not applicable to this marketing site at this time. AAA criteria that require human authoring judgement (such as 3.1.5 Reading Level and 3.1.3 Unusual Words) are not claimed.

(n) Automated Testing in CI. We run Lighthouse CI on every push, with an accessibility score threshold that fails the build on regressions.

(o) Lint-Time Checks. We use ESLint with the jsx-a11y plugin at build time to surface common accessibility issues before they ship.

(p) Runtime Dev Audits. We run @axe-core/react in development mode so engineers see accessibility findings in the browser console while building features.

We aim to conform to WCAG 2.2 Level AA, with a number of AAA success criteria additionally addressed at the code layer as listed in Section 2(m). We do not currently perform or commission formal third-party accessibility audits, and we do not publish a Voluntary Product Accessibility Template (VPAT®) at this time. Our conformance claim is based on internal testing using the automated and manual methods described in Section 2.

Because formal third-party verification has not been performed, we make no claim of full WCAG 2.2 Level AAA conformance. Specific AAA criteria addressed are documented above; criteria not listed in Section 2(m) should be assumed unverified at AAA.

If you encounter content that does not meet the WCAG 2.2 Level AA target — or any of the AAA criteria listed in Section 2(m) — please report it using the contact information in Section 5. We treat accessibility defects as first-class bugs and prioritize them alongside other engineering work.

If you require an accommodation to access or use any part of WebGrowly's website or platform, please email us at accessibility@webgrowly.com with the subject line "Accessibility Accommodation".

We will use commercially reasonable efforts to acknowledge your request and respond with a proposed accommodation or alternative workflow on a timely basis appropriate to the nature of the request. Reasonable accommodations may include, without limitation:

• Guided walkthroughs by WebGrowly personnel via voice or video call
• Alternative configurations or modified workflows for specific features
• Provision of information in a screen-reader-friendly or plain-text format
• Extended timelines on time-sensitive workflows where accessibility barriers have delayed completion

We welcome your feedback on the accessibility of WebGrowly. Please let us know about any accessibility barriers you encounter so we can investigate and address them.

WebGrowly LLC Attn: Accessibility 407 Lincoln Rd, Ste 6H, PMB 529 Miami Beach, FL 33139, United States Email: accessibility@webgrowly.com

To reduce handling time, please submit accessibility feedback by email with the subject line "Accessibility Feedback" and include (a) the URL of the page where you encountered the issue, (b) a description of the barrier, and (c) the assistive technology, browser, and operating system you were using, if known.

We may update this Accessibility Statement from time to time to reflect changes to our accessibility practices, the Service, or applicable law. When we make a material change, we will update the Last Updated date at the top of this statement. Continued use of the Service after an update constitutes acknowledgement of the updated statement.