Accessibility with Block Kit

Accessibility in your apps means ensuring users with disabilities can understand, navigate, and interact with them effectively. And it benefits everyone! Consider that everyone at some point in life will experience a disability, whether it be permanent, temporary, or situational (think "I sat on my glasses and can't quite see today"). Building your apps in an accessible way will make the world a better place.

Here are our tips and recommendations for how to make your apps accessbile while using Block Kit, broken down by color, content, and screen reader considerations.


There are two main rules around the use of color:

  • Use more than just color to convey meaning. Color can enhance and reinforce meaning, but it should not be the only way to convey meaning. Say, for instance, you'd like to have a button to cancel a subscription. A red button that says "cancel" would not be sufficient because "cancel" is used in many contexts that are not a severe action. Instead, the button should read "cancel subscription" to fully convey the meaning of the action.

  • Provide sufficient contrast for text and important visual indicators. The ideal contrast ratio is 4.5:1 for regular text, though we at Slack mostly control this so you don't need to worry about it. However, it's always a good idea to test your apps in both light and dark mode to ensure usability in both.


Here are some general guidelines for content in Slack apps.

Keep content clear and concise. Use short, clear sentences and paragraphs.
Explain abbreviations.
Use jargon, buzzwords, idioms, and slang; be fun but don't alienate anyone.
Use directional and sensory language, including emojis. For example, do not use an arrow to refer to a prior message.

Screen reader considerations

A screen reader is a tool used that helps people who have difficulties seeing with accessing and interacting with digital content. There are several considerations to keep in mind to most effectively work with a screen reader, including emoji use, images, and interactive elements.

Emoji use 😄

Emojis are tied to text aliases, which display on hover and when emojis are turned off. Text aliases also as act as the accessible name for the emoji. A screen reader user will hear “[alias] emoji” when they read an emoji. There is no way to indicate that an emoji is decorative or add an ARIA (Accessible Rich Internet Applications) label to an emoji to describe it better. Also, organizations and end users have the ability to turn off emojis and default to the alias as plain text. Knowing this, here are some tips:

  • Do not use an emoji as a control. Do not use them for field labels or inline help, in a button, or to trigger a workflow. Always pair emojis with text.
  • Always the grand finale. Ideal emoji placement is at the end of a sentence or line; this improves readability.
  • Just a sprinkle. Use emojis sparingly in headers and append them to the end. We recommend using emojis either in the header or the subtext, but not both.
  • Emojis are not word replacements. Ensure they are paired with relevant text.
  • Avoid using emojis as bullet points. You can talk about them in bulleted lists, just don't make them the bullets themselves.


Guidelines regarding images in Slack apps are:

  • Describe your images. Provide clear, context-specific alt_text for all images, and if appropriate, a title too.
  • Save the gallery wall for your stairway. Limit the number of redundant and purely decorative images in your apps. Because each image requires alt_text, and each will be read by a screen reader, the experience could get messy with too many extraneous images.


Keep in mind that users can turn off animated gifs and emojis in their Slack accessibility preferences, so for every informational animation you have, ensure its meaning is conveyed even when paused. Either the freeze frame or the animation's surrounding text should capture the main point. Like images, always include descriptive alt_text.

Don't cause seizures
Do not add more than three large flashes per second in animations. This is a WCAG (Web Content Accessibility Guidelines) standard.


Every chart that an app visually displays needs an accompanying accessible PDF. Include:

  • An image block containing a chart screenshot with brief alt_text, e.g. “chart preview”.
  • A button allowing the user to download the chart as an accessible PDF.
  • An accessible PDF in PDF/UA format containing a properly-tagged table version of the data displayed visually in the chart screenshot.

Interactive elements

Input fields

Do Don't
Wrap inputs in input blocks. Wrap inputs in section or action blocks.
Be a good host and provide associated labels for all input fields, so all users are clear on what information to enter where. Use emojis in input labels.
Use descriptive placeholder text for selects.

Repetitive controls in lists

To ensure the best experience for your users, we recommend you:

  • Give buttons brief, repetitive labels to avoid truncation.
  • Make placeholder text for inputs record-specific where possible.

If you get a little wordy with your button and/or placeholder text such that Block Kit truncates the text, know that a screen reader will still read the entire placeholder text, but the button text will be cut off, so prioritize brevity on those buttons!

Was this page helpful?