Accessibility Statement

Last Updated: July 1, 2026

This Accessibility Statement describes how Sites may approach accessibility for Sites-controlled public website pages, pricing pages, onboarding surfaces, checkout surfaces, Help Center surfaces, dashboard surfaces, support surfaces, and related online surfaces.

This Statement is written for Sites' business-to-business managed website service model. Customer websites, customer-controlled tools, regulated industries, public-sector use cases, international users, and consumer-facing workflows may require additional or different accessibility review, feedback processes, notices, technical testing, or legal review before launch or publication.

1. Scope

1.1 Sites-owned surfaces. This Statement applies to Sites-controlled online surfaces, which may include public website pages, pricing pages, onboarding surfaces, checkout surfaces, Help Center pages, customer dashboard surfaces, support surfaces, forms, and related online service operations.

1.2 Customer websites. If Sites builds, migrates, hosts, supports, or manages a customer's website, accessibility responsibilities for that customer website may depend on the signed customer documents, selected plan, customer-provided content, third-party tools, platform capabilities, customer changes, access status, post-launch edits, regulated or sensitive category, and any separately scoped accessibility work.

1.3 Customer obligations. This Statement does not replace customer-specific accessibility review, customer industry obligations, customer website notices, customer legal or professional review, customer content approval, or customer-specific accessibility analysis.

1.4 Surface separation. Sites-owned public surfaces, Sites checkout, Sites dashboard, Sites Help Center/support, customer-owned websites, customer-controlled accounts, third-party widgets, customer-provided content, PDFs/documents, embedded media, mobile or responsive surfaces, and post-launch customer changes may involve different responsibilities, limitations, and review paths.

1.5 Geography and law scope. Additional federal, state, local, public-sector, procurement, international, sector-specific, public-accommodation, effective-communication, consumer, business-contact, or customer-site requirements may apply depending on user geography, customer geography, customer industry, customer use case, surface type, and tool configuration. This Statement does not decide which accessibility framework applies to every surface or customer website.

2. Accessibility Approach

2.1 Process-based approach. Sites may use accessibility review, technical QA, issue logging, feedback intake, support review, vendor review, and customer-content review as part of its online service operations. Any public accessibility statement should describe only processes actually implemented for the applicable surface.

2.2 Technical references. Sites may use recognized accessibility guidance, including WCAG technical criteria where appropriate, as a technical reference for QA design, issue review, remediation classification, and service records. This Statement does not represent that any particular WCAG version, level, or legal standard applies to every Sites-owned surface or customer website.

2.3 No legal-status statement. This Statement does not promise legal status, identical experience across every device/browser/assistive technology, meeting any accessibility standard, or accessibility of every third-party widget, integration, platform, customer-provided item, or post-launch customer change.

2.4 Customer-specific work. Customer-specific accessibility work is governed by the signed scope and may be classified as included work, Managed Time, Growth Time, add-on work, Exception Path work, customer responsibility, deferred work, vendor dependency, or unsupported work.

2.5 Automated tools and widgets. Sites does not treat AI tools, overlays, widgets, automation, templates, platform settings, scanning tools, or plugins as automatically resolving accessibility issues or establishing any accessibility status for a Sites-owned surface or customer website.

2.6 Claim review. Statements about accessibility process, standards, audit results, remediation, support, response timing, third-party tools, templates, customer websites, case studies, testimonials, screenshots, or outcomes should be supported by appropriate records and claim review before publication.

3. Accessibility Review And QA

Accessibility review may involve, depending on the surface and actual workflow:

• scope review for Sites-owned surfaces, customer websites, templates, components, checkout, dashboard, Help Center, forms, PDFs/documents, media, embedded tools, third-party widgets, and post-launch changes;

• automated checks, with recognition that automated checks may have false positives, false negatives, and coverage limits;

• keyboard-operation checks, including focus visibility, focus not obscured, skip links where applicable, activation by keyboard, and keyboard-trap review;

• screen-reader-oriented checks, including page title, language, headings, landmarks, accessible names, buttons/links, form labels, error messages, status updates, dialogs, and dynamic content;

• visual checks, including color contrast, non-color-only indicators, text resizing/zoom, reflow/responsive layout, target size, spacing, focus states, and reduced-motion behavior;

• form, checkout, dashboard, account, authentication, payment, and support-path checks where those surfaces are in scope;

• media and document checks, including alternative text, decorative-image treatment, captions, transcripts, audio description where relevant, PDFs/documents, menus, downloadable files, and customer-provided media; and

• third-party limitation review for tools, vendors, embeds, customer-controlled accounts, platform limitations, and alternative access paths where applicable.

3.1 No audit overclaim. Automated scans, manual spot checks, template reviews, or QA records do not by themselves prove legal status, complete alignment with an accessibility standard, absence of accessibility issues, or suitability for all users or assistive technologies.

3.2 QA records. Technical QA records may identify the tested surface, test method, accessibility reference used if any, identified issues, limitations, remediation status, and follow-up status.

3.3 Forms, checkout, and authentication. Dashboard, onboarding, account, checkout, payment, contact, booking, and intake forms should be reviewed for labels, instructions, autocomplete, error identification, error suggestions, error-summary or focus handling, status announcements, non-color-only error cues, submission confirmation, password-manager or paste support where applicable, and alternative authentication methods where supported by the platform.

3.4 Release and change review. New or materially changed Sites-controlled surfaces, dashboard flows, checkout flows, customer-site templates, reusable components, forms, authentication flows, or embedded tools may require accessibility review before release depending on severity, affected users, affected surface, available workaround, scope, and third-party or customer dependencies.

4. Customer Content And Customer Responsibilities

4.1 Customer content. Customer-provided content can affect accessibility, including images, videos, PDFs, menus, service descriptions, tables, embedded content, widgets, forms, third-party tools, colors, brand assets, documents, transcripts/captions, account settings, customer instructions, and post-launch edits.

4.2 Customer materials. Customer is responsible for the accuracy, rights, permissions, completeness, and approval of customer-provided content and materials unless a signed scope expressly assigns a task to Sites.

4.3 Customer changes. Post-launch customer changes, third-party changes, platform changes, embedded tools, content updates, plugin/widget updates, account changes, removed access, or dashboard changes can affect accessibility and may require separate review or remediation.

4.4 Regulated, sensitive, public-sector, and international categories. Health, wellness, medspa, dental, medical, legal, accounting, financial, real estate, education, child-directed, employment/recruiting, housing, insurance, government/public-sector, public-benefit, e-commerce, non-U.S., and other regulated or sensitive customers may require extra review for customer content, claims, forms, intake, accessibility, privacy, effective communication, public notices, and professional-responsibility issues.

4.5 Customer-site statements. A customer website should not use a Sites-drafted accessibility statement, accessibility claim, accessibility-standard reference, feedback process, or remediation promise unless the customer-specific scope, customer authorization, technical review, professional review, and publication record support that use.

5. Third-Party Tools, Platforms, And Integrations

5.1 Third-party dependencies. Sites websites and customer websites may rely on website platforms, checkout or billing portals, forms, booking tools, CRM tools, maps, menus, ordering tools, payment processors, analytics, pixels, embedded media, widgets, scripts, chat/support tools, customer accounts, AI tools, and other third-party platforms.

5.2 Limits. Third-party platforms and widgets have their own code, settings, accessibility behavior, update cycles, support practices, policies, and limitations. Sites may not control or remediate every third-party accessibility issue.

5.3 Review classification. Third-party accessibility issues may be classified as included remediation, Managed Time, Growth Time, add-on work, Exception Path work, customer responsibility, vendor dependency, deferred work, or unsupported work.

5.4 Platform and widget records. Third-party platform, widget, integration, embedded-media, form, map, menu, booking, payment, analytics, dashboard, AI, chat/support, or script issues may be recorded with the affected tool/vendor, surface, issue description, data or access implications, Sites-control status, customer-control status, vendor-ticket status if any, workaround status, remediation classification, and customer communication status.

5.5 Payment and checkout accessibility. If an accessibility issue affects checkout, invoices, billing portal, saved payment method, cancellation, account access, default notice response, refund/credit request, or support communication, the issue should be routed through the applicable payment, default, support, legal, and accounting review path before any customer notice or action relies on the affected surface.

6. Feedback And Assistance

6.1 Contact. Accessibility feedback or assistance requests may be submitted to the contact method listed on the Sites website or through another monitored accessibility/support intake channel identified by Sites.

6.2 Optional feedback information. To help Sites review a reported issue, feedback may include the page URL or dashboard location, description of the issue, device, browser, assistive technology used if the reporter chooses to share it, steps to reproduce, screenshot or recording if available, and whether the issue involves customer-provided content or a third-party tool.

6.3 No required disability disclosure. A feedback process should not require a person to disclose a disability, medical condition, assistive-technology use, screenshot, or recording in order to submit accessibility feedback.

6.4 Privacy and security handling. Accessibility feedback may include disability-related details, assistive-technology details, screenshots, recordings, account information, support content, customer-site visitor information, payment screens, health/financial/legal context, or other sensitive information. Intake, retention, escalation, and response records should follow the Privacy Policy, Cookie Policy, and applicable incident/support workflows.

6.5 Triage. Accessibility feedback may be reviewed through the then-current support process. Any response, recordkeeping, owner assignment, classification, or remediation path depends on the affected surface, signed scope, available information, customer-controlled content, and third-party/vendor dependencies.

6.6 Possible response paths. Depending on the issue, Sites may fix the issue, classify it for remediation, request more information, provide a feasible accessible alternative path while triage is pending where appropriate, refer it to a third-party vendor, classify it as customer responsibility, propose a scope change, escalate to legal/privacy/security/payment review, or document why it cannot be remediated within the current scope.

6.7 No response-time promise. This Statement does not promise a specific response time, remediation time, alternate-format delivery time, support availability, or escalation process unless Sites separately publishes or agrees to a specific workflow for the applicable surface.

6.8 No assured outcome. Feedback intake, triage, or remediation classification does not mean that every issue can be fixed, fixed immediately, fixed without customer input, fixed without third-party/vendor action, fixed within the current plan/scope, or resolved through a particular outcome.

7. Remediation Classification

Accessibility issues may be classified based on scope, control, severity, affected surface, customer responsibility, vendor dependency, support impact, payment impact, privacy/security impact, and available remediation path.

Potential classifications may include in-scope correction, Managed Time, Growth Time, add-on or Exception Path work, customer responsibility, third-party or vendor dependency, privacy/security/payment escalation, deferred work, or unsupported work.

7.1 Service categories only. Remediation classifications are service categories only. They do not decide legal responsibility, waive accessibility obligations, alter signed contract duties, or authorize publication of a customer responsibility allocation without legal review.

8. Claims, Marketing, And Public Statement Controls

8.1 Accessibility claims. Public language about Sites, a Sites-owned surface, a customer website, a template, a widget, an AI tool, or an automated scan should not state or imply an accessibility legal status, accessibility-standard alignment, universal usability, automated resolution, or continuous accessibility unless exact wording, evidence, technical audit scope, and legal/claims review support that statement.

8.2 Process-only claims. Accessibility statements should be framed as process, scope, and review concepts unless professional review supports stronger wording. Examples include technical QA process, issue logging, feedback intake, review of in-scope items, third-party limitation tracking, and customer-content responsibility records.

8.3 Customer marketing. Sites must not use customer names, logos, testimonials, case studies, screenshots, project descriptions, analytics/results, accessibility scores, audit findings, issue counts, remediation outcomes, dashboard data, payment/support data, or customer-site examples for public marketing unless the use has a customer permission/publication record, evidence/claim review, and privacy/sensitive-data review.

8.4 Reviews and endorsements. Accessibility-related reviews, testimonials, badges, certifications, audit references, third-party articles, partner statements, or endorsements require claim-substantiation and material-connection review before public use.

8.5 Help Center and sales scripts. Help Center articles, onboarding text, sales emails, proposals, dashboard messages, support macros, and customer-site explanations should not expand signed service scope, create legal/accessibility promises, or imply a professional accessibility audit unless the signed scope and professional review support the exact wording.

9. Records, Retention, And Requests

9.1 Accessibility records. Sites may maintain accessibility records related to feedback, technical QA, issue reports, customer-site questions, support tickets, third-party limitations, vendor communications, service impacts, release reviews, and remediation classifications.

9.2 Record contents. Accessibility records may identify the affected surface, Sites-owned versus customer-site classification, issue description, optional technical context, customer-provided content status, third-party component status, privacy/security/payment/support impact, classification, action taken, communications, escalation status, and follow-up status.

9.3 Audit and release records. Accessibility records may address tested surfaces, test methods, limitations, unresolved issues, release status where applicable, and relationship to the applicable statement version.

9.4 Retention and deletion. Accessibility records, feedback records, screenshots/recordings, support tickets, customer-site records, and evidence records may include sensitive personal information. Retention, deletion, access, export, and redaction should be handled under applicable privacy/security/legal review and related request workflows.

9.5 Offboarding and loss of Sites control. At customer offboarding or loss of Sites control, Sites may create an accessibility handoff record addressing known open issues, customer-responsibility items, third-party/vendor dependencies, content needing accessibility support, dashboard or form limitations, access/account changes, and the date Sites control ended.

10. Relationship To Other Documents

10.1 Signed documents. Customer service scope, customer responsibilities, accessibility-related service boundaries, support limits, Managed Time, Growth Time, add-ons, and Exception Path work are governed by the applicable signed customer documents.

10.2 Website Terms. Website Terms may govern use of Sites public website, dashboard, onboarding, Help Center, and online surfaces.

10.3 Privacy and Cookie Policies. The Privacy Policy and Cookie Policy may address privacy, cookies, tracking, data collection, vendors, analytics, feedback intake, support data, screenshots/recordings, and incident handling.

10.4 Payment, default, and transfer documents. If accessibility affects checkout, billing portal, invoices, saved payment method, default response, support communication, account access, cancellation, refund/credit request, or ownership transfer, the issue should be routed through the applicable payment/default/transfer review workflow before any customer notice or action relies on an inaccessible surface.

10.5 Order of control. If this Statement conflicts with signed customer documents or another applicable final policy, the signed customer documents or other applicable final policy should control for the applicable scope and version.

11. Changes To This Statement

Sites may update this Statement to reflect accessibility processes, service scope, support workflow, feedback process, platform changes, vendor changes, technical QA, changes in law, or service practices.

12. Contact

Questions about this Statement or accessibility feedback may be sent through the contact method listed on the Sites website.