Accessibility Statement

cohero, operated by Fenkil Technologies LTD, aims to make supporting personal dreams accessible to people with disabilities. Our goal is that Dreamers and Backers can understand the service, navigate its features and make their own decisions without unnecessary barriers. Accessibility is part of product quality, not a separate privilege that a user must purchase.

This Accessibility Statement describes the standard we target, the practices we use, areas that need particular care and how to request assistance. It covers our interface on phones and computers, including dream discovery, account management, messaging, milestone proof and payment-related journeys within our control. Content uploaded by users and checkout operated by our payment partner can introduce limitations that require additional work or another format.

We do not represent this statement as an independent certification, a completed audit report or a guarantee that every page already conforms in every combination of browser and assistive technology. We welcome specific reports so that we can investigate actual barriers rather than rely only on general commitments. If you cannot complete a task, contact hello@coheroapp.com and describe the outcome you were trying to achieve.

An accessibility request does not reduce your rights under applicable law or require you to disclose a diagnosis. We ask about functional needs and the affected interaction, not for medical evidence as a routine condition of help. We seek a practical resolution that respects your privacy, autonomy and ability to make your own financial choices.

We target the Web Content Accessibility Guidelines version 2.2 at Level AA, commonly abbreviated WCAG 2.2 AA. These guidelines organise accessibility around content that is perceivable, operable, understandable and robust. They address matters such as text alternatives, keyboard access, contrast, focus visibility, error identification and compatibility with assistive technology.

Targeting WCAG 2.2 AA means using its Level A and Level AA success criteria as a design and evaluation reference. It does not mean that an automated checker can certify the whole service, that every uploaded document meets the standard, or that a third-party checkout is fully controlled by us. Where we identify a gap, we assess its effect on real tasks and work toward remediation.

We also consider usability beyond a checklist, including fatigue, cognitive load, language comprehension and the difficulty of correcting an accidental action. A technically labelled control may still be confusing, and a keyboard-accessible flow may still contain too many steps. Reports describing these practical problems are valuable even if the reporter cannot identify a particular guideline.

This statement is an explanation of our approach rather than an agreement to waive any accessibility duty. Applicable legal requirements may differ by jurisdiction and remain in force independently of the standard we target. Nothing here limits mandatory consumer protections or your ability to contact an appropriate authority about discrimination or access.

We use semantic page structure so that headings, navigation areas, main content and controls can be understood without relying on visual placement alone. Headings should describe the topic that follows and follow a meaningful hierarchy. A screen-reader user should be able to scan the structure rather than listen to every line to locate dream details or account controls.

Interactive elements should expose their role and purpose through appropriate native elements or accessible semantics. A button should behave as an action and a link should identify a destination; a decorative container should not be the only way to discover an important operation. Where a repeated control appears on multiple dream cards, its accessible context should make clear which dream it affects.

We aim for consistent naming across the interface, particularly for Dreamer, Backer, milestones, proof, messages and account actions. One account can act as both Dreamer and Backer, so navigation should not assume a person has only one role. Important explanations should remain available as text rather than exist only inside an icon, animation or transient visual cue.

We seek to provide clear instructions before a person supplies information, and actionable error messages when a submission cannot proceed. A useful error identifies what needs attention without relying only on a red border or requiring the user to remember an earlier screen. If a page is confusing or an error is not announced, report the page and the action that triggered it.

Core tasks should be operable using a keyboard without requiring precise pointer movements. This includes moving through dream information, opening controls, completing forms, reading messages and reaching profile settings. Navigation should follow a logical sequence that corresponds to the meaning of the page rather than an arbitrary order created by its visual layout.

Focus states should make the currently active control visible in both light and dark mode. Focus should not disappear behind a dialog, sticky panel or overlay, and a person should not become trapped inside a component with no understandable exit. When a dialog opens or closes, focus management should preserve context and help the user continue the task.

• Use the keyboard's standard forward and backward focus navigation to move among interactive controls.
• Use the normal activation keys for the type of control rather than assuming every element responds identically.
• If a menu or dialog captures focus, an understandable dismissal route should allow a return to the underlying task.
• Report a control that cannot be reached, a missing focus indicator or an unexpected jump, including the last control that worked.

We do not prescribe custom key combinations that could conflict with an assistive technology's own commands. Screen-reader browsing modes, keyboard layouts and operating-system settings can change how keystrokes are interpreted. When reporting a problem, explain whether the issue occurs in ordinary keyboard navigation, a screen-reader interaction mode or both.

Dream discovery uses a swipe-oriented presentation, but swiping should not be the only route through dreams. Button alternatives should allow a user to perform the corresponding discovery actions without dragging a card across the screen. This supports keyboard users, switch users and people who find touch gestures painful, imprecise or difficult to coordinate.

A gesture alternative must communicate what the action does rather than merely reproduce an unlabeled arrow. Passing a dream, viewing its details and choosing to back a Dreamer are different actions and should not be confused. Browsing past a dream must not be presented as an agreement to make a payment.

We aim to avoid requiring complex multipoint gestures, tightly timed movements or device motion to perform core account tasks. Touch targets should be usable without demanding fine motor precision, and neighboring actions should not be placed so closely that accidental activation becomes likely. Reports of controls that are difficult to tap are useful even where a keyboard workaround exists.

If a gesture has no usable alternative, contact hello@coheroapp.com with the affected screen and the action you need to complete. We will assess whether a button, a simpler interaction or assistance can provide equivalent access. Assistance must not require you to disclose a password or permit another person to make a financial decision on your behalf.

We consider text and interface contrast in both light and dark mode. Information should not depend only on color: a milestone status, error or approval needs a readable label or other meaningful cue as well as any colored styling. Uploaded images and documents can have their own contrast problems, which we address through creator guidance and requests for alternative descriptions.

The WCAG AA reference includes a contrast ratio of at least 4.5 to 1 for ordinary text and at least 3 to 1 for qualifying large text, subject to the standard's exceptions. Non-text interface components and meaningful graphical indicators also require adequate contrast under the applicable criteria. These are evaluation targets, not a statement that every user-supplied image has been verified against them.

The interface should support browser text resizing and zoom without concealing essential information or disabling controls. We consider readability at text enlargement up to 200 percent and reflow at narrow effective widths, subject to content that genuinely requires a two-dimensional layout. A person should not have to reduce text to an uncomfortable size merely to reach a confirmation button.

Responsive presentation should preserve reading order when a screen changes size or orientation. If zoom causes text to overlap, truncates a payment explanation or hides the only way to close a dialog, that is an access issue worth reporting. Include the approximate zoom or text-size setting and the affected page, without sending private account content.

Form fields and controls should have accessible names that communicate their purpose to screen readers and other assistive technologies. Placeholder text alone is not a dependable replacement for a persistent label. Where additional instructions are needed, they should be associated with the relevant control rather than located only in an unrelated block of text.

Meaningful images need useful text alternatives, while purely decorative imagery should not distract from the reading experience. Accessible names should not be a string of unrelated keywords or repeat the surrounding paragraph unnecessarily. For controls built around icons, the name should describe the action, such as opening messages, rather than simply describe the icon's shape.

Real-time messaging, read receipts, typing indicators and account notifications require careful handling because unexpected announcements can interrupt reading. Important changes should be made discoverable without overwhelming the user with every minor update. A new message, a failed action and an urgent account-security problem do not necessarily need the same announcement behavior.

Milestone status changes and proof submissions should remain understandable through text rather than animation alone. If an update appears visually but is not available to your assistive technology, report the interaction and whether moving focus or refreshing revealed it. We will investigate the underlying communication barrier rather than assume a refresh is an adequate permanent solution.

We respect reduced-motion preferences when implementing interface motion. Non-essential transitions and animated effects should be reduced or avoided when a device or browser communicates that preference. A swipe-style interface should remain usable through a simpler presentation and button controls rather than depending on animation to explain the result of an action.

Motion can cause discomfort, distraction or difficulty tracking information even when an animation is brief. We seek to avoid unnecessary flashing, unexpected movement and effects that obscure the current focus. Meaningful state changes should also be expressed in text so that reducing animation does not remove important feedback.

User-uploaded media may contain motion or other sensory effects outside the design of the interface. Dreamers should avoid flashing material and provide a clear description of media that may be difficult to view. If a piece of content creates an access or safety concern, use the reporting controls where available or contact hello@coheroapp.com with a reference to the dream.

We do not assume everyone who needs less motion uses the same device setting or can safely preview a video to discover its contents. Tell us if movement remains problematic despite a reduced-motion preference, or if a control needed to stop it is inaccessible. We will consider both an immediate alternative and changes to the presentation.

The interface supports English, Hindi, Arabic, Spanish, French, Portuguese and Chinese. Language choice should be available through understandable controls, and the selected language should be communicated appropriately to assistive technologies. Correct language information matters for pronunciation, word boundaries and the interpretation of page structure.

Arabic requires a right-to-left layout rather than simply translated words in an otherwise unchanged interface. We consider reading order, alignment, placement of controls and the handling of mixed-direction content such as numbers and links. The visual order and the order available to assistive technology should remain coherent when Arabic appears alongside other scripts.

Translations can introduce longer labels, line wrapping and different navigation needs. We consider these effects in responsive layouts and encourage reports of clipped text, ambiguous labels or incorrect reading direction. A translation may be linguistically understandable while still causing a technical accessibility problem, so both aspects deserve review.

User content may be in a language different from the surrounding interface, and we cannot promise an automatic accurate translation or a particular screen-reader pronunciation for every upload. Ask for help if this prevents access to essential information. The English policy version prevails in case of conflict, subject to mandatory law; that rule does not remove our commitment to understandable access in the supported languages.

We design for current, maintained browsers on phones and computers and for the accessibility features available through their operating systems. Relevant technologies include screen readers, keyboard-only navigation, screen magnification, voice input, switch access, text enlargement, high-contrast settings and reduced-motion preferences. Compatibility is assessed through actual task behavior rather than a claim that every possible combination is identical.

A browser and assistive technology work together, and support for a feature can differ between combinations or versions. We do not publish a blanket certification for every browser, screen reader, device or extension, or claim a completed test of a particular combination where one has not been established. If your usual environment does not work, please report it rather than assume it is outside our responsibility.

• For screen-reader issues, identify the screen reader, browser and device type if you are comfortable doing so, together with the control or announcement that failed.
• For keyboard or switch issues, describe the sequence that led to the barrier and whether focus was visible.
• For magnification or contrast issues, describe the relevant display setting, selected theme and approximate viewport size.
• For voice-input issues, identify the visible control label and whether the spoken command selected the intended control.

Using an updated browser can improve security and accessibility support, but an update recommendation is not a substitute for investigating a reproducible problem. Extensions and device policies may affect behavior; we can ask about them without requiring broad removal of privacy or security protections. We will seek an accessible route that preserves the safety of your account.

The main areas requiring particular attention are user-uploaded media and proof, dynamic chat and notification updates, swipe-oriented discovery and our payment partner's checkout. These areas can create barriers even when the surrounding page has accessible labels and structure. This statement identifies risk areas and limits of control rather than asserting that a particular unresolved defect has been independently verified.

Uploaded images may lack descriptions, videos may lack captions and documents may be scans with no readable text. We encourage Dreamers to supply alternatives and can help request an accessible explanation, but we cannot truthfully guarantee that every existing upload meets WCAG. A person's need for accessible proof should not be dismissed merely because another Backer can view the original image.

Checkout controls operated by our payment partner may have behavior we cannot directly change. We can investigate the handoff, communicate a barrier and seek an alternative supported route, but cannot promise a specific correction date for another operator's system. Do not send payment-card details by email or ask support to enter sensitive credentials as a workaround.

We prioritise barriers that block authentication, account safety, essential financial decisions or access to core information. We then consider severity, frequency, availability of an equivalent alternative and the number of affected journeys. A temporary workaround does not automatically close the underlying issue, and we avoid presenting inaccessible content as resolved merely because someone can ask another person to read it.

Dreamers should make their dream understandable without relying on a photograph, color or spoken narration alone. Explain the goal, planned milestones and relevant context in ordinary text, using short paragraphs and descriptive headings where the editor allows them. Avoid placing the only explanation of a milestone inside a poster or screenshot.

• Provide useful alternative text or an adjacent written description for meaningful images. Describe the information needed to understand the dream rather than every visual detail.
• For video, provide accurate captions for speech and relevant sounds, and a transcript or written summary where needed. Check automated text before relying on it, especially for names, amounts and dates.
• For proof documents, prefer selectable, readable text over an image-only scan. If a scan is necessary, add a typed explanation of the relevant facts and do not rely on optical text recognition being available to every Backer.
• Use readable type, adequate contrast and clear language. Do not communicate completion solely through a colored mark, and avoid flashing visuals or unnecessary animation.
• Remove unnecessary identity, medical, financial and third-party information before uploading. An accessible description should not disclose sensitive data that the original proof did not need to reveal.

Alternative text should describe the image's role in the dream, while proof descriptions should explain what was completed and how the material supports it. A useful description might identify the completed work and relevant date without copying an unrelated document number. Accessibility is not permission to alter evidence, exaggerate progress or conceal a material fact.

Every dream is reviewed before publication, but that review is not a guarantee that every media item has a complete accessibility assessment. The Dreamer Rules and Community Guidelines continue to apply to descriptions, captions and updates. If you receive an accessibility request from a Backer, respond respectfully and provide an equivalent explanation without demanding medical details.

Our evaluation approach combines automated checks with manual review of real user journeys. Automated checks can help identify missing labels, some contrast failures and structural issues, but cannot determine whether a proof description is meaningful or a financial explanation is understandable. Manual testing is necessary for keyboard flow, focus management, announcements and usable alternatives to gestures.

Relevant journeys include browsing a dream, opening details, preparing a draft, using account settings, messaging, reading proof and understanding a milestone decision. Review should include light and dark mode, narrow screens, enlarged text, reduced motion and right-to-left presentation. A page that works only in its default language and display setting has not been adequately considered for the range of supported use.

When a report is reproducible, we aim to record the affected interaction, expected behavior, observed barrier and a way to check a correction. Changes should be reviewed for regressions in nearby tasks rather than assessed only on the modified component. A fix to a dialog's keyboard behavior, for example, should not remove its accessible name or hide its confirmation text.

We do not claim a particular audit frequency, external certification, disability-user testing panel or completed coverage percentage without evidence. Our process is intended to improve over time, and feedback helps identify gaps that internal checks miss. We assess a reported barrier on its impact even when an automated tool reports no error.

Contact hello@coheroapp.com to report a barrier or request information in an accessible format. Identify the page, dream or document and explain the task you could not complete. If possible, include the browser, device, assistive technology and a short sequence of steps, but do not delay asking for help because you do not know technical names.

You may request a plain-text explanation, a readable version of essential instructions, a description of relevant visual material or another format that meets your needs. Tell us your preferred format and which information is essential to your task. We will discuss a workable option when the exact format requested is not available, rather than assume a screenshot or image-based document is equivalent.

Do not send passwords, session tokens, full card details or unnecessary medical information. If a screenshot or recording helps, remove private messages, identities and unrelated proof where possible. We handle the personal information needed for assistance under the Privacy Policy and may ask proportionate account-verification questions when a request concerns private material.

We can help explain a process, locate information or investigate an inaccessible control, but we cannot make a backing or milestone decision for you. Backings are voluntary gifts, and released milestone money is final under the Backing & Gift Policy. An accessible alternative must preserve your informed choice and must not require you to share your account with support or another user.

We aim to acknowledge accessibility requests promptly and provide an initial substantive response within a reasonable time based on the issue's urgency and complexity. This is a service objective, not a guaranteed deadline or a statement that every defect can be corrected immediately. We will explain when investigation or coordination with a Dreamer or payment partner needs additional time.

Tell us clearly if a barrier affects a deadline, account security, a pending payment or a milestone review. A Backer normally has 14 days after proof submission to release a milestone; if no release occurs, the relevant unreleased amounts are returned under the Backing & Gift Policy, with the 15% platform fee retained. An accessibility report does not itself pause that period or change transaction rules, so contact us as early as possible.

For an issue we cannot resolve immediately, we aim to explain an available interim route, what remains under investigation and when a further update can reasonably be expected. Remediation timing depends on the severity, the affected component and any external dependency. We will not promise a universal repair period that could mislead someone deciding whether they can safely complete a task.

If you do not receive a response, send a follow-up to hello@coheroapp.com with a reference to your earlier message and indicate whether the issue has become urgent. You need not repeat sensitive information already provided. Any mandatory statutory response period applies independently of these service expectations, and nothing here extends a legal deadline for handling a request.

If our response does not resolve your concern, reply to hello@coheroapp.com and ask for further review of the accessibility issue. Explain the remaining barrier, why a suggested alternative is not equivalent and what outcome would enable you to complete the task. We will reconsider the issue in light of that information and communicate limitations honestly rather than require you to accept an ineffective workaround.

You may have the right to complain to a competent accessibility, equality, consumer-protection or other public authority, or seek an available legal remedy under the law that applies to you. The appropriate route depends on your circumstances and jurisdiction; we do not invent a regulator or require internal review before you exercise a mandatory right. You may ask us for information about the service needed to describe your complaint.

Fenkil Technologies LTD is responsible for this statement and the accessibility approach of cohero. We may update it as the product, standards or known limitations change, with advance in-app or email notice of material policy changes. Continued use after a notified change takes effect constitutes acceptance to the extent permitted by law, without waiving non-excludable rights.

For accessibility feedback, format requests, unresolved barriers or questions about this statement, contact hello@coheroapp.com. The Privacy Policy explains handling of support information, and the Terms of Service, Dreamer Rules and Backing & Gift Policy explain the underlying service and decisions. We aim to make those explanations accessible as well as accurate, and welcome reports when the policy pages themselves create a barrier.