Question
Workflow Builder custom steps keyboard accessibility limits
Rey Moss
0 reputation · 01 Jan 2026, 05:07 UTC
24.2K views1
Loading…
0 reputation · 01 Jan 2026, 05:07 UTC
The goal is to define consistent accessibility expectations for custom steps in Slack Workflow Builder that are exposed to end users in messaging, canvases and workflow builder surfaces.
Slack documents web app conformance with keyboard navigation, visible focus indicators and ARIA labeling for core channels, messages and threads. Desktop accessibility is mediated through native OS accessibility APIs, so screen reader behavior differs across platforms. Mobile apps rely on iOS VoiceOver and Android TalkBack, with support varying for newer surfaces such as huddles, canvases and workflow builder steps. Plan tier affects availability of canvases and workflow builder.
Custom app modals and Workflow Builder steps are reported to exhibit inconsistent keyboard traps and missing accessible names. There is an unresolved decision on whether custom steps must meet WCAG 2.1 AA for keyboard-only operation and how that requirement is enforced across web, desktop and mobile.
Does Slack publish a documented requirement for custom Workflow Builder steps to be keyboard operable and to provide accessible names? How is responsibility for keyboard traps in custom app modals defined between Slack and app builders? Are support boundaries for screen reader announcements of custom steps documented per platform?
29275 reputation · 01 Jan 2026, 15:40 UTC
Slack does not currently publish a granular, public-facing technical specification that mandates WCAG 2.1 AA compliance specifically for the internal logic of custom Workflow Builder steps. While Slack maintains general conformance for its core web application—including visible focus indicators and ARIA labeling for channels and threads—the accessibility of custom-built app components is largely delegated to the developer.
The responsibility for preventing keyboard traps in custom app modals is shared, but the primary burden of implementation lies with the app builder. Slack provides the framework (the modal container), but the interactive components and input fields defined by the developer determine the tab sequence.
slackTab key and that the Escape key provides a consistent exit path from custom overlays.Support boundaries for screen reader announcements are not documented as a unified standard across platforms because they rely on different underlying technologies:
| Platform | Accessibility Driver | Behavioral Expectation |
|---|---|---|
| Web | Browser DOM / ARIA | Standard Tab-index and ARIA live regions. |
| Desktop | Native OS APIs | Mediated through Slack's wrapper; behavior varies by OS. |
| Mobile | VoiceOver / TalkBack | Linear focus traversal; limited support for complex custom surfaces. |
To ensure a custom step is keyboard operable, perform the following scoped tests:
Tab key. Verify that no element is skipped and that the focus indicator is always visible.Esc.aria-label) rather than relying solely on visual placeholders.Diagnostic Detail Needed: Are the reported keyboard traps occurring within standard Block Kit elements or within a custom-hosted web view (iframe) embedded in the step?
Use comments to ask for clarification. Post a solution as an answer.
29,275 reputation · 01 Jan 2026, 13:46 UTC
To clarify the responsibility split, it is important to note that Slack's Voluntary Product Accessibility Template (VPAT) typically covers core product surfaces—such as channels and threads—but explicitly excludes third-party custom steps from its conformance claims. This means that while the platform provides the container, the legal and technical burden of accessibility for the step's internal content rests entirely with the developer.
Regarding keyboard traps, developers should be aware that while Slack's modal framework manages the top-level focus trap, internal focus order is determined by the Block Kit components used. A common point of failure occurs when developers implement nested overlays or complex custom inputs that override the default tab sequence. To verify this, developers should test focus traversal specifically in the Electron-based desktop app, as the mapping from ARIA attributes to native OS accessibility APIs (like UIA or NSAccessibility) can occasionally differ from standard browser behavior.