Skip to main content

Blocking Issue: Triggering Flow via API & Accessibility Roadmap Update

Bug Reports

Hi Chatling Team,

We are developing a custom chat frontend using your API v2 to adhere to strict WCAG accessibility standards, as the native widget is not yet compliant.

We are facing two major issues:

1. Technical Blocker (API v2): We are unable to trigger a Flow (Playbook) via the API. Even when sending specific trigger keywords associated with an Intent, the API ignores the Flow logic and returns a generic Knowledge Base response.

  • Question: Is there a specific parameter or method to force the API to bypass the KB and execute a structured Flow?

2. Accessibility Roadmap: We raised the issue regarding the native widget's accessibility a few months ago, and it was added to your roadmap.

  • Question: What is the current ETA for full accessibility support in the native widget?

Looking forward to your quick guidance.

Best regards,

Koby

Posted by koby ·
Status: Completed5 comments

Log in to comment and vote

Comments5

  • Ali Mahdi

    Team•

    Jan 5

    Hi Koby,

    At the moment, it’s not possible to trigger a flow via the API and we don’t plan on implementing this in the API, mainly due to technical constraints.

    As for accessibility, we’re planning to address it soon. Can you please email us your requirements so we can make sure it’s covered when we begin the implementation?

    • koby

      •

      Jan 8

      Hi Ali,

      Thank you for the update regarding the API limitations.

      Since we cannot trigger Flows via the API, we must rely on your native widget. Therefore, full WCAG 2.1 AA Accessibility compliance is critical for us to meet legal requirements.

      Here are the standard accessibility features we require:

      1. Keyboard Navigation:

      • Focus Management: Keyboard focus (Tab key) must be trapped within the widget when open and not drift to the background page.

      • Focus Indicators: All interactive elements (Buttons, Inputs, Quick Replies) must have clearly visible focus rings.

      • Shortcuts: Support for standard keys like Esc to close the widget.

      2. Screen Reader Support (ARIA):

      • Labels: All buttons (Launcher, Send, Close) must have descriptive aria-label attributes.

      • Live Regions: New incoming messages from the bot must be announced automatically using aria-live.

      3. Visual Accessibility:

      • Contrast: Text and UI elements must meet the standard 4.5:1 contrast ratio.

      • Scaling: The widget must remain functional when the browser is zoomed in up to 200%.

      Can you please provide an estimated timeline for these accessibility updates?

      Best regards,

      Koby

      • Ali Mahdi

        Team•

        Jan 9

        Hi Koby, we’re working on it. We’ve completed and released the accessibility implementation for the AI agent widget and are working on the chatbot widget.

        • Ali Mahdi

          Team•

          Jan 14

          Update: we’ve implemented full accessibility for the AI Chatbot widget as well.

          • koby

            •

            Jan 18

            Hi Ali,

            First of all, huge kudos to you and the team for prioritizing this and rolling out the update so quickly! We really appreciate the effort to support inclusivity and make the widget accessible.

            We conducted a QA test on the updated widget to verify WCAG 2.1 AA compliance. While we see great improvements (like proper button labels), we found 4 remaining functional gaps that currently block us from deploying it to production:

            1. Launcher Keyboard Interaction (Critical): While we can navigate to the launcher using Tab, pressing Enter or Space does not open the chat. This effectively locks out keyboard-only users.

            2. Welcome Message Skipped: Upon opening the widget, focus lands directly on the input field. As a result, the Screen Reader skips the Welcome Message/Greeting entirely.

            3. Streaming Causes Stuttering: The text streaming effect (typing visual) causes Screen Readers to cut off or repeat the beginning of sentences due to rapid DOM updates. (Suggestion: Use a hidden container for the full text or manage aria-busy).

            4. Missing Auditory Context:

              • Typing: The 3-dot animation is silent (needs role="status").

              • Speaker ID: Incoming messages are read without context. Users need a hidden prefix (e.g., "Bot says:") to distinguish the bot's reply from their own input.

            Looking forward to a patch for these final items so we can go live!

            Thanks again, Koby