Workflow Builder custom steps keyboard accessibility limits

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?