Skip to document
CoulLegal & trust
Policy libraryData rightsTrustResearch
Log inStart free

Inclusive access

Accessibility Statement

Coul's current accessibility target, verified features, known barriers, planned accommodation process, regional context, and remediation launch gates.

Effective July 18, 202620 min readUpdated July 18, 2026
At a glance

Plain-language summary

Coul is working toward WCAG 2.2 Level AA for customer-facing web experiences. That is a design and remediation target—not a certification or a claim that every page, workflow, file, template, output, integration, or third-party surface currently conforms.

  • Coul has not completed an independent, product-wide WCAG 2.2 conformance audit and does not claim full conformance.
  • Known limitations affect the node canvas, calendar dragging, charts, autoplay media, some dialogs, and generated or user-provided content.
  • A monitored accessibility intake and tracked accommodation process must be activated before Coul publishes a contact or response-time promise.
This summary helps with navigation. The full document below controls.

On this page

  1. 01Commitment and scope
  2. 02Target standard and current status
  3. 03Accessibility features currently present
  4. 04Known limitations
  5. 05Node canvas and workflow authoring
  6. 06Calendar, scheduling, analytics, and charts
  7. 07Media, AI editing, and accessible authoring
  8. 08Keyboard, focus, pointer, and input
  9. 09Visual, cognitive, and language access
  10. 10Testing and assistive-technology status
  11. 11Third-party services and customer content
  12. 12Requesting help, an accommodation, or an alternative format
  13. 13How requests should be handled
  14. 14Privacy and accessibility request records
  15. 15Escalation, complaints, and non-retaliation
  16. 16United States context
  17. 17European Union context
  18. 18United Kingdom and other regions
  19. 19Assessment and update history
  20. 20Accessibility launch gates
01

Commitment and scope

Coul intends people with disabilities to be able to discover the Service, create and manage an account, analyze and edit their own content, use planning and publishing tools, understand analytics, manage billing and privacy choices, and obtain support without avoidable barriers. Disability can be permanent, temporary, situational, apparent, or non-apparent, and accessibility work must consider visual, auditory, mobility, speech, cognitive, learning, neurological, and multiple disabilities.

This statement covers customer-facing web experiences Coul controls, including the public website, research and policy pages, authentication and onboarding, the signed-in application, and Coul-created exports or documentation where applicable. A factual scope description is not a disclaimer from duties that apply to a connected flow, third-party component, customer template, or content Coul selects, configures, remediates, or provides.

The statement describes the reviewed source as of the updated date. A semantic element, utility file, automated check, design-system rule, or accessible policy page does not prove that every deployed page or complete customer process conforms. Coul must update this statement when testing, product behavior, standards, legal scope, or material barriers change.

02

Target standard and current status

Coul is working toward the Web Content Accessibility Guidelines 2.2 at Level AA for customer-facing web experiences. WCAG organizes accessibility under perceivable, operable, understandable, and robust principles and evaluates full pages and complete processes—not isolated components alone.

Coul has not completed an independent, product-wide WCAG 2.2 conformance audit, disabled-user research program, screen-reader and browser compatibility matrix, Voluntary Product Accessibility Template, Accessibility Conformance Report, or equivalent certification. Coul therefore does not claim that the Service is fully accessible, WCAG 2.2 AA compliant or certified, universally keyboard accessible, or compatible with every assistive technology.

WCAG is a technical target, not a universal legal safe harbor. A page that meets a technical criterion can still create an unequal experience, and a legal duty can require an effective adjustment or alternative beyond a checklist. Applicable obligations depend on the service, customer, contract, jurisdiction, and facts.

Target, not certification

No Coul badge, score, code utility, or automated scan should be read as a product-wide WCAG 2.2 AA conformance claim.

Official sourcesW3C Web Content Accessibility Guidelines 2.2 (opens in a new tab)
03

Accessibility features currently present

Selected Coul surfaces include semantic headings and landmarks, descriptive page titles, keyboard-operable links and buttons, visible focus styles, labeled form controls, programmatic error states, status announcements, decorative-image hiding, reduced-motion handling, and responsive layouts. Coverage varies by feature and must not be generalized to the entire product.

The shared legal-page system includes a skip link, structured headings and navigation, current-location states, descriptive external-link behavior, focus-visible styling, at least 44-pixel navigation targets, reduced-motion and reduced-transparency handling, increased-contrast support, forced-colors treatment, and a print layout. Public landing, research, and application-shell surfaces include a visible-on-focus skip route to primary content.

Authentication and sign-up forms use visible labels and connect many validation messages to their fields. Cookie choices expose named controls, an equally prominent reject path, and a modal dialog. These examples are surface-specific and do not establish that every form, dialog, toast, table, chart, editor, or generated asset has equivalent support.

04

Known limitations

The reviewed product has material barriers that prevent a product-wide conformance claim. Coul is publishing them so customers can assess current fit and so remediation can be tracked rather than hidden behind a general commitment.

  • The visual node canvas relies substantially on pointer selection, dragging, and visual connections and does not yet provide a complete keyboard or nonvisual outline equivalent.

  • Calendar rescheduling relies on drag-and-drop in important paths and does not yet expose a verified complete keyboard alternative.

  • Interactive charts do not consistently include an accessible chart name, plain-language takeaway, structured data table, or non-color-dependent equivalent.

  • A public preview can autoplay and loop without a user-facing pause control, and reduced-motion behavior has not been verified for every moving surface.

  • Some custom dialogs have not been verified for initial focus, focus containment, Escape handling, inert background behavior, and focus restoration.

  • Captions, transcripts, audio description, alt text, reading order, document tagging, and accessibility metadata are not guaranteed for every upload, AI output, template, export, or connected-platform post.

No hidden workaround claim

Coul does not claim that asking another person to operate an inaccessible control is an equivalent alternative. A usable independent path or an effective accommodation must be designed and tested.

05

Node canvas and workflow authoring

The current canvas allows users to arrange content and processing nodes visually. Reviewed nodes are not uniformly keyboard-focusable or operable, a Topic input lacks a verified programmatic label, drag and connection operations rely on pointer behavior, and visual edges do not provide a complete nonvisual relationship model. Screen-reader users and people who cannot perform precise dragging may be unable to create, inspect, reorder, connect, or delete a workflow independently.

Remediation requires visible labels, logical focus order, named node controls, keyboard move/connect/disconnect/delete commands, announced state changes, undo, error recovery, and an outline or list view that exposes every node, port, edge, direction, status, and validation issue without spatial perception. Pointer operation should remain available but cannot be the only path for an essential action.

Coul must test the complete process: create a workflow, add source media, configure nodes, understand connections, run it, review errors, save, share, duplicate, and delete. Passing an isolated button test does not make the workflow accessible.

Official sourcesWCAG 2.2 Understanding Dragging Movements (opens in a new tab)
06

Calendar, scheduling, analytics, and charts

A customer must be able to schedule, move, edit, approve, cancel, and inspect a post without dragging. Coul must provide a complete date, time, destination, timezone, and recurrence editing path; preserve focus after changes; announce results and conflicts; and avoid conveying schedule state through color or position alone.

Analytics must pair each visualization with a descriptive heading, period and units, key takeaway, source and freshness context, and an accessible table or export of the underlying values. Trends, confidence, positive or negative movement, comparison series, hover-only details, and viral-score bands need text or pattern equivalents that do not depend only on color, shape, animation, or pointer hover.

Dense calendar grids and charts must be tested at 200% and 400% zoom, narrow reflow, large text, increased contrast, forced colors, keyboard-only use, and representative screen readers. Horizontal scrolling may be appropriate for a genuine data table but must not hide controls or require two-dimensional scrolling for ordinary reading text.

07

Media, AI editing, and accessible authoring

Coul analyzes and edits video, audio, transcripts, scripts, captions, carousels, stories, and other content. Automated transcripts, captions, alt text, reading order, scene descriptions, flashing-content checks, and accessibility recommendations can be incomplete or wrong. AI output must be presented as a draft for human review, not as proof that the resulting post is accessible.

Coul should prompt creators for meaningful alt text, caption language and speaker identification; support transcript and caption correction; preserve timing, line breaks, accessibility metadata, credits, and disclosures through edits and exports; identify content that needs audio description; and warn before an edit removes or obscures accessibility information. Generated decorative descriptions should not burden assistive-technology users.

Moving, blinking, scrolling, looping, or auto-updating content must provide appropriate pause, stop, hide, or update controls and avoid unsafe flashes. Informative prerecorded media needs accurate alternatives appropriate to its content. Reduced-motion settings should prevent nonessential autoplay or animation without removing necessary information or functionality.

Official sourcesW3C guidance for audio and video media (opens in a new tab)
08

Keyboard, focus, pointer, and input

Every essential action should work with a keyboard alone, with a visible and logical focus order, no keyboard trap, and focus that is not obscured by sticky navigation, banners, dialogs, or toasts. Opening and closing a dialog should move and restore focus predictably; changes of route, view, validation state, upload, generation, publish, deletion, and payment status need appropriate announcements without overwhelming the user.

Coul should not require a complex gesture, precision drag, hover, device motion, path-based movement, or timed multi-pointer action when a simpler alternative can perform the same function. Touch targets, adjacent destructive actions, resize handles, timeline controls, canvas ports, chart points, and calendar handles require particular review across mouse, touch, switch, voice, and keyboard input.

Authentication and security design must also be accessible. Password-manager and paste support, understandable error recovery, sufficient time, reauthentication without lost work, and alternatives to cognitive-function tests must be evaluated without weakening account security.

09

Visual, cognitive, and language access

Text and essential interface graphics need sufficient contrast in default, hover, active, disabled, error, and placeholder states. Focus indicators, selected states, score bands, alerts, chart series, and required fields cannot rely on color alone. Content should reflow without loss at supported zoom and text-spacing settings, and Windows forced-colors mode should retain meaningful boundaries, states, and focus.

Instructions, prediction explanations, pricing, cancellation, privacy choices, errors, and irreversible actions should use direct language, consistent names, predictable placement, and confirmation proportional to risk. Users need enough time to read and act, a warning before expiry where applicable, preserved input after recoverable errors, and protection against accidental publication, deletion, or purchase.

The product language is primarily English in the reviewed source. A translated interface must identify language changes programmatically and receive accessibility testing in that language; machine translation can alter labels, reading order, pronunciation, abbreviations, error meaning, and legal information.

10

Testing and assistive-technology status

The repository contains custom accessibility validation and testing utilities, but reviewed scripts still reference WCAG 2.1 in places and are not wired into a verified accessibility CI gate. There is no evidence of a current product-wide axe audit, complete manual keyboard audit, 400% zoom and reflow audit, color and forced-colors review, or recurring disabled-user test program.

Coul does not publish a list of supported screen-reader, browser, operating-system, speech-input, magnification, switch, or mobile combinations because the required compatibility testing has not been completed. Naming a combination without testing its complete processes could mislead users who depend on it.

Before publishing compatibility claims, Coul should test dated versions of VoiceOver with Safari, NVDA with Firefox or Chrome, keyboard-only flows, mobile screen readers, zoom and text spacing, reduced motion, increased contrast and forced colors, and any combinations materially used by customers. Automated rules can find some failures; human evaluation and testing with disabled people remain necessary.

11

Third-party services and customer content

Coul connects to social networks, payment and OAuth providers, AI vendors, public-profile sources, embeds, fonts, storage, and other services. Customers also upload media and publish or share templates. These sources can introduce barriers Coul did not author, but their involvement does not automatically remove Coul's responsibility for selection, configuration, labeling, integration, complaint handling, or an effective alternative where required.

When a third-party step blocks access, Coul should document the barrier, offer an equivalent Coul-controlled route where possible, escalate to the provider, preserve the customer's place and data, and avoid charging extra for a required accommodation. If no immediate equivalent exists, Coul should explain the limitation candidly and provide a next update rather than claiming the external surface is simply outside scope.

Template authors and creators remain responsible for reviewing their own captions, transcripts, alt text, contrast, reading order, flashing content, instructions, and platform disclosures. Coul should provide accessible authoring prompts and preserve metadata; a user-content rule cannot replace accessible product controls or duties that apply to Coul.

12

Requesting help, an accommodation, or an alternative format

Coul must provide an accessible web form and monitored email before launch. A requester should be able to describe the affected page or feature, the task attempted, the barrier, the accommodation or format requested, urgency or an external deadline, and a preferred accessible response method. Browser, device, and assistive-technology details may help diagnosis but must remain optional.

Coul should not require a diagnosis, medical record, government identity document, account login, or disclosure of assistive technology merely to report a digital barrier. Never request a password, social token, payment credential, private key, or unnecessary copy of user content. An authorized representative or support person should be able to assist without displacing the disabled person's preferences or privacy.

Possible responses include accessible HTML or structured text, a tagged document, corrected captions or transcript, a data table, keyboard-assisted completion, a non-drag scheduling path, help completing an account or billing action, or another equally effective method. The right response depends on the request and applicable law; Coul should discuss an effective alternative rather than insist on one format.

Intake is a launch gate

The reviewed repository does not establish a monitored accessibility mailbox, public request form, case owner, or escalation queue. No proposed address is actionable on this page.

13

How requests should be handled

Once intake is operational, Coul should acknowledge a request in the person's preferred accessible method, assign a case identifier and owner, protect any sensitive information, assess immediate access needs, offer a workable interim alternative, investigate the underlying barrier, and provide dated updates until resolution or a reasoned outcome.

Time-sensitive barriers involving account entry, cancellation, billing, a legal or privacy request, an expiring trial, scheduled publication, security, or a fixed external deadline need expedited triage. Coul must not let an inaccessible cancellation or request path extend a charge, erase a statutory deadline, or require the person to accept a less private or materially less effective process.

A future operational target may aim to acknowledge within two business days and provide an initial update or workable alternative within ten business days, with a next-update date for complex remediation. Those are not current guarantees and must not be published as service levels until staffing, holidays, urgent routing, provider dependencies, and measurement have been approved and tested.

14

Privacy and accessibility request records

Accessibility requests can reveal disability, health, communication preferences, assistive technology, employment, deadlines, or private content. Coul should collect the minimum necessary information, separate case records from product analytics and marketing, restrict access, define retention, protect attachments, and explain any provider or international transfer in the Privacy Policy.

A requester should be able to ask for correction or deletion of unnecessary case information subject to applicable exceptions. Diagnostic logs, recordings, screenshots, and uploaded examples require explicit purpose and bounded access; live credentials and unrelated third-party data should be removed. Accessibility information must not be used to profile, advertise to, penalize, or retaliate against a person.

Aggregated barrier trends may guide remediation only when individual identity and sensitive details are not exposed beyond the approved purpose. Coul should retain enough audit evidence to track commitments and recurring defects without keeping a diagnosis or raw customer content indefinitely.

15

Escalation, complaints, and non-retaliation

The operational process should let a requester ask for an accessibility escalation through the same accessible channel, route the review to someone other than the original handler where practical, preserve the case history, reconsider the proposed alternative, and state the next step in an accessible format.

Using Coul's internal process does not waive a person's statutory complaint, regulator, court, contractual, procurement, or consumer-remedy rights; pause a mandatory deadline; require arbitration where applicable law prevents it; or authorize retaliation. Coul's Terms and regional limitations remain subject to non-waivable disability and consumer protections.

Coul must not suspend, downgrade, charge, deprioritize, or expose a user because they request accessibility, use assistive technology, decline unnecessary medical disclosure, help another person, or report a barrier in good faith.

16

United States context

The Americans with Disabilities Act applies to state and local government services and to covered businesses open to the public, while application to a particular private digital service, available remedies, and state-law protections can depend on the service and jurisdiction. Coul does not claim blanket ADA compliance or exemption.

The U.S. Department of Justice's Title II web rule uses WCAG 2.1 Level AA for covered state and local government web and mobile services, subject to its scope, dates, exceptions, and duties. That public-entity rule does not itself certify Coul as a private SaaS product, but it can matter when Coul provides content or functionality for a covered entity or accepts contractual accessibility obligations.

Section 508 and procurement accessibility requirements can apply to federal agencies, contractors, or supplied information and communications technology without making every private service a federal program. State civil-rights, consumer, education, employment, and procurement rules may impose additional duties. Coul must assess the actual customer and transaction rather than publish a universal U.S. conclusion.

Official sourcesU.S. Department of Justice web accessibility guidance (opens in a new tab)U.S. Department of Justice Title II web rule guide (opens in a new tab)
17

European Union context

The European Accessibility Act applies through Member State law to specified products and consumer services made available after June 28, 2025, including covered e-commerce functions such as identification, security, and payment. Whether Coul is in scope depends on verified facts including its legal entity, establishment, markets, consumer offering, service category, national implementing law, and any fact-specific exception.

A service-provider microenterprise exception, fundamental-alteration position, or disproportionate-burden assessment cannot be assumed. Employee and turnover figures, resources, frequency and duration of use, benefits to people with disabilities, contracts, alternatives, and national procedures require documented analysis. Lack of priority, time, or accessibility knowledge is not by itself an adequate assessment.

WCAG 2.2 AA is not identical to EN 301 549. An applicable or procurement-specified version of EN 301 549 can include requirements beyond web content, while harmonized-standard status and legal presumptions depend on the governing instrument and current official publication. Coul does not claim EAA or EN 301 549 conformity without a scoped assessment and required service information.

Official sourcesDirective (EU) 2019/882 — European Accessibility Act (opens in a new tab)European Commission accessibility standards guidance (opens in a new tab)
18

United Kingdom and other regions

In the United Kingdom, service providers can have an anticipatory duty to make reasonable adjustments under the Equality Act 2010. The public-sector website and mobile-app accessibility regime and its statement requirements do not automatically govern Coul as a private service or prove private-sector compliance, but a public-sector customer or contract can create additional requirements.

Other countries and subnational jurisdictions may use WCAG, local standards, equality law, consumer law, electronic-communications rules, procurement terms, or sector-specific duties. This statement is not an exhaustive legal map and does not narrow a mandatory right or adjustment.

Coul must verify where it offers the Service, whether the customer acts as a consumer, business, employer, educator, public body, or regulated organization, and which complete processes are supplied. A regional exception should be documented narrowly and should not become a global product-design ceiling.

Official sourcesUK Equality Act 2010 — services and public functions (opens in a new tab)GOV.UK public-sector website and app accessibility guidance (opens in a new tab)
19

Assessment and update history

This initial statement is based on source review and limited rendered checks of the shared legal-page experience. It is not based on an independent conformance audit or representative disabled-user study. Coul should not present the updated date as an audit date.

A future assessment record should identify the product version and environment, URLs and complete processes tested, WCAG and other standards used, methods and tools, assistive-technology and browser versions, evaluator qualifications, user-research scope, excluded content, known failures, severity, workarounds, owners, remediation dates, retest results, and whether a formal conformance claim is made.

Coul should review this statement after a material redesign, new authoring or publishing workflow, acquisition, accessibility complaint trend, audit, standard or legal change, major third-party integration, or remediation release—and on a recurring approved cadence. Resolved barriers should be retested before removal; newly discovered barriers should be added promptly rather than waiting for a scheduled annual edit.

20

Accessibility launch gates

Coul has selected these risk-based controls as requirements before presenting this statement as evidence of a mature accessibility program. This list does not claim every control is universally required by every law.

  • Activate and verify an accessible request form, monitored contact, case tracking, privacy notice, urgent routing, interim-accommodation authority, internal escalation, ownership, and measured response targets.

  • Complete an inventory of customer-facing pages, components, complete processes, generated assets, documents, third-party steps, supported browsers, and assistive-technology use cases.

  • Remediate the canvas with labeled controls, keyboard operation, announced state, undo, and a nonvisual outline that fully exposes nodes and connections.

  • Provide non-drag scheduling and complete keyboard calendar operation; add accessible chart names, takeaways, tables or exports, units, freshness, and non-color equivalents.

  • Add pause or stop controls for informative autoplay and honor reduced motion; build creator tools to review and preserve captions, transcripts, alt text, audio-description information, reading order, and accessibility metadata.

  • Audit and fix dialog focus, keyboard traps, sticky-content focus obstruction, toasts and live regions, labels and errors, timeouts, authentication, 200% and 400% zoom, reflow, text spacing, contrast, forced colors, target size, and destructive confirmations.

  • Run automated accessibility checks in CI and recurring manual keyboard, zoom, contrast, VoiceOver/Safari, NVDA/browser, mobile screen-reader, and disabled-user testing across complete processes.

  • Verify the Coul legal entity, service markets, consumer and public-sector scope, EAA and national implementation facts, UK and U.S. duties, procurement obligations, and any claimed exception before publishing regional compliance conclusions.

  • Replace inaccessible third-party steps where possible, document provider escalation, and establish an equally effective alternative instead of relying on a blanket third-party disclaimer.

  • Publish only evidence-bounded feature, compatibility, response-time, audit, standards, and conformance statements; assign an owner to update this page when the evidence changes.

Contact

Accessibility request channel not yet active

Before launch, Coul must activate and test an accessible request form and monitored contact, connect both to case tracking and escalation, and publish only response targets the responsible team can meet. Until then, do not rely on an unverified Coul address to request an accommodation or report a barrier.

Accessibility request channel not yet active

Keep reading

Related Coul policies

Terms of ServicePrivacy PolicySecurity/TrustData Rights & Account DeletionUser Content & AI Output Policy

Policy library

  • 01Terms
  • 02Privacy
  • 03AI transparency
  • 04Public data
  • 05Acceptable use
  • 06Content & AI output
  • 07Copyright & DMCA
  • 08Community
  • 09Cookies
  • 10Subscriptions
  • 11Data rights
  • 12Security
  • 13Accessibility
CoulLegal & trust
  • Terms
  • Privacy
  • Cookies
  • Cookie settings
  • Security
  • Accessibility
© 2026 Coul