1. Accessibility Commitment

Loombus aims to make its knowledge, community, communication, discovery, commerce, and support features usable by people with a broad range of visual, auditory, physical, speech, cognitive, neurological, and situational access needs.

Accessibility is an ongoing engineering and content responsibility, not a one-time certification. Loombus is continuing to evaluate new and existing features as the platform expands.

2. Accessibility Standard and Goal

Loombus uses the Web Content Accessibility Guidelines, WCAG 2.2 Level AA, as a reference target for web accessibility work where applicable. This is a development goal and does not claim that every page, state, native component, user upload, PDF, or third-party service currently conforms.

Native iOS and Android experiences are also evaluated against the accessibility capabilities and guidance provided by their operating systems.

3. Page Structure and Navigation

• meaningful headings and logical content order;
• descriptive page titles, links, buttons, labels, and navigation landmarks;
• consistent routes and recognizable interaction patterns where practical;
• skip, focus, or landmark behavior that helps users reach primary content;
• avoiding reliance on color, location, or icon shape as the only way to communicate meaning.

4. Keyboard and Focus Access

Report any control that cannot be reached, activated, exited, or understood using a keyboard or comparable assistive input.

• interactive controls should be reachable and operable without a pointing device;
• focus should remain visible and move in a logical order;
• dialogs, menus, search overlays, dropdowns, composer tools, and forms should manage focus predictably;
• keyboard users should be able to dismiss supported overlays and avoid focus traps;
• timing or hover-only interactions should have an accessible alternative where practical.

5. Screen Readers, Names, and Semantics

• form inputs should have programmatically associated names and instructions;
• icons that convey no additional meaning should be hidden from assistive technology;
• status, validation, loading, error, notification, and success messages should be announced appropriately where practical;
• tables, lists, headings, regions, buttons, and links should use meaningful semantics;
• dynamic experiences should preserve context when content updates.

6. Contrast, Color, Themes, and Readability

Loombus supports Light, Dark, and System appearance modes. The platform aims to maintain readable text, controls, borders, selected states, error states, and focus indicators across supported themes.

Text should not require color alone to understand status. Members who find a contrast, theme, font, spacing, or selected-state issue should report the exact page, theme, device, and control.

7. Zoom, Reflow, Text Size, and Orientation

• web content should remain usable at supported browser zoom and text enlargement levels;
• mobile layouts should reflow without requiring unnecessary horizontal scrolling for ordinary reading;
• controls should remain large enough to identify and activate where practical;
• content should not be unnecessarily locked to one device orientation;
• important information should not disappear solely because the viewport is narrow or text is enlarged.

8. Motion, Animation, and Time

Loombus aims to avoid unnecessary flashing and to respect reduced-motion preferences where supported. Autoplay is not used for Video Context.

Features that update, dismiss, expire, or move should provide enough time and control for users where the product purpose allows. Report animation, motion, or timing that causes disorientation or prevents completion.

9. Forms, Errors, and Authentication

• required fields, formats, and constraints should be explained clearly;
• errors should identify the affected field and provide a usable correction path;
• authentication and recovery instructions should not rely on memory or inaccessible puzzles where avoidable;
• support, reporting, listing, Room, appointment, event, job, service, request, and marketplace forms should preserve understandable labels and states;
• password, verification, and billing flows may include third-party interfaces with separate accessibility behavior.

10. Search and AI-Assisted Features

Search results, filters, source links, loading states, result counts, no result states, and permission boundaries should be understandable through keyboard and assistive technology.

Ask Loombus AI answers should identify source links where provided and should not require a user to rely on visual layout alone to understand the answer. AI output may still be inaccurate and does not replace accessible access to the original source.

11. Images, Video Context, Audio, and User Media

Loombus provides fields or product patterns for accessible description where supported, but much of the platform’s media is uploaded by users. The member or organization publishing media is responsible for providing accurate captions, transcripts, alt text, descriptions, or equivalent access when needed and available.

Video Context does not autoplay and does not display a public view count. Captions, audio description, transcription, and player accessibility may vary by media, device, browser, operating system, and implementation.

12. PDFs, Documents, Room Files, and Attachments

User-uploaded PDFs, images, documents, forms, flyers, resumes, job materials, marketplace images, and event files may not be accessible even when the surrounding Loombus page is accessible.

Publishers should use selectable text, meaningful reading order, document headings, tagged PDFs, descriptive filenames, alt text, accessible form fields, and an accessible HTML alternative when practical.

13. Local Discovery, Distance, and Location Content

Local Discovery should provide text-based results and filters rather than requiring a visual map alone. Distance, place, remote status, and event date should be available in text where supported.

Business owners, providers, employers, organizers, and sellers should describe entrances, remote access, mobility barriers, sensory conditions, accommodations, and other accessibility information accurately when it is relevant to a listing.

14. Mobile Applications and Device Features

The native applications rely partly on iOS and Android accessibility services, including screen readers, text sizing, display scaling, switch control, voice control, captions, reduced motion, contrast, and device authentication.

A barrier may occur only on a specific app version, operating system, device size, orientation, or permission state. Include these details in an accessibility report.

15. Third-Party Services

Authentication providers, payment processors, app stores, email links, maps, external websites, embedded media, and files can have accessibility limitations outside Loombus’s direct control.

Loombus will consider reasonable alternatives or workarounds when a third-party dependency creates a material barrier, but cannot guarantee changes to an external service.

16. Known and Potential Limitations

• rapidly evolving pages may contain inconsistent labels, focus behavior, contrast, or responsive states;
• user-generated content may lack alt text, captions, transcripts, structure, or plain-language explanation;
• complex visualizations, maps, conversation structures, charts, or AI outputs may need improved nonvisual equivalents;
• private Room files and imported documents may not have been created accessibly;
• third-party checkout, sign-in, maps, app-store, or linked content may behave differently;
• older pages or experimental Labs features may lag behind the current accessibility target.

17. Requesting Assistance or an Accommodation

Contact Loombus when a barrier prevents you from creating an account, accessing content, managing a subscription, using a safety tool, submitting a listing, participating in a Room, contacting a provider, or completing another important action.

Loombus may provide instructions, an alternative support path, a content explanation, or another reasonable response depending on the feature and available resources. A request does not require you to disclose a diagnosis.

18. How to Report an Accessibility Barrier

Submit the report through Loombus Support or email support@loombus.com.

• the exact page, feature, or URL;
• what you were trying to do and what prevented completion;
• device, operating system, browser or app version, and appearance mode;
• assistive technology and version, if you are comfortable sharing it;
• keyboard steps, screen-reader announcement, screenshot, recording, or error text that helps reproduce the issue;
• an accessible way for Loombus to respond to you.

19. Accessibility Feedback Review

Accessibility reports may be logged, reproduced, prioritized, tested, and connected to product changes. Priority can consider whether the barrier blocks account access, safety, legal information, payment management, communication, or a core platform task.

Loombus does not retaliate against a person for making a good-faith accessibility request or reporting a barrier.

Document status

Last reviewed: July 18, 2026

This public explanation describes the current Loombus service and may be updated as features, operational practices, or legal requirements change.