1. Accessibility target
The proposed product standard is WCAG 2.2 Level AA. The interface is designed around semantic headings, accessible names, keyboard operation, visible focus, readable contrast, responsive layouts, and reduced-motion support. This is a target and ongoing engineering process, not a declaration of full conformance or ADA certification.
A policy, automated scan, or accessibility overlay does not establish that every user can complete every task. Assess complete journeys, including authentication, records, documents, maps, communications, and third-party services.
2. Testing and current scope
The repository includes automated accessibility checks for sign-in and selected workspace routes, mobile overflow checks, a keyboard/focus test for the Copilot dialog, and reduced-motion verification. Historical tests filter serious and critical automated findings; that scope is narrower than a full WCAG conformance audit. New legal pages are tested separately.
A comprehensive manual audit with assistive technology has not been completed for the entire deployed product. Conformance depends on the exact release and connected components. The release record must distinguish locally tested pages from independently deployed application pages.
3. Known limitations and remediation
Uploaded PDFs and customer documents may be inaccessible. Third-party sign-in, embedded services, maps, and generated content need their own assessment. Maps must not be the only way to find or act on a property. Audio and video need appropriate accessible alternatives where provided.
Before claiming full conformance, complete keyboard-only and screen-reader reviews, focus and error handling, 200% zoom and 400% reflow, touch target and contrast checks, accessible authentication, and content-alternative testing. Track barriers by severity, assign an owner, and retest fixes. Do not rely on a support channel to justify avoidable barriers.
4. Regional accessibility requirements
For applicable U.S. public accommodations, assess ADA Title III and state law. The ADA Title II web rule governs state and local government services and must not be described as the universal rule for this private SaaS. WCAG is useful technical guidance; legal applicability requires its own assessment.
In Canada, assess the Accessible Canada Act only where the operator or service falls within its federal scope, Québec disability and human-rights duties, and AODA requirements if Ontario operations meet the applicable criteria. In the EU, assess the European Accessibility Act where the offering is a covered consumer service, including any relevant exemptions, rather than assuming every business software subscription is covered.
5. Report a barrier or request assistance
Email support@loomlogic.io with subject “Accessibility request”. Include the page or task, the barrier, browser and assistive technology if relevant, and the best way to contact you. You do not need to disclose a diagnosis. Request an accessible document or an alternative way to complete a task when needed.
The operator must agree and publish response targets before this statement becomes final. If support does not resolve a barrier, ask for escalation. Applicable rights to complain to an accessibility or human-rights authority remain available.
Official references
These sources explain the relevant frameworks. Applicability and implementation must be assessed for the actual service.
Requests and questions: support@loomlogic.io